From stefan at bytereef.org  Tue Mar  1 04:17:37 2016
From: stefan at bytereef.org (Stefan Krah)
Date: Tue, 1 Mar 2016 09:17:37 +0000 (UTC)
Subject: [python-committers] Making the PSF CoC apply to core developers
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <loom.20160227T121049-853@post.gmane.org> <56D1DA64.5050505@egenix.com>
Message-ID: <loom.20160301T100856-886@post.gmane.org>

M.-A. Lemburg <mal <at> egenix.com> writes:
> > This particular CoC specifically addresses conference misbehavior, which is
> > fine.
> 
> The PSF CoC has a focus on community interaction, not on conferences.
> It's different from eg. the PyCon US conference CoC.

Consider me schooled. :)


> Mix all that with a good dose of Monty Python's don't-take-yourself-
> too-seriously, add some Tim Peters takes-one-to-know-one-ly and
> I believe we can all be on the same page 
> 
> Hmm, perhaps we ought to make reading some Python humor a
> prerequisite for core developers instead...

I would throw in "Life of Brian" (in particular the "we are all individuals"
dialogue) and "Yes Minister" (don't get me started on that one).

Wondering what a Monty Python episode about CoCs would look like ...


Stefan Krah




From thomas at python.org  Tue Mar  1 04:33:00 2016
From: thomas at python.org (Thomas Wouters)
Date: Tue, 1 Mar 2016 10:33:00 +0100
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <loom.20160301T100856-886@post.gmane.org>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <loom.20160227T121049-853@post.gmane.org>
 <56D1DA64.5050505@egenix.com>
 <loom.20160301T100856-886@post.gmane.org>
Message-ID: <CAPdQG2qpHKS+pO-HcamZYcApmDNWzWnxx8MCy4q9qcKKWiXeUQ@mail.gmail.com>

On Tue, Mar 1, 2016 at 10:17 AM, Stefan Krah <stefan at bytereef.org> wrote:

> Wondering what a Monty Python episode about CoCs would look like ...
>

I think you're misunderstanding Monty Python's humour if you think they'd
have made one about the CoC :) They were very much for punching upward, not
kicking downward. They ridiculed themselves and the environments they came
from, not those thinking of others. Certainly not measures taken to make
the playing field more open and clear for everyone. (Contrast with, say,
South Park, which inherited Monty Python's visual humour with an entirely
different stance on social responsibility ;P)

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160301/89f390c6/attachment.html>

From stefan at bytereef.org  Tue Mar  1 04:51:25 2016
From: stefan at bytereef.org (Stefan Krah)
Date: Tue, 1 Mar 2016 09:51:25 +0000 (UTC)
Subject: [python-committers] Making the PSF CoC apply to core developers
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <loom.20160227T121049-853@post.gmane.org> <56D1DA64.5050505@egenix.com>
 <loom.20160301T100856-886@post.gmane.org>
 <CAPdQG2qpHKS+pO-HcamZYcApmDNWzWnxx8MCy4q9qcKKWiXeUQ@mail.gmail.com>
Message-ID: <loom.20160301T103809-147@post.gmane.org>

Thomas Wouters <thomas <at> python.org> writes:
> On Tue, Mar 1, 2016 at 10:17 AM, Stefan Krah <stefan <at> bytereef.org>
wrote:Wondering what a Monty Python episode about CoCs would look like ...
> 
> I think you're misunderstanding Monty Python's humour if you think they'd
have made one about the CoC :) They were very much for punching upward, not
kicking downward. They ridiculed themselves and the environments they came
from, not those thinking of others. Certainly not measures taken to make the
playing field more open and clear for everyone. (Contrast with, say, South
Park, which inherited Monty Python's visual humour with an entirely
different stance on social responsibility ;P)

Sorry, this is a huge strawman. Core developers are already very much on a
level playing field.  If you want, I can post a IRC log where people who are
undoubtedly in favor of the CoC a) gossip about two core devs, b) ask if
said core-devs "had any influence", and c) make fun of the works of said
core-devs.

Some of these people have impeccable manners on mailing lists, and not
addressing Machiavellianism is one of the most glaring flaws of this CoC.


I'm quite upset about you bringing in "kicking downward" (even if qualified
by a smiley).



Stefan Krah


 


From antoine at python.org  Tue Mar  1 04:50:41 2016
From: antoine at python.org (Antoine Pitrou)
Date: Tue, 1 Mar 2016 10:50:41 +0100
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <CAPdQG2qpHKS+pO-HcamZYcApmDNWzWnxx8MCy4q9qcKKWiXeUQ@mail.gmail.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <loom.20160227T121049-853@post.gmane.org> <56D1DA64.5050505@egenix.com>
 <loom.20160301T100856-886@post.gmane.org>
 <CAPdQG2qpHKS+pO-HcamZYcApmDNWzWnxx8MCy4q9qcKKWiXeUQ@mail.gmail.com>
Message-ID: <56D565F1.4070300@python.org>


Le 01/03/2016 10:33, Thomas Wouters a ?crit :
> 
> On Tue, Mar 1, 2016 at 10:17 AM, Stefan Krah <stefan at bytereef.org
> <mailto:stefan at bytereef.org>> wrote:
> 
>     Wondering what a Monty Python episode about CoCs would look like ...
> 
> I think you're misunderstanding Monty Python's humour if you think
> they'd have made one about the CoC :) They were very much for punching
> upward, not kicking downward.

Why would ridiculing a CoC have anything to do about kicking downward?
Promoters of CoCs are certainly mostly found in the same social classes
as their detractors.

Monty Python have ridiculed militant practices and jargon in the past
(e.g. the anarcho-syndicalist commune in Holy Grail, or the various
Liberation Fronts in Life Of Brian).  I'm sure if the CoC frenzy had
appeared in the 1970s they'd have made fun of it too.

Note ridiculing a CoC is not the same thing as ridiculing marginalized
people, just as ridiculing a self-proclaimed "Workers' Party" is not the
same thing as ridiculing factory workers.

Regards

Antoine.

From antoine at python.org  Tue Mar  1 05:12:33 2016
From: antoine at python.org (Antoine Pitrou)
Date: Tue, 1 Mar 2016 11:12:33 +0100
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <56D565F1.4070300@python.org>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <loom.20160227T121049-853@post.gmane.org> <56D1DA64.5050505@egenix.com>
 <loom.20160301T100856-886@post.gmane.org>
 <CAPdQG2qpHKS+pO-HcamZYcApmDNWzWnxx8MCy4q9qcKKWiXeUQ@mail.gmail.com>
 <56D565F1.4070300@python.org>
Message-ID: <56D56B11.6040806@python.org>


Le 01/03/2016 10:50, Antoine Pitrou a ?crit :
> 
> Monty Python have ridiculed militant practices and jargon in the past
> (e.g. the anarcho-syndicalist commune in Holy Grail, or the various
> Liberation Fronts in Life Of Brian).  I'm sure if the CoC frenzy had
> appeared in the 1970s they'd have made fun of it too.

Btw I'll admit the word "frenzy" isn't very fortunate here.  CoCs
certainly have their uses.  It would be nice if people like Anita
Sarkeesian didn't have to go through insults and threats every day...

Regards

Antoine.

From thomas at python.org  Tue Mar  1 08:10:44 2016
From: thomas at python.org (Thomas Wouters)
Date: Tue, 1 Mar 2016 14:10:44 +0100
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <loom.20160301T103809-147@post.gmane.org>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <loom.20160227T121049-853@post.gmane.org>
 <56D1DA64.5050505@egenix.com>
 <loom.20160301T100856-886@post.gmane.org>
 <CAPdQG2qpHKS+pO-HcamZYcApmDNWzWnxx8MCy4q9qcKKWiXeUQ@mail.gmail.com>
 <loom.20160301T103809-147@post.gmane.org>
Message-ID: <CAPdQG2q_kasGbT_Ea-gsper_z70K2jETOqJEcLqCfGzGt9DpSQ@mail.gmail.com>

On Tue, Mar 1, 2016 at 10:51 AM, Stefan Krah <stefan at bytereef.org> wrote:

> Sorry, this is a huge strawman. Core developers are already very much on a
> level playing field.
>

The intent of the CoC isn't just about protecting the current community
members. It's also about making it open and inviting to *new members*. The
core-dev community, despite best efforts, can easily be seen as an "good
old boys club". Making it clear that we don't *intend* for it to be that
way is a good step to make.


> If you want, I can post a IRC log where people who are
> undoubtedly in favor of the CoC a) gossip about two core devs, b) ask if
> said core-devs "had any influence", and c) make fun of the works of said
> core-devs.
>

All the more reason to point them to the CoC and ask if they would be more
considerate.


> Some of these people have impeccable manners on mailing lists, and not
> addressing Machiavellianism is one of the most glaring flaws of this CoC.
>

It's proven quite hard to draft a CoC -- or any document -- that everyone
agrees to *and* covers everything everyone wants. I wish it were more
explicit about certain things, and more condemning, but I'm glad to have it
to refer to anyway. (I frequently refer to it on #python on Freenode.)


> I'm quite upset about you bringing in "kicking downward" (even if qualified
> by a smiley).
>

It was not meant as a personal attack, merely a reaction to what I
perceived as you making light of the idea of a CoC. I see that I was
mistaken, so I'm sorry.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160301/20eeffc6/attachment-0001.html>

From rdmurray at bitdance.com  Tue Mar  1 12:36:24 2016
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 01 Mar 2016 12:36:24 -0500
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <CAP1=2W4F8WWA=UpDe7o7cw+QFLRg-iS3y+_z2aNzDKzZg-x+WQ@mail.gmail.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <loom.20160227T121049-853@post.gmane.org>
 <CAP1=2W5RLvVPRqvH=psWfjU=MrQ2CQRv+ntn8QSQXW7P_QjrrQ@mail.gmail.com>
 <20160228022741.GK12028@ando.pearwood.info>
 <CADiSq7fHyzGC0TGX0e1+Apcap1FasEayEwNZGikm41sOT-VRfw@mail.gmail.com>
 <20160301020031.GM12028@ando.pearwood.info>
 <CAP1=2W4F8WWA=UpDe7o7cw+QFLRg-iS3y+_z2aNzDKzZg-x+WQ@mail.gmail.com>
Message-ID: <20160301173625.B2A4CB14026@webabinitio.net>

On Tue, 01 Mar 2016 04:10:08 +0000, Brett Cannon <brett at python.org> wrote:
> On Mon, 29 Feb 2016 at 18:01 Steven D'Aprano <steve at pearwood.info> wrote:
> > So let me make it clear: Brett, and the other list maintainers, you're
> > not listening. Even if I'm a minority of one out of the whole community,
> > your words say "of course we care what you think" but your actions say
> > "actually no, we couldn't care less". You might not have intended it
> > that way, but nevertheless that's the way it is.
> >
> 
> I see where the issue came in: I simply considered the discussion on the
> CoC already settled. As you pointed out in your second paragraph, the

Just so Steven doesn't think he's a minority of one, let me say that I
too find CoCs problematic.  I have a code of conduct, and it applies to my
*life*.  For shorthand, you could call it "being a gentleman", but a more
modern term might be "being civil".  Do I fail to live up to my personal
code occasionally?  Yes, and I hope people call me on it when I do fail.
Do I care what code of conduct the organization has promulgated?  No.
It has no affect on my behavior, nor will it.  At most, it might drive
me from the community if it is ever used against me.

Referencing a CoC will only work at all with those who are self-governed
by a personal code of civility.  Yet all such people need is to have it
pointed out to them that they have been uncivil, with reference to the
universal code of civility and/or a civil discussion about civility in
the immediate context.

Those who are not already self-governed by a personal code of civility
will not be bound by the CoC, though they may give it lip service and
carry on a long, probably uncivil, argument about the rules embodied in
the CoC.

Against those who are not self-governed, only power plays, which
ultimately probably means expulsion by technical means, will work...and
what matters it if you reference that expulsion to a specific code of
conduct, or the universal one?

How it actually matters is that people who are not civil will "rules
lawyer" you on the specific one if you have one and you attempt to use it
to police their behavior.  Worse, they will use it to "rules lawyer" people
they don't like or whose opinions they object to.

When things get bad enough that a call to (universal) civility is not
enough, ultimately someone has to make the call.  That person might
as well do it based on their own moral code, as the "owner" of the
resource[*], and not have to try to justify it based on some specific set
of rules-on-paper.  They are going to take flak for making the decision
anyway, so why hand the uncivil an extra weapon?

Note that I am not saying that there aren't/weren't problems.  Those
problems need to be (and are) addressed *universally* by a change in
civic culture via the cultural dialog that is always going on around us.
Discussions of what civility is in the context of specific incidents are
an important part of that.  Specific codes of conduct, on the other hand,
very often make the problem *worse*, and delay the implementation of
beneficial cultural shifts, because they attempt to freeze the rules,
very often do it badly, and thus become instead a weapon in the hands
of the uncivil and/or the power hungry.

All that said, the Python CoC is not a bad restatement of parts of the
universal code, so it is hopefully less subject to this abuse than
others that I have seen.  For that I am thankful.  As I am thankful
that the Python community rarely has conflicts that rise to the level of
intransigent uncivility.  The fundamental civility of this community is
one of the things that I value about it, even if it isn't quite perfect :)

--David

[*] Yes, in our case that is ultimately Guido, as Brett indicated.

From p.f.moore at gmail.com  Tue Mar  1 12:54:52 2016
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 1 Mar 2016 17:54:52 +0000
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <20160301173625.B2A4CB14026@webabinitio.net>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <loom.20160227T121049-853@post.gmane.org>
 <CAP1=2W5RLvVPRqvH=psWfjU=MrQ2CQRv+ntn8QSQXW7P_QjrrQ@mail.gmail.com>
 <20160228022741.GK12028@ando.pearwood.info>
 <CADiSq7fHyzGC0TGX0e1+Apcap1FasEayEwNZGikm41sOT-VRfw@mail.gmail.com>
 <20160301020031.GM12028@ando.pearwood.info>
 <CAP1=2W4F8WWA=UpDe7o7cw+QFLRg-iS3y+_z2aNzDKzZg-x+WQ@mail.gmail.com>
 <20160301173625.B2A4CB14026@webabinitio.net>
Message-ID: <CACac1F9_Ng5B7=qHSj5y4w+OQ6iFAvFX6yoShzS-vMGg=6gVOA@mail.gmail.com>

On 1 March 2016 at 17:36, R. David Murray <rdmurray at bitdance.com> wrote:
> On Tue, 01 Mar 2016 04:10:08 +0000, Brett Cannon <brett at python.org> wrote:
>> On Mon, 29 Feb 2016 at 18:01 Steven D'Aprano <steve at pearwood.info> wrote:
>> > So let me make it clear: Brett, and the other list maintainers, you're
>> > not listening. Even if I'm a minority of one out of the whole community,
>> > your words say "of course we care what you think" but your actions say
>> > "actually no, we couldn't care less". You might not have intended it
>> > that way, but nevertheless that's the way it is.
>> >
>>
>> I see where the issue came in: I simply considered the discussion on the
>> CoC already settled. As you pointed out in your second paragraph, the
>
> Just so Steven doesn't think he's a minority of one, let me say that I
> too find CoCs problematic.  I have a code of conduct, and it applies to my
> *life*.  For shorthand, you could call it "being a gentleman", but a more
> modern term might be "being civil".  Do I fail to live up to my personal
> code occasionally?  Yes, and I hope people call me on it when I do fail.
> Do I care what code of conduct the organization has promulgated?  No.
> It has no affect on my behavior, nor will it.  At most, it might drive
> me from the community if it is ever used against me.

Let me also add that I have little or no interest in codes of conduct.
I don't *object* to them (specifically I have no problem with the
Python CoC or it being applied to core devs in relevant situations)
but it seems to me that they are becoming a bit of a "trendy thing to
have" rather than anything of any particular substance.

But ultimately what matters is that people who feel unwelcome, or
discriminated against, have said that they help lessen such problems -
so that's fine by me. I'm 100% behind doing whatever makes such people
feel better about participating in the community.

Contrariwise, I wouldn't feel any need to refer to a CoC when calling
someone out on bad behaviour - if pointing out that they are being
unpleasant isn't enough then waving a set of rules at them won't help.
And if *I* ever behave badly, I'd expect people to simply say so, not
to quote a CoC at me.

Going into specifics:

Brett - I don't have any problem with what you did, or the changes you
want to make.
Steven - you make some good points that I think people should keep in mind
But overall, arguing over the specifics of how we set our expectations
that people simply be nice to each other is basically a bit silly, and
if we let it go on, could easily result in the opposite effect from
what was intended.

That's about all I have to say on this matter.
Paul

From alexander.belopolsky at gmail.com  Tue Mar  1 13:16:54 2016
From: alexander.belopolsky at gmail.com (Alexander Belopolsky)
Date: Tue, 1 Mar 2016 13:16:54 -0500
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <20160301173625.B2A4CB14026@webabinitio.net>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <loom.20160227T121049-853@post.gmane.org>
 <CAP1=2W5RLvVPRqvH=psWfjU=MrQ2CQRv+ntn8QSQXW7P_QjrrQ@mail.gmail.com>
 <20160228022741.GK12028@ando.pearwood.info>
 <CADiSq7fHyzGC0TGX0e1+Apcap1FasEayEwNZGikm41sOT-VRfw@mail.gmail.com>
 <20160301020031.GM12028@ando.pearwood.info>
 <CAP1=2W4F8WWA=UpDe7o7cw+QFLRg-iS3y+_z2aNzDKzZg-x+WQ@mail.gmail.com>
 <20160301173625.B2A4CB14026@webabinitio.net>
Message-ID: <CAP7h-xY=8LKOikdekmDOkFS=6g1vhF8bR7VQ+CVY_t=7MxcENg@mail.gmail.com>

On Tue, Mar 1, 2016 at 12:36 PM, R. David Murray <rdmurray at bitdance.com>
wrote:
>
> On Tue, 01 Mar 2016 04:10:08 +0000, Brett Cannon <brett at python.org> wrote:
> > On Mon, 29 Feb 2016 at 18:01 Steven D'Aprano <steve at pearwood.info>
wrote:
> > > So let me make it clear: Brett, and the other list maintainers, you're
> > > not listening. Even if I'm a minority of one out of the whole
community,
> > > your words say "of course we care what you think" but your actions say
> > > "actually no, we couldn't care less". You might not have intended it
> > > that way, but nevertheless that's the way it is.
> > >
> >
> > I see where the issue came in: I simply considered the discussion on the
> > CoC already settled. As you pointed out in your second paragraph, the
>
> Just so Steven doesn't think he's a minority of one, let me say that I
> too find CoCs problematic.

I did not think I would ever reply in this thread, but its 25+ messages in
my inbox made me click on the CoC link and actually read it.

As a result, I am truly puzzled.  The CoC just states "we're good to each
other" in not so many words.  The dispute over Brett not being good to
others by stating that we all are reminds me of the Russell's paradox. [1]

I suggest that we deal with the question "Does CoC apply to core
developers?" in the same manner the modern set theory deals with the Barber
problem.

[1] https://en.wikipedia.org/wiki/Barber_paradox
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160301/eb406eb3/attachment.html>

