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

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/

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

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/