Re: [python-committers] Davin Potts as a new committer

[Berker Peksağ]

On Sat, Mar 5, 2016 at 8:44 AM, Gregory P. Smith  wrote:
>
> On Fri, Mar 4, 2016 at 10:07 PM Raymond Hettinger
>  wrote:
>>
>>
>> > On Mar 4, 2016, at 4:07 PM, Brett Cannon  wrote:
>> >
>> > I guess I'm just worried about the health of this project. I'm doing
>> > what I can through the migration to GitHub to make it easier for others to
>> > get involved while making it easier for us to accept the work of others, 
>> > but
>> > the maintenance and health of this team worries me. For instance, if you
>> > look at the developer's log you will notice we only gained 2 core devs for
>> > all of 2015 and the last one was August 2015:
>>
>> Last year on this list, I recommended that Davin Potts be granted core
>> developer status for his on-going work on the multiprocessing module.  This
>> group collectively said no, leaving Davin in an odd and uncomfortable limbo.
>
>
> Huh?  Searching for Davin Potts in my mail, I see a ~27 message long thread
> from January 2015 about that.  Many of us were +1 to give him commit rights.
>
> I personally assumed it had happened, but the only objections seemed to be
> "lets see some patches first"... That part has happened:
>
> Among the other things in my mail with Davin's name mentioned are several
> streams of committed patches over the past year or so on multiprocessing
> related issues (as expected), including recently.
>
> berker.peksag, martin.panter and serhiy.storchaka have been the primary
> committers of said Davin patches.

+1!

I was going to send an email to python-committers about this a couple
weeks ago, but I couldn't find enough time (or I was just lazy :)) to
collect issue numbers (he did a great job on triaging old
multiprocessing issues) and commits.

I'm willing to mentor/co-mentor him if there's no other candidate.

--Berker
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Davin Potts as a new committer

[Ned Deily]

On Mar 5, 2016, at 01:44, Gregory P. Smith  wrote:
> I personally assumed it had happened, but the only objections seemed to be 
> "lets see some patches first"... That part has happened:
> 
> Among the other things in my mail with Davin's name mentioned are several 
> streams of committed patches over the past year or so on multiprocessing 
> related issues (as expected), including recently.
> 
> berker.peksag, martin.panter and serhiy.storchaka have been the primary 
> committers of said Davin patches.
> 
> Let's get Davin a commit bit.

+1, Davin has been doing a great job supporting multiprocessing

--
  Ned Deily
  n...@python.org -- []

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Making the PSF CoC apply to core developers

[Antoine Pitrou]

Le 05/03/2016 07:07, Raymond Hettinger a écrit :
> 
>> On Mar 4, 2016, at 4:07 PM, Brett Cannon  wrote:
>>
>> I guess I'm just worried about the health of this project. I'm doing what I 
>> can through the migration to GitHub to make it easier for others to get 
>> involved while making it easier for us to accept the work of others, but the 
>> maintenance and health of this team worries me. For instance, if you look at 
>> the developer's log you will notice we only gained 2 core devs for all of 
>> 2015 and the last one was August 2015:
> 
> Last year on this list, I recommended that Davin Potts be granted
> core
developer status for his on-going work on the multiprocessing module.
This group collectively said no, leaving Davin in an odd and
uncomfortable limbo.

This is a partial way to put it.  You recommended Davin while he had no
experience contributing to CPython.  This was why your proposal was
rejected, and it was the only decent answer to your proposal IMHO.  It
is unfair to promote people on the basis of their sole name or
professional occupation (not to mention that those can be very
inefficient criteria in practice...), all the while asking others to
prove themselves through patches and code reviews.

(see
https://mail.python.org/pipermail/python-committers/2015-January/003240.html
-- note mail.p.o seems down here and now)

If we want contributors to feel they are treated equally and decently
regardless of their personal acquaintances or non-CPython experiences,
then we should continue judging them on the basis of their actual
contributions, not some a priori positive feelings about them.  I think
most people on this list agree this is necessary.

Regards

Antoine.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Making the PSF CoC apply to core developers

[Ned Deily]

