I agree with the view that Python 2.7 is still the industry standard and there’s not much reason or motivation to migrate now aside from the novelty aspect. However, since an eventual migration to Python 3 is inevitable, we might as well just work a bit on it here and there for the benefit of enthusiast’s convenience and to make it easier for that future moment when there is a real demand for Python 3.
As I said earlier, though, it’s not a high priority for me, as there are more important things to do, but I do keep it somewhere in the back of my mind since it’ll have to happen sooner or later anyway.
However, count me into the camp of people who would like to see a Python 2.8, even if that is very unlikely to happen.
I’ve been using Panda with Python 3 for a while, and it seems to work pretty well. There are still a whole lot of trivial fixes to be made to the ‘direct’ tree (which is implemented in Python) though, to take out all the Python-2-isms.
Python 2.7 is still supported and will be supported for a long time. No features from Python 2.7 will be deprecated any time soon.
The only thing I changed is syntax that only worked with Python 2.7 (which was already deprecated in 2.7 to begin with), which I replaced with syntax that works in both Python 2.7 and 3.3.
Just FYI for people following this: I finally tracked down and fixed the “Invalid access to memory location” issue that prevented the Python 3 build from working on Windows. So the Python 3 port seems to work on Windows as well now.
Sorry, I was occupied by a new job for the past year and wan’t in position to program much. I’m glad to see you basically have this working though; I’ll be reviving my panda3d project over the winter and since it was always my goal to write it in python 3 I’ll definitely give this a try.
Ok, I built from the latest CVS (as of yesterday) using python 3.4. No problems with the build, but I can’t import from the pyd files like “core”, it just raises an ImportError saying the module can’t be found. It’s not a path issue since I can import from a test module I put in the same folder. Did I miss an option on the build? It looked like py2to3 ran at the start of the build, but I can’t really remember.
I made an installer and used that, but python is finding the installed directory alright because I can import from other modules in the installation, just not the .pyd files in panda3d. Also I tried subbing the core.pyd file with a core.py with some test objects in it and I can import those fine, it’s just the .pyd files themselves that it can’t seem to find. In my test script it finds DirectStart, but fails when it encounters the first “from panda3d import *”.
import direct.directbase.DirectStart
..
DirectStart: Starting the game.
Traceback (most recent call last):
File "main.py", line 4, in <module>
import direct.directbase.DirectStart
File "E:\dev\panda\Panda3D-1.9.0\direct\directbase\DirectStart.py", line 3, in <module>
from direct.showbase import ShowBase
File "E:\dev\panda\Panda3D-1.9.0\direct\showbase\ShowBase.py", line 10, in <module>
from panda3d.core import *
ImportError: DLL load failed: The specified module could not be found.
It could also be that it can’t find some of the dependencies of core.pyd. Is the bin directory in your PATH? You should try opening core.pyd with Dependency Walker to see which dependencies are causing the problem.
The bin dir is in my PATH var. Dependency walker shows the following:
Searching around it seems a lot of people have these exact errors on Win7 for various reasons sometimes to do with conflicts between 32 and 64 bit dlls. They’re all delay load as well which seems puzzling if they’re causing the import to fail.
Well, at least some of those are expected to show up and don’t really have much to do with Panda.
It’s kind of annoying that Python doesn’t show which library failed. Hmm, could it be that you’re building 64-bit Panda with a 32-bit version of Python, or vice versa?
I thought it might be that so I built a x64 version of panda3d using a x64 build of python 3.4.2 but I get the exact same error. I’m using the latest CVS (as of Sat Nov 15) from “panda3d.cvs.sourceforge.net”. I’ll keep messing around with it.
Just to clarify I can’t import from any of the .pyd files in the “panda3d” dir, but I can import from normal .py modules from the same directory, so it’s definitely something to do with the .pyd files themselves.
Hmmm, think I made things worse, now Dep walker is showing that, despite panda3d and python being x64 builds, all the Winows dlls being loaded are x86:
I seem to have a bunch of Visual C++ stuff installed so maybe something’s messing up in the build?
That doesn’t necessarily indicate a problem - I’ve seen Dependency Walker get confused over 32-bit vs 64-bit libraries when there was no such issue.
It shouldn’t be a problem to have the Visual C++ redistributables installed.
One thing I tried in the past (though it’s very crude) is try to dlopen some of the panda libraries in bin directly, eg. using ctypes.CDLL. That way, you can find out which library is the offender by finding the library that won’t load.
