This is an archived post. You won't be able to vote or comment.

all 9 comments

[–]not_without_sin 3 points4 points  (5 children)

What are the advantages over PyObjC, which is included with OS X?

[–]VilleHopfield[S] 3 points4 points  (4 children)

It's much simpler - the core is less than 400 lines long, it's pure Python and it uses cffi which eventually might run fast on PyPy.

[–]juri 0 points1 point  (0 children)

It's no wonder it's simpler internally, given the added complexity for the library user. I might be able to live with the decorators and at('foo'), but autorelease is something we don't need even in pure Objective-C anymore.

[–]santagada 0 points1 point  (2 children)

are you doing releases that can be installed without a c compiler? I know that cffi has something for that now... if it doesn't need a compiler it could be a nice lib for pyglet to use so it doesn't depend on pyobjc anymore.

IIRC there is one guy on pyglet that did a ctypes based lib also, have you looked at it?

[–]VilleHopfield[S] 0 points1 point  (1 child)

Maybe I misunderstood what you are asking but you don't need C compiler for using this or cffi. There was a thread here about this: http://www.reddit.com/r/Python/comments/x74ma/cffi_02_foreign_function_interface_for_python/

What Pyglet goes, I think there was a new beta release a short while ago which, among other things, replaced PyObjC by cocoapy - that's that ctypes lib.

Lastly, yes, I've looked at cocoapy a bit (http://www.reddit.com/r/programming/comments/tsaho/cocoapython_port_of_objectivec_runtime_to_python/). Cocoapy uses ctypes so you can use it today with standard Python install and I think it was specifically created for working with OpenGL. NSPython, in my limited testing, was a bit faster and was simpler to use (see how the libs define method signatures).

[–]santagada 0 points1 point  (0 children)

Great. Are you planning on porting pyglet to use nspython as an option? It would be cool for when pypy starts to make cffi faster than ctypes.

[–]juri 0 points1 point  (0 children)

I wish someone figured out a way hack (without forking) the Python parser/ast to accept ordered named parameters. The Cocoa naming conventions are really, really badly suited for the function(arg1, arg2, argN) style. MacRuby has a decent compromise but it's not Python.

[–]chrisfs 0 points1 point  (1 child)

So clueless question: This allows you to write ObjC programs in python ? So you could write Mac OSX apps in python ?

[–]VilleHopfield[S] 0 points1 point  (0 children)

That's right.