In article <20160305043104.60898b14...@webabinitio.net>,
 "R. David Murray"  wrote:
> Remember how new committers happen: current committers notice their
> contributions on the tracker, suggest they be given the commit bit and
> offer to mentor them, and we take a poll.  The critical bits here are
> (1) noticing and (2) being willing to mentor.  So, if we want more
> committers, current ones need to put forth the effort to monitor active
> bugs, evaluate prospects, and recommend and mentor them.  And hopefully
> do some mentoring via the bug tracker to get more people commit-bit ready.
> 
> This is a catch 22: we need more active committers in order to get
> more active committers.  But we know that; that question is what to do
> about it.
> 
> I the past few years I've monitored the bug tracker fairly closely, and
> watched for good prospects, and recommended or inspired the recommendation
> of several.  Right now I don't have the time to monitor the bug tracker
> the way I had been and watch people the way I had been, so I won't be
> in a position to recommend anyone for the next while

I don't think any of us truly understand how much time you have put into 
this kind of behind-the-scenes activity over the years nor fully 
appreciate how important that has been to the on-going success of 
python-dev.  Thanks, David.

> PS: Actually, let me throw out that the people that had been at the
> top of my list before I stopped were eryksun, paul.j3 (for argparse),
> and davin (for multiprocessing).

I agree with your recommendations for all three.

-- 
 Ned Deily,
 n...@python.org

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] CFFI is slow (was: Re: Redoing the C API?)

[Stefan Krah]

Larry Hastings  hastings.org> writes:
> If we could wave a magic wand and get all extension authors to
> switch to writing their extensions in Python and using cffi, we
> should absolutely do it.

CFFI is slow. This would effectively kill one of the strongholds of CPython.
IMO CPython's C-API is the best out there and a large part of Python's success.

We're talking about a slowdown of at least an order of magnitude here:


  https://mail.python.org/pipermail/python-dev/2013-December/130772.html


I think people who don't need the C-API can use PyPy.




Stefan Krah

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Making the PSF CoC apply to core developers

[Serhiy Storchaka]

On 05.03.16 10:18, Ned Deily wrote:

In article <20160305043104.60898b14...@webabinitio.net>,
  "R. David Murray"  wrote:

I the past few years I've monitored the bug tracker fairly closely, and
watched for good prospects, and recommended or inspired the recommendation
of several.  Right now I don't have the time to monitor the bug tracker
the way I had been and watch people the way I had been, so I won't be
in a position to recommend anyone for the next while


I don't think any of us truly understand how much time you have put into
this kind of behind-the-scenes activity over the years nor fully
appreciate how important that has been to the on-going success of
python-dev.  Thanks, David.


Want to join the acknowledgement. David's work is invaluable.


PS: Actually, let me throw out that the people that had been at the
top of my list before I stopped were eryksun, paul.j3 (for argparse),
and davin (for multiprocessing).


I agree with your recommendations for all three.


I haven't been following the activity in the argparse module, but
I'm watching Eryk Sun and was going to offer his candidacy if it will 
retain his activity over the next few months.



___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Davin Potts as a new committer

[Serhiy Storchaka]

On 05.03.16 09:21, Berker Peksağ wrote:

On Sat, Mar 5, 2016 at 8:44 AM, Gregory P. Smith  wrote:

On Fri, Mar 4, 2016 at 10:07 PM Raymond Hettinger
 wrote:

On Mar 4, 2016, at 4:07 PM, Brett Cannon  wrote:

I guess I'm just worried about the health of this project. I'm doing
what I can through the migration to GitHub to make it easier for others to
get involved while making it easier for us to accept the work of others, but
the maintenance and health of this team worries me. For instance, if you
look at the developer's log you will notice we only gained 2 core devs for
all of 2015 and the last one was August 2015:


Last year on this list, I recommended that Davin Potts be granted core
developer status for his on-going work on the multiprocessing module.  This
group collectively said no, leaving Davin in an odd and uncomfortable limbo.



Huh?  Searching for Davin Potts in my mail, I see a ~27 message long thread
from January 2015 about that.  Many of us were +1 to give him commit rights.

