It's in the same spirit as what I proposed in my answer to Guido's crazy idea, but set at a different level (in code instead of in setup.py in my proposal).
I think it belongs to the same discussion, so I'm copying it here (sorry for the inconvenience if you already read it there):
Le 16/05/2018 à 11:22, Brice Parent a écrit :
Why not have the compatibility be done at setup.py's level?
Like having something like this:
setup( name="LegacyLib", version="8.4.1", ... max_compatibility="3.4" # Defining here Python's max version for which this lib has been upgraded )
Of course, we may use any other word instead of "max_compatibility", like "designed_for", "python_version", or anything a better English speaker could think of.
The point is, it would either:
- when you install the library, rename all variables that are now
keywords (we'd know the exact list thanks to max_compatiblity) by suffixing them with "_"
- or set a flag that will do that when creating the *.pyc files.
Possible problems/limitations I can already find:
- There would still be possible errors when using variable names that
are generated on the fly (I have no clue how this could ever be addressed)
- It might get complicated at some point to know what to do, like when
we have lib_a in some version depending on lib_b (with or without a max_compatibility version number), it is obvious that lib_a will use lib_b's original variable names (without the appended "_"), but our code which might also want to interact with lib_b would have to.
Le 16/05/2018 à 21:02, MRAB a écrit :
Instead of verbatim identifiers, how about a special comment giving the Python version in which the file was written?
There could then be a tool similar to 2to3 that converts the file to a more recent version of Python that might have new reserved words. In most cases the new file would merely be a copy of the original, but with an updated Python version. _______________________________________________ Python-ideas mailing list Pythonfirstname.lastname@example.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/