From brett at python.org  Tue Mar  1 14:00:21 2016
From: brett at python.org (Brett Cannon)
Date: Tue, 01 Mar 2016 19:00:21 +0000
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <20160301173625.B2A4CB14026@webabinitio.net>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <loom.20160227T121049-853@post.gmane.org>
 <CAP1=2W5RLvVPRqvH=psWfjU=MrQ2CQRv+ntn8QSQXW7P_QjrrQ@mail.gmail.com>
 <20160228022741.GK12028@ando.pearwood.info>
 <CADiSq7fHyzGC0TGX0e1+Apcap1FasEayEwNZGikm41sOT-VRfw@mail.gmail.com>
 <20160301020031.GM12028@ando.pearwood.info>
 <CAP1=2W4F8WWA=UpDe7o7cw+QFLRg-iS3y+_z2aNzDKzZg-x+WQ@mail.gmail.com>
 <20160301173625.B2A4CB14026@webabinitio.net>
Message-ID: <CAP1=2W7mA1ApR_D5T9GaMi8MQW9JXxOgHiRp+fbgcwpHz=mOkw@mail.gmail.com>

On Tue, 1 Mar 2016 at 09:36 R. David Murray <rdmurray at bitdance.com> wrote:

> On Tue, 01 Mar 2016 04:10:08 +0000, Brett Cannon <brett at python.org> wrote:
> > On Mon, 29 Feb 2016 at 18:01 Steven D'Aprano <steve at pearwood.info>
> wrote:
> > > So let me make it clear: Brett, and the other list maintainers, you're
> > > not listening. Even if I'm a minority of one out of the whole
> community,
> > > your words say "of course we care what you think" but your actions say
> > > "actually no, we couldn't care less". You might not have intended it
> > > that way, but nevertheless that's the way it is.
> > >
> >
> > I see where the issue came in: I simply considered the discussion on the
> > CoC already settled. As you pointed out in your second paragraph, the
>
> Just so Steven doesn't think he's a minority of one, let me say that I
> too find CoCs problematic.  I have a code of conduct, and it applies to my
> *life*.  For shorthand, you could call it "being a gentleman", but a more
> modern term might be "being civil".  Do I fail to live up to my personal
> code occasionally?  Yes, and I hope people call me on it when I do fail.
> Do I care what code of conduct the organization has promulgated?  No.
> It has no affect on my behavior, nor will it.  At most, it might drive
> me from the community if it is ever used against me.
>
> Referencing a CoC will only work at all with those who are self-governed
> by a personal code of civility.  Yet all such people need is to have it
> pointed out to them that they have been uncivil, with reference to the
> universal code of civility and/or a civil discussion about civility in
> the immediate context.
>

I don't want this discussion to drag on forever as CoC discussions tend to,
but I do want to point out that the CoC serves two purposes: putting in
writing that people are expected to behave appropriately instead of purely
by unspoken social contract and thus have something to point to when
dealing with bad actors, and to make people who feel like a minority to
know that someone who is in the majority cannot bully or out-shout them
without consequences.

It's that last point I really care about with this group (in the case of
python-ideas it was the former). If you look at our makeup, we are all men
and of the dominant ethnic group in our home country (if I'm wrong, please
let me know). I suspect the vast majority of us have never experienced
systemic discrimination for extended periods of time (I'm talking for
months, not while on vacation for a week or two). And if you didn't know
coming into python-dev, the issue tracker, or GitHub that bad behaviour
won't be tolerated, it can be quite a barrier to entry as it's very easy to
want to avoid participation if you don't have a spirit for fighting when
you think you may have to fight to participate.

For instance, I actually did experience discrimination in high school in
the US while on a sports team. I happened to be one of two white kids on
the team and it was made abundantly clear by our teammates that we were the
ethnic minority. It sucked and it very quickly makes you try and avoid
confrontations because you know you may be outnumbered if you ask people to
stop verbally abusing you and the majority choose not to comply. And this
extends to going to greater powers when you don't know if they will take
your side on verbal abuse since if they don't you will be outnumbered by
the majority and thus have little in the way or protection against
potential retaliation over trying to get help (luckily when we did go to
our coach, while he didn't believe us in terms of severity, people
basically got the point and things improved, but there was always an
undercurrent of being different to the point the other kid quit the team,
making me a minority of one). Being a minority really sucks when you don't
know if the majority will support you when you have to fight to be treated
fairly and with kindness.

And that's what I want for us. I want people to know that they can
participate here and know we will do it in a civil manner and that even if
you are technically a minority compared to the group in the real world, you
will be treated as an equal. Whether the CoC really ever has to be used or
how much teeth it may have is not entirely the point: it's about how
outsiders feel and if they feel protected and comfortable. It's letting
others know that if they come here and happen to be treated badly -- even
if I doubt that will truly ever happen from a core dev -- that they won't
have to fight to continue to participate or simply walk away because of how
they were treated by someone. The simple act of writing it down can mean a
lot to know that we at least strive for that. In this instance (written)
words speak louder than actions when you don't know what the dynamic of a
group is ahead of time. The participation of women at PyCon US thanks to a
combination of a CoC and outreach is proof this stuff can make a difference
in participation.

Now obviously I could be totally wrong and this isn't an actual barrier for
getting women or ethnic minorities to participate in Python's development.
But from my perspective, the chances that the lack of CoC is causing
someone to not participate seems greater than the chances that the CoC will
somehow be abused to silence someone who has a valid point that was
delivered in a reasonable tone. And this is why I'm working to get
everything we do as core devs under the PSF CoC (which I have said
previously is python-dev, bugs.python.org, and GitHub at this point).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160301/fc22e73a/attachment-0001.html>

From rdmurray at bitdance.com  Tue Mar  1 14:44:51 2016
From: rdmurray at bitdance.com (R. David Murray)
Date: Tue, 01 Mar 2016 14:44:51 -0500
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <CAP1=2W7mA1ApR_D5T9GaMi8MQW9JXxOgHiRp+fbgcwpHz=mOkw@mail.gmail.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <loom.20160227T121049-853@post.gmane.org>
 <CAP1=2W5RLvVPRqvH=psWfjU=MrQ2CQRv+ntn8QSQXW7P_QjrrQ@mail.gmail.com>
 <20160228022741.GK12028@ando.pearwood.info>
 <CADiSq7fHyzGC0TGX0e1+Apcap1FasEayEwNZGikm41sOT-VRfw@mail.gmail.com>
 <20160301020031.GM12028@ando.pearwood.info>
 <CAP1=2W4F8WWA=UpDe7o7cw+QFLRg-iS3y+_z2aNzDKzZg-x+WQ@mail.gmail.com>
 <20160301173625.B2A4CB14026@webabinitio.net>
 <CAP1=2W7mA1ApR_D5T9GaMi8MQW9JXxOgHiRp+fbgcwpHz=mOkw@mail.gmail.com>
Message-ID: <20160301194452.41C8BB14026@webabinitio.net>

On Tue, 01 Mar 2016 19:00:21 +0000, Brett Cannon <brett at python.org> wrote:
> I don't want this discussion to drag on forever as CoC discussions tend to,

Agreed, I made my point and don't otherwise feel a need to engage in
further discussion.  Unless someone pushes one of my buttons, I
suppose :)

> Now obviously I could be totally wrong and this isn't an actual barrier for
> getting women or ethnic minorities to participate in Python's development.

Yeah, there's no way to know, as far as I can see.  But I think our
*being* welcoming is way, *way* more important than our *saying* we are
welcoming.

--David

From larry at hastings.org  Tue Mar  1 20:01:30 2016
From: larry at hastings.org (Larry Hastings)
Date: Tue, 1 Mar 2016 17:01:30 -0800
Subject: [python-committers] Call For Participants For The 2016 Python
 Language Summit
Message-ID: <56D63B6A.6040805@hastings.org>



It's that time once again: time to start planning for the 2016 Python 
Language Summit!  This year the summit will be at the Oregon Convention 
Center in Portland, Oregon, USA, on May 28th.  Sadly, again this year 
Michael Foord won't be in attendance.  Barry Warsaw and I are running 
the summit for the second time.

The purpose of the event is to disseminate information and spark 
conversation among Python core developers.  It's our once-a-year chance 
to get together and hash out where we're going and what we're doing, 
face-to-face.

We're making two minor changes this year.  First: we're going to 
experiment with lightning talks!  We may have a bunch at the end, or we 
may throw some in between longer presentations--not sure yet, we'll see 
how it goes.  In the grand tradition of lightning talks, they'll be 
scheduled exclusively on the day of the summit.  We'll provide a 
whiteboard or other drawable surface in case you don't show up with 
slides, and wild gesticulation isn't enough.

Second: we're using a Google Form to collect signups.  This one form 
lets you request an invitation to the summit, and also optionally 
propose a talk.  Please note: filling out the form does not guarantee 
you an invitation.  Space is limited; if you're a core developer, your 
request for invitation *will* be honored, but we may need to restrict 
attendance for others.  (Sorry!)  Barry and I will email the invitations 
separately.

Signups are open as of now, and will remain open for six weeks, closing 
April 12th.  But it'll only take you a minute to fill out the form, so 
you might as well do it right now!  Signing up sooner will make our 
lives easier, too.

You'll find a link to the signup form on the summit's official web page, 
here:

    https://us.pycon.org/2016/events/langsummit/


One final note.  Again this year we're inviting Jake Edge from Linux 
Weekly News to attend the summit and provide press coverage.  In case 
you missed it, Jake did a phenomenal job of covering last year's summit, 
giving the reader a very thorough overview of what happened.

    https://lwn.net/Articles/639773/

Some attendees were worried last year about sharing private or 
proprietary information in front of a reporter.  Jake, Barry, and I want 
to assure you that it's just not a problem.  Jake's not there to 
embarrass anybody or get anybody in trouble.  He said he'd be happy to 
work with any attendees about any discussions you want considered "off 
the record".


We hope to see you at the summit!


[BL]arry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160301/a9de4268/attachment.html>

From jackdied at gmail.com  Tue Mar  1 22:54:17 2016
From: jackdied at gmail.com (Jack Diederich)
Date: Tue, 1 Mar 2016 22:54:17 -0500
Subject: [python-committers] Call For Participants For The 2016 Python
 Language Summit
In-Reply-To: <56D63B6A.6040805@hastings.org>
References: <56D63B6A.6040805@hastings.org>
Message-ID: <CACLn2+14bzKa5KAU8_imdjwvSE2wL5CdGTHoe_Dvjnc1JJ6pfQ@mail.gmail.com>

I'll be there. Unless it requires us both getting a PyCon talk accepted. In
which case I will demur to more wizened people than we.

On Tue, Mar 1, 2016 at 8:01 PM, Larry Hastings <larry at hastings.org> wrote:

>
>
> It's that time once again: time to start planning for the 2016 Python
> Language Summit!  This year the summit will be at the Oregon Convention
> Center in Portland, Oregon, USA, on May 28th.  Sadly, again this year
> Michael Foord won't be in attendance.  Barry Warsaw and I are running the
> summit for the second time.
>
> The purpose of the event is to disseminate information and spark
> conversation among Python core developers.  It's our once-a-year chance to
> get together and hash out where we're going and what we're doing,
> face-to-face.
>
> We're making two minor changes this year.  First: we're going to
> experiment with lightning talks!  We may have a bunch at the end, or we may
> throw some in between longer presentations--not sure yet, we'll see how it
> goes.  In the grand tradition of lightning talks, they'll be scheduled
> exclusively on the day of the summit.  We'll provide a whiteboard or other
> drawable surface in case you don't show up with slides, and wild
> gesticulation isn't enough.
>
> Second: we're using a Google Form to collect signups.  This one form lets
> you request an invitation to the summit, and also optionally propose a
> talk.  Please note: filling out the form does not guarantee you an
> invitation.  Space is limited; if you're a core developer, your request for
> invitation *will* be honored, but we may need to restrict attendance for
> others.  (Sorry!)  Barry and I will email the invitations separately.
>
> Signups are open as of now, and will remain open for six weeks, closing
> April 12th.  But it'll only take you a minute to fill out the form, so you
> might as well do it right now!  Signing up sooner will make our lives
> easier, too.
>
> You'll find a link to the signup form on the summit's official web page,
> here:
>
> https://us.pycon.org/2016/events/langsummit/
>
>
> One final note.  Again this year we're inviting Jake Edge from Linux
> Weekly News to attend the summit and provide press coverage.  In case you
> missed it, Jake did a phenomenal job of covering last year's summit, giving
> the reader a very thorough overview of what happened.
>
> https://lwn.net/Articles/639773/
>
> Some attendees were worried last year about sharing private or proprietary
> information in front of a reporter.  Jake, Barry, and I want to assure you
> that it's just not a problem.  Jake's not there to embarrass anybody or get
> anybody in trouble.  He said he'd be happy to work with any attendees about
> any discussions you want considered "off the record".
>
>
> We hope to see you at the summit!
>
>
> [BL]arry
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160301/49b3d83a/attachment.html>

From ncoghlan at gmail.com  Wed Mar  2 03:02:34 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 2 Mar 2016 18:02:34 +1000
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <20160301194452.41C8BB14026@webabinitio.net>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <loom.20160227T121049-853@post.gmane.org>
 <CAP1=2W5RLvVPRqvH=psWfjU=MrQ2CQRv+ntn8QSQXW7P_QjrrQ@mail.gmail.com>
 <20160228022741.GK12028@ando.pearwood.info>
 <CADiSq7fHyzGC0TGX0e1+Apcap1FasEayEwNZGikm41sOT-VRfw@mail.gmail.com>
 <20160301020031.GM12028@ando.pearwood.info>
 <CAP1=2W4F8WWA=UpDe7o7cw+QFLRg-iS3y+_z2aNzDKzZg-x+WQ@mail.gmail.com>
 <20160301173625.B2A4CB14026@webabinitio.net>
 <CAP1=2W7mA1ApR_D5T9GaMi8MQW9JXxOgHiRp+fbgcwpHz=mOkw@mail.gmail.com>
 <20160301194452.41C8BB14026@webabinitio.net>
Message-ID: <CADiSq7cNCU+qbELrrbh7vxqU=qL2aAitLxMjaayB6SSpFpAK1w@mail.gmail.com>

On 2 March 2016 at 05:44, R. David Murray <rdmurray at bitdance.com> wrote:
> On Tue, 01 Mar 2016 19:00:21 +0000, Brett Cannon <brett at python.org> wrote:
>> Now obviously I could be totally wrong and this isn't an actual barrier for
>> getting women or ethnic minorities to participate in Python's development.
>
> Yeah, there's no way to know, as far as I can see.  But I think our
> *being* welcoming is way, *way* more important than our *saying* we are
> welcoming.

Words that weren't backed up by behaviour would be false advertising,
and hence far more problematic than silence or an explicit statement
that an environment is deliberately adversarial.

However, it also isn't reasonable for open source projects to expect
potential contributors to invest weeks or months in assessing their
likely treatment if they speak up on a mailing list or submit a new
patch - it turns out that having the kind of spare time needed to
speculatively invest in following a community for long enough to make
that kind of judgement for ourselves is a rare luxury.

That's where written behavioural commitments can help - as long as
they accurately reflect the way that community members actually strive
to conduct themselves, than it helps newcomers better assess "Am I
likely to feel comfortable here?".

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From ericsnowcurrently at gmail.com  Wed Mar  2 11:26:56 2016
From: ericsnowcurrently at gmail.com (Eric Snow)
Date: Wed, 2 Mar 2016 09:26:56 -0700
Subject: [python-committers] Call For Participants For The 2016 Python
 Language Summit
In-Reply-To: <56D63B6A.6040805@hastings.org>
References: <56D63B6A.6040805@hastings.org>
Message-ID: <CALFfu7AvtF2mMygBgVbm6=FDd_m5w3-NEAqisDFA5-y=X2S5SQ@mail.gmail.com>

On Tue, Mar 1, 2016 at 6:01 PM, Larry Hastings <larry at hastings.org> wrote:
> It's that time once again: time to start planning for the 2016 Python
> Language Summit!  This year the summit will be at the Oregon Convention
> Center in Portland, Oregon, USA, on May 28th.

Thanks for chairing this again!

>  Sadly, again this year Michael Foord won't be in attendance.

:(

> Second: we're using a Google Form to collect signups.  This one form lets
> you request an invitation to the summit, and also optionally propose a talk.

In case folks are taking requests, I'd love to hear about:

* status report on core workflow improvements
* how typing has been received and what's next (e.g. more integration
into the compiler, multiple dispatch)
* Python in the embedded/-ish space (e.g. MicroPython, BBC MicroBit,
RaspberryPi, android, iOS, ARM)
* status of alternate implementations and tool chains:
  - pyjion
  - pyston
  - pypy
  - jython
  - ironpython
  - cython
  - numba
  - others?

FWIW, I've offered to present the following (as a last resort <wink>):

* about C OrderedDict
* about my Multi-core Python project
* the successor to PEP 406 ("Improved Encapsulation of Import State")

-eric

From brett at python.org  Wed Mar  2 11:47:43 2016
From: brett at python.org (Brett Cannon)
Date: Wed, 02 Mar 2016 16:47:43 +0000
Subject: [python-committers] Call For Participants For The 2016 Python
 Language Summit
In-Reply-To: <CALFfu7AvtF2mMygBgVbm6=FDd_m5w3-NEAqisDFA5-y=X2S5SQ@mail.gmail.com>
References: <56D63B6A.6040805@hastings.org>
 <CALFfu7AvtF2mMygBgVbm6=FDd_m5w3-NEAqisDFA5-y=X2S5SQ@mail.gmail.com>
Message-ID: <CAP1=2W7nh6o0ENSw11RVhLXx2TCK=WghfvaLhcyuoxEWA9bgng@mail.gmail.com>

On Wed, 2 Mar 2016 at 08:27 Eric Snow <ericsnowcurrently at gmail.com> wrote:

> On Tue, Mar 1, 2016 at 6:01 PM, Larry Hastings <larry at hastings.org> wrote:
> > It's that time once again: time to start planning for the 2016 Python
> > Language Summit!  This year the summit will be at the Oregon Convention
> > Center in Portland, Oregon, USA, on May 28th.
>
> Thanks for chairing this again!
>
> >  Sadly, again this year Michael Foord won't be in attendance.
>
> :(
>
> > Second: we're using a Google Form to collect signups.  This one form lets
> > you request an invitation to the summit, and also optionally propose a
> talk.
>
> In case folks are taking requests, I'd love to hear about:
>
> * status report on core workflow improvements
> * how typing has been received and what's next (e.g. more integration
> into the compiler, multiple dispatch)
> * Python in the embedded/-ish space (e.g. MicroPython, BBC MicroBit,
> RaspberryPi, android, iOS, ARM)
> * status of alternate implementations and tool chains:
>   - pyjion
>   - pyston
>   - pypy
>   - jython
>   - ironpython
>   - cython
>   - numba
>   - others?
>

I've put in for a 20 minute slot request for Pyjion to give the team a mini
version of our actual Python talk to find out if we even have a chance of
getting the C API changes we want merged in. I have no issue talking about
the GitHub transition or about my push for the CoC applying everywhere, but
I'm not sure if (B|L)arry want to give me so many talk slots (I suspect the
CoC bit can be a lightning talk).

-Brett


>
> FWIW, I've offered to present the following (as a last resort <wink>):
>
> * about C OrderedDict
> * about my Multi-core Python project
> * the successor to PEP 406 ("Improved Encapsulation of Import State")
>
> -eric
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160302/ff0accd6/attachment.html>

