On Nov 24, 10:53 pm, Nathan <[email protected]> wrote:
> On Thu, Nov 24, 2011 at 7:26 PM, Tristam MacDonald <[email protected]> 
> wrote:
> > Let be very explicit here. As I understand it:
> > pyglet trunk contains a Cocoa implementation via PyObjC, which works on
> > Apple's stock python, and occasionally works on other python packages, but
> > notably does not work on PyPy.
> > evilphillip-cocoa-ctypes, regardless of whether it is maintained, contains a
> > Cocoa implementation via a custom ctypes layer, *without* PyObjC, which
> > should (when complete) run on *all* python packages, including PyPy.
> > Am I correct?

Yes, that's correct.  To add to that, back when I was still working on
this, I wrote a third cocoa implementation for pyglet based on ctypes,
which arguably looks a bit nicer than what's in evilphillip-cocoa-
ctypes (no more send_message and no more specifying argument and
return types with each call) but is still kind of rough. I would like
to eventually replace the trunk with this code, however I just haven't
had time to do any work on it and I don't want to simply obliterate
PyObjC implementation which does work.  I also haven't had a chance to
see how this implementation interacts with PyPy.  I would post it as
another branch or clone, but I think things are confusing enough as it
is.

I feel like it would be a good idea to have an official release of 1.2
containing the PyObjC backend before I start completely changing
what's in the trunk.

> That's a great conversation to have.  To help determine the best
> long-term strategy for 64-bit support on OS X, I would add the
> questions:
>
> - What are the pros/cons of a ctypes implementation in general?
> - What are the pros/cons of a PyObjC implementation in general?
>
> From the (admittedly limited) information I have run across so far, it
> would seem that ctypes implementation has the major advantage of being
> able to be run by more python environments than the PyObjC
> implementation, and the disadvantage of being more work to implement.
> If that major advantage is important to people willing to contribute
> coding time.
>
> I've been a lurker on the PyObjC mailing list for many years now, ever
> since I heard of it, got interested in maybe using it, but then never
> did.  From what I see, PyObjC is a one-man project that doesn't get a
> whole lot of attention, as the mailing list is extremely low traffic.
> Occasionally when things break, or changes happen to OS X, PyObjC
> seems to take awhile to catch up.  To the his credit, that one guy
> seems to do a great job when he has the time to work on it.  I don't
> know much more about it than that.

This is my impression also.

--phillip

-- 
You received this message because you are subscribed to the Google Groups 
"pyglet-users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/pyglet-users?hl=en.

Reply via email to