Specifying Python version
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.
On Wed, May 16, 2018 at 08:02:47PM +0100, MRAB wrote:
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.
That would be a serious PITA for modules which have to work with more than one version of Python. -- Steve
On 17May2018 10:33, Steven D'Aprano
On Wed, May 16, 2018 at 08:02:47PM +0100, MRAB wrote:
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.
That would be a serious PITA for modules which have to work with more than one version of Python.
It also feels rather fragile. Though I'm having a little trouble formulating a
concrete example, I just feel like this is the kind of thing that is easily
mangled.
For example in a revision control merge (pull new change from branch using
older Python, whose older Python got slightly changed in the special comment -
in the diff the special comment looks new, easy to accidentally roll over the
target branch whose special comment has been updated:
main branch: # ##pyver 3.3##
maintenance branch: # ##pyver 2.4##
maintenance branch: update to # ##pyver 2.5## and add a feature or fix
main branch: merge changeset from maintenance, tread on the "3.3" with "2.5"
Cheers,
Cameron Simpson
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.
-Brice 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 Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
participants (4)
-
Brice Parent -
Cameron Simpson -
MRAB -
Steven D'Aprano