[python-committers] Brian Kearns for commit

Jim Baker jbaker at zyasoft.com
Tue Mar 11 17:23:06 CET 2014


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 at python.org> wrote:

>
>
> On Tue, Mar 11, 2014 at 4:36 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>>
>> On 11 Mar 2014 09:10, "Antoine Pitrou" <antoine at 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.orgbefore requesting commit privileges again.
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140311/d1ca5482/attachment.html>


More information about the python-committers mailing list