It just occurred to me that the current Python interface is locked to Python22.dll
Looking at other products, such as numpy or wxWidgets, what tends to happen is either:
the installation will automatically build the Python interface files for you, binding them to your own Python installation (eg NumPy)
itās possible to download the application for multiple Python versions (wxWidgets)
Would it be possible to do something similar with Panda please?
I think the easiest would probably be:
split the Python interface to a separate dll, that links with libpanda.dll and so on. This makes the building and linking process much simpler, because the amount of code involved is considerably smaller
pre-run the interrogate to generate the source code files (This bit takes an awfully long time, so this would save a lot of pain)
then the installer will simply locate your Python installation, build the provided source code files, and bind them to oneās site-packages
By the way, I found the doc for creating the installer that takes the modules, locates the Python installation, and copies the packages into site-packages, amongst other things:
I would expect if you have multiple developers working on the same project, that you would really want to use a consistent version of python across the board.
If you have some developers working strictly in python, and another team concentrating on extending the c++ sideā¦makepanda.py will let you build an installable panda distribution like the ones you can download from here. So on my laptop, which I have setup for compiling Panda, I had it build the installer.
On my desktop, which I have just been using for messing with python in panda, I just installed it from my own installer. So my desktop is using the version of ppython that goes with the install of panda that I built from source.
I do think it would be a swell idea to either recompile the Python interface layer on-the-fly (especially tricky to do on Windows, where a compiler is not likely to be installed) or provide prebuilt versions for common versions of Python (further exploding our list of downloadables).
Both approaches do have their problems, though. But consider the suggestion on our to-do list.
Just so you know, Python on Windows can automatically build included C files. It needs the Microsoft .Net 2003 compiler, which coincidentally is the free-to-download one. OTOH, itās looking for registry keys that correspond to the full-blown Microsoft Visual Studio IDE).
So, it would be possible to get Python to recognize the free Toolkit by a suitable .reg file to tweak a registry key.
The Python module that manages this is %PYTHON%\Lib\distutils\msvccompiler.py.
Itās looking for paths under the following:
HKEY_whatever\Software\Microsoft\VisualStudio\7.1\VC\VC_OBJECTS_PLATFORM_INFO\Win32\Directories
Stampson,
Dont suppose⦠could you make your prebuilt Python 2.4 binaries publically available please?
Here is the installer it built for me. This is from makepanda.py with python 2.4.1, and is built without dx7 or dx8, and without helix. The source is unmodified from the distributed source. My only changes were to makepanda.py to get it to compile using the free MS compiler.
If it is a problem for me to provide this link, let me know and of course Iāll take it down.
However, you might want to test it thoroughly. We havenāt done any testing with 2.3 or 2.4, so we donāt know if there are any subtle problems. Thatās the only reason I havenāt upgraded the main distribution. I donāt want to release a version of panda using a particular python distribution until Iām sure itās reliable.
Actually, Iām interested in stackless python, too, if anybody wants to dink around with that.
My testing of the above binary with python 2.4.1 has consisted of running the sample programs and poking around with the tutorials. Itās been working for me, which is about all I can say =)
Weāve started to migrate to Python 2.4 in the VR Studio. We found a few subtle issues with signedness; Python 2.4 has an automatic upconversion to the ālongā type, which gives a limitless range on integers. This means that tricks like (foo | 0x80000000) do not produce a negative number. Python 2.2 didnāt do this.
The practical difference is only an issue in some very subtle cases, especially having to do with networking. I suspect you can run Panda in Python 2.4 for quite a while before you notice any of the problems that we came across.
When we eventually get Panda3D version 1.1 ready, of course, it will include all of the fixes we made for Python 2.4.