Sadly Jython is really in catch up mode right now. So we can discuss our involvement when we actually start supporting 3.x ;). Having said that, I expect any work that PyPy does will be extremely helpful advance prep for our future work.

Not that it's so far off. It is possible that work on Jython 3.x could be seen in 2015, especially if we can continue to see committer support. (I should certainly thank Rackspace for making my time available.) For those who are interested, Jython 2.7 is currently somewhat stalled on socket/select/ssl support, but this work is finally coming together with the socket-reboot project which allows us to completely(*) support Python's C-oriented API on top of underlying Java support. I will have a complete status update prepared for the summit.

- Jim

*OK, "completely" does not mean functionality that assumes sockets are files, or a forking model of the world. Still pretty good, especially since this is close to the Windows model.


On Tue, Mar 11, 2014 at 8:58 AM, Brett Cannon <brett@python.org> wrote:


On Tue, Mar 11, 2014 at 4:36 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:


On 11 Mar 2014 09:10, "Antoine Pitrou" <antoine@python.org> wrote:
>
> On lun., 2014-03-10 at 16:02 -0700, Alex Gaynor wrote:
> > Hi all,
> >
> >
> > I'd like to propose Brian Kearns for commit. He's been a committer on
> > PyPy for about a year and a half now, and in particular he's done a
> > bunch of "Python version" works: things like upgrading us from the
> > 2.7.3 stdlib to the 2.7.6 stdlib, and py3k work. He's interested in
> > having commit for the purposes of doing interop work on the stdlib
> > tests: things like making sure tests aren't reliant on refcounting,
> > correctly marking tests as impl details, etc.
>
> I'd really prefer someone to have experience in contributing to CPython
> before they get commit rights. I might mistaken, but I can't find any
> contribution bearing Brain's name.
>
> Furthermore, giving arbitrary commit rights to core devs of third-party
> projects (such as PyPy and Twisted) doesn't seem to have produced any
> significant CPython contributions from them, IIRC.

Aye, our processes are currently arcane enough that posting a patch to the tracker is *less* work than doing the commit yourself (on the other hand, it depends on another human to get it committed).

On the other hand, if Brian has read PEP 462 and *still* wants to commit patches directly, then I wouldn't be opposed (given Alex's recommendation). Call it +0.


There's also precedent as Antoine alluded to; we previously gave two people on each major interpreter implementation commit rights to work on compatibility issues (Alex and Maciej represent PyPy directly, although obviously people like Armin had commit rights predating PyPy). But as Antoine also pointed out, the experiment never really went anywhere.

I still think it's a good idea, though, to get the other interpreters involved with helping with compatibility issues. I would be fine if Brian started out restricted to Lib/test to fix tests that weren't properly marked as implementation details, and if that went well then allowed to branch out to actually fixing compatibility bugs. If people are uncomfortable with even that restriction of abilities then we can do this the old fashioned way of Brian submitting patches through bugs.python.org before requesting commit privileges again.

_______________________________________________
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers