Create a Pythonic API

[GoogleCodeExporter]

The pybox2d library should allow access to the standard box2d-style API. It
should also have a secondary Pythonic, easy to use interface.

Original issue reported on code.google.com by sir...@gmail.com on 15 Jul 2008 at 6:11

[GoogleCodeExporter]

This is interesting -- this seems to suggest we should push the physics portion 
of
Elements [1] upstream to pybox2d. In this way, Elements would then tie together 
the
simple physics syntax of pybox2d with the simple drawing syntax of pygame.

[1] http://www.assembla.com/wiki/show/elements

Original comment by bcjor...@gmail.com on 19 Jul 2008 at 9:24

[GoogleCodeExporter]

In its current state, pybox2d has been deemed non-Pythonic and unusable by a few
users. With that in mind, an unpythonic Python library doesn't seem to have 
much of a
place. But how far should we take it?

The way I picture it is that pybox2d would be increased to cover a slightly 
higher
level. Perhaps some of its goals would overlap with Elements', but definitely 
not
all. I personally don't want it to encroach on Elements' territory by taking 
over
drawing (or interacting with any other libraries, for that matter).

Rather than decide this all myself, I was hoping to open this up to discussion.

[As far as Elements goes, I still haven't had any luck getting in contact with 
Chris.
I've been dying to get the spam off of the site and update a few of the things 
there...]

Original comment by sir...@gmail.com on 19 Jul 2008 at 11:25

[GoogleCodeExporter]

What do you mean by "slightly higher level" Sirkne? Drawing routines should be
independent of pybox2d. Also from my experience with pybox2d it is much better 
then
pymunk (the only usable alternative that i could find with reasonable community
support). By all means, make pybox2d more pythonic, however, the pybox2d api 
should
not deviate too far from the original box2d api, as this would mean less box2d
community support (If the api's significantly different from one another the 
box2d
community cannot relay their code/tutorials/help to pybox2d users). I am 
willing to
sacrifice pythonic code for community support. 

Original comment by neon...@gmail.com on 20 Jul 2008 at 9:57

[GoogleCodeExporter]

neonnds,

I fully agree with your desire for code-compatibility between the standard 
box2d and
pybox2d, for porting/documentation/support/etc reasons. As such, I fully intend 
to
keep the original API accessible through pybox2d.

The two options I see for the project now are:
(1) Leave pybox2d as it is, only modify things from Box2D as necessary to allow
functionality in Python
(2) Take pybox2d, create a secondary pythonic interface (extension?) at a 
"slightly
higher level":
* Allow for creation of shapes, bodies, etc. without requiring lengthy b2*Def's
* Increasing support for tuples in places where b2Vec2's are expected
* More generator usage (for enumerating shapes, bodies, etc.)
* Reducing slow callbacks by using lists (perhaps after some speed tests)
* Etc, etc.

If we choose option 2, how can we do it properly to avoid it interfering too 
much
with cross-compatibility? Does the community even want option 2? I would really 
love
some additional input from users, as I'll take the project where they want it 
to go.

Original comment by sir...@gmail.com on 22 Jul 2008 at 2:10

[GoogleCodeExporter]

I think option two is going to the extreme. It also creates more problems then 
it
solves. 

I see the following disadvantages / cons to the pythonic layer:

-The pythonic layer will need an additional level of support/documentation, 
which
will effectively cut into the time spent on insuring that pybox2d is working
correctly and version synced with box2d 

-Will adding a pythonic layer reduce the user-base of pybox2d? I don't think 
so, as
many physics library alternative do not currently have as many features 
(ray-cast,
sensors etc) or the same level of community support / documentation 

-As box2d's feature base increases so to will pybox2d's and its community / 
user base
(adding a pythonic layer will contribute to braking this bond)

-Pythonic code is only a nicety not a necessity (which is important to remember)

However on the flip side the advantages / pro's are:

-Python developers would be more inclined towards a pythonic API

-Also pymunk has a pythonic API (So a bit of competition if pybox2d does not 
have a
pythonic API? Maybe.)

-Making some things in the API pythonic and somethings non-pythonics can become
messy, so maybe its better to bite the bullet and make a distinctive 
pythonic-layer
for the sake of future maintenance of pybox2d.

I personally want pybox2d to be as bug free as box2d. And i think adding a 
pythonic
layer to pybox2d would cause more bugs, thus preventing people wanting to use 
it. On
the other hand if it can be insured bugs are reduced and time spent on 
documentation
/ community support is maintained at its current level, then i don't see why a
pythonic layer is not possible.

Original comment by neon...@gmail.com on 23 Jul 2008 at 6:17

[GoogleCodeExporter]

Support/documentation
As it is, the help from the other users in the Box2D forums (who aren't 
necessarily
using the python bindings) is indispensable. I couldn't possibly offer the same 
level
of support on my own during or after the creation of a pythonic layer, as I'm 
only
one person doing this as a little thing on the side. As far as bugs go, I hope 
to
come up with some unit tests to insure a bit of stability over the versions. 
(It's
terrible to have a python library that doesn't do unit testing…)

User-base
I was hoping to expand the user-base by making it more pythonic. There are 
hundreds
of people downloading the bindings, yet very few projects popping up that are 
even
considering using them. Is it because of the ugly C-style usage? Is it just too
difficult? Is there still a lack of documentation for the python version? 
Perhaps if
I wait a bit more, the complaints and/or projects will start popping up.

Necessity/nicety
Certainly, it isn't a necessity (for most people). It just seems like there are 
some
advantages that python could provide for ease of use that would just make 
coding so
much easier in most cases. 

There's definitely competition from pymunk (which is a great library, and I'd 
be just
as happy to see people use it). There'll also be a physics extension in one of 
the
coming versions of pygame – and my guess is that it'll be pythonic also. 

