type hints are static, not necessarily runtime.
A chaos monkey throws everything at everything to see what breaks.
That won’t be caught by perfect type hints, which is merely one tool in the toolbox.
and when things break, often hear WAD, works as designed. Or some other nonsense excuse.
Oh no a stray None! Take cover …
Robust codebase should never fail from a stray None
Chaos testing is specifically geared towards bullet proofing code against unexpected param types including None.
The only exception is for private support function for type specific checking functions. Where it’s obviously only for one type ever.
We live in clownworld, i’m a clown and keep the company of shit throwing monkeys.
Another use case is to reduce maintenance cost
Assuming an equivalent package is produced, what’s the maintenance cost (factoring in coder availability) difference between the Python vs faster language implementations?
^^ therein lies the rub
Reminds of the expression, premature optimization is the root of all evil
if not swimming in funding, might be a darwinic move to choose the faster language and have to code everything yourself from scratch
They want to prevent coders from dictating terms. It’s about perceived control/power over coders and ensuring whatever power coders wield is dispelled thru legalese spells.
Have written lots of open source as well as packages which are not published. The amount of contributions measured in issues/PRs/funding has been the same. Absolutely none.
Lost any incentive to care about debating licenses’ purity.
Will save the world by foreshadowning the pypi.org delisting announcement
Great example of malware that uses social engineering to deceive and only later realize those good intentions were quite harmful.
One step away from requiring a PoW algo to fund package authors. Which is great unless running on a crap laptop from the stone ages. Then it becomes a barrier to entry or simply broken UX.
Don’t like to hear this, but at some point in time this package will be delisted from pypi.org
Hello! i have an inferiority complex. Would like to leave the impression to everyone that i’m a very important person.
For my packages, how to make imports install duration correlated to my deep inferiority complex? To give the impression of compiling a massive code base written in a low level language. Rather than this ducked typed language static type checked with pre py312 knowhow (which is the truth!).
American Python packages should run like American motorcycles, bleeding oil all over the road.
Lets Make America clunky af again
It’s really really dangerous to expose a parody onto a package author whose written both a build backend and a requirements parser. If Trump found out about this, the build backend might incorporate tariff.
This is one plugin away from becoming a feature
Heil cobra!!
Because foreign packages have been STEALING our CPU cycles for TOO LONG! It’s time to put AMERICA FIRST and make importing FAIR and BALANCED again!
i use interrogate
Which 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.
interrogate author and maintainers: UX … what’s that?
The most obvious bug in the history of bugs … setuptools maintainers, oh that's a feature request
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
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``
"""
Who are you writing package for?
backend stuff need not run on Windows at all.