I personally assumed it had happened, but the only objections seemed to be
"lets see some patches first"... That part has happened:

Among the other things in my mail with Davin's name mentioned are several
streams of committed patches over the past year or so on multiprocessing
related issues (as expected), including recently.

berker.peksag, martin.panter and serhiy.storchaka have been the primary
committers of said Davin patches.


+1!

I was going to send an email to python-committers about this a couple
weeks ago, but I couldn't find enough time (or I was just lazy :)) to
collect issue numbers (he did a great job on triaging old
multiprocessing issues) and commits.


+1 from me. I have committed not too much Davin's patches (they were not 
easy), but confirm his proficiency. We need an expert in this domain.



___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] CFFI is slow (was: Re: Redoing the C API?)

[Stefan Krah]

Stefan Krah  bytereef.org> writes:
> We're talking about a slowdown of at least an order of magnitude here:
> 
>   https://mail.python.org/pipermail/python-dev/2013-December/130772.html
> 
> I think people who don't need the C-API can use PyPy.


Or, of course, use CPython with Numba, which handles an ever increasing
amount of traditional bottlenecks:  For example, it is possible to write a
"native speed" transpose function for NumPy arrays in plain Python.



Stefan Krah

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] CFFI is slow

[Larry Hastings]

I guess I have two responses to that.

1. I don't know what it is about cffi that makes it slow.  Perhaps it 
could be improved?  If it got a lot of traction, maybe it'd get more 
eyes looking at it?


2. How important is this speed difference?  I suppose the answer, as 
always, is "it depends".  It depends on how often you call the C 
library, and how long you spend in the routine when you get there.  
Certainly a benchmark for library X is a worst-case scenario; in 
real-world code, for most libraries, perhaps the performance of the glue 
code isn't crucial.


I always feel a little funny when people talk about performance in 
Python.  Not that I believe performant Python isn't possible or 
desirable--just that, if you're writing your code in Python, you've 
already implicitly conceded that performance is not your top priority.  
The design of Python the language, and of CPython the interpreter, is 
necessarily a series of tradeoffs, and it's not like those tradeoffs are 
always made in favor of performance.


Plus, this change itself would be such a tradeoff.  We'd (likely) be 
giving up performance of glue code for C libraries, and in return for 
this we could finally perform the brain surgery on CPython that we're 
all dying to do.  It's reasonable to suggest that such radical changes 
to CPython might "pay" for the loss of performance in the glue code.



Of course this is all academic.  I absolutely don't think we can get rid 
of the C API, or even modify it in any meaningful way that would let us 
abstract away implementation details like reference counting.  As I said 
in my original email, this magic wand simply doesn't exist.



//arry/

On 03/05/2016 12:42 AM, Stefan Krah wrote:

Larry Hastings  hastings.org> writes:

 If we could wave a magic wand and get all extension authors to
 switch to writing their extensions in Python and using cffi, we
 should absolutely do it.

CFFI is slow. This would effectively kill one of the strongholds of CPython.
IMO CPython's C-API is the best out there and a large part of Python's success.

We're talking about a slowdown of at least an order of magnitude here:


   https://mail.python.org/pipermail/python-dev/2013-December/130772.html


I think people who don't need the C-API can use PyPy.




Stefan Krah

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/


___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Redoing the C API?

[Paul Moore]

On 5 March 2016 at 04:25, Larry Hastings  wrote:
> * The only exception I know of is Lua--are there more?

TCL and Racket (was mzscheme). I think the key thing is that languages
designed for embedding provide a C API. Python supports embedding, so
if we did move away from the C API, we'd need to be very careful not
to make it harder to embed Python (or deprecate embedding altogether,
but I don't think that's realistic - quite a few projects embed
Python).

Paul
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] CFFI is slow

[Stefan Krah]

Larry Hastings  hastings.org> writes:
>   2. How important is this speed difference?  I suppose the answer,
>   as always, is "it depends".  It depends on how often you call the
>   C library, and how long you spend in the routine when you get
>   there.  Certainly a benchmark for library X is a worst-case
>   scenario; in real-world code, for most libraries, perhaps the
>   performance of the glue code isn't crucial.

