the version of PyMate in the svn repository doesn't work with Python 3.0rc1, as there have been major changes both to the language and to the standard library.
the diff file attached to this message describes the changes needed to make PyMate compatible with Python 3.0; it also migrates from the % string formatting operator to the new str.format function, as recommended by the Python 3.0 documentation.
sadly the changes are not backwards compatible (valid Python 2.x code is not necessarily valid Python 3.x code and vice versa), so some sorts of version check should be put in place -- I'll leave that to the senior mantainers of the bundle.
cheers,
domenico
Domenico Carbotta wrote:
the diff file attached to this message describes the changes needed to make PyMate compatible with Python 3.0; it also migrates from the % string formatting operator to the new str.format function, as recommended by the Python 3.0 documentation.
sadly the changes are not backwards compatible (valid Python 2.x code is not necessarily valid Python 3.x code and vice versa), so some sorts of version check should be put in place -- I'll leave that to the senior mantainers of the bundle.
The Python developpers suggest to use 2.x as long as you can, and use the conversion tools to translate existing code from 2.x to 3.0 code whenever 3.0 is ready.
So I vote that the Python bundle should support 2.x as long as possible. Python 3.0 support should probably be done in at least a separate syntax, and perhaps even a different bundle?
Jeroen.
The Python developpers suggest to use 2.x as long as you can, and use the conversion tools to translate existing code from 2.x to 3.0 code whenever 3.0 is ready.
that sure is an interesting take -- if I state I want to use python 3 here and now, will guido come and grab me by the jacket, shouting "use it if you dare!" in that sweet dutch accent of his? ;)
anyway, what I meant was PyMate should include the appropriate flavor of sitecustomize (the current, 2.x-compatible version or the modified, 3.x-compatible version) -- this can be readily obtained by placing the two different versions in two different folders, and inserting the appropriate folder in the PYTHONPATH environment variable.
cheers,
d.
On Oct 15, 2008, at 3:20 AM, Domenico Carbotta wrote:
The Python developpers suggest to use 2.x as long as you can, and use the conversion tools to translate existing code from 2.x to 3.0 code whenever 3.0 is ready.
that sure is an interesting take -- if I state I want to use python 3 here and now, will guido come and grab me by the jacket, shouting "use it if you dare!" in that sweet dutch accent of his? ;)
anyway, what I meant was PyMate should include the appropriate flavor of sitecustomize (the current, 2.x-compatible version or the modified, 3.x-compatible version) -- this can be readily obtained by placing the two different versions in two different folders, and inserting the appropriate folder in the PYTHONPATH environment variable.
it should be possible to just put all in the same file, but branch immediately after checking the python version. this is what i had done in my partially working sitecustomize.py for python 3 that i abandoned :).
domenico, there was a compatibility problem that i couldn't find a workaround for. i think that it had something to do with STDOUT / STDERR not being initialized properly when sitecustomize.py got loaded and so I couldn't set them to unicode streams. did they fix that?
—Alex
On 15 okt 2008, at 03:20, Domenico Carbotta <domenico.carbotta@fastwebnet.it
wrote:
The Python developpers suggest to use 2.x as long as you can, and use the conversion tools to translate existing code from 2.x to 3.0 code whenever 3.0 is ready.
that sure is an interesting take -- if I state I want to use python 3 here and now, will guido come and grab me by the jacket, shouting "use it if you dare!" in that sweet dutch accent of his? ;)
In my own sweet Dutch accent I can say that I really said 'suggest' and not 'must'.
But what I meant to convey was that 2.x and 3.x should be viewed as separate versions that are incompatible. So i think they should be handled separately.
Jeroen.
But what I meant to convey was that 2.x and 3.x should be viewed as separate versions that are incompatible. So i think they should be handled separately.
I think it can be properly handled by a single script, I'd be more than willing to hack on it… but since the gist of it is written in ruby, and ruby for me is basically line noise, I'll happily accept whatever the community decides.