Here's a useful thread of conversation re supporting Pyglet on Jython. BTW, I just realized that I mixed up the ordering of talking about os and inspect; obviously os is where we need JNA.
---------- Forwarded message ----------
From: Jim Baker <james.edward.ba...@gmail.com>
Date: Mar 25, 12:07 pm
Subject: Pyglet on Jython
Thanks, this is very helpful. os and possibly inspect could be
problematic. But for the latter, that's one reason we are using JNA,
which is the basis of the ctypes for Jython work. There is also
ongoing porting of mmap and unicodedata to Jython. The other libraries
should work, at least once we get them up to 2.5 (or in this case,
2.4) support. Regardless, we want to find any such issues so we can
make Jython better. Re GC with respect to ctypes, this certainly could
be interesting, but it's exactly the sort of problem we need to solve.
On Mar 24, 3:41 pm, "Alex Holkner" <alex.holk...@gmail.com> wrote:
> On Tue, Mar 25, 2008 at 4:57 AM, Jim Baker <james.edward.ba...@gmail.com> wrote:
> > A GSoC applicant is interested in adding ctypes support to Jython. As
> > I understand it, Pyglet uses just pure Python with ctypes, so this
> > seems like a great way of having a testable target that could be very
> > useful. After all, why shouldn't Java platform users have fun? ;)
> Sounds good. pyglet probably exercises more of ctypes than any other
> library, using a mixture of both hand-written and generated code.
> > But since I don't use Pyglet (yet), we have some questions:
> > What's the minimum version of Python that is required? We are
> > currently moving quite fast on production 2.5 language support in
> > Jython, but there's more to Python than just that.
> Python 2.4 (with ctypes). Standard library modules used are:
> sys, warnings, select (Linux only), weakref, time, string, math, os,
> codecs, mmap (Linux only), struct, operator, re, array, zlib, inspect,
> unicodedata, pprint, traceback.
> > Are there any specific libraries that come to mind that could
> > potentially cause issues?
> pyglet may depend on undocumented GC behaviour in ctypes (it's not
> clear to me from the ctypes documentation alone when objects under
> pointers are released, for example). Because of this, and pyglet's
> extensive use of ctypes callbacks, it would probably be a good idea to
> leave pyglet testing until simpler libraries or examples are working.
> Happy to help out and fix pyglet bugs where needed.