On Nov 29, 2014, at 0:46, Liam Marsh <liam.marsh.home@gmail.com> wrote:

hello,

yes, the bug which gave me this idea is a py3.2 to py3.3 bug with Vpython, a 3D graphs library.

And is the bug a stdlib bug, or a language bug?

I also thought this will be the reconciliation between py2 and py3. (this is why I thought the packs will include a version of the stdlibs)

The language differences between 2.x and 3.x are huge, and most of the stdlib differences between 2.6 and 3.1 or 2.7 and 3.2 are related to those language differences. Porting code to 3.x is primarily about fixing Unicode stuff, or code that was already deprecated in 2.5 or 2.6 but wasn't broken until 3.x. Having the 2.7 stdlib in 3.x would be a huge amount of work for almost no benefit.

in fact, how do the .pyc work? were them modified by the "language and implementation changes"? how do them import other modules?

.pyc files are just compiled bytecode, with a version-specific header. If you fixed the 2.7 stdlib to work in 3.x (which, again, would be a huge amount of work), you could compile it with 3.4.

But you're missing the fact that large chunks of the stdlib are written in C, and compiler against the Python C API. And parts of the stdlib (especially builtins and the sys module) are exposing types and functions written in C that are part of the core implementation, so the 2.x version of the sys module wouldn't be compatible with 2.x code anyway.

Also, did you mean to write just to me instead of to the list?

thank you!

2014-11-29 6:07 GMT+01:00 Andrew Barnert <abarnert@yahoo.com>:

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/