hello, the problem is that even with extreme precaution, it is impossible to keep ALL modules compatible from a version to another. what I want to ask is this: -some "packs" which can, like py-compile, generate .pyc files, but using "old" versions of the default library, and of __builtins__. -One will go with every minor version and will be optionnal in the installation -any imported py file will be able to choose which version it wants with the "#! py recommended version X.X" or "#! py mandatory version X.X" commentaries at the begining of the file. thank you and have a nice day/evening/night.
On Nov 28, 2014, at 8:29, Liam Marsh <liam.marsh.home@gmail.com> wrote:
hello, the problem is that even with extreme precaution, it is impossible to keep ALL modules compatible from a version to another.
Do you have a specific library or app that you've had a problem with? There were a handful of modules that had a problem with the 3.2 to 3.3 conversion, but every one I saw was caused by language and implementation changes, not stdlib changes. I don't think I've seen anything that works with 3.3 but not 3.4. I'm sure it's not impossible for such a thing to happen, but it would be helpful to have at least one real-life example.
what I want to ask is this: -some "packs" which can, like py-compile, generate .pyc files, but using "old" versions of the default library, and of __builtins__.
But how would this work? The same changes that broke a handful of third-party modules between 3.2 and 3.3 probably also mean that the 3.2 stdlib wouldn't work in 3.3 without minor changes. And as for builtins, most of those are exposing internals of the implementation, so trying to make the 3.2 builtins work with 3.3 would take a lot more work than just building the 3.2 code against 3.3.
-One will go with every minor version and will be optionnal in the installation -any imported py file will be able to choose which version it wants with the "#! py recommended version X.X" or "#! py mandatory version X.X" commentaries at the begining of the file.
thank you and have a nice day/evening/night. _______________________________________________ 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 29 November 2014 at 15:07, Andrew Barnert <abarnert@yahoo.com.dmarc.invalid> wrote:
On Nov 28, 2014, at 8:29, Liam Marsh <liam.marsh.home@gmail.com> wrote:
hello, the problem is that even with extreme precaution, it is impossible to keep ALL modules compatible from a version to another.
Do you have a specific library or app that you've had a problem with? There were a handful of modules that had a problem with the 3.2 to 3.3 conversion, but every one I saw was caused by language and implementation changes, not stdlib changes. I don't think I've seen anything that works with 3.3 but not 3.4. I'm sure it's not impossible for such a thing to happen, but it would be helpful to have at least one real-life example.
The desire for doing selective upgrades on a stable base is actually a pretty common one (e.g. using modern unittest features on Python 2.6 or 2.7). The hard part is figuring out a way to provide those selective upgrades cost effectively. (In the context of unpaid development, the costs are measured in contributor time)
what I want to ask is this: -some "packs" which can, like py-compile, generate .pyc files, but using "old" versions of the default library, and of __builtins__.
But how would this work? The same changes that broke a handful of third-party modules between 3.2 and 3.3 probably also mean that the 3.2 stdlib wouldn't work in 3.3 without minor changes. And as for builtins, most of those are exposing internals of the implementation, so trying to make the 3.2 builtins work with 3.3 would take a lot more work than just building the 3.2 code against 3.3.
The feature Liam is looking for effectively already exists, in the form of updated standard library modules that have been backported to earlier versions via PyPI. There's a (likely incomplete) list at https://wiki.python.org/moin/Python2orPython3#Supporting_Python_2_and_Python.... This tackles the problem in the opposite direction, by ensuring particular modules remain compatible with older versions, rather than only running on the latest release. One of our reasons for making pip more readily available to Python 2 users in Python 2.7.9 is to make those modules easier to access (together with Python 3 migration tools like six, modernize, future, and caniusepython3). Cheers, Nick. P.S. While some of those backports are maintained directly by core developers, the PSF license actually allows anyone that wants to (and has the necessary time available) to backport modules. A number of the backports originated in users wanting particular features on earlier versions for their own use, and deciding to make their backport generally available, rather than keeping it to themselves. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (3)
-
Andrew Barnert -
Liam Marsh -
Nick Coghlan