Several of the early adopters of library X were the sqlalchemy people,
who absolutely had real-world issues.



>   Of course this is all academic.  I absolutely don't think we can
>   get rid of the C API, or even modify it in any meaningful way that
>   would let us abstract away implementation details like reference
>   counting.  As I said in my original email, this magic wand simply
>   doesn't exist./arry


Sorry for misquoting, indeed you said that. I was a little concerned that
CFFI was mentioned by several people as a solution and wanted to highlight
the drawbacks.


Stefan Krah
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] CFFI is slow

[Antoine Pitrou]

Le 05/03/2016 10:31, Larry Hastings a écrit :
> 
> I always feel a little funny when people talk about performance in
> Python.  Not that I believe performant Python isn't possible or
> desirable--just that, if you're writing your code in Python, you've
> already implicitly conceded that performance is not your top priority. 
> The design of Python the language, and of CPython the interpreter, is
> necessarily a series of tradeoffs, and it's not like those tradeoffs are
> always made in favor of performance.

Agreed. However, if the kind of performance problem you have is the kind
where you have a couple well-known critical paths, it is possible to
speed that up significantly using either raw C, or Cython, or even Numba
in some cases as Stefan mentions.  Not to mention of course any
third-party library that might already have done the work for you (in
the field of scientific computing, there are many of them).

For the other kind of Python performance problem, where the slowness
comes from a long convoluted critical path crossing a lot of high-level
interfaces, then PyPy is currently king and I expect it to remain it for
a long time.

> Plus, this change itself would be such a tradeoff.  We'd (likely) be
> giving up performance of glue code for C libraries, and in return for
> this we could finally perform the brain surgery on CPython that we're
> all dying to do.  It's reasonable to suggest that such radical changes
> to CPython might "pay" for the loss of performance in the glue code.

This is all overlooking the fact that the C API isn't merely used for
low-level binding to third-party C libraries (something which Cython
allows you to do without writing C code, btw, and AFAIU Cython kindof
has a PyPy backend?).  The C API allows you to write extension types, or
accces interpreter structures for other purposes.  Those uses aren't
catered for by cffi, by design.

Regards

Antoine.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] CFFI is slow

[Terry Reedy]

On 3/5/2016 4:31 AM, Larry Hastings wrote:


2. How important is this speed difference?


I believe Pygame originally used SWIG or something similar to wrap the 
underlying C SDL library.  When a ctypes version was tried, it was much 
slower, so slow that they stayed with the original wrapping.  I don't 
know what they are doing now.



 I suppose the answer, as
always, is "it depends".  It depends on how often you call the C
library, and how long you spend in the routine when you get there.
Certainly a benchmark for library X is a worst-case scenario; in
real-world code, for most libraries, perhaps the performance of the glue
code isn't crucial.

I always feel a little funny when people talk about performance in
Python.  Not that I believe performant Python isn't possible or
desirable--just that, if you're writing your code in Python, you've
already implicitly conceded that performance is not your top priority.


One reason for wrapping 3rd party C code is because reasonable 
performance *is* a priority in some situations.



The design of Python the language, and of CPython the interpreter, is
necessarily a series of tradeoffs, and it's not like those tradeoffs are
always made in favor of performance.


Part of the design of CPython, and what makes its relative slowness more 
tolerable, is the possibility to convert bottleneck Python code to C. 
We even do that within the stdlib.  Currently, those conversions are 
sufficient for me, and I have no need to do any conversions myself.  But 
I like knowing that I have to option to trade personal effort for better 
performance should I need it.  If I had to go that route, I would first 
try Cython.  So I would not much care what happened to the C API as long 
as Cython was not (permanently) disabled.


tjr

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Davin Potts as a new committer

[Brett Cannon]

Who wants to be Davin's mentor and tell him to do the steps outlined in
https://docs.python.org/devguide/coredev.html#gaining-commit-privileges ?

On Sat, 5 Mar 2016 at 01:04 Serhiy Storchaka  wrote:

