python 2.6 is out

[Cyan]

@treeform

panda3d is about at 880,000 source lines of code. (it would take you 30 workdays to look at every line at 1 line/sec) (note its more code then python3.0 itself) It would take a lot to updating this to python3.0. Another problem is that python dropped support for older windowes which panda3d must support.

I don’t think we will see panda3d ported to 3.0 any time soon.

Gosh, would it really be that difficult? There’s a command line switch to highlight incompatibilities. You wouldn’t have to go over every line by hand. To quote from the python website: docs.python.org/3.0/whatsnew/3.0.html

For porting existing Python 2.5 or 2.6 source code to Python 3.0, the best strategy is the following:

0. (Prerequisite:) Start with excellent test coverage.
1. Port to Python 2.6. This should be no more work than the average port from Python 2.x to Python 2.(x+1). Make sure all your tests pass.
2. (Still using 2.6:) Turn on the -3 command line switch. This enables warnings about features that will be removed (or change) in 3.0. Run your test suite again, and fix code that you get warnings about until there are no warnings left, and all your tests still pass.
3. Run the 2to3 source-to-source translator over your source code tree. (See 2to3 - Automated Python 2 to 3 code translation for more on this tool.) Run the result of the translation under Python 3.0. Manually fix up any remaining issues, fixing problems until all tests pass again.

It is not recommended to try to write source code that runs unchanged under both Python 2.6 and 3.0; …

Besides, I think a backwards-incompatible version of Panda is a good opportunity to fix all the design flaws that were only visible in hindsight. Haven’t we heard drwr complain about some of those? Sure it would still be a lot of work, but its not like we have a deadline to meet.

[treeform]

Python tool only works for python code which there is about 80,000 lines of the rest of C++ lines the tool highlight does you squat.

I think most of the py3k convention would be in the interrogate.

Maybe we can look at swig or some thing as well.

[N.tox]

@drwr

Actually, multiprocessing starts separate processes, which each has its own memory space. So it should be safe to use with Panda, but you’ll have to be careful: you won’t be able to make Panda calls across the process gap (but you won’t be able to make other library calls across the gap either; that’s the fundamental problem with multiprocessing).

It’s no salve for all your woes. It would be silly to avoid writing code in Python 2.5 because you’re waiting for this particular feature. Especially because the backport is available, as pro-rsoft points out.

David

Wow, sorry for the (very very) late answer, and I arrived to the same conclusion… I didnt know about the backport, it’ll can be usefull when the time will come… what i found interesting with the multiprocessing was that we could exceed the one memory module cap of python (maybe there is another way but if this is the case, I don’t know it… ).
Even if regarding what you said I seriously doubt now this module will be really usefull to me, i’ll give it a try.

And, like 90% of the code I need is python 3.0 and 2.5 (yeah, I like to be mostly up to date ) compatible, I don’t really mind it, except for the other languages translations, far more convenient with the 3.0 version.

But whatever, thanxs to you and Pro-soft for the answering and giving the link, with the time I came to think it wasn’t so a big deal to stay in 2.5.x few years longer (yeah, I still hope Disney’s targeted computers will change, and it will… but when…)

[croxis]

To bump an old thread,

Within the past week Ubuntu Jaunty upgraded to Python 2.6 as the default. That was a fun few days of upgrades with random chunks of the system crashing =p. Starting with Ubuntu 9.04 there will probably need to be dual releases for python 2.5 and 2.6. I’ll see if I can get a package together for us crazy mofos who live on the bleeding edge.

[rdb]

croxis: the linux builds are compiled against whatever the linux distro’s offer as default. It’s the Windows build that is stuck at a python version.

It appears that everyone is moving towards Python 2.6 now, so I’m upgrading the Python version on Windows to 2.6 for the upcoming Panda3D 1.7 release. Any objections, let me know.

[bigfoot29]

Its not 2.6 I am worrying about, its 3.x which is giving me head aches… This new revision is just changing a LOT in the way the Python devs have to code - away from “intuitive coding” to “coding how its meant to be by the devs”.
Actually “intuitive coding” was the one and only reason why I landed here.
However, thats rumors. I never used 3.x till now.

What I meant: I hope that 2.x-releases of python are supported for a LONG time as long as its compatible with older Python code (which will break in 3.0 at least but should not in 2.6?)

Regards, Bigfoot29

[rdb]

Oh, don’t worry about that. The world isn’t ready for 3k yet, also because a lot of major Python libraries don’t feel like upgrading yet.

Python 2.x is still supported, a Python 2.7 is even in development.

2.6 is backward compatible, so upgrading should not break anything. In fact, some of panda’s Linux builds have already been built against Python 2.6 for some time.

[Bradamante]

Well I am not exactly a Python pro, but from all what I read, hear or see of Python 3K I don’ think that’s true. Except for the print() thing I guess most people here can still use their code. There’s also some change in range and/or xrange, that might effect people, but I am not even sure about that one.

@bigfoot29

Its not 2.6 I am worrying about, its 3.x which is giving me head aches… This new revision is just changing a LOT in the way the Python devs have to code - away from “intuitive coding” to “coding how its meant to be by the devs”.
Actually “intuitive coding” was the one and only reason why I landed here.

[rdb]

I think the biggest problem is with the C API, not with the Python code.
And people do need to do big rewrites of Python code. “print” is just a mere example - has_key another.

It will take weeks to rewrite Panda for Python 3 - and I don’t think it’s worth it. Most other libraries and engines didn’t upgrade to Python 3 yet either. Python 2 is still supported and only hobbyists use Py3K yet.

I don’t see any reason to upgrade.