pylygon - 1.0

alright then. I can change the naming scheme if that will better accord to convention.

the API will not have to change, the __init__ file will simply need to be modified.

thanks for the tip on planar. it looks like planar could benefit from the functionality provided by the GJK and GJK-raycast algorithms, but otherwise has all the same features (and much much more) as pylygon. and it is developed by Casey Duncan. my noiselib library was born from his C implementation of Perlin noise.

I have to agree with Xandar. This is a good start of a library. However, to the majority of those that use Python (at least as I have gleaned from user feedback), ease of use and conformance to accepted standards are almost as important as functionality itself.

I would highly recommend renaming classes like 'Main' to be what they actually represent. Similarly, modules with an initial underscore usually indicate that they are compiled C/C++ extensions. (see http://www.python.org/dev/peps/pep-0008/ ). It might just be me, but I like having the examples modify the system path (i.e., add '..' in your case) to find the library so I don't have to install the library just to try the examples out.

Have you thought about possibly integrating your ideas with planar ( http://pypi.python.org/pypi/planar/ )? I have yet to see another library do better than it for representing planar objects.

And finally, in defense of Box2D, "top-down friction" is possible with the friction joint.

I'm so happy someone else found the code useful!

I should have been converting things to ints in the examples, my OS X system give 'deprecation warngings' but I just ignored them. I'll make a minor update and fix that in the examples.

The naming convention is a bit indirect but it makes me feel happy. I adopted it because I like each file to be about one thing and that thing is named Main or main. the Polygon object of the polygon file seems redundant to me. I prefer the Main object of the polygon file. I always rename things using the __init__ file so that the API isn't so indirect. I think naming the primary object of each file as 'Main' enforces that each file is about one thing, and stresses that this thing named Main is what that file is about.

Your point regarding the terseness of names is well taken. 'centroid' is definitely more descriptive. I like terse names because they often look leaner and less cluttered. I think it is a hard call, but If there is a conventional symbol for a thing, like 'C' for centroid or 'a' for area, I will often use the symbol instead of a more descriptive name.

Thank you for sharing your code! I think this type of library is a great resource for others.

I had a little trouble getting it to run on my Debian/Kubuntu 11.04 system (Python 2.7.1, pygame 1.9.1). When running examples/collidepoly.py for example, I get this error:

Traceback (most recent call last):
File "c1.py", line 67, in <module>
draw.circle(SCREEN, (255, 255, 255), triangle.C, 3)
TypeError: integer argument expected, got float

I need to add this function:

def make_int( t ):
return int( t[0] ), int( t[1] )

and change the lines to:

draw.circle(SCREEN, (255, 255, 255), make_int( triangle.C ), 3)
draw.circle(SCREEN, (255, 255, 255), make_int( rhombus.C ), 3)

By the way, I understand that you transcribed the algorithms from another source, but I found some of the naming non-intuitive. Like "C" means "centroid". Well, why not name the function "centroid"? Or "_A" means "area". Similarly for the names of the polygon, line, and convexhull classes all being called Main. I don't understand why they have such an indirect abstraction.

Still, this is good, thank you.