Uncommon python Dll-Wrapping and builtins & path hacks

Hello everybody.

Is there any particular reason for the uncommon Dll-2-Python panda implementation:* not containing python wrapper classes before connecting to the c-functionalities
* making functionalities and managers like “render, taskMgr, etc.” globally by inserting into the builtins space
* preparing the import path for “direct” modules by inserting into the path attribute (this attribute is unprovided for that … why so complicated?)
* providing an object-orientated architecture but enabling just a flat programmability? This uncommon ways of offering and (partly) wrapping DLL functionalities to python will blocks QA support-tools like PyLint and other language checker.

What’s wrong with implementing first empty python classes for all ‘to-wrapp’ components (as a kind of interface) and finishing then with loading/connect the Dlls and functionality wrapper?

(Besides reduction of effort :wink: )

[color=darkred]>>Masaru<<

Some people find it ugly, but it’s what makes panda so easy to use. If you don’t like it, subclass ShowBase (or make your own showbase equivalent class)

I agree. It sucks. There must be some reason for it though – but if there is none, I’ll get that fixed.

What the heck do you mean? Have you seen the list of classes:
panda3d.org/apiref.php?page=classes
Many of those are C++ implemented classes.

I don’t have a clue what you mean with the whole dll2python thing. I believe it’s done using the common way Python extensions are written - using its C API. The way you’re pointing at rather sounds to me like the uncommon way.
Panda’s auto-generated wrappers already work with native Python types and is already object oriented - why do so complicated and make empty Python classes?

That’s just my two cents, though I’m not an expert on this.

Thank you for such a quick answer pro-soft :slight_smile:

Mhm … maybe it makes panda easy to program … but its squeezing the object-orientated concept and power of python back into the corset of just being a simple procedural scripting-language. That’s not what van Rossum was meant for I think.

And that’s the fact. The C++ classes (the architecture of Panda3D) is a giagantic OOP construct. But take a look on the python side. The way you have to program with panda is not a quarter so ‘object orientated’ like the big C++ brother. You have to “script” python, instead of developing according the paradigm of OO. But why? Oh … jeah … because it’s easy.

You’ve suggested that I can subclass ShowBase. But in my opinion a pythonic tool has to provide this from scratch.

There are many reasons. First - other libraries do this also (wxPython, pywin32Extentions … there python classes are located for example in the PYD files). It’s not being written as a Python PEP but it has become a “pythonicâ€

I think that a deep rooted design error that sort of stuck. Its hard to change all the code now but you know, it makes stuff easy at the end so it kind of balances out.

There is organization to the masses. See here panda3d.org/manual/index.php/Class_Reference its just not presented this way. Oh and panda3d predates new style classes and i am not sure if it predates user defined classes.

And whats wrong with being easy? I also don’t get why you think panda3d is not OO, it has clases, it has proper hierarchy tree, it has proper OO design.

I think I understand you to mean that you would prefer the C++ classes to be wrapped by a true Python class, which internally redirects its method calls into the C++ class, instead of a C-implemented Python object, which directly presents the C++ methods as C-wrapped Python methods. This is indeed the way that wxPython et al wrap their C++ internals. And, in fact, it is also the way we wrapped the C++ internals in Panda3D 1.0 and earlier.

The reason we abandoned that system in favor of the current one is simple: performance. We get at least a 10% performance gain from having one fewer layer in the call stack. To me, that’s well worth the inconvenience of not being able to use tools like PyLint so easily.

This is another one of those poor early design decisions that’s hard to root out now. The poor design in question is that dratted “src” directory in the cvs tree, as in direct/src/showbase and so on. No one wants to “import direct.src.showbase”, so we hide that poor design by munging the path at startup. But the system is intended so that in a production environment, the Python files should be installed into the proper directory structure, e.g. direct/showbase and so on. I don’t think Josh ever got around to setting up the CMU distribution to do this, though, so even if you unpack the CMU distribution you still get the “src” directory and the path munging.

(The reason it’s especially hard to fix is that we have lots of other trees–more than just direct–in the VR Studio that all do it this same way.)

treeform hit the nail on the head here. No one loves this builtin slamming, no one claims it is elegant, but we’ve got it for now, and it turns out it’s not so bad. One of Python’s guiding precepts, in fact, has been to first build something useful, and only second worry about design principles. (In the VR Studio, we long ago abandoned Squeak in favor of Python, partly because Squeak wasn’t able to bend its design principles enough to give us a workable product.) Still, it has always been on my wish-list to write a replacement for ShowBase that doesn’t do all of this messy slamming. If you’re volunteering to do it now, it would be a welcome addition to the project.

I’m with the crowd here–I sure don’t see what you’re talking about on this point.

David

If I knew before there was no good reason to do it this way, it would have been fixed by now.
I’ll make sure this gets fixed for the upcoming 1.6.0.