Python 3k

Will panda3d work with the Python 3k release?
Anyway, when it should be released the next panda3d version?!

Thanks in advance…

No, panda runs currently with Python 2.5.
There are multiple threads about it you would have found if you searched:
discourse.panda3d.org/viewtopic.php?t=5355
discourse.panda3d.org/viewtopic.php?t=4994

The upcoming Panda3D release, 1.6.0, will probably be released within a few months. It won’t support Py3K either, though, for lots of reasons (see posts above)

Sorry, I’ve looked for “Python 3k” “Python 3000” and “Python3k” with no results… maybe I wrote it in a wrong way…

Thank you very much!

Python 3.0 support may be a long term issue, but python 2.6 support should be considered sooner rather than later. The python 2.5 build on windows is largely dependent on VS2003 with no real support for building in later releases. This has resulted in builds for extensions that will work in anything but VS2003 very difficult.

I know there are a lot of Linux people who don’t care one way or the other about issues on the Windows side, but this one is pretty hairy. You can quickly get into a DLL hell scenario if your project has C extensions that have to be built for python.

Falling behind the curve means falling behind all the way down the tool chain, and getting up to date will never get any easier. As a result, the arguments for not updating python will never change. Meaning, you are either committing to sticking to 2.5 for the life of Panda, or those arguments are not really valid. Python is a big enough project dependency that it really deserves to be treated with priority.

Switching to python 2.6 is not a bad idea, but I’m afraid it will be somewhat of a big step (that will also cause some confusion, as with the 2.4>2.5 switch.)
Currently, the Linux packages are built against whatever the distros define as default version of Python, and this is still 2.5 in most cases. Once new versions of these distros are released that have 2.6 as default version, we would certainly build Panda against those versions.
On Windows, it’s a lot more difficult, since it requires to replace Panda’s shipped version of Python. We should definitely consider it, however, when 2.6 becomes the industry standard.

The problem here is also that python goes on to break external libraries retrocompatibility every new release…
Yet moving c++ interface programming language from python to other scripting languages (Lua?) is not a viable solution right now…

And about the linux-Windows side… I’ve been using both of them together for two years, and I must say that windows has sometimes a better library management… 'cause linux simply refuse to understand that it should be possible to have two versions of the very same library…
So the problem is here and IMHO poses a great question: what’s the panda future if its target is users that can simply use it out-of-the-box?

Perhaps I am showing my ignorance of panda here, but that risk aside… Is it possible to have Python fully embedded in Panda3d so that it does not matter what Python is installed on the system?

That’s what it is right now, on Windows. Panda ships with its own version of Python. You shouldn’t have your own copy of Python installed.

That’s what’s a problem to most people: they have a downloaded copy of Python installed on their machine, which will then conflict with Panda3D’s python installation. That’s where ppython kicks in: its an easy way to make sure you’re using Panda’s copy of python.

I’ve also noticed that sometimes Linux itself is not very kind about python <-> panda3d connection (maybe it depends from the linux distribution used)…
Is there really a so big difference between python releases?
I mean, take java or c#, every new release is not going to break every single line coded against other external dependencies…

There are benefits in it, too. Since java releases have to be binary-compatible with each other, they can’t replace a module for a more efficient one, or stuff like that. Instead, they have to make a separate module for it. Where it gets hoggy, big and heavy.

We’ll find soon that managed code and assembly are the solution for python… :laughing: :laughing: :laughing:

/me stabs eliaballade