Panda's User Created Module Importing...Different?

As someone that has been using python for some years now… I have created my own modules for importing a lot (using the site-packages folder).

Normally, when writing a python application, importing a module that defines a class makes that class apart of your program… Which it should, because if it didn’t, the purpose of modules is lost.

I could in fact define a variable with some value, create a module that uses that variable somewhere in the code, import the module into the main app and have everything run accordingly.

This however is not so with P3D’s usage of python.

Importing a module within a Panda App does NOT make the module apart of the App in the truest sense.

I noticed an exception will raise if your module uses variables defined within your main App (of course those variables are defined before the creation of the instance, of the imported class…so they exist).

It’s like the module is acting as a separate program which is doing it’s own work on the side of the main app, within the main running window….

Believe me, I have written plenty of python apps and entire websites using modular importing and have never seen anything like this.


What I want to know is….

Is it even possible to import a module as part of the main application (inheriting from the main app) with P3D?

And if it is possible (my intuition is telling me no), how can I specify a folder within my game folder instead of site-packages? Extending the python path does not work for that, besides, my game folder is already apart of the path (but imports fail).

By saying P3D do you mean Panda3D or a p3d package?


After begging some computer nerds I know to take a look under Panda’s hood and help me out with my module importing issue…

All is good now. :laughing:

The first part that is; I can now force my modules to behave, so the next thing is loading those modules from a folder inside my main game folder and not Panda’s python site-packages folder.

Anyone knows how to achieve that?

Wow…I’ve been getting to it! :laughing:

Solved my second issue.

I just have one worry now…

Since I’m using a Windows OS, extending the python path only excepts Win style paths.

Wouldn’t this cause problems if the same App was tring to run on…lets say Linux? Since Linux uses the “pathpart1/pathpart2” and not the “pathpart1\parthpart2”

Or does Panda3D convert paths correctly based on OS on its own? (I’m guessing, no)

If the latter is not the case, then I would have to create another installation program at project end for other OSs like Linux, which include the correct pathing… ( :question: )

Come on drwr…break this down for me so I can get back to it. My program is really starting to get that professional feel to it now (I’m starting to fillout the first area). :smiley:

Windows accepts forward slashes too, apparently.

Yes, but apparently extending Panda’s python path to access a module does not work with forwards (on Win)…like I previously stated.

Drwr…where are you!? :slight_smile:

I just want to know what to expect, Sir. Will I have to create multiple installers down the road or not?

I don’t want to move forward using the modules if a road block is going to pop up later (it would leave too much code to modify).

I would rather use them because large programs can be broken down into smaller code blocks; instead of having one enormous scrolling text editor full of code, which can make it difficult to locate specific parts as the App grows even more.

If I have to modify the path from Win to Linux/Mac by creating different installers then that’s fine. I have made cd/dvd launch menus before which allows the user to pick an installation, so that part shouldn’t be an issue.

In fact, I first thought about creating an installation menu program using Panda. Then I thought about doing it with pure python and Tkinter. Either way would work, since python can cross platform an Panda3D can cross platform. There’s a third option I might at least try out. :slight_smile:

I’m not really sure what question you’re asking. When you’re talking about importing modules, you are talking 100% about Python; Panda has nothing to do with the way Python imports modules.

(The only exception is when you package everything up in a p3d file; in that case, the p3d subsystem introduces some additional Python code to allow it to find and read modules that have been packed into a p3d file. But still, even this is part of Python itself.)

Whenever you extend sys.path in Python, of course you are going to have to deal with local operating-system differences. This doesn’t mean you have to write completely different code for each different system.


You popped up! “Hurray!!” :laughing:

I better just create two different installations; one for Win, and one for Linux/Mac.

That should do it. :smiley:

When deploying your game you can either publish a p3d file, which is cross platform, or make a native package out of the p3d for each OS.

Still, you don’t need to have different code files for every OS. You can simply check the variable sys.platform which tells you whether you’re on windows, linux, mac or other. When it comes to paths you only have to care about two groups: windows and all others - which use forward slash.
Alternatively you can use Filename’s toOsSpecific() and fromOsSpecific() methods.

What arguments do toOsSpecific() and fromOsSpecific() take, if any? And of course, what does each class function do?

That API reference is “roughed up.”

I can find good use for sys.platform…

The API reference is pretty clear as to what toOsSpecific and fromOsSpecific do:

  • fromOsSpecific takes an OS-specific path as its first and only argument and returns an OS-agnostic path
  • toOsSpecific returns the OS-specific representation of the Filename class it’s attached to