> On 05.03.16 09:21, Berker Peksağ wrote:
> > On Sat, Mar 5, 2016 at 8:44 AM, Gregory P. Smith 
> wrote:
> >> On Fri, Mar 4, 2016 at 10:07 PM Raymond Hettinger
> >>  wrote:
>  On Mar 4, 2016, at 4:07 PM, Brett Cannon  wrote:
> 
>  I guess I'm just worried about the health of this project. I'm doing
>  what I can through the migration to GitHub to make it easier for
> others to
>  get involved while making it easier for us to accept the work of
> others, but
>  the maintenance and health of this team worries me. For instance, if
> you
>  look at the developer's log you will notice we only gained 2 core
> devs for
>  all of 2015 and the last one was August 2015:
> >>>
> >>> Last year on this list, I recommended that Davin Potts be granted core
> >>> developer status for his on-going work on the multiprocessing module.
> This
> >>> group collectively said no, leaving Davin in an odd and uncomfortable
> limbo.
> >>
> >>
> >> Huh?  Searching for Davin Potts in my mail, I see a ~27 message long
> thread
> >> from January 2015 about that.  Many of us were +1 to give him commit
> rights.
> >>
> >> I personally assumed it had happened, but the only objections seemed to
> be
> >> "lets see some patches first"... That part has happened:
> >>
> >> Among the other things in my mail with Davin's name mentioned are
> several
> >> streams of committed patches over the past year or so on multiprocessing
> >> related issues (as expected), including recently.
> >>
> >> berker.peksag, martin.panter and serhiy.storchaka have been the primary
> >> committers of said Davin patches.
> >
> > +1!
> >
> > I was going to send an email to python-committers about this a couple
> > weeks ago, but I couldn't find enough time (or I was just lazy :)) to
> > collect issue numbers (he did a great job on triaging old
> > multiprocessing issues) and commits.
>
> +1 from me. I have committed not too much Davin's patches (they were not
> easy), but confirm his proficiency. We need an expert in this domain.
>
>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Making the PSF CoC apply to core developers

[Georg Brandl]

On 03/05/2016 01:07 AM, Brett Cannon wrote:
> 
> 
> On Fri, 4 Mar 2016 at 15:07 R. David Murray  > wrote:
> 
> On Fri, 04 Mar 2016 21:31:44 +, Brett Cannon  > wrote:
> > The discussion about the Code of Conduct has sputtered out, so I'm 
> going to
> > assume those who care to speak up have at this point. It seems to me 
> that
> > the general agreement is that putting python-dev and bugs.python.org
>  under
> > the CoC might not solve any real issues we currently have, but it won't
> > hurt anything either (and both python-committers and python-ideas are
> > already covered). And since the CoC might make some people feel more
> > comfortable in participating, that means going ahead and flipping on the
> > CoC where we reasonably can.
> 
> I guess I have one more thing to say.
> 
> Thinking about this, I realized that in fact this emphasis on the CoC is
> making me feel less like contributing.  I doesn't feel like a large
> effect, but it is real[*].  Just thought you should know :)
> 
> 
> I'm sorry if that's what this thread has caused for you, David, and it's
> obviously not what I'm after.
> 
> I guess I'm just worried about the health of this project. I'm doing what I 
> can
> through the migration to GitHub to make it easier for others to get involved
> while making it easier for us to accept the work of others, but the 
> maintenance
> and health of this team worries me. For instance, if you look at the 
> developer's
> log you will notice we only gained 2 core devs for all of 2015 and the last 
> one
> was August 2015: https://docs.python.org/devguide/developers.html. 2013 was 
> the
> next slowest year with 4, but most years are much closer to 10 than 0. We also
> still have no female or minority members.

Not sure how you determined the latter.  There are many kinds of minorities.

Anyway, with the migration to Git it becomes much easier to spot and remind us
of potential committers, as both author and committer info are retained in
commits.  This makes a periodic report (by a bot, presumably) possible that
lists those authors with the most commits, but without commit bit.

cheers,
Georg


___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Making the PSF CoC apply to core developers

[Brett Cannon]

On Sat, 5 Mar 2016 at 10:58 Georg Brandl  wrote:

