No normal sqa user will have any clue how to do this.
might wanna take this up with the sqlachemy maintainers OR look at sqlachemy tests for how they are testing driver integration.
Some other dialect+driver will do the exact same thing as this jbdc driver.
informix+ifx_jdbc://hostname:port/db_name;INFORMIXSERVER=server_name;delimident=y;user=user;password=pass
becomes
informix+ifx_jdbc://user:pass@hostname:port/db_name?INFORMIXSERVER=server_name&delimident=y
If this is a sqlalchemy engine connect url then it would look like the fixed one.
https://github.com/OpenInformix/IfxPy/blob/master/README.md
This does not appear to support SQLAlchemy. Has a dbapi2 but no official driver+dialect supported by SQLAlchemy.
In which case, why are you bothering? Time would be better spent working on adding SQLAlchemy support than using the dbapi2 directly. In which case the code would be completely non-portable when decide to switch to other driver+dialect
setuptools is for enforcing a cartel, naively can simplify that to for building.
I hope uv completely replaces setuptools and build. Then the maintainers can move on to another racket.
Regular dependencies lack host url and hashes. Those are most important.
For the full details, encourage you to read pep751
^^ look a link! Oh so clickable and tempting. Go ahead. You know that pretty blue font-color is just asking for it. And after clicking the font-color changes colors. Wonder what font-color it’ll become? Hmmmm
i love requirements files, venv, and pyenv.
Bringing requirements into pyproject.toml does not have enough value add to bother with. My requirements files are hierarchical. Extensively using -r and -c options AND venv aware.
pep751 does bring value, by stating both the host url and the hash of every package.
setuptools will fight this to continue their strange hold on Python
wreck 0.3.4.post0 no longer emits build front end options into .lock files wreck#30.
Background of efforts to beg and plead for setuptools maintainers to bend ever so slightly.
Continuing from denied way to pass build front end options thru requirement files so know non-pypi.org hosts setuptools#4928
This hurts those hosting packages locally or remotely on non-pypi.org package index servers. For those who are, the packages themselves give no clue where the dependencies and transitive packages are hosted.
Each and every user would need to have a ~/.pip/pip.conf or pass --extra-index-url pip install cli option. And somehow know all the possible package index servers.
This allows the pypi.org cartel to continue along it’s merry way unimpeded.
Wish pep751 good luck and may there be a .unlock equivalent. Do not yet understand how the pep751 implementers will bypass setuptools and build.
From the hatch docs, not seeing where it discusses publishing to alternative package warehouses.
Will look at it again
Does it do away with setuptools? After my experience interacting with the maintainers, now refer to that package as, The Deep State
The Deep State only supports loading dependencies from pypi.org Which has many advantages right up until it doesn’t.
This new standard contains dependency host url. Hope there is a package other than setuptools that supports it.
When bring it up, and prove it, the responses alternate between playing dumb and gaslighting. The truth is The Deep State are gate keepers. And they are in the way.
Training wheels off mode please! So there is support for requirements files that contain on which server dependencies are hosted with more than one choice. Would like the option to host packages locally or remotely using pypiserver or equivalent.
On the positive side, setuptool maintainers did not suggest voodoo dolls, try to wait out the planetary alignment, better economic conditions, or peace on Earth.
That’s how the conversation comes off to my eyes. But form your own opinion. Especially enjoyable for folks who also enjoyed the TV series, The Office.
What are the alternatives to being stonewalled by setuptools?
Disclosure: Wrote requirements rendering package, wreck. I have my own voodoo dolls and plenty of pins
Learn Sphinx which can mix .rst and .md files. myst-parser is the package which deals with .md files.
Just up your game a bit and you’ll have variables similar to Obsidian tags which doesn’t cause problems when being rendered into html web site and pdf file
the OP is discussing one step before pandoc
The way forward is to make a unittest module (unfortunately author not using pytest). With characters that are taken as an example from each of the four forms.
THEN go to town testing each of the low level functions.
Suspect the test coverage is awful. mypy and flake8 also awful.
There are several forms
K1 NoSymbol K2 NoSymbol characters with lower/upper case forms
K1 K2 K1 K2 unicode <= 256 with no lower/upper case forms. Like | or + symbol
K1 K2 K3 NoSymbol 2 bytes latin extended character set
K1 K2 K3 K4 3 bytes like nuke radiation emoji
Non-authoritative guess. Having played around with xev together with onboard virtual keyboard with my symbols layout.
keysym 0 and 2 are for lower and upper case. If the character has an upper and lower case equivalents.
This is documented in keysym_group when it should be documented in keysym_normalize
In that case, the group should be treated as if the first element were
the lowercase form of ``K`` and the second element were the uppercase
form of ``K``.
so for 1 byte characters has both upper and lower case forms
def keysym_group(ks1, ks2):
"""Generates a group from two *keysyms*.
The implementation of this function comes from:
Within each group, if the second element of the group is ``NoSymbol``,
then the group should be treated as if the second element were the same
as the first element, except when the first element is an alphabetic
*KeySym* ``K`` for which both lowercase and uppercase forms are
defined.
In that case, the group should be treated as if the first element were
the lowercase form of ``K`` and the second element were the uppercase
form of ``K``.
This function assumes that *alphabetic* means *latin*; this assumption
appears to be consistent with observations of the return values from
``XGetKeyboardMapping``.
:param ks1: The first *keysym*.
:param ks2: The second *keysym*.
:return: a tuple conforming to the description above
"""
Solves the mystery of the repeating entries
1 2 and 3 bytes unicode to corresponding keysym
mapped into that tuple. Seems author likes the number 4.
def keysym_normalize(keysym):
"""Normalises a list of *keysyms*.
The implementation of this function comes from:
If the list (ignoring trailing ``NoSymbol`` entries) is a single
*KeySym* ``K``, then the list is treated as if it were the list
``K NoSymbol K NoSymbol``.
If the list (ignoring trailing ``NoSymbol`` entries) is a pair of
*KeySyms* ``K1 K2``, then the list is treated as if it were the list
``K1 K2 K1 K2``.
If the list (ignoring trailing ``NoSymbol`` entries) is a triple of
*KeySyms* ``K1 K2 K3``, then the list is treated as if it were the list
``K1 K2 K3 NoSymbol``.
This function will also group the *keysyms* using :func:`keysym_group`.
:param keysyms: A list of keysyms.
:return: the tuple ``(group_1, group_2)`` or ``None``
"""
eggplant math cuz it isn’t in SYMBOLS
>>> s = '''🍆'''
>>> dec_s = ord(s)
127814
>>> hex(dec_s)
'0x1f346'
From the source code
def char_to_keysym(char):
"""Converts a unicode character to a *keysym*.
:param str char: The unicode character.
:return: the corresponding *keysym*, or ``0`` if it cannot be found
"""
ordinal = ord(char)
if ordinal < 0x100:
return ordinal
else:
return ordinal | 0x01000000
What a nutter! Comparing an int to a hex.
>>> int(0x100)
256
>>> int(0x01000000)
16777216
eggplant emoji keysym
>>> 127814 | 16777216
16905030
i use
interrogateWhich has a fun bug. Uses ast to compile every module. If a module contains a compile error, get a traceback showing only the one line that contains the issue, but not the module path nor the line #
The only way to find the issue is to just test your code base and ignore interrogate until code base is more mature.
interrogateauthor and maintainers: UX … what’s that?The most obvious bug in the history of bugs … setuptools maintainers,
oh that's a feature request