"import direct.directbase.DirectStart" pollutes na

I don’t understand why panda’s modules insist on polluting the global namespace (is that the right term in python?). For example, when you do the normal DirectStart import, run() suddenly exists in the global namespace:


import direct.directbase.DirectStart
run()

Why isn’t it something like this, instead?


import panda
panda.run()

Is there a good reason for the way it is? Would people object to this being fixed?

It’s just a philosophical difference. Some of the programmers here at the VR studio like the idea of minimizing typing by making commonly-used symbols available in the global namespace without having to import anything.

Personally, I dislike this practice, and would prefer to have everything namespace-protected, as you describe. But not everyone agrees with me. And we already have a lot of code that uses the existing system.

Still, this is a small part of the Panda package. Most of Panda3D–that is, the C++ code–is all protected properly. It’s just this startup code in DirectStart.py and ShowBase.py that jams a bunch of stuff in the global namespace. If you wanted to design an alternative way to start up Panda3D that didn’t involve this kind of namespace pollution, so that future developers had a choice of which method to use to start Panda3D, I bet it would be appreciated.

David

Thanks for the quick reply. I understand the desire to minimize typing…but that’s what “from blah import *” is for :wink:. I haven’t looked at the panda source code at all, so I’m not in a position to commit to fixing this but am I right in thinking that a patch would be considered for inclusion as long as it doesn’t break old code and still allows the option of minimal typing?

Out of curiosity, “panda” seems the logical module name…why is everything called “direct” instead?

Right, but even “from blah import *” is one line more than you would have to type if the symbols were already in the global namespace. It seems silly, but it does make a difference if you are using Python as an interactive shell for development, rather than strictly as a batch tool to launch a program stored in a .py file.

And “from blah import *” works by copying the symbols into the local namespace at the time of the import command. That’s mostly the same thing as putting the symbols in the global namespace, unless the symbols change value (e.g. 1 becomes 2)–in which case, the symbols previously imported with “from blah import *” will not change value. (Certain mutable objects like lists might change internally, but that’s something different.) Again, this makes more of a difference when you are running Python as an interactive shell.

I’m not endorsing the builtin system, I’m just explaining why some people do still prefer it to work the way that it does. Anyway, I don’t think it’s possible to exactly emulate the current system without stuffing values in builtins. Still, it would be possible to make something that does behave similarly, and this would be appreciated. If you made it work without breaking existing code, and we could persuade the developers here to embrace it, we would certainly include it.

As to the naming thing, that’s mainly to do with a bit of history. Within the VR Studio, we have always made a logical distinction between “panda”, which is a 3-D engine written in C++ that has nothing to do with Python, and “direct”, which is a layer of high-level tools, written in Python, that run on top of the core Panda engine.

When CMU released a public distribution of Panda3D, it made more sense to use the name “panda” to refer to the whole suite, so this distinction we made within the VR Studio now seems strange to an outsider.

David

Ah ok. So when they run ppython (or whatever they are using) the DirectStart stuff is imported automatically? I can see how that would make a difference…typing the import line every time would be a drag.

David is on vacation, but this is an interesting line of questioning. The namespace stuff bugs me too.

As it turns out, there are really only three or four places in the source code where it assigns to builtins. It does seem like it would be feasible to have some simple mechanism to suppress all that crap.

The other problem is files that have side effects.