A half-assed implementation of a pythonic layer would undoubtedly cause a lot of
problems. I guess given your good argument, plus the fact that it's so much 
easier to
leave pybox2d at a bare-minimum port of the original, I'll indefinitely put the
pythonic layer on hold.

Original comment by sir...@gmail.com on 24 Jul 2008 at 6:32

• Changed state: Onhold

[GoogleCodeExporter]

I'm insterested to see what the pymunk community has to say on the matter. And 
why
they use pymunk over pybox2d (which is the obvious better solution from a 
features
perspective). I think the primary reason for people using pymunk over pybox2d 
is that
people hear about pymunk before pybox2d (that was my case). I think if you wait 
it
out pybox2d will be the physics engine to use for python developers. Also to 
make
pybox2d more appealing insure that its really, really, really easy to install. I
found installing it for osx was more tricky then pymunk. At the end of the day, 
if
people can install it, look at demos, know that it is not buggy, they will use 
it
even if its not pythonic. Keep up the good work :) When i have some free time i 
will
be happy to help out.

Original comment by neon...@gmail.com on 24 Jul 2008 at 7:45

[GoogleCodeExporter]

Thanks for your input, by the way, it's much appreciated. 

As far as easy installation goes, it's always been one of my goals, but I've 
never
had access to an OSX machine to create an installer on. If you have any hints 
for
other users trying to install it, please share them. My goal is a universal OSX
installer -- if you think you can help out with that goal, I'd be more than 
happy to
add you onto the team. :)

Original comment by sir...@gmail.com on 24 Jul 2008 at 8:20

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I have written up a little guide for osx users. It's not anything special, and 
by no
means takes the technical edge of the whole installation process, however may 
find it
helpful :P

Original comment by neon...@gmail.com on 24 Jul 2008 at 1:24

Attachments:

• INSTALL_OSX.txt

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I think adding a pythonic layer wouldn't cause much bugs if test cases for its 
features are made. 

I also agree implement and mantaining them would take lots of extra work, 
specially 
in the beginning.

My opinion is: don't do the pythonic layer now. I think people that are using 
pybox2d aren't absolutely needing it (I'm not), and surely you got more 
important 
things to do. I also don't think a pythonic layer would attract much more 
people to 
pybox2d. I believe there are other reasons for people not using it much.

Meanwhile, we could plan the features this layer would have! As you already 
proposed, I'm very favorable to:
* Allow for creation of shapes, bodies, etc. without requiring lengthy b2*Def's
* Increasing support for tuples in places where b2Vec2's are expected

Original comment by msiegwarth@gmail.com on 27 Oct 2008 at 12:03

[GoogleCodeExporter]

As submitted in a separate issue report, I think supporting EGG (easy_install) 
would make pybox2d much 
more accessible to Linux and OS/X developers. Both OS/X and most Linux 
distributions include easy_install by 
default, and if pybox2d were submitted to PyPi (http://pypi.python.org/pypi) 
prospective developers could 
add it with "easy_install pybox2D".... (or easy_install Box2D, which seems like 
the way people have been going 
w/ EGG naming).

I've been using pybox2d in my app (not really of general public interest, 
though I'll eventually get around to 
releasing it), and I have to say when you're evaluating libraries at the start 
of a project, ease of "getting her 
going" and installed makes a pretty big difference. That combined with good 
demos (the testbed is great for 
this, but its a little hard to find in the directory structure)...

Original comment by snick...@gmail.com on 28 Oct 2008 at 8:07

[GoogleCodeExporter]

I read some chat here about making a more "pythonic" interface to box2d. 
Excellent
idea! I'm wrapping Box2D with Boost.Python, just for fun. Far from mirroring 
the C++
interface, my plan is to add hefty swoudjes of functionality in python (like 
merging
bodies, automatic gear ratio calculation, helpers for chains, ui for building 
bodies,
gametastic goodness?).

It's rudimentary at this point, but there is a sandbox sample app with a mouse 
joint.
Beware: This software may not make the slightest bit of sense. 8o

git clone git://github.com/blak3mill3r/pybox2d.git

send me an email if you like: blak3mill3r&gmail^com

I've heard unconfirmed rumors that Boost.Python extensions perform significantly
better than their SWIGgy sisters.

(I am not knocking SWIG, for SWIG is very cool)

http://osdir.com/ml/programming.swig/2003-12/msg00086.html

Original comment by blak3mil...@gmail.com on 18 Dec 2008 at 5:23

[GoogleCodeExporter]

Original comment by sir...@gmail.com on 11 Sep 2009 at 12:04

• Changed state: WontFix

[GoogleCodeExporter]

Original comment by sir...@gmail.com on 12 Apr 2011 at 12:39

• Changed state: Fixed