> On 03/05/2016 01:07 AM, Brett Cannon wrote:
> >
> >
> > On Fri, 4 Mar 2016 at 15:07 R. David Murray  > > wrote:
> >
> > On Fri, 04 Mar 2016 21:31:44 +, Brett Cannon  > > wrote:
> > > The discussion about the Code of Conduct has sputtered out, so I'm
> going to
> > > assume those who care to speak up have at this point. It seems to
> me that
> > > the general agreement is that putting python-dev and
> bugs.python.org
> >  under
> > > the CoC might not solve any real issues we currently have, but it
> won't
> > > hurt anything either (and both python-committers and python-ideas
> are
> > > already covered). And since the CoC might make some people feel
> more
> > > comfortable in participating, that means going ahead and flipping
> on the
> > > CoC where we reasonably can.
> >
> > I guess I have one more thing to say.
> >
> > Thinking about this, I realized that in fact this emphasis on the
> CoC is
> > making me feel less like contributing.  I doesn't feel like a large
> > effect, but it is real[*].  Just thought you should know :)
> >
> >
> > I'm sorry if that's what this thread has caused for you, David, and it's
> > obviously not what I'm after.
> >
> > I guess I'm just worried about the health of this project. I'm doing
> what I can
> > through the migration to GitHub to make it easier for others to get
> involved
> > while making it easier for us to accept the work of others, but the
> maintenance
> > and health of this team worries me. For instance, if you look at the
> developer's
> > log you will notice we only gained 2 core devs for all of 2015 and the
> last one
> > was August 2015: https://docs.python.org/devguide/developers.html. 2013
> was the
> > next slowest year with 4, but most years are much closer to 10 than 0.
> We also
> > still have no female or minority members.
>
> Not sure how you determined the latter.  There are many kinds of
> minorities.
>
> Anyway, with the migration to Git it becomes much easier to spot and
> remind us
> of potential committers, as both author and committer info are retained in
> commits.  This makes a periodic report (by a bot, presumably) possible that
> lists those authors with the most commits, but without commit bit.
>

That's a great idea! Recorded in PEP 512:
https://hg.python.org/peps/rev/fad7b646ab06.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Davin Potts as a new committer

[Raymond Hettinger]

> On Mar 5, 2016, at 8:51 AM, Brett Cannon  wrote:
> 
> Who wants to be Davin's mentor and tell him to do the steps outlined in 
> https://docs.python.org/devguide/coredev.html#gaining-commit-privileges ?

Davin already knows what to do, he just needs the commit bit flipped.

FWIW, I had volunteered for any needed mentorship 15 months ago but that didn't 
seem to affect the outcome of the conversation.


Raymond



___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Redoing the C API?

[Nick Coghlan]

On 5 March 2016 at 19:49, Paul Moore  wrote:

> On 5 March 2016 at 04:25, Larry Hastings  wrote:
> > * The only exception I know of is Lua--are there more?
>
> TCL and Racket (was mzscheme). I think the key thing is that languages
> designed for embedding provide a C API. Python supports embedding, so
> if we did move away from the C API, we'd need to be very careful not
> to make it harder to embed Python (or deprecate embedding altogether,
> but I don't think that's realistic - quite a few projects embed
> Python).
>

I actually want to make embedding CPython even easier (ideally ending up in
a situation where we can offer a shared embedding API with MicroPython),
but that's a time consuming task that requires a pretty deep knowledge of
CPython's startup and shutdown sequences.

