Sorry, I forgot to reply-to-all... still getting used to GMail. :-)
Here's the message I sent to Nicholas.
---------- Forwarded message ----------
From: John Szakmeister <john@...>
Date: Wed, Mar 26, 2008 at 4:17 AM
Subject: Re: [Jython-dev] Exposing the posix module...
To: Nicholas Riley <njriley@...>
On Tue, Mar 25, 2008 at 9:00 PM, Nicholas Riley <njriley@...> wrote:
> In article
> "John Szakmeister" <john@...> wrote:
> > I'm making some headway towards having a posix module using the JRuby
> > implementation as a starting point (their code is unmodified at the
> > moment, so the org.jruby namespace is still being used).
> That's probably OK in the long run to; we can use jarjar to wrap it in
> org.python as happens with ASM for the new compiler.
> > So I have several questions:
> > 1) I need to maintain a member variable to the posix internals... do
> > we want that shared across all the interpreters running in the same
> > JVM? I'm implementing the module using ClassDictInit, so right now I
> > have a static member variable being used.
> It sounds like you're trying to do this from Java. Why not implement it
> in Python?
Ignorance. It seemed fairly straightforward... until I ran into the
Python/Java edge. :-) Although, I don't think it's that much simpler
from the Python side. Things like getting a stream to the current
stderr and stdout (presumably from sys.stderr and sys.stdout) will
still require some work since they can be replaced, right?
> Did you see the sample implementation work the JRuby guys did? I
> cleaned it up a bit and implemented chmod last week:
I did not. I had to bail mid-day Monday, so I missed much of the
sprinting... which was the best part! I know better for next year.
Did they end up packaging the jna-posix stuff as a separate jar? Is
their repo going to be the canonical place for it? I'm asking so I
know where to post patches, if necessary.
> Probably the _posix/PythonPOSIXHandler stuff should be in a _posix
> module or something, since it'll be used by more than the os module.
> One important issue is error handling. I sent an email to Thomas Enebo
> about this and he responded:
[snip long passage about errno support]
Looks like we got our work cut out for us on the errno side.
> CPython's tests appear to check for the exception type but not for the
> message, so it will probably take some trial and error to get this stuff
> to work.
> > 4) What's the best way to integrate this into Jython? I can sit
> > here on my own, using Bazaar to keep track of what I'm doing, but I'd
> > much rather it be a collaborative effort... out in the open. Would it
> > be possible to get commit access to a branch for this work? That
> > would make it easier for you guys to see what's going on and provide a
> > mechanism to get the work integrated back into trunk easily. If a
> > patch bomb is the way to go, I can do that too. :-)
> Can you publish your Bazaar repository somewhere? Merging in Subversion
> is pretty painful, so I imagine you'd be happier if you just kept using
> Bazaar. My exposure to Bazaar has consisted of the shirt I got at PyCon
> but hopefully this is easy to do like it is in Git and Mercurial.
> On the other hand, if you're just implementing new, self-contained
> functionality, it doesn't sound like you need a branch at all; you can
> just develop directly on trunk.
Merging wouldn't be all that painful in this case... since it doesn't
really step on anyone else's current work. I proposed a separate
branch because I don't currently have commit access at all, and
figured it would be easier to give me commit access to branch rather
than giving me outright access to trunk. Either way, if this ends up
being a lengthy change, it would be much better to do it in the open
where committers can actually see how things are progressing. I don't
care much one way or another. I can do whatever works best for you
BTW, I don't want to step on anyone's toes. If someone else
(Alexandru or a GSoC student) wants to do this, I'll happily work on
something else (like the compiler). I'm very flexible in that regard.