Thinking about python 3000

py3k ffi interface you would like?

  • none - lets just use py2.X for ever
  • ctypes - c layer + any python support
  • swig - tons of languages support
  • interigate - and fix it for any changes to py3k
  • 100% py3k - lets just port c++ to static python

0 voters

Python 3000 (python.org/dev/peps/pep-3000/) is new python that is scheduled to be released some time around August 2008.

It will break compatibility with most of the python code. I would like to start a discussion on what we can expect to happen at that time. Mainly from the maintainers of panda like David and Josh.

Python3000 will support optional static annotations - also nothing fantastic on their own they will allow other libraries (like psyco) too hook and optimize code to near c++ speed. If that will porting panda3d to python might be a cool idea.

There is more pythons then just the CPython there is pypy,jython and IronPython all of which support ctypes - the default python foreign function interface. This allows easy calls to C functions but it still requires some auto generated wrappers to tell python how many arguments and the structure layout to pass etc … but this does not work with C++ functions which panda3d uses because classes and calling conventions (to some degree) are handled differently by all the compilers. So ctyles only interfaces with plain C not C++. Also many other languages can interface with plain C but not C++ maybe having a C wrapper (interrogate documentation says it can generate it) and ctypes stubs of some sort so that all python implementations and any other language could use panda3d.

I say this because interfacing to pythno3000 c++ layer (as panda3d does to python2.x) will cause is work any ways maybe we can get it right.

The other option is to use swig which i am sure will get python3000 bindings at some point and has been already started here on the forums.

I would like to hear your thoughts and ideas about this! - post a way.

Lets see how it comes out and how its accepted among the devs. Note that you need to distribute Py3k. Py2.x is available nearly everywhere.

We should discuss that topic once Py3k is there one or two years. Before that it might be a bad idea to spread the few devs even more into a feature dev team and a porting dev team.

Regards, Bigfoot29

Oh please, please keep that thought for yourself. That would require me to recode lots of my games…
Never in my lifetime will I support that thought.

I was waiting for such a thread for a longer time.
If van Rossum and the core team cleans up python and improves the speed I wont miss this and other stuff in a game engine, were speed is often essential! (unfortunatly they didnt get rid of “self” which would be my first target for a cleanup…)
Anyway it wouldnt be uninteresting to have the option to use forks like stackless or pypy with panda, too. But I dont know if this is possible (with swig?).

yeah i would get rid of self too. Swig would allow many other languages Java,.net,perl,C to work with panda3d. While ctypes solutions would allow more of the python languages to work with panda3d.