From ncoghlan at gmail.com  Thu Mar  3 02:45:28 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 3 Mar 2016 17:45:28 +1000
Subject: [python-committers] Call For Participants For The 2016 Python
 Language Summit
In-Reply-To: <56D63B6A.6040805@hastings.org>
References: <56D63B6A.6040805@hastings.org>
Message-ID: <CADiSq7fr=mOmyXbLtvySNDD3Y697mb5BsCu=P4uUH_Zfo_C3Ug@mail.gmail.com>

On 2 March 2016 at 11:01, Larry Hastings <larry at hastings.org> wrote:
> It's that time once again: time to start planning for the 2016 Python
> Language Summit!

Huzzah, thanks for organising this again!

I've forwarded the email to a few folks to suggest they submit
presentation proposals, but I also have a question for everyone else:
would folks be interested in a summary of the SSL/TLS handling
developments over the past couple of years and open issues (aka
"things that are still hard that we would prefer were simpler") we
could potentially help with in core dev?

I don't think there's anything in particular pending that can't be
handled just via the mailing lists and issue tracker, so this would be
more a question of whether or not folks that haven't been following it
closely would like to learn more about the *why* of it all. (Or,
equivalently, "What do we know about network security management now
that we didn't know back when the ssl module was added to Python
2.6?")

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From christian at python.org  Thu Mar  3 05:54:30 2016
From: christian at python.org (Christian Heimes)
Date: Thu, 3 Mar 2016 11:54:30 +0100
Subject: [python-committers] Call For Participants For The 2016 Python
 Language Summit
In-Reply-To: <CADiSq7fr=mOmyXbLtvySNDD3Y697mb5BsCu=P4uUH_Zfo_C3Ug@mail.gmail.com>
References: <56D63B6A.6040805@hastings.org>
 <CADiSq7fr=mOmyXbLtvySNDD3Y697mb5BsCu=P4uUH_Zfo_C3Ug@mail.gmail.com>
Message-ID: <56D817E6.40706@python.org>

On 2016-03-03 08:45, Nick Coghlan wrote:
> On 2 March 2016 at 11:01, Larry Hastings <larry at hastings.org> wrote:
>> It's that time once again: time to start planning for the 2016 Python
>> Language Summit!
> 
> Huzzah, thanks for organising this again!
> 
> I've forwarded the email to a few folks to suggest they submit
> presentation proposals, but I also have a question for everyone else:
> would folks be interested in a summary of the SSL/TLS handling
> developments over the past couple of years and open issues (aka
> "things that are still hard that we would prefer were simpler") we
> could potentially help with in core dev?

Thanks! TLS/SSL is already covered. :) I have invited Cory Benfield
(python-requests, urllib3, hyper). Cory and I are co-chairing a
presentation about the future of TLS/SSL in Python core and Python
ecosystem together. Let's hope 20 minutes are enough.

I have also proposed a short recap of Python Security, PSRT and Coverity
Scan activity in the past year. I also like to address communications of
security fixes. From the bug tracker it is not immediately visible,
which Python releases contains a fix. The changelog doesn't highlight
security fixes, too. This allowed one nasty bug to fly under the radar
and caused a downstream $VENDOR to not backport a fix. I'd like to have
security issues marked in the changelog, e.g. with "[S]" or "[SECURITY]"
prefix/suffix.

Christian


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160303/0d018b02/attachment.sig>

From victor.stinner at gmail.com  Thu Mar  3 06:26:01 2016
From: victor.stinner at gmail.com (Victor Stinner)
Date: Thu, 3 Mar 2016 12:26:01 +0100
Subject: [python-committers] Call For Participants For The 2016 Python
 Language Summit
In-Reply-To: <56D63B6A.6040805@hastings.org>
References: <56D63B6A.6040805@hastings.org>
Message-ID: <CAMpsgwbwJC9zM5UsGT6ZSoF=mU_yV2KqPb7LdULLNVX-2eXsVw@mail.gmail.com>

2016-03-02 2:01 GMT+01:00 Larry Hastings <larry at hastings.org>:
> The purpose of the event is to disseminate information and spark
> conversation among Python core developers.  It's our once-a-year chance to
> get together and hash out where we're going and what we're doing,
> face-to-face.

Sadly, I don't plan to attend Pycon US 2016 (one of the reasons is
that my talk on FAT Python was not accepted, but it's not the only
reason).

But it would be nice if we can open a discussion on the Python C API.
I understood that it's a major blocker issue for PyPy. It's probably
also a major issue for IronPython and Jython. Since Pyston & Pyjion
are based on CPython, it may impact them less, but it's probably still
an annoyance to reach *best* performances.

I would be nice to discuss how to move to a new C API which doesn't
expose implementation details and discuss if libraries will move to it
or not. Implementation "details": GIL, reference counting, C
structures like PyObject, etc.

Sorry, I have no idea how to "abstract" Python objects in such C API.
I have no idea how to design such API.

But I know well that the current C API is too wide, it's almost a
trash where we put everything. There is no clear separation between
functions strictly written to only be used internally, and functions
which are ok to be used outside the CPython code base.

I know that we have a "_Py" prefix for some symbols, but it's more the
exception than the rule. We inherited a giant C API for the old days
of CPython.

The latest major enhancement was the addition of a stable ABI, but the
usage of this API is unclear to me. I'm quite sure that we don't build
our own C extensions of the stdlib using the stable ABI. I also heard
that the stable ABI was broken more than once... So I don't think that
we can say that it's a success...

Sadly, we may conclude that it's not possible to replace the C API, or
that yet another API will not be widely used. Especially if the new
API is only supported by the latest version of Python! A requirement
is probably to be compatible with Python 2.7 and 3.4.

If someone has a more concrete vision of what should be done for the
"Python C API", please organize a session at the Language Summit
and/or open a thread on python-ideas or python-dev.

Victor

From ncoghlan at gmail.com  Thu Mar  3 07:40:22 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 3 Mar 2016 22:40:22 +1000
Subject: [python-committers] Call For Participants For The 2016 Python
 Language Summit
In-Reply-To: <CAMpsgwbwJC9zM5UsGT6ZSoF=mU_yV2KqPb7LdULLNVX-2eXsVw@mail.gmail.com>
References: <56D63B6A.6040805@hastings.org>
 <CAMpsgwbwJC9zM5UsGT6ZSoF=mU_yV2KqPb7LdULLNVX-2eXsVw@mail.gmail.com>
Message-ID: <CADiSq7cKXGJgqTQqaBR7eep008tPfbsqX45s_Y6izqVwUSnUOw@mail.gmail.com>

On 3 March 2016 at 21:26, Victor Stinner <victor.stinner at gmail.com> wrote:
> 2016-03-02 2:01 GMT+01:00 Larry Hastings <larry at hastings.org>:
>> The purpose of the event is to disseminate information and spark
>> conversation among Python core developers.  It's our once-a-year chance to
>> get together and hash out where we're going and what we're doing,
>> face-to-face.
>
> Sadly, I don't plan to attend Pycon US 2016 (one of the reasons is
> that my talk on FAT Python was not accepted, but it's not the only
> reason).
>
> But it would be nice if we can open a discussion on the Python C API.
> I understood that it's a major blocker issue for PyPy. It's probably
> also a major issue for IronPython and Jython. Since Pyston & Pyjion
> are based on CPython, it may impact them less, but it's probably still
> an annoyance to reach *best* performances.
>
> I would be nice to discuss how to move to a new C API which doesn't
> expose implementation details and discuss if libraries will move to it
> or not. Implementation "details": GIL, reference counting, C
> structures like PyObject, etc.

Adding cffi (including its dependencies) to the standard library was
approved-in-principle a couple of years ago, and I believe the one
technical issue with a lack of support for ahead-of-time compilation
of the extension module has since been addressed, so as far as I know
that just needs a champion to actually work through the details of
getting it added via the PEP process.

I'm also not aware of any explicit documentation of the underlying FFI
from a C API/ABI perspective, which is what would be needed for tools
like SWIG and Cython to support it as an alternative to the full
CPython API.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From victor.stinner at gmail.com  Thu Mar  3 09:26:01 2016
From: victor.stinner at gmail.com (Victor Stinner)
Date: Thu, 3 Mar 2016 15:26:01 +0100
Subject: [python-committers] Call For Participants For The 2016 Python
 Language Summit
In-Reply-To: <CADiSq7cKXGJgqTQqaBR7eep008tPfbsqX45s_Y6izqVwUSnUOw@mail.gmail.com>
References: <56D63B6A.6040805@hastings.org>
 <CAMpsgwbwJC9zM5UsGT6ZSoF=mU_yV2KqPb7LdULLNVX-2eXsVw@mail.gmail.com>
 <CADiSq7cKXGJgqTQqaBR7eep008tPfbsqX45s_Y6izqVwUSnUOw@mail.gmail.com>
Message-ID: <CAMpsgwYbyqtU6F5Mrr6h0OtYL1FTmwuBso5LxJFbuPgOy1qDSw@mail.gmail.com>

2016-03-03 13:40 GMT+01:00 Nick Coghlan <ncoghlan at gmail.com>:
> Adding cffi (including its dependencies) to the standard library was
> approved-in-principle a couple of years ago, and I believe the one
> technical issue with a lack of support for ahead-of-time compilation
> of the extension module has since been addressed, (...)

Hum, I also recall vaguely a discussion about pycparser dependency of cffi.

Victor

From antoine at python.org  Thu Mar  3 09:30:44 2016
From: antoine at python.org (Antoine Pitrou)
Date: Thu, 3 Mar 2016 15:30:44 +0100
Subject: [python-committers] Call For Participants For The 2016 Python
 Language Summit
In-Reply-To: <CADiSq7cKXGJgqTQqaBR7eep008tPfbsqX45s_Y6izqVwUSnUOw@mail.gmail.com>
References: <56D63B6A.6040805@hastings.org>
 <CAMpsgwbwJC9zM5UsGT6ZSoF=mU_yV2KqPb7LdULLNVX-2eXsVw@mail.gmail.com>
 <CADiSq7cKXGJgqTQqaBR7eep008tPfbsqX45s_Y6izqVwUSnUOw@mail.gmail.com>
Message-ID: <56D84A94.40800@python.org>


Le 03/03/2016 13:40, Nick Coghlan a ?crit :
>>
>> I would be nice to discuss how to move to a new C API which doesn't
>> expose implementation details and discuss if libraries will move to it
>> or not. Implementation "details": GIL, reference counting, C
>> structures like PyObject, etc.
> 
> Adding cffi (including its dependencies) to the standard library was
> approved-in-principle a couple of years ago, and I believe the one
> technical issue with a lack of support for ahead-of-time compilation
> of the extension module has since been addressed, so as far as I know
> that just needs a champion to actually work through the details of
> getting it added via the PEP process.
> 
> I'm also not aware of any explicit documentation of the underlying FFI
> from a C API/ABI perspective, which is what would be needed for tools
> like SWIG and Cython to support it as an alternative to the full
> CPython API.

I don't understand what cffi has to do with the CPython API.  You use
cffi for binding with third-party libraries.  C code wanting to
interface with CPython will continue to have to use the CPython API.

As for integrating cffi into the stdlib, it seems to be doing fine as a
third-party library.

Regards

Antoine.

From brett at python.org  Thu Mar  3 12:17:02 2016
From: brett at python.org (Brett Cannon)
Date: Thu, 03 Mar 2016 17:17:02 +0000
Subject: [python-committers] Call For Participants For The 2016 Python
 Language Summit
In-Reply-To: <CAMpsgwYbyqtU6F5Mrr6h0OtYL1FTmwuBso5LxJFbuPgOy1qDSw@mail.gmail.com>
References: <56D63B6A.6040805@hastings.org>
 <CAMpsgwbwJC9zM5UsGT6ZSoF=mU_yV2KqPb7LdULLNVX-2eXsVw@mail.gmail.com>
 <CADiSq7cKXGJgqTQqaBR7eep008tPfbsqX45s_Y6izqVwUSnUOw@mail.gmail.com>
 <CAMpsgwYbyqtU6F5Mrr6h0OtYL1FTmwuBso5LxJFbuPgOy1qDSw@mail.gmail.com>
Message-ID: <CAP1=2W44T45QeVTgzOyh5sZRj-03EuPvzd5ckMv9KKBWrUUQqw@mail.gmail.com>

On Thu, 3 Mar 2016 at 06:26 Victor Stinner <victor.stinner at gmail.com> wrote:

> 2016-03-03 13:40 GMT+01:00 Nick Coghlan <ncoghlan at gmail.com>:
> > Adding cffi (including its dependencies) to the standard library was
> > approved-in-principle a couple of years ago, and I believe the one
> > technical issue with a lack of support for ahead-of-time compilation
> > of the extension module has since been addressed, (...)
>
> Hum, I also recall vaguely a discussion about pycparser dependency of cffi.
>

Yep, the issue was pycparser which depended on PLY. At the time Alex Gaynor
said he and David Beazley were planning to fix a bunch of things in PLY and
that it would be best to hold off until PLY was cleaned up enough to go
into the stdlib. That obviously didn't happen. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160303/157df7db/attachment.html>

From brett at python.org  Thu Mar  3 12:39:17 2016
From: brett at python.org (Brett Cannon)
Date: Thu, 03 Mar 2016 17:39:17 +0000
Subject: [python-committers] Redoing the C API? (was: Call For Participants
 For The 2016 Python Language Summit)
In-Reply-To: <56D84A94.40800@python.org>
References: <56D63B6A.6040805@hastings.org>
 <CAMpsgwbwJC9zM5UsGT6ZSoF=mU_yV2KqPb7LdULLNVX-2eXsVw@mail.gmail.com>
 <CADiSq7cKXGJgqTQqaBR7eep008tPfbsqX45s_Y6izqVwUSnUOw@mail.gmail.com>
 <56D84A94.40800@python.org>
Message-ID: <CAP1=2W7hKXizRzCLK-ae8NWnMp6wOFFUpE0X0zR=d+BaOFOc1A@mail.gmail.com>

On Thu, 3 Mar 2016 at 06:31 Antoine Pitrou <antoine at python.org> wrote:

>
> Le 03/03/2016 13:40, Nick Coghlan a ?crit :
> >>
> >> I would be nice to discuss how to move to a new C API which doesn't
> >> expose implementation details and discuss if libraries will move to it
> >> or not. Implementation "details": GIL, reference counting, C
> >> structures like PyObject, etc.
> >
> > Adding cffi (including its dependencies) to the standard library was
> > approved-in-principle a couple of years ago, and I believe the one
> > technical issue with a lack of support for ahead-of-time compilation
> > of the extension module has since been addressed, so as far as I know
> > that just needs a champion to actually work through the details of
> > getting it added via the PEP process.
> >
> > I'm also not aware of any explicit documentation of the underlying FFI
> > from a C API/ABI perspective, which is what would be needed for tools
> > like SWIG and Cython to support it as an alternative to the full
> > CPython API.
>
> I don't understand what cffi has to do with the CPython API.  You use
> cffi for binding with third-party libraries.  C code wanting to
> interface with CPython will continue to have to use the CPython API.
>

You're right, it doesn't directly address the needs of integrators like
Blender who embed CPython as a scripting language. And this doesn't
directly address the needs of Numba where you want low-level access to (I
assume) the code object.

