oops..
I sent an answer to andrew barnert, who have sent the first answer to my
question, and not to the list...
however , I do have an answer to my question.
thank you!
2014-11-29 11:51 GMT+01:00 Andrew Barnert <abarnert@yahoo.com>:
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/