I'm pretty happy with the general design and proposed implementation
strategy in PEP 432 now, but it's sufficiently far removed from anything
I'm doing for work that it isn't a project I can pick and work on for a few
hours here and there. (Which also creates problems for coaching anyone else
in tackling it - this project touches parts of the interpreter that *I*
have to relearn in order to work on it effectively, and it's mainly the
relearning that's the time consuming part rather than the actual work)

That said, there's already some pretty interesting work in embedding based
cross-runtime bridges (metabiosis for CPython-in-PyPy, jitpy for
PyPy-in-CPython, Lunatic Python for both Lua-in-CPython and CPython-in-Lua,
Julia's native bidirectional Python bridge), so I suspect development
energy around "Python without the CPython C API" could be directed towards
some of those combinations, rather than trying to significantly refactor
CPython itself.

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Making the PSF CoC apply to core developers

[Nick Coghlan]

On 6 March 2016 at 06:52, Brett Cannon  wrote:

>
> On Sat, 5 Mar 2016 at 10:58 Georg Brandl  wrote:
>
>>
>> Anyway, with the migration to Git it becomes much easier to spot and
>> remind us
>> of potential committers, as both author and committer info are retained in
>> commits.  This makes a periodic report (by a bot, presumably) possible
>> that
>> lists those authors with the most commits, but without commit bit.
>>
>
> That's a great idea! Recorded in PEP 512:
> https://hg.python.org/peps/rev/fad7b646ab06.
>

Bonus points if the bot can figure out how many iterations the patch went
through prior to being merged - when I've recommended folks for commit bits
in the past, it's generally been because I've got to a point where I feel
like I'm just rubberstamping their patches (rather than needing to suggest
changes), so I can be confident they've worked out for themselves what
"good" looks like.

(Such a bot would be useful even without that though, as the folks actually
reviewing and merging the commits would still be the ones to propose new
contributors for merge privileges)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Making the PSF CoC apply to core developers

[Brett Cannon]

On Sat, 5 Mar 2016 at 18:15 Nick Coghlan  wrote:

> On 6 March 2016 at 06:52, Brett Cannon  wrote:
>
>> On Sat, 5 Mar 2016 at 10:58 Georg Brandl  wrote:
>>
>
>>> Anyway, with the migration to Git it becomes much easier to spot and
>>> remind us
>>> of potential committers, as both author and committer info are retained
>>> in
>>> commits.  This makes a periodic report (by a bot, presumably) possible
>>> that
>>> lists those authors with the most commits, but without commit bit.
>>>
>>
>> That's a great idea! Recorded in PEP 512:
>> https://hg.python.org/peps/rev/fad7b646ab06.
>>
>
> Bonus points if the bot can figure out how many iterations the patch went
> through prior to being merged - when I've recommended folks for commit bits
> in the past, it's generally been because I've got to a point where I feel
> like I'm just rubberstamping their patches (rather than needing to suggest
> changes), so I can be confident they've worked out for themselves what
> "good" looks like.
>

It's called a "synchronize" action for the pull request, so yes, it can be
tracked. :)

-Brett


>
> (Such a bot would be useful even without that though, as the folks
> actually reviewing and merging the commits would still be the ones to
> propose new contributors for merge privileges)
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Davin Potts as a new committer

[Brett Cannon]

On Sat, 5 Mar 2016 at 17:59 Raymond Hettinger 
wrote:

>
> > On Mar 5, 2016, at 8:51 AM, Brett Cannon  wrote:
> >
> > Who wants to be Davin's mentor and tell him to do the steps outlined in
> https://docs.python.org/devguide/coredev.html#gaining-commit-privileges ?
>
> Davin already knows what to do, he just needs the commit bit flipped.
>

It's a bit more involved than that since he needs to send his SSH key(s) to
hgaccou...@python.org (which can also simply be his GitHub account since
https://github.com/.keys lists one's keys registered  with
GitHub), tell us what his name is for the hg account, and tell us what
email address he wants to subscribe to python-committers with. Then he will
get listed in the devguide at
https://docs.python.org/devguide/developers.html and get his flag flipped
on the issue tracker as a committer (and I assume his username is "davin").
That's the kind of stuff listed at the URL I sent you, not how to make a
commit happen.


>
> FWIW, I had volunteered for any needed mentorship 15 months ago but that
> didn't seem to affect the outcome of the conversation.
>

Finding someone a mentor is a necessary but not sufficient condition to
getting someone commit privileges. It's great that you were willing to
vouch for Davin 15 months ago, Raymond, but he simply had to gain more
people's trust before we as a group were ready to give him commit
privileges. That's now happened and so we are getting him the privileges he
has demonstrated he is capable of having.

Does your offer to mentor Davin still stand, or would you rather someone
else take Davin on to double-check his first few commits follow our
development process?
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/