But I do think the spirit of Victor's idea is worth considering. Our C API
does expose *a lot* of low-level detail that isn't necessarily needed and
can hamper our ability to tweak how Python itself operates. We also have
not been good about deprecating parts of the C API and thus getting rid of
old ways of doing things that no longer map well on to how Python operates
now (the [import APIs]( https://docs.python.org/3/c-api/import.html) are an
example of this; I mean how many ways do we really need to expose for
importing Python code?).

So it might behoove us to stop and look at what exactly is needed by
embedders like Blender, library wrappers like NumPy or the various DB
drivers, and accelerators like Numba. That way we can maybe start
discussing things like all external code must go through a function/macro,
PyObject is to be considered opaque to third-parties, and all public APIs
have an error return value. And we discuss how to handle deprecations. And
we see if there's a way to do memory management where INCREF/DECREF is no
longer the direct responsibility of C API users. I mean if you want a
motivation/lens to look at this through, then what would we need to do to
our C API to make it so that anyone following a new API wouldn't be broken
if we dropped the GIL?


>
> As for integrating cffi into the stdlib, it seems to be doing fine as a
> third-party library.
>

It is doing fine as an external library, but if something as radical as
heavily trimming back and/or rewriting the C API occurs then having CFFI in
the stdlib to evolve with the internal C changes makes sense. I think
that's where the thought of pulling CFFI in the stdlib stems from.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160303/d1ca0035/attachment.html>

From ericsnowcurrently at gmail.com  Thu Mar  3 12:58:13 2016
From: ericsnowcurrently at gmail.com (Eric Snow)
Date: Thu, 3 Mar 2016 10:58:13 -0700
Subject: [python-committers] Redoing the C API? (was: Call For
 Participants For The 2016 Python Language Summit)
In-Reply-To: <CAP1=2W7hKXizRzCLK-ae8NWnMp6wOFFUpE0X0zR=d+BaOFOc1A@mail.gmail.com>
References: <56D63B6A.6040805@hastings.org>
 <CAMpsgwbwJC9zM5UsGT6ZSoF=mU_yV2KqPb7LdULLNVX-2eXsVw@mail.gmail.com>
 <CADiSq7cKXGJgqTQqaBR7eep008tPfbsqX45s_Y6izqVwUSnUOw@mail.gmail.com>
 <56D84A94.40800@python.org>
 <CAP1=2W7hKXizRzCLK-ae8NWnMp6wOFFUpE0X0zR=d+BaOFOc1A@mail.gmail.com>
Message-ID: <CALFfu7C1Ku2sfvnrJoA-o+XnFc4BwFyYJP3n7xgzn_cA1HhHtQ@mail.gmail.com>

On Thu, Mar 3, 2016 at 10:39 AM, Brett Cannon <brett at python.org> wrote:
> But I do think the spirit of Victor's idea is worth considering.

+1

> ...what would we need to do to our C API to make
> it so that anyone following a new API wouldn't be broken if we dropped the
> GIL?

If I recall correctly, this was one key topic that Larry discussed at
the language summit latest year.

>
>>
>>
>> As for integrating cffi into the stdlib, it seems to be doing fine as a
>> third-party library.
>
>
> It is doing fine as an external library, but if something as radical as
> heavily trimming back and/or rewriting the C API occurs then having CFFI in
> the stdlib to evolve with the internal C changes makes sense. I think that's
> where the thought of pulling CFFI in the stdlib stems from.

At least part of the motivation was to deprecate/remove ctypes and
replace it in the stdlib with CFFI.

-eric

From antoine at python.org  Thu Mar  3 13:04:08 2016
From: antoine at python.org (Antoine Pitrou)
Date: Thu, 3 Mar 2016 19:04:08 +0100
Subject: [python-committers] Redoing the C API?
In-Reply-To: <CALFfu7C1Ku2sfvnrJoA-o+XnFc4BwFyYJP3n7xgzn_cA1HhHtQ@mail.gmail.com>
References: <56D63B6A.6040805@hastings.org>
 <CAMpsgwbwJC9zM5UsGT6ZSoF=mU_yV2KqPb7LdULLNVX-2eXsVw@mail.gmail.com>
 <CADiSq7cKXGJgqTQqaBR7eep008tPfbsqX45s_Y6izqVwUSnUOw@mail.gmail.com>
 <56D84A94.40800@python.org>
 <CAP1=2W7hKXizRzCLK-ae8NWnMp6wOFFUpE0X0zR=d+BaOFOc1A@mail.gmail.com>
 <CALFfu7C1Ku2sfvnrJoA-o+XnFc4BwFyYJP3n7xgzn_cA1HhHtQ@mail.gmail.com>
Message-ID: <56D87C98.9060908@python.org>


Le 03/03/2016 18:58, Eric Snow a ?crit :
>> It is doing fine as an external library, but if something as radical as
>> heavily trimming back and/or rewriting the C API occurs then having CFFI in
>> the stdlib to evolve with the internal C changes makes sense. I think that's
>> where the thought of pulling CFFI in the stdlib stems from.
> 
> At least part of the motivation was to deprecate/remove ctypes and
> replace it in the stdlib with CFFI.

Why would that be desirable again? ctypes works perfectly fine and cffi
isn't better for its core use case (runtime binding of C libraries).

Regards

Antoine.

From brett at python.org  Thu Mar  3 13:38:04 2016
From: brett at python.org (Brett Cannon)
Date: Thu, 03 Mar 2016 18:38:04 +0000
Subject: [python-committers] Redoing the C API?
In-Reply-To: <56D87C98.9060908@python.org>
References: <56D63B6A.6040805@hastings.org>
 <CAMpsgwbwJC9zM5UsGT6ZSoF=mU_yV2KqPb7LdULLNVX-2eXsVw@mail.gmail.com>
 <CADiSq7cKXGJgqTQqaBR7eep008tPfbsqX45s_Y6izqVwUSnUOw@mail.gmail.com>
 <56D84A94.40800@python.org>
 <CAP1=2W7hKXizRzCLK-ae8NWnMp6wOFFUpE0X0zR=d+BaOFOc1A@mail.gmail.com>
 <CALFfu7C1Ku2sfvnrJoA-o+XnFc4BwFyYJP3n7xgzn_cA1HhHtQ@mail.gmail.com>
 <56D87C98.9060908@python.org>
Message-ID: <CAP1=2W6vNXBYfYZEJ6V-SDiGGAsbouz3kUz8H_2Sk00O0hxHEg@mail.gmail.com>

On Thu, 3 Mar 2016 at 10:04 Antoine Pitrou <antoine at python.org> wrote:

>
> Le 03/03/2016 18:58, Eric Snow a ?crit :
> >> It is doing fine as an external library, but if something as radical as
> >> heavily trimming back and/or rewriting the C API occurs then having
> CFFI in
> >> the stdlib to evolve with the internal C changes makes sense. I think
> that's
> >> where the thought of pulling CFFI in the stdlib stems from.
> >
> > At least part of the motivation was to deprecate/remove ctypes and
> > replace it in the stdlib with CFFI.
>
> Why would that be desirable again? ctypes works perfectly fine and cffi
> isn't better for its core use case (runtime binding of C libraries).
>

Ignoring the potential to crash the interpreter (I personally don't care
but some do), is the maintenance issue we have with ctypes (or at least
that's my hang-up with it). I think we still have not figured out what code
we have patched and so no one has been willing to update to a newer version
of libffi. I think Zachary looked into it and got some distance but never
far enough to feel comfortable with trying to update things.

But I thought CFFI's ABI in-line solution matched what ctypes did?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160303/279e5ed5/attachment.html>

From antoine at python.org  Thu Mar  3 13:40:36 2016
From: antoine at python.org (Antoine Pitrou)
Date: Thu, 3 Mar 2016 19:40:36 +0100
Subject: [python-committers] Redoing the C API?
In-Reply-To: <CAP1=2W6vNXBYfYZEJ6V-SDiGGAsbouz3kUz8H_2Sk00O0hxHEg@mail.gmail.com>
References: <56D63B6A.6040805@hastings.org>
 <CAMpsgwbwJC9zM5UsGT6ZSoF=mU_yV2KqPb7LdULLNVX-2eXsVw@mail.gmail.com>
 <CADiSq7cKXGJgqTQqaBR7eep008tPfbsqX45s_Y6izqVwUSnUOw@mail.gmail.com>
 <56D84A94.40800@python.org>
 <CAP1=2W7hKXizRzCLK-ae8NWnMp6wOFFUpE0X0zR=d+BaOFOc1A@mail.gmail.com>
 <CALFfu7C1Ku2sfvnrJoA-o+XnFc4BwFyYJP3n7xgzn_cA1HhHtQ@mail.gmail.com>
 <56D87C98.9060908@python.org>
 <CAP1=2W6vNXBYfYZEJ6V-SDiGGAsbouz3kUz8H_2Sk00O0hxHEg@mail.gmail.com>
Message-ID: <56D88524.7060703@python.org>


Le 03/03/2016 19:38, Brett Cannon a ?crit :
> 
> Ignoring the potential to crash the interpreter (I personally don't care
> but some do), is the maintenance issue we have with ctypes (or at least
> that's my hang-up with it). I think we still have not figured out what
> code we have patched and so no one has been willing to update to a newer
> version of libffi. I think Zachary looked into it and got some distance
> but never far enough to feel comfortable with trying to update things.
> 
> But I thought CFFI's ABI in-line solution matched what ctypes did?

I think it does more or less, which is why precisely I would find it
gratuitous to deprecate ctypes.

As for the maintenance problem, ok, but we might end up with the same
problems with cffi (both rely on libffi after all).

Regards

Antoine.

From brett at python.org  Thu Mar  3 13:52:20 2016
From: brett at python.org (Brett Cannon)
Date: Thu, 03 Mar 2016 18:52:20 +0000
Subject: [python-committers] Redoing the C API?
In-Reply-To: <56D88524.7060703@python.org>
References: <56D63B6A.6040805@hastings.org>
 <CAMpsgwbwJC9zM5UsGT6ZSoF=mU_yV2KqPb7LdULLNVX-2eXsVw@mail.gmail.com>
 <CADiSq7cKXGJgqTQqaBR7eep008tPfbsqX45s_Y6izqVwUSnUOw@mail.gmail.com>
 <56D84A94.40800@python.org>
 <CAP1=2W7hKXizRzCLK-ae8NWnMp6wOFFUpE0X0zR=d+BaOFOc1A@mail.gmail.com>
 <CALFfu7C1Ku2sfvnrJoA-o+XnFc4BwFyYJP3n7xgzn_cA1HhHtQ@mail.gmail.com>
 <56D87C98.9060908@python.org>
 <CAP1=2W6vNXBYfYZEJ6V-SDiGGAsbouz3kUz8H_2Sk00O0hxHEg@mail.gmail.com>
 <56D88524.7060703@python.org>
Message-ID: <CAP1=2W4UDK1VXFGqtfDs1MTYtwmmgdqZr84t_9Vdk8wMDPq03Q@mail.gmail.com>

On Thu, 3 Mar 2016 at 10:40 Antoine Pitrou <antoine at python.org> wrote:

>
> Le 03/03/2016 19:38, Brett Cannon a ?crit :
> >
> > Ignoring the potential to crash the interpreter (I personally don't care
> > but some do), is the maintenance issue we have with ctypes (or at least
> > that's my hang-up with it). I think we still have not figured out what
> > code we have patched and so no one has been willing to update to a newer
> > version of libffi. I think Zachary looked into it and got some distance
> > but never far enough to feel comfortable with trying to update things.
> >
> > But I thought CFFI's ABI in-line solution matched what ctypes did?
>
> I think it does more or less, which is why precisely I would find it
> gratuitous to deprecate ctypes.
>
> As for the maintenance problem, ok, but we might end up with the same
> problems with cffi (both rely on libffi after all).
>

Personally, if I got my way we would deprecate ctypes in the stdlib and
give it to the community to maintain (but in situations like this I rarely
get my way :). We would then keep CFFI externally and just make sure that
any new C API we developed makes sense for use by CFFI.

And another idea I had for some new-fangled C API: no macros. That gives us
a better ABI and it also makes AST analysis easier with tools like
clang-analyzer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160303/05b1711c/attachment.html>

From zachary.ware+pydev at gmail.com  Thu Mar  3 15:58:36 2016
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Thu, 3 Mar 2016 14:58:36 -0600
Subject: [python-committers] The state of our copies of libffi (was: Redoing
 the C API?)
Message-ID: <CAKJDb-N86poQ5WOyTTFVogJefeTAb4C_tryYeTp4W7ae25Ov4Q@mail.gmail.com>

On Thu, Mar 3, 2016 at 12:38 PM, Brett Cannon <brett at python.org> wrote:
> [...] the maintenance issue we have with ctypes (or at least that's
> my hang-up with it). I think we still have not figured out what code we have
> patched and so no one has been willing to update to a newer version of
> libffi. I think Zachary looked into it and got some distance but never far
> enough to feel comfortable with trying to update things.

Since I've been invoked, I'll try to explain our libffi situation as
far as I understand it.  This is just a history lesson, I don't really
have an opinion on what should be done with it.  I will opine that we
have some seriously old unmaintained code here, and the whole libffi
situation in cpython is far more complex than is ideal.

We actually have four separate copies of libffi:

Modules/_ctypes/libffi: This is a mostly-vanilla copy of libffi-3.1
(released 19May2014), lightly patched according to
Modules/_ctypes/libffi.diff.  This one is used for any non-OSX posix
build that doesn't use `--with-system-ffi`.  doko has done a pretty
good job keeping this one relatively up to date.

Modules/_ctypes/libffi_osx: This is a "lightly patched" copy from
somewhere before libffi-2.0, probably.  It has barely been touched
since 2009.  I've been given to understand that it has modifications
necessary to allow building fat binaries on OSX (Ned or Ronald would
know better than I), but I don't know if such modifications may have
made it upstream since pre-2.0.  This one is used for all OSX builds
that don't use `--with-system-ffi`.

Modules/_ctypes/libffi_msvc: This is a heavily patched copy from
27January2004 and is used for all Windows builds.  The patches include
additional functionality, namely
(IIRC) returning the number of arguments expected when calling a
foreign function with the wrong number of arguments to allow ctypes to
raise a ValueError instead of crashing.  I'm fairly certain those
modifications have not been even submitted upstream, and the
intervening twelve years (and my utter lack of experience working with
asm) scare me away from trying to forward-port the patches from
libffi_msvc.  I did attempt to use a vanilla libffi on Windows
sometime in 2014/2015, but ran into the issue that it doesn't have the
features ctypes wants, which made a few fairly basic tests fail.

Modules/_ctypes/libffi_arm_wince: I don't know why we even have this.
Nobody has touched it since ctypes was merged into cpython in 2006.

-- 
Zach

From victor.stinner at gmail.com  Thu Mar  3 19:43:17 2016
From: victor.stinner at gmail.com (Victor Stinner)
Date: Fri, 4 Mar 2016 01:43:17 +0100
Subject: [python-committers] The state of our copies of libffi (was:
 Redoing the C API?)
In-Reply-To: <CAKJDb-N86poQ5WOyTTFVogJefeTAb4C_tryYeTp4W7ae25Ov4Q@mail.gmail.com>
References: <CAKJDb-N86poQ5WOyTTFVogJefeTAb4C_tryYeTp4W7ae25Ov4Q@mail.gmail.com>
Message-ID: <CAMpsgwYfrzasn2JP5xUMHjAVZ0uGmNapTQE5wZCa4wDLqT6Zuw@mail.gmail.com>

Why starting many discussions on the private python-committers mailing
list? Why not discussing libffi on python-dev?

Victor

From victor.stinner at gmail.com  Thu Mar  3 19:49:03 2016
From: victor.stinner at gmail.com (Victor Stinner)
Date: Fri, 4 Mar 2016 01:49:03 +0100
Subject: [python-committers] Redoing the C API? (was: Call For
 Participants For The 2016 Python Language Summit)
In-Reply-To: <CAP1=2W7hKXizRzCLK-ae8NWnMp6wOFFUpE0X0zR=d+BaOFOc1A@mail.gmail.com>
References: <56D63B6A.6040805@hastings.org>
 <CAMpsgwbwJC9zM5UsGT6ZSoF=mU_yV2KqPb7LdULLNVX-2eXsVw@mail.gmail.com>
 <CADiSq7cKXGJgqTQqaBR7eep008tPfbsqX45s_Y6izqVwUSnUOw@mail.gmail.com>
 <56D84A94.40800@python.org>
 <CAP1=2W7hKXizRzCLK-ae8NWnMp6wOFFUpE0X0zR=d+BaOFOc1A@mail.gmail.com>
Message-ID: <CAMpsgwbWi2KitR1p-7wE=DFB0Kjd5zy0soBxUxjZxdJ8e=s4Pw@mail.gmail.com>

2016-03-03 18:39 GMT+01:00 Brett Cannon <brett at python.org>:
> But I do think the spirit of Victor's idea is worth considering.

Oh, another note about such theorical API. For CPython, it would be
nice to experiment to implement such new API *on top* of the existing
Python C API. And it should be a third party project to get more
contributors, faster feedback, etc. As I wrote, supporting Python 2.7
and 3.4 with the same API is important to ensure that the API is
widely used.

Maybe I should start to collect ideas somewhere...

Victor

From brett at python.org  Thu Mar  3 22:23:33 2016
From: brett at python.org (Brett Cannon)
Date: Fri, 04 Mar 2016 03:23:33 +0000
Subject: [python-committers] The state of our copies of libffi (was:
 Redoing the C API?)
In-Reply-To: <CAMpsgwYfrzasn2JP5xUMHjAVZ0uGmNapTQE5wZCa4wDLqT6Zuw@mail.gmail.com>
References: <CAKJDb-N86poQ5WOyTTFVogJefeTAb4C_tryYeTp4W7ae25Ov4Q@mail.gmail.com>
 <CAMpsgwYfrzasn2JP5xUMHjAVZ0uGmNapTQE5wZCa4wDLqT6Zuw@mail.gmail.com>
Message-ID: <CAP1=2W5099QiZw3Un7Nsey+ft1_NCQbTw0VOufT51L3=_rbbJw@mail.gmail.com>

On Thu, Mar 3, 2016, 16:43 Victor Stinner <victor.stinner at gmail.com> wrote:

> Why starting many discussions on the private python-committers mailing
> list? Why not discussing libffi on python-dev?
>

Because they are offshoots of your email to python-committers about the C
API and no one changed the to: field.



> Victor
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160304/82bc922f/attachment.html>

From brett at python.org  Fri Mar  4 16:31:44 2016
From: brett at python.org (Brett Cannon)
Date: Fri, 04 Mar 2016 21:31:44 +0000
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
Message-ID: <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>

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.

So what I will do is try to convince the managers of python-dev to put it
under the CoC and get the CoC mentioned in the footer of  bugs.python.org.
I will update the devguide to say that the various mailing lists and issue
tracker are under the CoC so people are aware, but I won't go as far as I
was originally proposing about covering all public, Python-related
interactions. Once we move to GitHub we will most likely have a
CONTRIBUTING file that links to the devguide and that file will mention
that interactions involving the repo are under the CoC (or some other
wording that says pull requests fall under the Code of Conduct).

On Fri, 26 Feb 2016 at 11:29 Brett Cannon <brett at python.org> wrote:

> I noticed that the devguide didn't explicitly mention that core developers
> were expected to follow the PSF CoC (
> https://docs.python.org/devguide/coredev.html and
> https://www.python.org/psf/codeofconduct/, respectively). I have opened
> http://bugs.python.org/issue26446 to make sure it gets documented.
>
> Since this is technically a modification of the requirements of getting
> commit privileges I wanted to mention it here before I (or anyone else)
> made the change.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160304/bd0caf54/attachment.html>

From mal at egenix.com  Fri Mar  4 17:04:07 2016
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 4 Mar 2016 23:04:07 +0100
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
Message-ID: <56DA0657.3060401@egenix.com>

Brett,

I don't think that spamming all MLs, Github accounts, etc.
with CoC notices will help anyone.

You may not be aware, but all PSF infrastructure is covered by
the PSF CoC already, and has been for quite a while:

"""
     RESOLVED, that the Python Software Foundation shall manage and curate the Foundation's public
and member-accessible web properties to remove spam, serve the membership, and conform to the the
Python Community Code of Conduct.

Approved 9-0-0 by IRC vote, 3 January, 2014.
"""

All PSF members have acknowledged this and adding yet another
notice to each and every point of interaction will not make
things better.

If there are issues, point people to the CoC. Otherwise, let's
not get all tangled up in CoC links everywhere :-)

We can get the 16 ton weight out when needed...

https://www.youtube.com/watch?v=U90dnUbZMmM

and optionally even send the tiger.

Cheers,
-- 
Marc-Andre Lemburg


On 04.03.2016 22:31, 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.
> 
> So what I will do is try to convince the managers of python-dev to put it
> under the CoC and get the CoC mentioned in the footer of  bugs.python.org.
> I will update the devguide to say that the various mailing lists and issue
> tracker are under the CoC so people are aware, but I won't go as far as I
> was originally proposing about covering all public, Python-related
> interactions. Once we move to GitHub we will most likely have a
> CONTRIBUTING file that links to the devguide and that file will mention
> that interactions involving the repo are under the CoC (or some other
> wording that says pull requests fall under the Code of Conduct).
> 
> On Fri, 26 Feb 2016 at 11:29 Brett Cannon <brett at python.org> wrote:
> 
>> I noticed that the devguide didn't explicitly mention that core developers
>> were expected to follow the PSF CoC (
>> https://docs.python.org/devguide/coredev.html and
>> https://www.python.org/psf/codeofconduct/, respectively). I have opened
>> http://bugs.python.org/issue26446 to make sure it gets documented.
>>
>> Since this is technically a modification of the requirements of getting
>> commit privileges I wanted to mention it here before I (or anyone else)
>> made the change.
>>
> 
> 
> 
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
> 

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Mar 04 2016)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...           http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
________________________________________________________________________
2016-02-19: Released eGenix PyRun 2.1.2 ...       http://egenix.com/go88

::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/
                      http://www.malemburg.com/


From rdmurray at bitdance.com  Fri Mar  4 18:07:00 2016
From: rdmurray at bitdance.com (R. David Murray)
Date: Fri, 04 Mar 2016 18:07:00 -0500
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
Message-ID: <20160304230701.BA000B1401C@webabinitio.net>

On Fri, 04 Mar 2016 21:31:44 +0000, Brett Cannon <brett at python.org> 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 :)

--David

[*] I think it is a feeling of annoyance, like I'm being nagged for
no good reason, inclining me to turn my attention away instead of joyfully
engaging.  Talking about how welcoming the Python community is, and how we
can be more so, engenders joy.  Talking about codes of conduct engenders
annoyance.  Regardless of the reality, it *feels* like the bureaucrats
have moved in and are squashing the native aliveness of the community.

From brett at python.org  Fri Mar  4 18:40:56 2016
From: brett at python.org (Brett Cannon)
Date: Fri, 04 Mar 2016 23:40:56 +0000
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <56DA0657.3060401@egenix.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
 <56DA0657.3060401@egenix.com>
Message-ID: <CAP1=2W5GjgAChz=ipLYPbVSHaC2h8Fu7iTQFyCJ+TDUP=3JpSQ@mail.gmail.com>

On Fri, 4 Mar 2016 at 14:04 M.-A. Lemburg <mal at egenix.com> wrote:

> Brett,
>
> I don't think that spamming all MLs, Github accounts, etc.
> with CoC notices will help anyone.
>

Which is not what I'm suggesting nor would I want to do unless it's a
stated change in policy so people feel properly notified.


>
> You may not be aware, but all PSF infrastructure is covered by
> the PSF CoC already, and has been for quite a while:
>
> """
>      RESOLVED, that the Python Software Foundation shall manage and curate
> the Foundation's public
> and member-accessible web properties to remove spam, serve the membership,
> and conform to the the
> Python Community Code of Conduct.
>
> Approved 9-0-0 by IRC vote, 3 January, 2014.
> """
>

That's great, but how are people to know this if they don't read the
minutes of the board? Is it considered too much if I link to the minutes in
the devguide so people know about this (
https://www.python.org/psf/records/board/minutes/2014-01-06/#management-of-the-psfs-web-properties
)?


>
> All PSF members have acknowledged this and adding yet another
> notice to each and every point of interaction will not make
> things better.
>

I'm not worried about PSF members, it's all the new folk who are just
"walking off the street" and are looking to contribute.


>
> If there are issues, point people to the CoC. Otherwise, let's
> not get all tangled up in CoC links everywhere :-)
>

Fair enough, but I would like at least one canonical location to link to
that bit of the minutes so that it's somewhere a bit more public. Is a link
in the devguide considered acceptable?

-Brett


>
> We can get the 16 ton weight out when needed...
>
> https://www.youtube.com/watch?v=U90dnUbZMmM
>
> and optionally even send the tiger.
>
> Cheers,
> --
> Marc-Andre Lemburg
>
>
> On 04.03.2016 22:31, 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.
> >
> > So what I will do is try to convince the managers of python-dev to put it
> > under the CoC and get the CoC mentioned in the footer of
> bugs.python.org.
> > I will update the devguide to say that the various mailing lists and
> issue
> > tracker are under the CoC so people are aware, but I won't go as far as I
> > was originally proposing about covering all public, Python-related
> > interactions. Once we move to GitHub we will most likely have a
> > CONTRIBUTING file that links to the devguide and that file will mention
> > that interactions involving the repo are under the CoC (or some other
> > wording that says pull requests fall under the Code of Conduct).
> >
> > On Fri, 26 Feb 2016 at 11:29 Brett Cannon <brett at python.org> wrote:
> >
> >> I noticed that the devguide didn't explicitly mention that core
> developers
> >> were expected to follow the PSF CoC (
> >> https://docs.python.org/devguide/coredev.html and
> >> https://www.python.org/psf/codeofconduct/, respectively). I have opened
> >> http://bugs.python.org/issue26446 to make sure it gets documented.
> >>
> >> Since this is technically a modification of the requirements of getting
> >> commit privileges I wanted to mention it here before I (or anyone else)
> >> made the change.
> >>
> >
> >
> >
> > _______________________________________________
> > python-committers mailing list
> > python-committers at python.org
> > https://mail.python.org/mailman/listinfo/python-committers
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
> >
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Experts (#1, Mar 04 2016)
> >>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
> >>> Python Database Interfaces ...           http://products.egenix.com/
> >>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
> ________________________________________________________________________
> 2016-02-19: Released eGenix PyRun 2.1.2 ...       http://egenix.com/go88
>
> ::: We implement business ideas - efficiently in both time and costs :::
>
>    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>            Registered at Amtsgericht Duesseldorf: HRB 46611
>                http://www.egenix.com/company/contact/
>                       http://www.malemburg.com/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160304/b12cf999/attachment-0001.html>

From ethan at stoneleaf.us  Fri Mar  4 18:51:06 2016
From: ethan at stoneleaf.us (Ethan Furman)
Date: Fri, 04 Mar 2016 15:51:06 -0800
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <20160304230701.BA000B1401C@webabinitio.net>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
 <20160304230701.BA000B1401C@webabinitio.net>
Message-ID: <56DA1F6A.1070001@stoneleaf.us>

On 03/04/2016 03:07 PM, R. David Murray wrote:

 > I guess I have one more thing to say.

[snip]

 > [*] I think it is a feeling of annoyance, like I'm being nagged for
 > no good reason [...]

I'm inclined to agree, but some bureaucracy is the price of success.  Be 
grateful somebody else is willing to do the work of getting it in place, 
so we don't have to.  ;)

--
~Ethan~

From brett at python.org  Fri Mar  4 19:07:47 2016
From: brett at python.org (Brett Cannon)
Date: Sat, 05 Mar 2016 00:07:47 +0000
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <20160304230701.BA000B1401C@webabinitio.net>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
 <20160304230701.BA000B1401C@webabinitio.net>
Message-ID: <CAP1=2W7QdTFtBpEjmw=VSQoqaipT4qiNSr6nGss70qmE8oq=3w@mail.gmail.com>

On Fri, 4 Mar 2016 at 15:07 R. David Murray <rdmurray at bitdance.com> wrote:

> On Fri, 04 Mar 2016 21:31:44 +0000, Brett Cannon <brett at python.org> 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.

Now I'm not advocating for some quota for adding new members or that they
have to meet some minority group status, but we should be aware of this and
perhaps ask why this is. When I thought about this the other week after a
cranky email to python-dev appeared I realized that the CoC isn't exactly
advertised so that people know they shouldn't act mean here like they might
in other corners of the internet where it's tolerated. I thought perhaps if
we took this one time to make it officially in effect then it would remove
at least one tiny barrier that might be holding up people from getting more
involved. I certainly don't want any morality police, but I do want people
to know that Python development is not one of the mean, cesspool corners of
the internet either. And so I figured adding a link at the bottom of a
couple of things would be a minor thing and a nice gesture to newcomers. I
didn't mean for it to seem like a perpetual burden for anyone or a
deterrent to contributing.

-Brett


>
> --David
>
> [*] I think it is a feeling of annoyance, like I'm being nagged for
> no good reason, inclining me to turn my attention away instead of joyfully
> engaging.  Talking about how welcoming the Python community is, and how we
> can be more so, engenders joy.  Talking about codes of conduct engenders
> annoyance.  Regardless of the reality, it *feels* like the bureaucrats
> have moved in and are squashing the native aliveness of the community.
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160305/2a684be3/attachment.html>

From ericsnowcurrently at gmail.com  Fri Mar  4 19:20:56 2016
From: ericsnowcurrently at gmail.com (Eric Snow)
Date: Fri, 4 Mar 2016 17:20:56 -0700
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <CAP1=2W7QdTFtBpEjmw=VSQoqaipT4qiNSr6nGss70qmE8oq=3w@mail.gmail.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
 <20160304230701.BA000B1401C@webabinitio.net>
 <CAP1=2W7QdTFtBpEjmw=VSQoqaipT4qiNSr6nGss70qmE8oq=3w@mail.gmail.com>
Message-ID: <CALFfu7BoEJ05EvE2gJx67o2ONRsNz-FG8_UfHkm+08nBCY96Fg@mail.gmail.com>

On Fri, Mar 4, 2016 at 5:07 PM, Brett Cannon <brett at python.org> wrote:
> When I thought about this the other week after a
> cranky email to python-dev appeared I realized that the CoC isn't exactly
> advertised so that people know they shouldn't act mean here like they might
> in other corners of the internet where it's tolerated. I thought perhaps if
> we took this one time to make it officially in effect then it would remove
> at least one tiny barrier that might be holding up people from getting more
> involved. I certainly don't want any morality police, but I do want people
> to know that Python development is not one of the mean, cesspool corners of
> the internet either. And so I figured adding a link at the bottom of a
> couple of things would be a minor thing and a nice gesture to newcomers. I
> didn't mean for it to seem like a perpetual burden for anyone or a deterrent
> to contributing.

Perhaps it would be sufficient to reference the CoC on each list's
page rather than in each email footer.  Then it's not so in-your-face
(not that I had visually noticed that it was already added on
recently).

-eric

From ethan at stoneleaf.us  Fri Mar  4 19:39:04 2016
From: ethan at stoneleaf.us (Ethan Furman)
Date: Fri, 04 Mar 2016 16:39:04 -0800
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <CAP1=2W7QdTFtBpEjmw=VSQoqaipT4qiNSr6nGss70qmE8oq=3w@mail.gmail.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
 <20160304230701.BA000B1401C@webabinitio.net>
 <CAP1=2W7QdTFtBpEjmw=VSQoqaipT4qiNSr6nGss70qmE8oq=3w@mail.gmail.com>
Message-ID: <56DA2AA8.9000003@stoneleaf.us>

On 03/04/2016 04:07 PM, Brett Cannon wrote:

> We also still have no female or minority members.

Well, I'n not female, but I am of Native American / Latino descent.  So 
you have at least one.  :)

And yes, those extremely low numbers of new committers are a bit 
worrying.  :(

--
~Ethan~

From larry at hastings.org  Fri Mar  4 23:25:27 2016
From: larry at hastings.org (Larry Hastings)
Date: Fri, 4 Mar 2016 20:25:27 -0800
Subject: [python-committers] Redoing the C API?
In-Reply-To: <CALFfu7C1Ku2sfvnrJoA-o+XnFc4BwFyYJP3n7xgzn_cA1HhHtQ@mail.gmail.com>
References: <56D63B6A.6040805@hastings.org>
 <CAMpsgwbwJC9zM5UsGT6ZSoF=mU_yV2KqPb7LdULLNVX-2eXsVw@mail.gmail.com>
 <CADiSq7cKXGJgqTQqaBR7eep008tPfbsqX45s_Y6izqVwUSnUOw@mail.gmail.com>
 <56D84A94.40800@python.org>
 <CAP1=2W7hKXizRzCLK-ae8NWnMp6wOFFUpE0X0zR=d+BaOFOc1A@mail.gmail.com>
 <CALFfu7C1Ku2sfvnrJoA-o+XnFc4BwFyYJP3n7xgzn_cA1HhHtQ@mail.gmail.com>
Message-ID: <56DA5FB7.2060801@hastings.org>

p

On 03/03/2016 09:58 AM, Eric Snow wrote:
> On Thu, Mar 3, 2016 at 10:39 AM, Brett Cannon <brett at python.org> wrote:
>> ...what would we need to do to our C API to make
>> it so that anyone following a new API wouldn't be broken if we dropped the
>> GIL?
> If I recall correctly, this was one key topic that Larry discussed at
> the language summit latest year.

Kinda, yeah.  Certainly it's a topic I've thought a lot about.

Consider this.  With almost no exceptions*, none of the popular new 
languages have a C API.  Instead they'll have a foreign function 
interface allowing you to call C from inside the language.  So you don't 
write extensions in C and call into the language, you write your 
extensions natively in the language and call out.

One advantage of this technique is that it allows most implementation 
details of the language to remain hidden.  CPython can't drop reference 
counting and move solely to tracing garbage collection, because the C 
API lets external callers deal with Python objects, which means Python's 
internal object lifetime management approach must be visible, which 
means it's implicitly part of the API.  In short, if we change from 
reference counting to tracing GC, we break every C extension in 
existence, kablooey, oblivion.

But!  If there were no C extensions--if all Python programs talked to 
native libraries through FFIs like ctypes and cffi--then this would be a 
private implementation detail and we could iterate however we liked on 
object lifetime management.  I've asked Armin Rigo about PyPy here.  
Pardon me if my memory is faulty, but what I think he said was this: 
they started with GC, then went to generational GC, then went to 
incremental generational GC.  If they'd had a C API, going to 
generational probably wouldn't have broken all their extensions, but 
going to incremental absolutely would have.  Since PyPy doesn't have a C 
API, naturally they can change it all they like.

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.  That'd be great for cross-implementation compatibility; your 
extension would (hopefully) run unchanged in CPython and PyPy today, and 
I heard a rumor that Jython and IronPython want to support cffi too, so 
hey! someday it might run unchanged in those too.  This would also make 
it possible for CPython to declare that the C API was dead and free us 
up to make some radical but welcome changes to CPython's innards. 
Unfortunately, we don't have such a magic wand, and I don't think 
there's any workable path to convince extension authors to switch en 
masse.  And if we're stuck with the C API, we're stuck with a lot of the 
implementation details that are baked into it.

I'm hoping to present on this subject at this year's summit.  I hope all 
the interested core devs can make it!


//arry/


* The only exception I know of is Lua--are there more?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160304/0727edd6/attachment-0001.html>

From rdmurray at bitdance.com  Fri Mar  4 23:31:02 2016
From: rdmurray at bitdance.com (R. David Murray)
Date: Fri, 04 Mar 2016 23:31:02 -0500
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <CAP1=2W7QdTFtBpEjmw=VSQoqaipT4qiNSr6nGss70qmE8oq=3w@mail.gmail.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
 <20160304230701.BA000B1401C@webabinitio.net>
 <CAP1=2W7QdTFtBpEjmw=VSQoqaipT4qiNSr6nGss70qmE8oq=3w@mail.gmail.com>
Message-ID: <20160305043104.60898B1401C@webabinitio.net>

On Fri, 04 Mar 2016 21:31:44 +0000, Brett Cannon <brett at python.org> 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:
> 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.

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....

--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).  And I suspect maciej.szulik is also a
candidate once we've seen a few more patches from him.  (And I need
to find the time to review the ones he has already submitted in the
email area.)

Someone or ones should look at tracker activity by username and see if
they can find some more candidates.

From raymond.hettinger at gmail.com  Sat Mar  5 01:07:43 2016
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Fri, 4 Mar 2016 22:07:43 -0800
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <CAP1=2W7QdTFtBpEjmw=VSQoqaipT4qiNSr6nGss70qmE8oq=3w@mail.gmail.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
 <20160304230701.BA000B1401C@webabinitio.net>
 <CAP1=2W7QdTFtBpEjmw=VSQoqaipT4qiNSr6nGss70qmE8oq=3w@mail.gmail.com>
Message-ID: <C7F77519-ED72-4DBB-97FC-755AD578B3D9@gmail.com>


> On Mar 4, 2016, at 4:07 PM, Brett Cannon <brett at python.org> 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.

The social barriers to entry proved too high even for an seasoned open source developer, the former chief scientist at Continuum, who had already devoted substantial time to reviewing the 100+ tracker entries for multiprocessing, who had expressed a willingness to handle complex and neglected tasks, and who was recommended by an active core developer.

If someone of his stature faces an uphill battle, then perhaps there is reason to worry.


Raymond

From greg at krypto.org  Sat Mar  5 01:44:15 2016
From: greg at krypto.org (Gregory P. Smith)
Date: Sat, 05 Mar 2016 06:44:15 +0000
Subject: [python-committers] Davin Potts as a new committer
In-Reply-To: <C7F77519-ED72-4DBB-97FC-755AD578B3D9@gmail.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
 <20160304230701.BA000B1401C@webabinitio.net>
 <CAP1=2W7QdTFtBpEjmw=VSQoqaipT4qiNSr6nGss70qmE8oq=3w@mail.gmail.com>
 <C7F77519-ED72-4DBB-97FC-755AD578B3D9@gmail.com>
Message-ID: <CAGE7PNKtBoxNgMiT-x3CgoV+FB1rMJKdU0VPqSbQ22tGHe5Eyg@mail.gmail.com>

On Fri, Mar 4, 2016 at 10:07 PM Raymond Hettinger <
raymond.hettinger at gmail.com> wrote:

>
> > On Mar 4, 2016, at 4:07 PM, Brett Cannon <brett at python.org> 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.

Let's get Davin a commit bit.

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160305/45eada97/attachment.html>

From berker.peksag at gmail.com  Sat Mar  5 02:21:38 2016
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Sat, 5 Mar 2016 09:21:38 +0200
Subject: [python-committers] Davin Potts as a new committer
In-Reply-To: <CAGE7PNKtBoxNgMiT-x3CgoV+FB1rMJKdU0VPqSbQ22tGHe5Eyg@mail.gmail.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
 <20160304230701.BA000B1401C@webabinitio.net>
 <CAP1=2W7QdTFtBpEjmw=VSQoqaipT4qiNSr6nGss70qmE8oq=3w@mail.gmail.com>
 <C7F77519-ED72-4DBB-97FC-755AD578B3D9@gmail.com>
 <CAGE7PNKtBoxNgMiT-x3CgoV+FB1rMJKdU0VPqSbQ22tGHe5Eyg@mail.gmail.com>
Message-ID: <CAF4280LBo9-r=zWNe9aqgtCGUipamvtjrZOZHr=LdnmB9NO7yQ@mail.gmail.com>

On Sat, Mar 5, 2016 at 8:44 AM, Gregory P. Smith <greg at krypto.org> wrote:
>
> On Fri, Mar 4, 2016 at 10:07 PM Raymond Hettinger
> <raymond.hettinger at gmail.com> wrote:
>>
>>
>> > On Mar 4, 2016, at 4:07 PM, Brett Cannon <brett at python.org> 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

From nad at python.org  Sat Mar  5 02:38:21 2016
From: nad at python.org (Ned Deily)
Date: Sat, 5 Mar 2016 02:38:21 -0500
Subject: [python-committers] Davin Potts as a new committer
In-Reply-To: <CAGE7PNKtBoxNgMiT-x3CgoV+FB1rMJKdU0VPqSbQ22tGHe5Eyg@mail.gmail.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
 <20160304230701.BA000B1401C@webabinitio.net>
 <CAP1=2W7QdTFtBpEjmw=VSQoqaipT4qiNSr6nGss70qmE8oq=3w@mail.gmail.com>
 <C7F77519-ED72-4DBB-97FC-755AD578B3D9@gmail.com>
 <CAGE7PNKtBoxNgMiT-x3CgoV+FB1rMJKdU0VPqSbQ22tGHe5Eyg@mail.gmail.com>
Message-ID: <AD463E44-ADCA-4A70-8533-744AD70E1CF5@python.org>

On Mar 5, 2016, at 01:44, Gregory P. Smith <greg at krypto.org> 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
  nad at python.org -- []


From antoine at python.org  Sat Mar  5 02:33:14 2016
From: antoine at python.org (Antoine Pitrou)
Date: Sat, 5 Mar 2016 08:33:14 +0100
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <C7F77519-ED72-4DBB-97FC-755AD578B3D9@gmail.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
 <20160304230701.BA000B1401C@webabinitio.net>
 <CAP1=2W7QdTFtBpEjmw=VSQoqaipT4qiNSr6nGss70qmE8oq=3w@mail.gmail.com>
 <C7F77519-ED72-4DBB-97FC-755AD578B3D9@gmail.com>
Message-ID: <56DA8BBA.9010807@python.org>


Le 05/03/2016 07:07, Raymond Hettinger a ?crit :
> 
>> On Mar 4, 2016, at 4:07 PM, Brett Cannon <brett at python.org> 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.

From nad at python.org  Sat Mar  5 03:18:54 2016
From: nad at python.org (Ned Deily)
Date: Sat, 05 Mar 2016 03:18:54 -0500
Subject: [python-committers] Making the PSF CoC apply to core developers
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
 <20160304230701.BA000B1401C@webabinitio.net>
 <CAP1=2W7QdTFtBpEjmw=VSQoqaipT4qiNSr6nGss70qmE8oq=3w@mail.gmail.com>
 <20160305043104.60898B1401C@webabinitio.net>
Message-ID: <nad-83CCD2.03185405032016@news.gmane.org>

In article <20160305043104.60898B1401C at webabinitio.net>,
 "R. David Murray" <rdmurray at bitdance.com> 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,
 nad at python.org


From stefan at bytereef.org  Sat Mar  5 03:42:14 2016
From: stefan at bytereef.org (Stefan Krah)
Date: Sat, 5 Mar 2016 08:42:14 +0000 (UTC)
Subject: [python-committers] CFFI is slow (was: Re: Redoing the C API?)
References: <56D63B6A.6040805@hastings.org>
 <CAMpsgwbwJC9zM5UsGT6ZSoF=mU_yV2KqPb7LdULLNVX-2eXsVw@mail.gmail.com>
 <CADiSq7cKXGJgqTQqaBR7eep008tPfbsqX45s_Y6izqVwUSnUOw@mail.gmail.com>
 <56D84A94.40800@python.org>
 <CAP1=2W7hKXizRzCLK-ae8NWnMp6wOFFUpE0X0zR=d+BaOFOc1A@mail.gmail.com>
 <CALFfu7C1Ku2sfvnrJoA-o+XnFc4BwFyYJP3n7xgzn_cA1HhHtQ@mail.gmail.com>
 <56DA5FB7.2060801@hastings.org>
Message-ID: <loom.20160305T093538-662@post.gmane.org>

Larry Hastings <larry <at> 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


From storchaka at gmail.com  Sat Mar  5 03:57:53 2016
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sat, 5 Mar 2016 10:57:53 +0200
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <nad-83CCD2.03185405032016@news.gmane.org>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
 <20160304230701.BA000B1401C@webabinitio.net>
 <CAP1=2W7QdTFtBpEjmw=VSQoqaipT4qiNSr6nGss70qmE8oq=3w@mail.gmail.com>
 <20160305043104.60898B1401C@webabinitio.net>
 <nad-83CCD2.03185405032016@news.gmane.org>
Message-ID: <nbe72h$p11$1@ger.gmane.org>

On 05.03.16 10:18, Ned Deily wrote:
> In article <20160305043104.60898B1401C at webabinitio.net>,
>   "R. David Murray" <rdmurray at bitdance.com> 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.



From storchaka at gmail.com  Sat Mar  5 04:03:49 2016
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Sat, 5 Mar 2016 11:03:49 +0200
Subject: [python-committers] Davin Potts as a new committer
In-Reply-To: <CAF4280LBo9-r=zWNe9aqgtCGUipamvtjrZOZHr=LdnmB9NO7yQ@mail.gmail.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
 <20160304230701.BA000B1401C@webabinitio.net>
 <CAP1=2W7QdTFtBpEjmw=VSQoqaipT4qiNSr6nGss70qmE8oq=3w@mail.gmail.com>
 <C7F77519-ED72-4DBB-97FC-755AD578B3D9@gmail.com>
 <CAGE7PNKtBoxNgMiT-x3CgoV+FB1rMJKdU0VPqSbQ22tGHe5Eyg@mail.gmail.com>
 <CAF4280LBo9-r=zWNe9aqgtCGUipamvtjrZOZHr=LdnmB9NO7yQ@mail.gmail.com>
Message-ID: <nbe7dl$tle$1@ger.gmane.org>

On 05.03.16 09:21, Berker Peksa? wrote:
> On Sat, Mar 5, 2016 at 8:44 AM, Gregory P. Smith <greg at krypto.org> wrote:
>> On Fri, Mar 4, 2016 at 10:07 PM Raymond Hettinger
>> <raymond.hettinger at gmail.com> wrote:
>>>> On Mar 4, 2016, at 4:07 PM, Brett Cannon <brett at python.org> 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.



From stefan at bytereef.org  Sat Mar  5 04:12:16 2016
From: stefan at bytereef.org (Stefan Krah)
Date: Sat, 5 Mar 2016 09:12:16 +0000 (UTC)
Subject: [python-committers] CFFI is slow (was: Re: Redoing the C API?)
References: <56D63B6A.6040805@hastings.org>
 <CAMpsgwbwJC9zM5UsGT6ZSoF=mU_yV2KqPb7LdULLNVX-2eXsVw@mail.gmail.com>
 <CADiSq7cKXGJgqTQqaBR7eep008tPfbsqX45s_Y6izqVwUSnUOw@mail.gmail.com>
 <56D84A94.40800@python.org>
 <CAP1=2W7hKXizRzCLK-ae8NWnMp6wOFFUpE0X0zR=d+BaOFOc1A@mail.gmail.com>
 <CALFfu7C1Ku2sfvnrJoA-o+XnFc4BwFyYJP3n7xgzn_cA1HhHtQ@mail.gmail.com>
 <56DA5FB7.2060801@hastings.org> <loom.20160305T093538-662@post.gmane.org>
Message-ID: <loom.20160305T100621-126@post.gmane.org>

Stefan Krah <stefan <at> 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


From larry at hastings.org  Sat Mar  5 04:31:34 2016
From: larry at hastings.org (Larry Hastings)
Date: Sat, 5 Mar 2016 01:31:34 -0800
Subject: [python-committers] CFFI is slow
In-Reply-To: <loom.20160305T093538-662@post.gmane.org>
References: <56D63B6A.6040805@hastings.org>
 <CAMpsgwbwJC9zM5UsGT6ZSoF=mU_yV2KqPb7LdULLNVX-2eXsVw@mail.gmail.com>
 <CADiSq7cKXGJgqTQqaBR7eep008tPfbsqX45s_Y6izqVwUSnUOw@mail.gmail.com>
 <56D84A94.40800@python.org>
 <CAP1=2W7hKXizRzCLK-ae8NWnMp6wOFFUpE0X0zR=d+BaOFOc1A@mail.gmail.com>
 <CALFfu7C1Ku2sfvnrJoA-o+XnFc4BwFyYJP3n7xgzn_cA1HhHtQ@mail.gmail.com>
 <56DA5FB7.2060801@hastings.org> <loom.20160305T093538-662@post.gmane.org>
Message-ID: <56DAA776.7030107@hastings.org>



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 <larry <at> 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 at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160305/b1df09c2/attachment.html>

From p.f.moore at gmail.com  Sat Mar  5 04:49:43 2016
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 5 Mar 2016 09:49:43 +0000
Subject: [python-committers] Redoing the C API?
In-Reply-To: <56DA5FB7.2060801@hastings.org>
References: <56D63B6A.6040805@hastings.org>
 <CAMpsgwbwJC9zM5UsGT6ZSoF=mU_yV2KqPb7LdULLNVX-2eXsVw@mail.gmail.com>
 <CADiSq7cKXGJgqTQqaBR7eep008tPfbsqX45s_Y6izqVwUSnUOw@mail.gmail.com>
 <56D84A94.40800@python.org>
 <CAP1=2W7hKXizRzCLK-ae8NWnMp6wOFFUpE0X0zR=d+BaOFOc1A@mail.gmail.com>
 <CALFfu7C1Ku2sfvnrJoA-o+XnFc4BwFyYJP3n7xgzn_cA1HhHtQ@mail.gmail.com>
 <56DA5FB7.2060801@hastings.org>
Message-ID: <CACac1F8QSJQN5A6-Ns-sMcOxM_udPEkiLxO=FS6HrHwWLMGwZQ@mail.gmail.com>

On 5 March 2016 at 04:25, Larry Hastings <larry at hastings.org> 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

From stefan at bytereef.org  Sat Mar  5 04:50:04 2016
From: stefan at bytereef.org (Stefan Krah)
Date: Sat, 5 Mar 2016 09:50:04 +0000 (UTC)
Subject: [python-committers] CFFI is slow
References: <56D63B6A.6040805@hastings.org>
 <CAMpsgwbwJC9zM5UsGT6ZSoF=mU_yV2KqPb7LdULLNVX-2eXsVw@mail.gmail.com>
 <CADiSq7cKXGJgqTQqaBR7eep008tPfbsqX45s_Y6izqVwUSnUOw@mail.gmail.com>
 <56D84A94.40800@python.org>
 <CAP1=2W7hKXizRzCLK-ae8NWnMp6wOFFUpE0X0zR=d+BaOFOc1A@mail.gmail.com>
 <CALFfu7C1Ku2sfvnrJoA-o+XnFc4BwFyYJP3n7xgzn_cA1HhHtQ@mail.gmail.com>
 <56DA5FB7.2060801@hastings.org> <loom.20160305T093538-662@post.gmane.org>
 <56DAA776.7030107@hastings.org>
Message-ID: <loom.20160305T104409-616@post.gmane.org>

Larry Hastings <larry <at> 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

From antoine at python.org  Sat Mar  5 05:52:52 2016
From: antoine at python.org (Antoine Pitrou)
Date: Sat, 5 Mar 2016 11:52:52 +0100
Subject: [python-committers] CFFI is slow
In-Reply-To: <56DAA776.7030107@hastings.org>
References: <56D63B6A.6040805@hastings.org>
 <CAMpsgwbwJC9zM5UsGT6ZSoF=mU_yV2KqPb7LdULLNVX-2eXsVw@mail.gmail.com>
 <CADiSq7cKXGJgqTQqaBR7eep008tPfbsqX45s_Y6izqVwUSnUOw@mail.gmail.com>
 <56D84A94.40800@python.org>
 <CAP1=2W7hKXizRzCLK-ae8NWnMp6wOFFUpE0X0zR=d+BaOFOc1A@mail.gmail.com>
 <CALFfu7C1Ku2sfvnrJoA-o+XnFc4BwFyYJP3n7xgzn_cA1HhHtQ@mail.gmail.com>
 <56DA5FB7.2060801@hastings.org> <loom.20160305T093538-662@post.gmane.org>
 <56DAA776.7030107@hastings.org>
Message-ID: <56DABA84.7080209@python.org>


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.

From tjreedy at udel.edu  Sat Mar  5 05:46:22 2016
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 05 Mar 2016 05:46:22 -0500
Subject: [python-committers] CFFI is slow
In-Reply-To: <56DAA776.7030107@hastings.org>
References: <56D63B6A.6040805@hastings.org>
 <CAMpsgwbwJC9zM5UsGT6ZSoF=mU_yV2KqPb7LdULLNVX-2eXsVw@mail.gmail.com>
 <CADiSq7cKXGJgqTQqaBR7eep008tPfbsqX45s_Y6izqVwUSnUOw@mail.gmail.com>
 <56D84A94.40800@python.org>
 <CAP1=2W7hKXizRzCLK-ae8NWnMp6wOFFUpE0X0zR=d+BaOFOc1A@mail.gmail.com>
 <CALFfu7C1Ku2sfvnrJoA-o+XnFc4BwFyYJP3n7xgzn_cA1HhHtQ@mail.gmail.com>
 <56DA5FB7.2060801@hastings.org> <loom.20160305T093538-662@post.gmane.org>
 <56DAA776.7030107@hastings.org>
Message-ID: <56DAB8FE.3050004@udel.edu>

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


From brett at python.org  Sat Mar  5 11:51:11 2016
From: brett at python.org (Brett Cannon)
Date: Sat, 05 Mar 2016 16:51:11 +0000
Subject: [python-committers] Davin Potts as a new committer
In-Reply-To: <nbe7dl$tle$1@ger.gmane.org>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
 <20160304230701.BA000B1401C@webabinitio.net>
 <CAP1=2W7QdTFtBpEjmw=VSQoqaipT4qiNSr6nGss70qmE8oq=3w@mail.gmail.com>
 <C7F77519-ED72-4DBB-97FC-755AD578B3D9@gmail.com>
 <CAGE7PNKtBoxNgMiT-x3CgoV+FB1rMJKdU0VPqSbQ22tGHe5Eyg@mail.gmail.com>
 <CAF4280LBo9-r=zWNe9aqgtCGUipamvtjrZOZHr=LdnmB9NO7yQ@mail.gmail.com>
 <nbe7dl$tle$1@ger.gmane.org>
Message-ID: <CAP1=2W6U1cWq0JUzaysGmM+A2eD99Tc-N9ybivB26Dpfz_Vt-Q@mail.gmail.com>

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 <storchaka at gmail.com> wrote:

> On 05.03.16 09:21, Berker Peksa? wrote:
> > On Sat, Mar 5, 2016 at 8:44 AM, Gregory P. Smith <greg at krypto.org>
> wrote:
> >> On Fri, Mar 4, 2016 at 10:07 PM Raymond Hettinger
> >> <raymond.hettinger at gmail.com> wrote:
> >>>> On Mar 4, 2016, at 4:07 PM, Brett Cannon <brett at python.org> 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 at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160305/7cdb9a75/attachment.html>

From g.brandl at gmx.net  Sat Mar  5 13:58:23 2016
From: g.brandl at gmx.net (Georg Brandl)
Date: Sat, 5 Mar 2016 19:58:23 +0100
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <CAP1=2W7QdTFtBpEjmw=VSQoqaipT4qiNSr6nGss70qmE8oq=3w@mail.gmail.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
 <20160304230701.BA000B1401C@webabinitio.net>
 <CAP1=2W7QdTFtBpEjmw=VSQoqaipT4qiNSr6nGss70qmE8oq=3w@mail.gmail.com>
Message-ID: <nbfa8f$rog$1@ger.gmane.org>

On 03/05/2016 01:07 AM, Brett Cannon wrote:
> 
> 
> On Fri, 4 Mar 2016 at 15:07 R. David Murray <rdmurray at bitdance.com
> <mailto:rdmurray at bitdance.com>> wrote:
> 
>     On Fri, 04 Mar 2016 21:31:44 +0000, Brett Cannon <brett at python.org
>     <mailto:brett at python.org>> 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
>     <http://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



From brett at python.org  Sat Mar  5 15:52:08 2016
From: brett at python.org (Brett Cannon)
Date: Sat, 05 Mar 2016 20:52:08 +0000
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <nbfa8f$rog$1@ger.gmane.org>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
 <20160304230701.BA000B1401C@webabinitio.net>
 <CAP1=2W7QdTFtBpEjmw=VSQoqaipT4qiNSr6nGss70qmE8oq=3w@mail.gmail.com>
 <nbfa8f$rog$1@ger.gmane.org>
Message-ID: <CAP1=2W55yerN2vomC_2Q1FnVuwNzmzDqX0=EjAXphQQuG2iCdw@mail.gmail.com>

On Sat, 5 Mar 2016 at 10:58 Georg Brandl <g.brandl at gmx.net> wrote:

> On 03/05/2016 01:07 AM, Brett Cannon wrote:
> >
> >
> > On Fri, 4 Mar 2016 at 15:07 R. David Murray <rdmurray at bitdance.com
> > <mailto:rdmurray at bitdance.com>> wrote:
> >
> >     On Fri, 04 Mar 2016 21:31:44 +0000, Brett Cannon <brett at python.org
> >     <mailto:brett at python.org>> 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
> >     <http://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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160305/9dbd94c5/attachment.html>

From raymond.hettinger at gmail.com  Sat Mar  5 20:59:01 2016
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Sat, 5 Mar 2016 17:59:01 -0800
Subject: [python-committers] Davin Potts as a new committer
In-Reply-To: <CAP1=2W6U1cWq0JUzaysGmM+A2eD99Tc-N9ybivB26Dpfz_Vt-Q@mail.gmail.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
 <20160304230701.BA000B1401C@webabinitio.net>
 <CAP1=2W7QdTFtBpEjmw=VSQoqaipT4qiNSr6nGss70qmE8oq=3w@mail.gmail.com>
 <C7F77519-ED72-4DBB-97FC-755AD578B3D9@gmail.com>
 <CAGE7PNKtBoxNgMiT-x3CgoV+FB1rMJKdU0VPqSbQ22tGHe5Eyg@mail.gmail.com>
 <CAF4280LBo9-r=zWNe9aqgtCGUipamvtjrZOZHr=LdnmB9NO7yQ@mail.gmail.com>
 <nbe7dl$tle$1@ger.gmane.org>
 <CAP1=2W6U1cWq0JUzaysGmM+A2eD99Tc-N9ybivB26Dpfz_Vt-Q@mail.gmail.com>
Message-ID: <150E8496-E77A-4D8F-A701-39924CDE6046@gmail.com>


> On Mar 5, 2016, at 8:51 AM, Brett Cannon <brett at python.org> 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




From ncoghlan at gmail.com  Sat Mar  5 21:00:40 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 6 Mar 2016 12:00:40 +1000
Subject: [python-committers] Redoing the C API?
In-Reply-To: <CACac1F8QSJQN5A6-Ns-sMcOxM_udPEkiLxO=FS6HrHwWLMGwZQ@mail.gmail.com>
References: <56D63B6A.6040805@hastings.org>
 <CAMpsgwbwJC9zM5UsGT6ZSoF=mU_yV2KqPb7LdULLNVX-2eXsVw@mail.gmail.com>
 <CADiSq7cKXGJgqTQqaBR7eep008tPfbsqX45s_Y6izqVwUSnUOw@mail.gmail.com>
 <56D84A94.40800@python.org>
 <CAP1=2W7hKXizRzCLK-ae8NWnMp6wOFFUpE0X0zR=d+BaOFOc1A@mail.gmail.com>
 <CALFfu7C1Ku2sfvnrJoA-o+XnFc4BwFyYJP3n7xgzn_cA1HhHtQ@mail.gmail.com>
 <56DA5FB7.2060801@hastings.org>
 <CACac1F8QSJQN5A6-Ns-sMcOxM_udPEkiLxO=FS6HrHwWLMGwZQ@mail.gmail.com>
Message-ID: <CADiSq7eUOXVxC5y6GG2aJKQ8z_J9LMg-N4vgi1Q8X=9i+im60A@mail.gmail.com>

On 5 March 2016 at 19:49, Paul Moore <p.f.moore at gmail.com> wrote:

> On 5 March 2016 at 04:25, Larry Hastings <larry at hastings.org> 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   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160306/565f5c34/attachment-0001.html>

From ncoghlan at gmail.com  Sat Mar  5 21:15:49 2016
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 6 Mar 2016 12:15:49 +1000
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <CAP1=2W55yerN2vomC_2Q1FnVuwNzmzDqX0=EjAXphQQuG2iCdw@mail.gmail.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
 <20160304230701.BA000B1401C@webabinitio.net>
 <CAP1=2W7QdTFtBpEjmw=VSQoqaipT4qiNSr6nGss70qmE8oq=3w@mail.gmail.com>
 <nbfa8f$rog$1@ger.gmane.org>
 <CAP1=2W55yerN2vomC_2Q1FnVuwNzmzDqX0=EjAXphQQuG2iCdw@mail.gmail.com>
Message-ID: <CADiSq7cVf9w=JrW5NjZN4WwQ1VhMxmoW_5Lt4gD7f_ZwzVc5_A@mail.gmail.com>

On 6 March 2016 at 06:52, Brett Cannon <brett at python.org> wrote:

>
> On Sat, 5 Mar 2016 at 10:58 Georg Brandl <g.brandl at gmx.net> 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   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160306/653992ec/attachment.html>

From brett at python.org  Sun Mar  6 00:48:26 2016
From: brett at python.org (Brett Cannon)
Date: Sun, 06 Mar 2016 05:48:26 +0000
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <CADiSq7cVf9w=JrW5NjZN4WwQ1VhMxmoW_5Lt4gD7f_ZwzVc5_A@mail.gmail.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
 <20160304230701.BA000B1401C@webabinitio.net>
 <CAP1=2W7QdTFtBpEjmw=VSQoqaipT4qiNSr6nGss70qmE8oq=3w@mail.gmail.com>
 <nbfa8f$rog$1@ger.gmane.org>
 <CAP1=2W55yerN2vomC_2Q1FnVuwNzmzDqX0=EjAXphQQuG2iCdw@mail.gmail.com>
 <CADiSq7cVf9w=JrW5NjZN4WwQ1VhMxmoW_5Lt4gD7f_ZwzVc5_A@mail.gmail.com>
Message-ID: <CAP1=2W4hayXrahRwJZqmArPDOdF9FnqLcdHVBDFVDGyfCyJrZQ@mail.gmail.com>

On Sat, 5 Mar 2016 at 18:15 Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 6 March 2016 at 06:52, Brett Cannon <brett at python.org> wrote:
>
>> On Sat, 5 Mar 2016 at 10:58 Georg Brandl <g.brandl at gmx.net> 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   |   ncoghlan at gmail.com   |   Brisbane, Australia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160306/f13ddb8d/attachment.html>

From brett at python.org  Sun Mar  6 01:13:14 2016
From: brett at python.org (Brett Cannon)
Date: Sun, 06 Mar 2016 06:13:14 +0000
Subject: [python-committers] Davin Potts as a new committer
In-Reply-To: <150E8496-E77A-4D8F-A701-39924CDE6046@gmail.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
 <20160304230701.BA000B1401C@webabinitio.net>
 <CAP1=2W7QdTFtBpEjmw=VSQoqaipT4qiNSr6nGss70qmE8oq=3w@mail.gmail.com>
 <C7F77519-ED72-4DBB-97FC-755AD578B3D9@gmail.com>
 <CAGE7PNKtBoxNgMiT-x3CgoV+FB1rMJKdU0VPqSbQ22tGHe5Eyg@mail.gmail.com>
 <CAF4280LBo9-r=zWNe9aqgtCGUipamvtjrZOZHr=LdnmB9NO7yQ@mail.gmail.com>
 <nbe7dl$tle$1@ger.gmane.org>
 <CAP1=2W6U1cWq0JUzaysGmM+A2eD99Tc-N9ybivB26Dpfz_Vt-Q@mail.gmail.com>
 <150E8496-E77A-4D8F-A701-39924CDE6046@gmail.com>
Message-ID: <CAP1=2W5+b58mSUo8HO47cf=rm_irX2AkUDemzbGWgsMB-ZcNUA@mail.gmail.com>

On Sat, 5 Mar 2016 at 17:59 Raymond Hettinger <raymond.hettinger at gmail.com>
wrote:

>
> > On Mar 5, 2016, at 8:51 AM, Brett Cannon <brett at python.org> 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
hgaccounts at python.org (which can also simply be his GitHub account since
https://github.com/<username>.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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160306/6d01ed71/attachment-0001.html>

From raymond.hettinger at gmail.com  Sun Mar  6 03:22:59 2016
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Sun, 6 Mar 2016 00:22:59 -0800
Subject: [python-committers] Davin Potts as a new committer
In-Reply-To: <CAP1=2W5+b58mSUo8HO47cf=rm_irX2AkUDemzbGWgsMB-ZcNUA@mail.gmail.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
 <20160304230701.BA000B1401C@webabinitio.net>
 <CAP1=2W7QdTFtBpEjmw=VSQoqaipT4qiNSr6nGss70qmE8oq=3w@mail.gmail.com>
 <C7F77519-ED72-4DBB-97FC-755AD578B3D9@gmail.com>
 <CAGE7PNKtBoxNgMiT-x3CgoV+FB1rMJKdU0VPqSbQ22tGHe5Eyg@mail.gmail.com>
 <CAF4280LBo9-r=zWNe9aqgtCGUipamvtjrZOZHr=LdnmB9NO7yQ@mail.gmail.com>
 <nbe7dl$tle$1@ger.gmane.org>
 <CAP1=2W6U1cWq0JUzaysGmM+A2eD99Tc-N9ybivB26Dpfz_Vt-Q@mail.gmail.com>
 <150E8496-E77A-4D8F-A701-39924CDE6046@gmail.com>
 <CAP1=2W5+b58mSUo8HO47cf=rm_irX2AkUDemzbGWgsMB-ZcNUA@mail.gmail.com>
Message-ID: <8490B0F1-700A-41DB-999F-797C42CA5B4C@gmail.com>


> On Mar 5, 2016, at 10:13 PM, Brett Cannon <brett at python.org> wrote:
> 
> Does your offer to mentor Davin still stand,

Yes.


Raymond


From ezio.melotti at gmail.com  Sun Mar  6 11:52:34 2016
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Sun, 6 Mar 2016 18:52:34 +0200
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <CAP1=2W5RLvVPRqvH=psWfjU=MrQ2CQRv+ntn8QSQXW7P_QjrrQ@mail.gmail.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <loom.20160227T121049-853@post.gmane.org>
 <CAP1=2W5RLvVPRqvH=psWfjU=MrQ2CQRv+ntn8QSQXW7P_QjrrQ@mail.gmail.com>
Message-ID: <CACBhJdFYjGvJng=MeXG83tM6w=Sk8EMwbjJjosS=tox9qKq3hw@mail.gmail.com>

On Sat, Feb 27, 2016 at 7:17 PM, Brett Cannon <brett at python.org> wrote:
>
>
> Python-ideas has been under the same CoC for a while now and it has been
> nothing but positive. When people know they are expected to behave in a
> civil manner and others know they are allowed to call someone out for being
> uncivil it typically is enough to make people behave.
>
> So there is no issue of people "being overburdened by regulations". The CoC
> only comes up when someone is being so rude that they need to be talked to
> about their attitude  problem, so as long as we try and keep people from
> being rude  it won't come up. Quite frankly, the CoC is really just meant as
> a way for people to feel comfortable in knowing they don't have to tolerate
> jerks. And I would hope none of us are jerks to people in the community, so
> saying as much shouldn't change anything for any of us. This also lets the
> community know that we don't view ourselves as some elite group of people
> whose attitudes must be tolerated no matter what; we hold ourselves to the
> same standards as the rest of the community does and it should be pointed
> out as such to make people feel comfortable.
>

It seems to me that the "controversies" raised in this thread stem
from a few underlying problems and points of confusions.

The first problem is that it is not entirely clear (at least to me)
why we need a CoC and what problem is the CoC trying to solve.  The
CoC itself simply mentions: "[...] these guidelines [...] help steer
our interactions and strive to keep Python a positive, successful, and
growing community.".  Clearly stating the goal of the CoC will help
people understand why it is useful.

The second problem is that Code of Conducts usually outline rules[0],
and this can be perceived as limiting one's freedom and potentially be
abused for censoring users.  Our CoC however is quite "mild", so I
believe people that expressed concern were mostly against the idea of
having a CoC, rather than being against our CoC in particular.
However is also not clear what measures -- if any -- will be taken to
enforce the CoC[1].

Which bring us to the the third problem: if, how, and by whom these
"guidelines" are enforced.  Enforcement requires judgment, and
judgment requires judges.  Who is to judge if e.g. one or more mails
in broken English, or with a perceived rude tone, or with unrealistic
proposals are detrimental to the conversation and should be "rejected"
or if they should be accepted/tolerated/embraced in the spirit of
inclusiveness?  If they are "rejected", what specific actions are
going to be taken?


ISTM that our CoC simply puts black on white the general principles
that we have already being following, without outlining any hard
rules. It should therefore have little to no effects -- both positive
and negative -- on existing members.  It might however serve as a
remainder to people that disregard (intentionally or not) these
principles, and help shaping the image of our community for external
people -- including potential new members of our community.

Best Regards,
Ezio Melotti


[0]: "A code of conduct is a set of rules outlining the social norms
and rules and responsibilities of, or proper practices for, an
individual, party or organization." --
https://en.wikipedia.org/wiki/Code_of_conduct

[1]: "Studies of codes of conduct in the private sector show that
their effective implementation must be part of a learning process that
requires training, consistent enforcement, and continuous
measurement/improvement." --
https://en.wikipedia.org/wiki/Code_of_conduct

From mal at egenix.com  Sun Mar  6 13:07:38 2016
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun, 6 Mar 2016 19:07:38 +0100
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <CACBhJdFYjGvJng=MeXG83tM6w=Sk8EMwbjJjosS=tox9qKq3hw@mail.gmail.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <loom.20160227T121049-853@post.gmane.org>
 <CAP1=2W5RLvVPRqvH=psWfjU=MrQ2CQRv+ntn8QSQXW7P_QjrrQ@mail.gmail.com>
 <CACBhJdFYjGvJng=MeXG83tM6w=Sk8EMwbjJjosS=tox9qKq3hw@mail.gmail.com>
Message-ID: <56DC71EA.4020202@egenix.com>

On 06.03.2016 17:52, Ezio Melotti wrote:
> On Sat, Feb 27, 2016 at 7:17 PM, Brett Cannon <brett at python.org> wrote:
>>
>>
>> Python-ideas has been under the same CoC for a while now and it has been
>> nothing but positive. When people know they are expected to behave in a
>> civil manner and others know they are allowed to call someone out for being
>> uncivil it typically is enough to make people behave.
>>
>> So there is no issue of people "being overburdened by regulations". The CoC
>> only comes up when someone is being so rude that they need to be talked to
>> about their attitude  problem, so as long as we try and keep people from
>> being rude  it won't come up. Quite frankly, the CoC is really just meant as
>> a way for people to feel comfortable in knowing they don't have to tolerate
>> jerks. And I would hope none of us are jerks to people in the community, so
>> saying as much shouldn't change anything for any of us. This also lets the
>> community know that we don't view ourselves as some elite group of people
>> whose attitudes must be tolerated no matter what; we hold ourselves to the
>> same standards as the rest of the community does and it should be pointed
>> out as such to make people feel comfortable.
>>
> 
> It seems to me that the "controversies" raised in this thread stem
> from a few underlying problems and points of confusions.
> 
> The first problem is that it is not entirely clear (at least to me)
> why we need a CoC and what problem is the CoC trying to solve.  The
> CoC itself simply mentions: "[...] these guidelines [...] help steer
> our interactions and strive to keep Python a positive, successful, and
> growing community.".  Clearly stating the goal of the CoC will help
> people understand why it is useful.
> 
> The second problem is that Code of Conducts usually outline rules[0],
> and this can be perceived as limiting one's freedom and potentially be
> abused for censoring users.  Our CoC however is quite "mild", so I
> believe people that expressed concern were mostly against the idea of
> having a CoC, rather than being against our CoC in particular.
> However is also not clear what measures -- if any -- will be taken to
> enforce the CoC[1].
> 
> Which bring us to the the third problem: if, how, and by whom these
> "guidelines" are enforced.  Enforcement requires judgment, and
> judgment requires judges.  Who is to judge if e.g. one or more mails
> in broken English, or with a perceived rude tone, or with unrealistic
> proposals are detrimental to the conversation and should be "rejected"
> or if they should be accepted/tolerated/embraced in the spirit of
> inclusiveness?  If they are "rejected", what specific actions are
> going to be taken?

FYI: I only know of a single case where we have triggered the CoC
to ban someone from MLs. The decision was taken by the PSF board
members who ultimately have to decide these things (or delegate the
decision to someone else).

The board deliberately put the bar very high for any such sanctions.

> ISTM that our CoC simply puts black on white the general principles
> that we have already being following, without outlining any hard
> rules. It should therefore have little to no effects -- both positive
> and negative -- on existing members.  It might however serve as a
> remainder to people that disregard (intentionally or not) these
> principles, and help shaping the image of our community for external
> people -- including potential new members of our community.
> 
> Best Regards,
> Ezio Melotti
> 
> 
> [0]: "A code of conduct is a set of rules outlining the social norms
> and rules and responsibilities of, or proper practices for, an
> individual, party or organization." --
> https://en.wikipedia.org/wiki/Code_of_conduct
> 
> [1]: "Studies of codes of conduct in the private sector show that
> their effective implementation must be part of a learning process that
> requires training, consistent enforcement, and continuous
> measurement/improvement." --
> https://en.wikipedia.org/wiki/Code_of_conduct
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
> 

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Mar 06 2016)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...           http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
________________________________________________________________________
2016-02-19: Released eGenix PyRun 2.1.2 ...       http://egenix.com/go88

::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/
                      http://www.malemburg.com/


From mal at egenix.com  Sun Mar  6 13:13:46 2016
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun, 6 Mar 2016 19:13:46 +0100
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <CAP1=2W5GjgAChz=ipLYPbVSHaC2h8Fu7iTQFyCJ+TDUP=3JpSQ@mail.gmail.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
 <56DA0657.3060401@egenix.com>
 <CAP1=2W5GjgAChz=ipLYPbVSHaC2h8Fu7iTQFyCJ+TDUP=3JpSQ@mail.gmail.com>
Message-ID: <56DC735A.9060900@egenix.com>

On 05.03.2016 00:40, Brett Cannon wrote:
> On Fri, 4 Mar 2016 at 14:04 M.-A. Lemburg <mal at egenix.com> wrote:
> 
>> Brett,
>>
>> I don't think that spamming all MLs, Github accounts, etc.
>> with CoC notices will help anyone.
>>
> 
> Which is not what I'm suggesting nor would I want to do unless it's a
> stated change in policy so people feel properly notified.

I was referring to adding CoC links to all ML footers (causing it
to appeary on each and every ML message), all Github repos, etc.

I think this is not helpful. It's better to have a single page
on the python.org where we state how we use the CoC and perhaps
a footer link on python.org pointing to it.

Perhaps we don't even need a new page and simply use the
existing CoC page for this, by adding some more text to it
and perhaps a FAQ section.

>>
>> You may not be aware, but all PSF infrastructure is covered by
>> the PSF CoC already, and has been for quite a while:
>>
>> """
>>      RESOLVED, that the Python Software Foundation shall manage and curate
>> the Foundation's public
>> and member-accessible web properties to remove spam, serve the membership,
>> and conform to the the
>> Python Community Code of Conduct.
>>
>> Approved 9-0-0 by IRC vote, 3 January, 2014.
>> """
>>
> 
> That's great, but how are people to know this if they don't read the
> minutes of the board? Is it considered too much if I link to the minutes in
> the devguide so people know about this (
> https://www.python.org/psf/records/board/minutes/2014-01-06/#management-of-the-psfs-web-properties
> )?

If needed at all, it's better to link to above yet-to-be-written page.

>> All PSF members have acknowledged this and adding yet another
>> notice to each and every point of interaction will not make
>> things better.
>>
> 
> I'm not worried about PSF members, it's all the new folk who are just
> "walking off the street" and are looking to contribute.
> 
> 
>>
>> If there are issues, point people to the CoC. Otherwise, let's
>> not get all tangled up in CoC links everywhere :-)
>>
> 
> Fair enough, but I would like at least one canonical location to link to
> that bit of the minutes so that it's somewhere a bit more public. Is a link
> in the devguide considered acceptable?
> 
> -Brett
> 
> 
>>
>> We can get the 16 ton weight out when needed...
>>
>> https://www.youtube.com/watch?v=U90dnUbZMmM
>>
>> and optionally even send the tiger.
>>
>> Cheers,
>> --
>> Marc-Andre Lemburg
>>
>>
>> On 04.03.2016 22:31, 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.
>>>
>>> So what I will do is try to convince the managers of python-dev to put it
>>> under the CoC and get the CoC mentioned in the footer of
>> bugs.python.org.
>>> I will update the devguide to say that the various mailing lists and
>> issue
>>> tracker are under the CoC so people are aware, but I won't go as far as I
>>> was originally proposing about covering all public, Python-related
>>> interactions. Once we move to GitHub we will most likely have a
>>> CONTRIBUTING file that links to the devguide and that file will mention
>>> that interactions involving the repo are under the CoC (or some other
>>> wording that says pull requests fall under the Code of Conduct).
>>>
>>> On Fri, 26 Feb 2016 at 11:29 Brett Cannon <brett at python.org> wrote:
>>>
>>>> I noticed that the devguide didn't explicitly mention that core
>> developers
>>>> were expected to follow the PSF CoC (
>>>> https://docs.python.org/devguide/coredev.html and
>>>> https://www.python.org/psf/codeofconduct/, respectively). I have opened
>>>> http://bugs.python.org/issue26446 to make sure it gets documented.
>>>>
>>>> Since this is technically a modification of the requirements of getting
>>>> commit privileges I wanted to mention it here before I (or anyone else)
>>>> made the change.
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> python-committers mailing list
>>> python-committers at python.org
>>> https://mail.python.org/mailman/listinfo/python-committers
>>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>>
>>
>> --
>> Marc-Andre Lemburg
>> eGenix.com
>>
>> Professional Python Services directly from the Experts (#1, Mar 04 2016)
>>>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>>>> Python Database Interfaces ...           http://products.egenix.com/
>>>>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
>> ________________________________________________________________________
>> 2016-02-19: Released eGenix PyRun 2.1.2 ...       http://egenix.com/go88
>>
>> ::: We implement business ideas - efficiently in both time and costs :::
>>
>>    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>>     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>>            Registered at Amtsgericht Duesseldorf: HRB 46611
>>                http://www.egenix.com/company/contact/
>>                       http://www.malemburg.com/
>>
>>
> 
> 
> 
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
> 

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Mar 06 2016)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...           http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
________________________________________________________________________
2016-02-19: Released eGenix PyRun 2.1.2 ...       http://egenix.com/go88

::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/
                      http://www.malemburg.com/


From brett at python.org  Sun Mar  6 13:19:43 2016
From: brett at python.org (Brett Cannon)
Date: Sun, 06 Mar 2016 18:19:43 +0000
Subject: [python-committers] Davin Potts as a new committer
In-Reply-To: <8490B0F1-700A-41DB-999F-797C42CA5B4C@gmail.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
 <20160304230701.BA000B1401C@webabinitio.net>
 <CAP1=2W7QdTFtBpEjmw=VSQoqaipT4qiNSr6nGss70qmE8oq=3w@mail.gmail.com>
 <C7F77519-ED72-4DBB-97FC-755AD578B3D9@gmail.com>
 <CAGE7PNKtBoxNgMiT-x3CgoV+FB1rMJKdU0VPqSbQ22tGHe5Eyg@mail.gmail.com>
 <CAF4280LBo9-r=zWNe9aqgtCGUipamvtjrZOZHr=LdnmB9NO7yQ@mail.gmail.com>
 <nbe7dl$tle$1@ger.gmane.org>
 <CAP1=2W6U1cWq0JUzaysGmM+A2eD99Tc-N9ybivB26Dpfz_Vt-Q@mail.gmail.com>
 <150E8496-E77A-4D8F-A701-39924CDE6046@gmail.com>
 <CAP1=2W5+b58mSUo8HO47cf=rm_irX2AkUDemzbGWgsMB-ZcNUA@mail.gmail.com>
 <8490B0F1-700A-41DB-999F-797C42CA5B4C@gmail.com>
Message-ID: <CAP1=2W7e97gsO24+o-D2LGmzoXsOkiaxmX_TSyc8GzDbApfMtQ@mail.gmail.com>

On Sun, 6 Mar 2016 at 00:23 Raymond Hettinger <raymond.hettinger at gmail.com>
wrote:

>
> > On Mar 5, 2016, at 10:13 PM, Brett Cannon <brett at python.org> wrote:
> >
> > Does your offer to mentor Davin still stand,
>
> Yes.
>

Great! Then as I said previously, get him to send his SSH keys to
hgaccounts at python.org, verify for me that his username is "davin" on
bugs.python.org, and have him subscribe to python-committers and friends,
and I will handle the rest.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160306/9ddac562/attachment.html>

From brett at python.org  Sun Mar  6 13:24:03 2016
From: brett at python.org (Brett Cannon)
Date: Sun, 06 Mar 2016 18:24:03 +0000
Subject: [python-committers] Making the PSF CoC apply to core developers
In-Reply-To: <56DC735A.9060900@egenix.com>
References: <CAP1=2W6R+BEBeFf=gq9ZvCo9RF78Gve8_PxPmLExzbDVU3kY7g@mail.gmail.com>
 <CAP1=2W6iZEP1ZV39VaxF7w5yBePKq7-i3OzQva78P=-dSf-FSg@mail.gmail.com>
 <56DA0657.3060401@egenix.com>
 <CAP1=2W5GjgAChz=ipLYPbVSHaC2h8Fu7iTQFyCJ+TDUP=3JpSQ@mail.gmail.com>
 <56DC735A.9060900@egenix.com>
Message-ID: <CAP1=2W4iGJjge6krFGqc_kNwN7HMVjL9QGxwE+r=iZVk0uBVNA@mail.gmail.com>

On Sun, 6 Mar 2016 at 10:13 M.-A. Lemburg <mal at egenix.com> wrote:

> On 05.03.2016 00:40, Brett Cannon wrote:
> > On Fri, 4 Mar 2016 at 14:04 M.-A. Lemburg <mal at egenix.com> wrote:
> >
> >> Brett,
> >>
> >> I don't think that spamming all MLs, Github accounts, etc.
> >> with CoC notices will help anyone.
> >>
> >
> > Which is not what I'm suggesting nor would I want to do unless it's a
> > stated change in policy so people feel properly notified.
>
> I was referring to adding CoC links to all ML footers (causing it
> to appeary on each and every ML message), all Github repos, etc.
>
> I think this is not helpful. It's better to have a single page
> on the python.org where we state how we use the CoC and perhaps
> a footer link on python.org pointing to it.
>
> Perhaps we don't even need a new page and simply use the
> existing CoC page for this, by adding some more text to it
> and perhaps a FAQ section.
>

That works for me as well. Did you want the board to amend the CoC with the
relevant details or did you want me to just  directly edit the coc repo?


>
> >>
> >> You may not be aware, but all PSF infrastructure is covered by
> >> the PSF CoC already, and has been for quite a while:
> >>
> >> """
> >>      RESOLVED, that the Python Software Foundation shall manage and
> curate
> >> the Foundation's public
> >> and member-accessible web properties to remove spam, serve the
> membership,
> >> and conform to the the
> >> Python Community Code of Conduct.
> >>
> >> Approved 9-0-0 by IRC vote, 3 January, 2014.
> >> """
> >>
> >
> > That's great, but how are people to know this if they don't read the
> > minutes of the board? Is it considered too much if I link to the minutes
> in
> > the devguide so people know about this (
> >
> https://www.python.org/psf/records/board/minutes/2014-01-06/#management-of-the-psfs-web-properties
> > )?
>
> If needed at all, it's better to link to above yet-to-be-written page.
>

WFM.

-Brett


>
> >> All PSF members have acknowledged this and adding yet another
> >> notice to each and every point of interaction will not make
> >> things better.
> >>
> >
> > I'm not worried about PSF members, it's all the new folk who are just
> > "walking off the street" and are looking to contribute.
> >
> >
> >>
> >> If there are issues, point people to the CoC. Otherwise, let's
> >> not get all tangled up in CoC links everywhere :-)
> >>
> >
> > Fair enough, but I would like at least one canonical location to link to
> > that bit of the minutes so that it's somewhere a bit more public. Is a
> link
> > in the devguide considered acceptable?
> >
> > -Brett
> >
> >
> >>
> >> We can get the 16 ton weight out when needed...
> >>
> >> https://www.youtube.com/watch?v=U90dnUbZMmM
> >>
> >> and optionally even send the tiger.
> >>
> >> Cheers,
> >> --
> >> Marc-Andre Lemburg
> >>
> >>
> >> On 04.03.2016 22:31, 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.
> >>>
> >>> So what I will do is try to convince the managers of python-dev to put
> it
> >>> under the CoC and get the CoC mentioned in the footer of
> >> bugs.python.org.
> >>> I will update the devguide to say that the various mailing lists and
> >> issue
> >>> tracker are under the CoC so people are aware, but I won't go as far
> as I
> >>> was originally proposing about covering all public, Python-related
> >>> interactions. Once we move to GitHub we will most likely have a
> >>> CONTRIBUTING file that links to the devguide and that file will mention
> >>> that interactions involving the repo are under the CoC (or some other
> >>> wording that says pull requests fall under the Code of Conduct).
> >>>
> >>> On Fri, 26 Feb 2016 at 11:29 Brett Cannon <brett at python.org> wrote:
> >>>
> >>>> I noticed that the devguide didn't explicitly mention that core
> >> developers
> >>>> were expected to follow the PSF CoC (
> >>>> https://docs.python.org/devguide/coredev.html and
> >>>> https://www.python.org/psf/codeofconduct/, respectively). I have
> opened
> >>>> http://bugs.python.org/issue26446 to make sure it gets documented.
> >>>>
> >>>> Since this is technically a modification of the requirements of
> getting
> >>>> commit privileges I wanted to mention it here before I (or anyone
> else)
> >>>> made the change.
> >>>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> python-committers mailing list
> >>> python-committers at python.org
> >>> https://mail.python.org/mailman/listinfo/python-committers
> >>> Code of Conduct: https://www.python.org/psf/codeofconduct/
> >>>
> >>
> >> --
> >> Marc-Andre Lemburg
> >> eGenix.com
> >>
> >> Professional Python Services directly from the Experts (#1, Mar 04 2016)
> >>>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
> >>>>> Python Database Interfaces ...           http://products.egenix.com/
> >>>>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
> >> ________________________________________________________________________
> >> 2016-02-19: Released eGenix PyRun 2.1.2 ...
> http://egenix.com/go88
> >>
> >> ::: We implement business ideas - efficiently in both time and costs :::
> >>
> >>    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
> >>     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
> >>            Registered at Amtsgericht Duesseldorf: HRB 46611
> >>                http://www.egenix.com/company/contact/
> >>                       http://www.malemburg.com/
> >>
> >>
> >
> >
> >
> > _______________________________________________
> > python-committers mailing list
> > python-committers at python.org
> > https://mail.python.org/mailman/listinfo/python-committers
> > Code of Conduct: https://www.python.org/psf/codeofconduct/
> >
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Experts (#1, Mar 06 2016)
> >>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
> >>> Python Database Interfaces ...           http://products.egenix.com/
> >>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
> ________________________________________________________________________
> 2016-02-19: Released eGenix PyRun 2.1.2 ...       http://egenix.com/go88
>
> ::: We implement business ideas - efficiently in both time and costs :::
>
>    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>            Registered at Amtsgericht Duesseldorf: HRB 46611
>                http://www.egenix.com/company/contact/
>                       http://www.malemburg.com/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160306/31b4e56f/attachment-0001.html>

From brett at python.org  Sun Mar  6 23:54:35 2016
From: brett at python.org (Brett Cannon)
Date: Mon, 07 Mar 2016 04:54:35 +0000
Subject: [python-committers] Welcoming Davin Potts to the Python development
 team
Message-ID: <CAP1=2W4rpvRGUZjTw1MUB+FdTSc9QmZcHd0CvLkSZ1R+9bmLvQ@mail.gmail.com>

I just finished doing what was necessary to make Davin a core dev, so let's
welcome our first new core dev of 2016!

And while I'm thinking about it, Davin, if you will be attending PyCon US
this year in Portland, it would be great if you can make the language
summit so we can all meet you in person! Details can be found in
https://mail.python.org/pipermail/python-committers/2016-March/003784.html.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160307/a1f94426/attachment.html>

From zachary.ware+pydev at gmail.com  Mon Mar  7 09:35:27 2016
From: zachary.ware+pydev at gmail.com (Zachary Ware)
Date: Mon, 7 Mar 2016 08:35:27 -0600
Subject: [python-committers] Welcoming Davin Potts to the Python
 development team
In-Reply-To: <CAP1=2W4rpvRGUZjTw1MUB+FdTSc9QmZcHd0CvLkSZ1R+9bmLvQ@mail.gmail.com>
References: <CAP1=2W4rpvRGUZjTw1MUB+FdTSc9QmZcHd0CvLkSZ1R+9bmLvQ@mail.gmail.com>
Message-ID: <CAKJDb-Ppts9td2B9aAS=4x0phAu+b1Lf+zvSp5GCpvhViQBpDw@mail.gmail.com>

On Mar 6, 2016 10:55 PM, "Brett Cannon" <brett at python.org> wrote:
>
> I just finished doing what was necessary to make Davin a core dev, so
let's welcome our first new core dev of 2016!

Welcome, Davin!

--
Zach
(On a phone)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20160307/51fea0a0/attachment.html>

From ethan at stoneleaf.us  Mon Mar  7 12:35:29 2016
From: ethan at stoneleaf.us (Ethan Furman)
Date: Mon, 07 Mar 2016 09:35:29 -0800
Subject: [python-committers] Welcoming Davin Potts to the Python
 development team
In-Reply-To: <CAP1=2W4rpvRGUZjTw1MUB+FdTSc9QmZcHd0CvLkSZ1R+9bmLvQ@mail.gmail.com>
References: <CAP1=2W4rpvRGUZjTw1MUB+FdTSc9QmZcHd0CvLkSZ1R+9bmLvQ@mail.gmail.com>
Message-ID: <56DDBBE1.50905@stoneleaf.us>

On 03/06/2016 08:54 PM, Brett Cannon wrote:

> I just finished doing what was necessary to make Davin a core dev, so
> let's welcome our first new core dev of 2016!

Congratulations, Davin!  Glad to have you.  :)

--
~Ethan~


From victor.stinner at gmail.com  Mon Mar  7 12:43:46 2016
From: victor.stinner at gmail.com (Victor Stinner)
Date: Mon, 7 Mar 2016 18:43:46 +0100
Subject: [python-committers] Welcoming Davin Potts to the Python
 development team
In-Reply-To: <CAP1=2W4rpvRGUZjTw1MUB+FdTSc9QmZcHd0CvLkSZ1R+9bmLvQ@mail.gmail.com>
References: <CAP1=2W4rpvRGUZjTw1MUB+FdTSc9QmZcHd0CvLkSZ1R+9bmLvQ@mail.gmail.com>
Message-ID: <CAMpsgwZSmkirqVC_K9amjv+qoPY5jmqJp_Dr1sbK=wj555614w@mail.gmail.com>

Nice to see fresh blood, especially for the multiprocessing module :-)

Victor

2016-03-07 5:54 GMT+01:00 Brett Cannon <brett at python.org>:
> I just finished doing what was necessary to make Davin a core dev, so let's
> welcome our first new core dev of 2016!
>
> And while I'm thinking about it, Davin, if you will be attending PyCon US
> this year in Portland, it would be great if you can make the language summit
> so we can all meet you in person! Details can be found in
> https://mail.python.org/pipermail/python-committers/2016-March/003784.html.
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

From ericsnowcurrently at gmail.com  Mon Mar  7 18:54:30 2016
From: ericsnowcurrently at gmail.com (Eric Snow)
Date: Mon, 7 Mar 2016 16:54:30 -0700
Subject: [python-committers] Welcoming Davin Potts to the Python
 development team
In-Reply-To: <CAP1=2W4rpvRGUZjTw1MUB+FdTSc9QmZcHd0CvLkSZ1R+9bmLvQ@mail.gmail.com>
References: <CAP1=2W4rpvRGUZjTw1MUB+FdTSc9QmZcHd0CvLkSZ1R+9bmLvQ@mail.gmail.com>
Message-ID: <CALFfu7BrP3PiffNvREbJd2JPyOqJ6wdW+hDcaSLP4_SUvNEw+w@mail.gmail.com>

On Sun, Mar 6, 2016 at 9:54 PM, Brett Cannon <brett at python.org> wrote:
> I just finished doing what was necessary to make Davin a core dev, so let's
> welcome our first new core dev of 2016!

You've certainly earned this, Davin.  Well done and thanks for sticking with it.

-eric

From python at discontinuity.net  Mon Mar  7 21:29:01 2016
From: python at discontinuity.net (Davin Potts)
Date: Mon, 7 Mar 2016 20:29:01 -0600
Subject: [python-committers] Welcoming Davin Potts to the Python
 development team
In-Reply-To: <CAP1=2W4rpvRGUZjTw1MUB+FdTSc9QmZcHd0CvLkSZ1R+9bmLvQ@mail.gmail.com>
References: <CAP1=2W4rpvRGUZjTw1MUB+FdTSc9QmZcHd0CvLkSZ1R+9bmLvQ@mail.gmail.com>
Message-ID: <20160308022901.GC7385@discontinuity.net>

Thanks everyone for the nice welcome and positive comments!

I'll look forward to hopefully meeting a number of you in person at
PyCon US.


Davin


On Mon, Mar 07, 2016 at 04:54:35AM +0000, Brett Cannon wrote:
> I just finished doing what was necessary to make Davin a core dev, so let's
> welcome our first new core dev of 2016!
> 
> And while I'm thinking about it, Davin, if you will be attending PyCon US
> this year in Portland, it would be great if you can make the language
> summit so we can all meet you in person! Details can be found in
> https://mail.python.org/pipermail/python-committers/2016-March/003784.html.

From berker.peksag at gmail.com  Thu Mar 17 05:44:21 2016
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Thu, 17 Mar 2016 11:44:21 +0200
Subject: [python-committers] The state of our copies of libffi (was:
 Redoing the C API?)
In-Reply-To: <CAKJDb-N86poQ5WOyTTFVogJefeTAb4C_tryYeTp4W7ae25Ov4Q@mail.gmail.com>
References: <CAKJDb-N86poQ5WOyTTFVogJefeTAb4C_tryYeTp4W7ae25Ov4Q@mail.gmail.com>
Message-ID: <CAF4280+NATPd20s7ujtgOA-CdfzNYV6=aCkxF_L2mm_i1Jh1Ww@mail.gmail.com>

On Thu, Mar 3, 2016 at 10:58 PM, Zachary Ware
<zachary.ware+pydev at gmail.com> wrote:
> We actually have four separate copies of libffi:
>
> Modules/_ctypes/libffi: This is a mostly-vanilla copy of libffi-3.1
> (released 19May2014), lightly patched according to
> Modules/_ctypes/libffi.diff.  This one is used for any non-OSX posix
> build that doesn't use `--with-system-ffi`.  doko has done a pretty
> good job keeping this one relatively up to date.

I've opened pull requests to the libffi repository for some of the
changes (I haven't looked at the ones in configure{.ac} yet) in
Modules/_ctypes/libffi.diff:
https://github.com/atgreen/libffi/pulls/berkerpeksag

> Modules/_ctypes/libffi_osx: This is a "lightly patched" copy from
> somewhere before libffi-2.0, probably.  It has barely been touched
> since 2009.  I've been given to understand that it has modifications
> necessary to allow building fat binaries on OSX (Ned or Ronald would
> know better than I), but I don't know if such modifications may have
> made it upstream since pre-2.0.  This one is used for all OSX builds
> that don't use `--with-system-ffi`.

I did a quick check and yes, some of them have already been
upstreamed. For example,
https://github.com/python/cpython/commit/9dc4e927f635a08ea236c9a1e5a32a990480263e#diff-4bc0ccb0eeb98833488f557ce8da5ce5R267

> Modules/_ctypes/libffi_arm_wince: I don't know why we even have this.
> Nobody has touched it since ctypes was merged into cpython in 2006.

I couldn't find any reference to Modules/_ctypes/libffi_arm_wince in
the codebase so I guess we can now file an issue to remove it.

Thanks for the great summary, Zachary :)

--Berker

From doko at ubuntu.com  Thu Mar 24 18:16:49 2016
From: doko at ubuntu.com (Matthias Klose)
Date: Thu, 24 Mar 2016 23:16:49 +0100
Subject: [python-committers] The state of our copies of libffi (was:
 Redoing the C API?)
In-Reply-To: <CAKJDb-N86poQ5WOyTTFVogJefeTAb4C_tryYeTp4W7ae25Ov4Q@mail.gmail.com>
References: <CAKJDb-N86poQ5WOyTTFVogJefeTAb4C_tryYeTp4W7ae25Ov4Q@mail.gmail.com>
Message-ID: <56F46751.6050407@ubuntu.com>

On 03.03.2016 21:58, Zachary Ware wrote:
> On Thu, Mar 3, 2016 at 12:38 PM, Brett Cannon <brett at python.org> wrote:
>> [...] the maintenance issue we have with ctypes (or at least that's
>> my hang-up with it). I think we still have not figured out what code we have
>> patched and so no one has been willing to update to a newer version of
>> libffi. I think Zachary looked into it and got some distance but never far
>> enough to feel comfortable with trying to update things.
>
> Since I've been invoked, I'll try to explain our libffi situation as
> far as I understand it.  This is just a history lesson, I don't really
> have an opinion on what should be done with it.  I will opine that we
> have some seriously old unmaintained code here, and the whole libffi
> situation in cpython is far more complex than is ideal.
>
> We actually have four separate copies of libffi:
>
> Modules/_ctypes/libffi: This is a mostly-vanilla copy of libffi-3.1
> (released 19May2014), lightly patched according to
> Modules/_ctypes/libffi.diff.  This one is used for any non-OSX posix
> build that doesn't use `--with-system-ffi`.  doko has done a pretty
> good job keeping this one relatively up to date.

when trying to update these extra copies, I was always told that upstream was 
wrong/not ready, etc ... So I don't care that much about the copies.  The 
explicit diff was intended to document the explicit and wanted changes.

Now, the last libffi release 3.2.1 is more than a year old, and getting outdated 
for some architectures.  Upstream currently doesn't react, and the libffi copy 
within GCC is ahead with many changes.  My plan was to update libffi with a 3.3 
release when it comes out, but I don't know when this will happen.

Matthias


From ronaldoussoren at mac.com  Mon Mar 28 06:12:48 2016
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon, 28 Mar 2016 12:12:48 +0200
Subject: [python-committers] The state of our copies of libffi (was:
 Redoing the C API?)
In-Reply-To: <CAKJDb-N86poQ5WOyTTFVogJefeTAb4C_tryYeTp4W7ae25Ov4Q@mail.gmail.com>
References: <CAKJDb-N86poQ5WOyTTFVogJefeTAb4C_tryYeTp4W7ae25Ov4Q@mail.gmail.com>
Message-ID: <C8F85B18-13F2-42E5-A298-2ABCBDE17CD9@mac.com>


> On 03 Mar 2016, at 21:58, Zachary Ware <zachary.ware+pydev at gmail.com> wrote:
> 
> Modules/_ctypes/libffi_osx: This is a "lightly patched" copy from
> somewhere before libffi-2.0, probably.  It has barely been touched
> since 2009.  I've been given to understand that it has modifications
> necessary to allow building fat binaries on OSX (Ned or Ronald would
> know better than I), but I don't know if such modifications may have
> made it upstream since pre-2.0.  This one is used for all OSX builds
> that don't use `--with-system-ffi`.

libffi_osx is a copy of the variant of libffi used by PyObjC, which was forked from libffi a long while ago (at the latest around the time OSX started supporting Intel processors, and probably earlier).

I don?t know if upstream libffi is good enough these days, this fork not only contains patches to make it easier to build fat binaries, but also contains a number of bug fixes that weren?t upstream at the time (mostly needed to support Apple?s interpretation of the x86_64 calling conventions in clang).

Ronald