what about making panda more pythonic?

General Discussion
21

Actually, the issues you are talking about have very recently been resolved, on the CVS head. They will be fixed in the 1.6.0 release, nice stuff like iterating through getChildren and findAllMatches, treating Vectors as tuples, etc.

Panda3D’s C++ classes are stored in ‘pandac.PandaModules’, it’s python tree is the ‘direct’ tree.

Lots of the issues you talk about are because the engine is mostly written in C++ (for speed of course) and C++ is simply not as pythonic as Python. :slight_smile:

About the DirectStart thing adding stuff to builtins: I totally agree. I vote for removing that too.

22

Thanks for the reply!

It’s good to hear that the api is getting polished. I’d like to use Panda for more projects in the future so I’ll keep an eye out for new releases.

I understand how it goes with Python api wrappers - I’ve used Blender for a long time. Blender’s api was pretty rough in the beginning, but has steadily improved after years of volunteer work. Unfortunately wrapping C, or especially C++, code in Python is a lot of work, and making it nice to use is even more work…

23

UP!

I’m totally agree with him: this thing is very funny! All C++ method names in panda 3D are very pythonic while all Python method names are very unpythonic (http://www.python.org/dev/peps/pep-0008/)!

And i agree on “set/get” and “builtins” considerations too.

24

I’m wondering, would it be a good compromise to create a configuration variable that switches ShowBase’s usage of builtins ?

25

I was thinking of this too. It sounds like a good idea to me, and a good path forward out of this mess. Many of the systems in direct rely on the builtin pollution, but we can gradually repair those as we go.

David

26

It also might be an idea to replace all direct.* stuff and the samples plus other python code using the new packaging system, so the modules are reorganized better and people will start using the new packaging system.

I’m happy to contribute on releasing this :slight_smile:

27

Ah. So a variable like “showbase-use-builtins” (just throwing something in, shout if you know something better) would work? And I guess I could simply enable it and fix all the bugs that come up.

wvd, do you mean using the panda3d.* import structure? It’ll probably best to write a script to do that, later. Replacing all those imports manually will be a pain.

28

Sounds excellent. :slight_smile:

David

29

I guess I’ll throw my two cents in also…

I don’t see the problem with having set/get functions in Panda. When I code I always include set/get functions because I think that it looks neater (doesn’t help that I was taught this way).

30

omg, such an old thread.

I was pretty annoyed by the builtins at the beginning, but meanwhile i got used to them, so i’m neutral on that.

Something to add to the issues on top:

# won't work:
x, y, z = Vec3(1, 2, 3)
# works:
x, y, z = [i for i in Vec3(1, 2, 3)]

To the ideas with properties:
I thought about that as well, already, but a test showed me that they’re pretty slow.

31

Uh, this works great:

>>> from panda3d.core import Vec3
>>> x, y, z = Vec3(1, 2, 3)
>>> print x, y, z
1.0 2.0 3.0
32

yes!

Its been getting there slowly over time.

33

I think treeform missed it by a milimeter.

Panda3D shouldn’t be more pythonic, it should be more python-simple.

Look, all panda3d needs is to re-write some commands. It would end-up with the same thing for the PC, same code in the end.

But for the programmer it should be easier to nevigate through code, finding bugs, and it may speed up the deveploment.

How? Simply instead of writing one built-in command on 3-5 lines, write it in one line. Or at least in one bracket.

look, before:

def cmdO(bla, bla):
   bla bla = cmd(vbla)
   vbla = zbla+dbla

After:

cmd(vbla(zbla+dbla))

After alternative:

cmd( vbla(
          zbla+dbla
          ))
34

So your argument is that by making code more terse, you make it more readable? Sorry, I must respectfully (but emphatically) disagree with you on that point.

David

35

MentalDisaster, thats just bad.
Maybe you are some super smart guy with IQ 5000, and somehow find that code more readable, but i certainly dont.

Its better to use many simple statements than few comlicated.

What i would like to see in Panda is consistency in function naming, i can “guess” many functions without autocomplete, but several times i miss something because its make_me_do_something instead of makeMeDoSomething.

As far as i have seen until now camelCase is used generally, but here and there i run in some weird_named_function.

36

In my opinion the direction that Panda should be taking is to remove all of the python-only code and replace it with a C++ implementation. Also remove all of DirectBase and all of Framework. Same API for both languages, and no global variables. Only one instance to a Panda object, and let the user get the camera, the task manager, the render node, etc, from there. If they want to avoid typing they can easily clone a couple of references. To ease transition a compatibility module could be done that sets up the main variables, but I wouldn’t even bother.

This idea that a couple of setup steps would scary novice users seems to me like it brings more problems that it solves in the long-term. Better to not have any global variable at all and try to make the setup as simple as possible (from the core of the engine).

37

@MentalDisaster: that’s just silly, sorry.

I agree with Gogg. That’s why I think there should be an Actor and ShowBase rewrite to C++, in a way that it is usable by both languages.

38

I totally agree with Gogg.

39

As Panda core developers you know better, so probably you are right. But I released 11 games using several engines and reason why now I’m using Panda it’s because it’s very Pythonic. When I saw Panda first time I said: “Wow at least engine without plain copy of cpp in python, has global variables and framework - this is real pythonic way !”.
My previous engines also had python bindings, but trying to fetch everything, everytime, in many files it’s a pain, I lost in that and I had horrible problems with doubling handlers, refcount, segfaults.
Thats my 5 eurocents. :slight_smile:

40

Not to worry. I think it’s perfectly possible to reimplement Actor and ShowBase in C++ without losing their basic Pythonic nature.

And I also agree that this is a desirable goal. :slight_smile:

David