[python-committers] Re: Do people still find this mailing list useful?

[Barry Warsaw]

Agreed about python-committers@.  I’m not on python-ideas so that’s up to them.

-Barry

> On Jul 3, 2023, at 12:36, Eric V. Smith via python-committers 
>  wrote:
> 
> I think it should be retired. I also think the same for python-ideas.
> Eric
> On 7/3/2023 3:15 PM, Brett Cannon wrote:
>> The question has come up as to whether people still find this mailing list 
>> useful enough to keep around. Looking at the archive 
>> (https://mail.python.org/archives/list/python-committers@python.org/latest), 
>> this list seems to be used for two things:
>> • Announcing new releases
>> • Announcing new core developers
>> In both cases the things are announced (at least) at discuss.python.org, and 
>> so are not exclusive to this list.
>> 
>> So, do people find this list useful enough to keep around, or should we 
>> archive it?
>> 
>> ___
>> python-committers mailing list -- python-committers@python.org
>> To unsubscribe send an email to python-committers-le...@python.org
>> https://mail.python.org/mailman3/lists/python-committers.python.org/
>> Message archived at 
>> https://mail.python.org/archives/list/python-committers@python.org/message/WAVEXV3FAK6IFMXTVO7PRNYOY66NBP2F/
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>> 
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-committers@python.org/message/JCYEQRWXWJA6E7DYWB2O5P5CCY2CYLO4/
> Code of Conduct: https://www.python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/O353A6TWPWLROEN3PPWAQL3YJVV46ASP/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Requiring PEPs to add/remove modules in the stdlib (and dropping the concept of "provisional")

[Barry Warsaw]

PEP 2 will have to be “un-superseded”, and presumably the devguide (which PEP 2 
points to) will also need to be updated.

I think it’s probably fine to drop the idea of provisional APIs.  Aside from 
the limit benefit of evolution within the stdlib, code still gets written 
against provisional APIs and people still complain when they break in 
non-backward compatible ways, so we might as well avoid the whole thing.

-Barry

> On Mar 22, 2022, at 16:26, Brett Cannon  wrote:
> 
> I had kicked off a discussion a while back at 
> https://discuss.python.org/t/how-do-we-want-to-manage-additions-removals-to-the-stdlib/10681
>  about how to manage the stdlib (this has nothing to with what the stdlib is 
> and thus what belongs in it). It finally bubbled up in the SC agenda and 
> after discussing things we have three proposals:
>   • Update PEP 2 to say a PEP is necessary to add a module to the stdlib
>   • Update PEP 4 to say that a PEP is necessary to deprecate/remove a 
> module
>   • Mark PEP 411 as obsolete and thus dropping the idea of provisional 
> modules
> The PEP requirements are because the stdlib is important to manage 
> appropriately and since it's a shared resource it should be something we all 
> discuss. The PEP process seems like a good mechanism for both keeping what we 
> bring in under control while also making sure people don't break people's 
> code needlessly with removals.
> 
> The dropping of the concept of provisional modules is from simply having not 
> seen any true benefit that could have been had in other ways (e.g. typing, 
> asyncio, importlib.metadata). In pretty much all cases the APIs could have 
> evolved publicly first and then been brought into the stdlib once stable (if 
> at all), so the concept of "provisional" just doesn't seem worth keeping 
> around.
> 
> We wanted to see if there was consensus around any of these ideas, hence this 
> email. 
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-committers@python.org/message/5EUZLT5PNA4HT42NGB5WVN5YWW5ASTT5/
> Code of Conduct: https://www.python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/SKD3XJQF44F2BB6BCCACCPDZDRWTCSWC/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: 2022 Python Steering Council Election Results

[Barry Warsaw]

My deepest thanks to everyone who voted for me, and my heartfelt 
congratulations and support to all the members of the 2022 Steering Council.  
I’ve been honored to serve for three years and I’m looking forward to joining 
Carol in retirement from the SC this year.   I won’t be retiring from Python.  
Quite the contrary!  I’m looking forward to spending the time to more directly 
contribute to my areas of interest.   The 2022 SC is in great hands, and I have 
full confidence that this year’s members will continue to successfully steward 
Python with their compassion, expertise, and commitment.  Congratulations to 
all!

-Barry

> On Dec 16, 2021, at 04:08, Ee Durbin  wrote:
> 
> Voting closed at 2021-12-16 12:00 UTC as specified in PEP 8103.
> 
> Of 85 eligible voters, 67 cast ballots.
> 
> The top five vote-getters are:
> 
> * Pablo Galindo Salgado
> * Petr Viktorin
> * Thomas Wouters
> * Gregory P. Smith
> * Brett Cannon
> 
> No conflict of interest as defined in PEP 13 were observed.
> 
> Full results have been published to PEP 8103.
> 
> Eligible voters have received result notification emails from helios, and may 
> return to the system to audit/verify the results.
> 
> Thanks to all participants! It was an honor serving as the administrator for 
> the governance votes.
> 
> -Ee Durbin
> Director of Infrastructure
> Python Software Foundation
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-committers@python.org/message/K3PSH4JX53WOEP55NUBGYPRQD6HH4KMK/
> Code of Conduct: https://www.python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/POJZZVHYHPE5G6V723C5NTSKLRHYFY2M/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Deprecation policy reminder

[Barry Warsaw]

PEP 387 says:

The steering council may grant exceptions to this policy. In particular, 
they may shorten the
required deprecation period for a feature. Exceptions are only granted for 
extreme situations
such as dangerously broken or insecure features or features no one could 
reasonably be depending
on (e.g., support for completely obsolete platforms).

I’m not sure I agree that these are the only reasons to grant an exception, but 
I guess we’ll have to discuss that.  Please do formally ask the SC for an 
exception.

Cheers,
-Barry

> On Sep 2, 2021, at 08:02, Guido van Rossum  wrote:
> 
> Are there any exceptions? In the discussion about PyCode_New we've come to 
> the conclusion that keeping it and PyCode_NewWithPosArgs around is going to 
> be impossible to support, and we've found the few users of that API (Cython) 
> supportive of changing it incompatibly.
> 
> On Thu, Sep 2, 2021 at 3:56 AM Łukasz Langa  wrote:
> Hi there,
> I noticed some deprecation activity this week. Nice! I'd just like to remind 
> everyone that we have a policy for that described in PEP 387  It's a very 
> short PEP so I recommend you read it in its entirety. The important piece I 
> want to highlight is that we cannot deprecate a feature in one release and 
> remove it in the next one. We need at least two releases with the warning.
> 
> Relevant quotes:
> 
>> Python's yearly release process (PEP 602) means that the deprecation period 
>> must last at least two years.
> 
> and:
> 
>> Wait for the warning to appear in at least two minor Python versions of the 
>> same major version, or one minor version in an older major version (e.g. for 
>> a warning in Python 3.10, you either wait until at least Python 3.12 or 
>> Python 4.0 to make the change). It's fine to wait more than two releases.
> 
> Since this PEP is easy to miss, I linked it to the docs of DeprecationWarning 
> in GH-28123.
> 
> Cheers,
> Ł
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-committers@python.org/message/WZQIL3GLGO7NYC4XHBVFBHUNUJV6NWLE/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
> 
> 
> --
> --Guido van Rossum (python.org/~guido)
> Pronouns: he/him (why is my pronoun here?)
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-committers@python.org/message/BS2L3MDXK232Z523NTIM55ANSDRHR7VJ/
> Code of Conduct: https://www.python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/LCQCL2HXQ6YMV7I4K6EFKXJKUDSB3OLN/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] PEP 657 Accepted - Include Fine Grained Error Locations in Tracebacks

[Barry Warsaw]

I’m happy to announce that PEP 657 (Include Fine Grained Error Locations in 
Tracebacks) has been unanimously accepted for Python 3.11 by the Python 
Steering Council.

Congratulations Pablo, Batuhan, and Ammar!

Cheers,
-Barry (on behalf of the Steering Council)



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/3WDJNOW2SPTPCKUGLG2ANBWZZEYTT6F6/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: status of smtpd

[Barry Warsaw]

On Jun 23, 2021, at 09:46, Marc-Andre Lemburg  wrote:
> 
> Since it's rather likely that we'll always find someone who still
> uses a module, I think we should find a better strategy on how to
> deal with such removals, e.g. create a separate attic repo where
> participation is easier than for CPython, publish the modules
> in this repo under a python-attic package, and move all deprecated
> code there.

That’s basically what PEP 594 suggests, and I think that’s a good approach 
while we’re working out the details and process for removing dead batteries.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/V7ORHP54ZXYKEALJ2BYIO4NNUAO7CQA3/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Pattern Matching

[Barry Warsaw]

Stay tuned, the Steering Council will be sending out official word on the 
pattern matching PEPs soon.

-Barry

> On Feb 5, 2021, at 07:33, Ethan Furman  wrote:
> 
> Greetings, all!
> 
> I was wondering if there was any movement on PEPs 634-636?
> 
> As Guido mentioned on another PEP, time is running out to get this into 3.10.
> 
> --
> ~Ethan~
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-committers@python.org/message/NNQRYQ25E2FD6WEUH5UVYN3TU3JCW6U7/
> Code of Conduct: https://www.python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/MUU3KMIBJIPBTETQVYPZXZ5377OXIHS6/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: 2021 Python Steering Council Election Results

[Barry Warsaw]

Thank you so much for once again running a smooth election!  Thanks to everyone 
who ran, voted, discussed, and participated in these elections.  It shows how 
healthy and vibrant our community and project is.

Because of the holidays, the SC does not plan on meeting again before the new 
year.  Have a safe and healthy holiday season, and look forward to more SC 
activity in January.

Cheers,
-Barry

> On Dec 16, 2020, at 05:23, Ee W. Durbin III  wrote:
> 
> Voting closed at 2020-12-16 12:00 UTC as specified in PEP 8102.
> 
> Of 91 eligible voters, 74 cast ballots.
> 
> The top five vote-getters are:
> 
> Barry Warsaw
> Brett Cannon
> Carol Willing
> Pablo Galindo Salgado
> Thomas Wouters
> 
> No conflict of interest as defined in PEP 13 were observed.
> 
> Full results have been published to PEP 8102.
> 
> Eligible voters have received result notification emails from helios, and may 
> return to
> the system to audit/verify the results.
> 
> Thanks to all participants! It was an honor serving as the administrator for 
> the
> governance votes.
> 
> -Ee W. Durbin III
> Director of Infrastructure
> Python Software Foundation
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-committers@python.org/message/AURPGHP3HJVTEWQ6NG2IHDNUKHANQOQK/
> Code of Conduct: https://www.python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/SOXSULUN4HDLHE3CSSYMFEVES7JGRXTJ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Is adding an email package "defect" a new feature?

[Barry Warsaw]

True/False in 2.2.1 still hurts!

Thanks all for confirming my intuition.  I will not back port this change.

-Barry

> On Oct 26, 2020, at 12:09, Brett Cannon  wrote:
> 
> Our lesson from our "innocuous" addition of booleans makes me leery of 
> anything that tweaks the API such that it isn't compatible in the same 
> feature release.
> 
> On Fri, Oct 23, 2020 at 3:16 PM Barry Warsaw  wrote:
> Over in:
> 
> * https://bugs.python.org/issue30681
> * https://github.com/python/cpython/pull/22090
> 
> Georges Toth has a PR that fixes some problems with 
> email.utils.parsedate_to_datetime().  I like the PR, and am ready to approve 
> it for 3.10.  Georges would like it back ported, which I would be normally be 
> okay with *except* that it adds a new “defect” class.
> 
> Defects are a way for the email parser to indicate problems with the incoming 
> data without throwing an exception.  This is an important constraint because 
> we never want clients of the parser to have to deal with exceptions.  So if 
> e.g. a message had some formatting or syntactic problem, but was otherwise 
> parseable, you’d still get an email object back from the parser, but attached 
> to it would be a list of defects that were encountered.  Clients then could 
> choose to ignore or handle these defects depending on the use case.  Defects 
> are implemented as classes that get instantiated with some useful information 
> and appended to an email message’s “defects” list.
> 
> PR #22090 adds an InvalidDateDefect for cases where parsing the Date: header 
> encounters problems, such as an invalid hour value.  I think this is the 
> right thing to do to fix the reported bug, but I am on the fence as to 
> whether this new defect class should prevent back porting.  OT1H, it can’t 
> break existing code, but OTOH this defect will only be found when run in 
> Python bug fix releases with the new defect detection.
> 
> What do you think?  And especially, what does Łukasz think, since he’s the RM 
> for back port candidates 3.8 and 3.9?
> 
> Cheers,
> -Barry
> 
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-committers@python.org/message/RXUMNWKIILG2WKUNL6DAYAQ42VO7AU6D/
> Code of Conduct: https://www.python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/2S4R3ABRS23QDAL27F7FM5ROGVKHGB76/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Is adding an email package "defect" a new feature?

[Barry Warsaw]

Over in:

* https://bugs.python.org/issue30681
* https://github.com/python/cpython/pull/22090

Georges Toth has a PR that fixes some problems with 
email.utils.parsedate_to_datetime().  I like the PR, and am ready to approve it 
for 3.10.  Georges would like it back ported, which I would be normally be okay 
with *except* that it adds a new “defect” class.

Defects are a way for the email parser to indicate problems with the incoming 
data without throwing an exception.  This is an important constraint because we 
never want clients of the parser to have to deal with exceptions.  So if e.g. a 
message had some formatting or syntactic problem, but was otherwise parseable, 
you’d still get an email object back from the parser, but attached to it would 
be a list of defects that were encountered.  Clients then could choose to 
ignore or handle these defects depending on the use case.  Defects are 
implemented as classes that get instantiated with some useful information and 
appended to an email message’s “defects” list.

PR #22090 adds an InvalidDateDefect for cases where parsing the Date: header 
encounters problems, such as an invalid hour value.  I think this is the right 
thing to do to fix the reported bug, but I am on the fence as to whether this 
new defect class should prevent back porting.  OT1H, it can’t break existing 
code, but OTOH this defect will only be found when run in Python bug fix 
releases with the new defect detection.

What do you think?  And especially, what does Łukasz think, since he’s the RM 
for back port candidates 3.8 and 3.9?

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/RXUMNWKIILG2WKUNL6DAYAQ42VO7AU6D/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Resignation from Stefan Krah

[Barry Warsaw]

This is true, but I think in the hopefully nonexistent future we should notify 
-owners on all affected mailing lists.

Cheers,
-Barry

> On Oct 9, 2020, at 11:49, Brett Cannon  wrote:
> 
> 
> 
> On Thu, Oct 8, 2020 at 5:21 PM Barry Warsaw  wrote:
> On Oct 8, 2020, at 14:34, Ethan Furman  wrote:
> >
> > Sure, but I don't know who they are.  Besides, if the SC did not do the 
> > banning/moderating then they should find out what happened.
> >
> > If the SC did do the banning/moderating then I'd really like to know why, 
> > both so that I can make sure and not do that thing myself, and so that I 
> > can caution others who are straying down that path.  That's handy 
> > information to have, especially when you're a mailing list moderator.
> 
> Thank you, Ethan.
> 
> The Steering Council did indeed ban Stefan, as Thomas’ followup email just 
> now sent elaborates on.  This was the first time that the SC has had to take 
> such actions, and we neglected to notify the mailing list owners of the 
> affected lists.
> 
> To be absolutely clear, I am an admin for -committers and -ideas, Barry is 
> for -dev. So an admin on all affected lists was aware of what was going on, 
> just not all of them for privacy reasons while we attempted to work things 
> out.
> 
> -Brett
> 
> 
> 
> 
>   We apologize for that.  We all hope that we never have to do this again, 
> but we will be sure to keep list owners in the loop should it ever be 
> necessary in the future.
> 
> Cheers,
> -Barry, on behalf of the Python Steering Council
> 
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-committers@python.org/message/YTC3LLSTIRSJ6DW4WRWVWALPIZHHPQS4/
> Code of Conduct: https://www.python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/47Q3FP5B2EGS4ITJEIQ4VGFT7XKSYTUU/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Resignation from Stefan Krah

[Barry Warsaw]

On Oct 8, 2020, at 14:34, Ethan Furman  wrote:
> 
> Sure, but I don't know who they are.  Besides, if the SC did not do the 
> banning/moderating then they should find out what happened.
> 
> If the SC did do the banning/moderating then I'd really like to know why, 
> both so that I can make sure and not do that thing myself, and so that I can 
> caution others who are straying down that path.  That's handy information to 
> have, especially when you're a mailing list moderator.

Thank you, Ethan.

The Steering Council did indeed ban Stefan, as Thomas’ followup email just now 
sent elaborates on.  This was the first time that the SC has had to take such 
actions, and we neglected to notify the mailing list owners of the affected 
lists.  We apologize for that.  We all hope that we never have to do this 
again, but we will be sure to keep list owners in the loop should it ever be 
necessary in the future.

Cheers,
-Barry, on behalf of the Python Steering Council



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/YTC3LLSTIRSJ6DW4WRWVWALPIZHHPQS4/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Thank you Larry Hastings!

[Barry Warsaw]

They say being a Python Release Manager is a thankless job, so the Python 
Secret Underground (PSU), which emphatically does not exist, hereby officially 
doesn’t thank Larry for his years of diligent service as the Python 3.4 and 3.5 
release manager.

On the other hand, the Python Steering Council, Python Software Foundation, and 
worldwide Python community, all of which emphatically *do* exist, all extend 
our heartfelt thanks to Larry for his excellent stewardship of Python 3.4 and 
3.5!

Python 3.4 and 3.5 were both pivotal releases.  While the features of these two 
releases are too numerous to mention here, they introduced such staples as:

* asyncio
* enum
* pathlib
* async and await keywords
* matrix multiplication operators
* typing and zipapp modules

and so much more.  For details, see:

* https://docs.python.org/3/whatsnew/3.4.html
* https://docs.python.org/3/whatsnew/3.5.html

Larry’s first official release of 3.4.0a1 was on 2013-08-03 and his last Python 
3.5.10 release was 2020-09-05.  That’s 7 years of exemplary release managing!

Larry, from all of us, and from me personally, thank you so much for your 
invaluable contributions to Python.  Enjoy your retirement!

Cheers,
-Barry (on behalf of the PSC and PSF)



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/QGIHFU64TBYT56K6M5A5LYTYTSVFKHWQ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Notification of a three-month ban from Python core development

[Barry Warsaw]

I’ve put this topic on the SC's agenda for our Monday meeting.  I can 
appreciate that core developers would like more detail on the behavior that 
initiated the ban.  I’ve also added an item to consider whether and how to 
create a private space for further discussion among core developers (and PSF 
staff) only.

As a general plea, please accept that this ban was not undertaken lightly, 
capriciously, or gladly.  There are lots of checks and balances, and more 
internal discussion that any of us (all volunteers) would ever have liked.  I 
can’t speak for the Conduct WG, but every reported violation was thoroughly 
investigated, and a report was issued to the Board and the SC, along with 
recommendations.  So there were a lot of people involved and consensus was 
reached.  By constitution, the SC has ultimate authority to issue bans, and 
ultimately both the PSF Board and Steering Council are elected positions.  As 
with any democracy, we serve you all, and elections are the way to signal your 
agreement or displeasure with the results.

On a personal note, I want to express my deep respect and gratitude to the 
members of the WG, the Board, and my fellow SC members for the compassion, 
diligence, and sense of responsibility in dealing with these matters.  Every 
single one of them only wants what’s best for the Python community, and we are 
all trying to figure out how to do this the right way, despite the personal 
toll it takes.  None of us wants to do this - we’d all rather be coding.  We’ve 
never had to issue a ban before, so this is uncharted territory.  Any missteps 
are unintentional.  Please, help us navigate this with your understanding, 
constructive, and compassionate assistance.  Let’s use these incidents to 
illustrate the best in the Python community, and why we love being part of it.

Cheers,
-Barry


> On Jul 23, 2020, at 01:17, Christian Heimes  wrote:
> 
> On 23/07/2020 09.52, Matthias Klose wrote:
>> Apparently there was agreement to hide this kind of information, and that's
>> worse than the original behavior that was acted on. Who will be next? For 
>> what
>> reason?  I am not questioning the decision, at least we voted for our 
>> delegates,
>> so I have to respect that decision even if I would disagree.  If you don't 
>> want
>> to communicate in public, then email committers separately, or create a 
>> private
>> ML for committers.
> 
> python-committers has a public mail archive. Anybody is able to follow
> python-committers discussions via the public mailing list interface. I
> understand why the SC is avoiding name calling in public.
> 
> Barry, multiple core devs have raised a concern now. There is at least
> one more CoC violation under investigation, which is going to cause even
> more concern. Would it make sense to disclose more details on the matter
> in the private area on discuss.python.org? We have an internal forum
> that is only accessible by core devs and PSF staff. That way the SC can
> disclose more information in a  private post without public name calling
> and public shaming.
> 
> Christian



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/CH2ZEZW4PWPMFIKKLZDLP4DO32JA5MWF/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Notification of a three-month ban from Python core development

[Barry Warsaw]

Hi Berker,

If you have specific concerns, you are always welcome to reach out to the SC or 
Conduct WG.  For now I’ll just say that we are continuing to work through 
conduct issues.

Cheers,
-Barry

> On Jul 22, 2020, at 16:57, Berker Peksağ  wrote:
> 
> On Wed, Jul 22, 2020 at 10:31 PM Python Steering Council
>  wrote:
>> 
>> The following message was sent to a core developer. This message was 
>> thoughtfully and respectfully sent by the Steering Council as a serious 
>> reminder that the privilege to serve as a core developer comes with the 
>> responsibility to act thoughtfully.
> 
> I respect the decision to handle this mess without pointing fingers.
> However, I must say I was expecting a decision about two people after
> I saw the message at
> https://mail.python.org/archives/list/python-committers@python.org/message/M56XWU2A6JYFGTMRFIGYHFFSPDWNSKYA/
> Should I expect a similar notification in the near future or should I
> directly reach out to the SC or conduct-wg?
> 
> --Berker
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-committers@python.org/message/NBMP4JSA2QWPJHZWVALQN2IJ6GBIR7PL/
> Code of Conduct: https://www.python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/KA7ZZPT2ESH5JLFZQZLMG6OQKVAIH2WG/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Notification of a three-month ban from Python core development

[Barry Warsaw]

It’s a really difficult call.  Please accept that everyone on the PSF Board, 
SC, and WG are really trying to do their best.  I know you do Nathaniel, so 
this is not meant to call you out personally, it’s just a general plea for 
understanding.  This has been really difficult for everyone involved, often in 
ways that are not visible publicly.

-Barry

> On Jul 22, 2020, at 13:54, Nathaniel Smith  wrote:
> 
> Given that this is a response to behavior in public mailing list
> posts, the lack of specificity feels off to me. Whatever this person
> did is already public. What's being hidden isn't their behavior; it's
> the conduct-wg/steering-council's reasoning for banning them. The
> point of having a CoC is that everyone is on the same page and can be
> confident about what behavior is unacceptable and acceptable, but it's
> hard for them or others to learn from this, if you don't tell them or
> us why they were banned...
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-committers@python.org/message/22464N65TVY4UVECNZ3LL3YUD72S5C3C/
> Code of Conduct: https://www.python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/DROOMERXTNHJ4K7I6A34HV2TEM22M7KI/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Notification of a three-month ban from Python core development

[Barry Warsaw]

Hello Ivan,

As mentioned, this was sent to python-committers, i.e. all core developers.  
The Steering Council, Conduct WG, and PSF Board have been working incredibly 
diligently on this incident for quite some time.  Remember that almost all of 
us are volunteers too!

We have tried to balance transparency and communication with respecting the 
privacy and reputation of the individuals involved, including the banned member 
and members who were reprimanded but not banned.  We tried to balance the 
severity of the corrective action with the hope that these members will reflect 
on the reasons for the warnings or ban, and when they next engage with the 
community, how they can more closely follow the spirit and letter of the code 
of conduct.

Making this community a place where people feel included, safe, and welcome is 
exactly why the Steering Council has taken the actions it has taken.  If you 
are still feeling scared, I urge you to reach out to the Steering Council to 
express your concerns and feelings.

Cheers,
-Barry

> On Jul 22, 2020, at 12:40, Ivan Levkivskyi  wrote:
> 
> Hi,
> 
> I don't remember participating in any of the recent discussions on the 
> mentioned lists. Why is this sent to me? Can you mention any particular posts?
> The scary atmosphere here becomes unbearable. I wasn't very active lately 
> anyway, and I think I will stop contributing indefinitely.
> 
> Best regards,
> Ivan
> 
> 
> On Wed, 22 Jul 2020 at 20:30, Python Steering Council 
>  wrote:
> The following message was sent to a core developer. This message was 
> thoughtfully and respectfully sent by the Steering Council as a serious 
> reminder that the privilege to serve as a core developer comes with the 
> responsibility to act thoughtfully.
> 
> ---
> 
> Based on Code of Conduct violations in your recent mailing list posts, and 
> under the recommendation of the Code of Conduct Working Group, the Python 
> Steering Council has voted to issue a three-month corrective action to you 
> for Core Python development.
> This corrective action bans you from all Core Development privileges 
> including commit rights, issue tracker privileges, and participation in all 
> core development communication spaces including mailing lists, Discourse, and 
> Zulip channels. This corrective action will be in effect for three months. At 
> the end of the three month period, these privileges will be automatically 
> reinstated.
> 
> The Python Code of Conduct workgroup reviewed the conduct reports and 
> recommended that corrective action was necessary for the violations. The 
> Python Steering Council finds these violations to be serious breaches of 
> civility and expected core development conduct.
> 
> Please consider this corrective action as a serious reminder that Python core 
> development is a privilege. This privilege to serve as a core developer comes 
> with the responsibility to act thoughtfully and reflect on how hostile 
> communications are harmful to other members of the community. We trust that 
> you will respect the temporary loss of privileges and the seriousness of this 
> action.
> 
> Respectfully,
> Python Steering Council
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-committers@python.org/message/2HC5XPURMQL6VRCXPMLQUL7OXBGU6OMS/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-committers@python.org/message/CLS5E634FCMB6W5H5JBLHZNSFRKKZGJG/
> Code of Conduct: https://www.python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/TQMPBGIHRHUVN7U4G7QX2ZK45XMHHYOI/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Please avoid non-bugfix changes during the beta phase

[Barry Warsaw]

It’s true that as releases get closer to final, more people will start 
exercising them.  However, you really don’t have to wait.  I maintain 
“official” Linux (Ubuntu) Docker images that contain all the latest releases 
(including alphas and betas), and the git head of the development branch at the 
time of the image builds.

https://gitlab.com/python-devs/ci-images/-/tree/master

I keep these up-to-date on every new maintenance release, alpha, beta, rc, and 
final, for Python 2.7, and 3.4 through 3.10.  I use this image in my own open 
source code’s CI, and you can too!  Unfortunately, we can’t do the same with 
Windows, but I’ve cracked the nut to get pretty good coverage for Windows 
releases too.  Here for example is flufl.lock’s .gitlab-ci.yml file:

https://gitlab.com/warsaw/flufl.lock/-/blob/master/.gitlab-ci.yml

I need to extend that to 3.9 pre-releases, via python.org downloads rather than 
nuget.

So, it’s entirely possible to test your stuff against pre-release versions, and 
I highly encourage it.

That said, I also think that the general rule of only bug fix changes post beta 
1 is the right policy.  For other changes, or anything that you think straddles 
the line between bug fix and non-bug fix, ask the Release Manager.  The RM’s 
primary role at this time is to ensure the stability of the final release.  
Their judgement is critical to the success of the final release, so ask!  CC 
the RM on the PR and request their approval and comment.

I’ll also say that I personally give the RM a lot of latitude and authority to 
unilaterally revert any change they are not comfortable with.  If the change 
author and RM cannot agree on whether a post-beta change is appropriate, you 
can escalate to the Steering Council.

Cheers,
-Barry

> On Jul 6, 2020, at 19:21, Raymond Hettinger  
> wrote:
> 
> My two cents: I think this should be a little more liberal. At beta 1, freeze 
> the addition of new features but continue to tweak the implementation with 
> code clean-ups, additional tests, algorithmic improvements, and better docs.  
> For many of the devs (and users), the first time we get to exercise and 
> interact with some of the new features is during the beta — that is our 
> chance to improve and stabilize it before it goes out the door.  If a new API 
> proves awkward in some way, the time to find out and improve it is during the 
> beta.  Ideally, we would like both the API and implementation to mature a bit 
> before the release (first draft != final copy).  A release candidate is 
> different — that is close to an across-the-board freeze.  Once the release 
> happens, bug fixes and documentation tweaks will continue to be checked in 
> for the next micro-release.
> 
> Side note: One problem we have is that so few people actually exercise the 
> beta and give useful feedback.  To me, the chief value of a public beta is 
> that people get to try it out before everything is set it stone.  And reason 
> for having multiple betas is so that we can iterate.  If not, perhaps we 
> should just have a single beta, frozen except for bugfixes.
> 
> 
> Raymond
> 
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-committers@python.org/message/EIXKURQS4HXHLMJM4LRIXODMJPON5SFR/
> Code of Conduct: https://www.python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/HRQWCVDHI4IPHO6UXJ4QT7YHQWU2X77N/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Please welcome our next Release Manager, Pablo!

[Barry Warsaw]

In light of the release of Python 3.9b1, let’s take a moment to celebrate all 
the great work that our Python 3.8 and 3.9 release manager Łukasz has done.  
The role of Python Release Manager is hugely important to each successful 
release, and it can be a lot of work, often unseen and thankless to shepherd a 
new Python version through its first alpha release to its last security 
release.  With all of your immeasurable help, the Release Manager ensures 
solid, feature-full releases that the entire Python community eagerly awaits.

Łukasz carries on the fine tradition of all of our past release managers, and 
now that his second release has entered beta phase, I’m very happy to announce 
our next Release Manager, for Python 3.10 and 3.11: Pablo Galindo Salgado!

Since becoming a core developer in 2018, Pablo has contributed significantly to 
Python.  With the change to an annual release cycle (PEP 602, authored by 
Łukasz), the time commitment for release managers has been reduced as well, and 
we will continue to look for ways to make the selection process for release 
managers more transparent and accessible.  I know that in addition to admirably 
managing the releases for 3.10 and 3.11, Pablo will also help to continually 
improve the process of selecting and serving as release manager.

Please join me in welcoming Pablo in his new role!

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/44TLJO5YX6XYM4ICWSHMBMCKPBBQQP5S/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Language Summit

[Barry Warsaw]

You should definitely finish your PEP!

-Barry

> On Apr 15, 2020, at 16:40, Eric V. Smith  wrote:
> 
> 
>> I am reliant on summaries and anyone attending posting details.  Everyone 
>> please share your slides if you have any that are meaningful without a talk 
>> to go with them. At least to this committers list or discourse forum.  I 
>> expect I feel just like all of our non-travel-enabled colleagues who feel 
>> left out on a recurring basis.  =)
>> 
> Hi, Greg.
> 
> Here are the slides from my talk: 
> https://github.com/ericvsmith/f-strings-by-default/raw/master/F-strings%20everywhere!.pdf
> 
> I can't decide if it's worth continuing my work on a PEP. I need to re-read 
> and consider the various questions and suggestions from today. Thanks, 
> everyone, for your input.
> 
> Eric
> 
> 
> 
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-committers@python.org/message/CIT3S7JAZJ4OZ3YD6LO77HZRMPQBRBVU/
> Code of Conduct: https://www.python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/HPMDSNO427N2SR3FVGY6LVBQEXKGHAYU/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: A urlparse regression in minor version

[Barry Warsaw]

On Feb 16, 2020, at 10:20, Ned Deily  wrote:

> Rather than continuing this change in 3.9 introducing yet another, even more 
> unexpected behavior, I think we should first try to address what appears to 
> me to be the (a?) root cause issue: urlparse's API is not suited for parsing 
> both strictly RFC-compliant URLs (which are clearly not well-understood) 
> *and* today's schemeless URLs as have evolved over the years to become the 
> most commonly encountered form of URL.  Users want and need both.  The merged 
> change makes the previous situation worse, IMHO.

ISTM that the tension between doing the right thing and keeping backward 
compatibility should be explored through the addition of a new function with 
the intended semantics, or at least a new parameter (keyword-only?) that 
controls the behavior.  I don’t like the latter as much, but if you really want 
to keep a single functional interface, that would be a way to do it.

I don’t agree that it’s obviously okay to introduce a backward incompatible 
default behavior in 3.9.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/3I5Q2PQ4BFJSUFTUIO7ELNE6HIW3QVIK/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: A urlparse regression in minor version

[Barry Warsaw]

On Feb 11, 2020, at 05:26, Łukasz Langa  wrote:
> 
> I'll let others voice their opinions but my intuition for 3.8.x is to leave 
> your patch be. True, it should not have been backported but it was, and it 
> was already released as part of 3.8.1 and now 3.8.2rc1.

I don’t think you should worry about 3.8.2rc1.  That’s not a release version so 
shouldn’t impact the decision IMHO.

Whether 3.8.1 is important enough not to revert this change is an RM decision.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/A3OWT4ZPL3V233DXNULCF4AZE25QMSZ5/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Possible bug in voting system ? (was: Re: Reminder to vote for the 2020 Steering Council)

[Barry Warsaw]

On Dec 11, 2019, at 02:28, M.-A. Lemburg  wrote:

> I'm sorry, but I had not expected to be delisted and thus did not
> check the voters list.

I didn’t expect to be delisted either but I’m sufficiently paranoid to have 
double checked that I was still on the voter list.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/E2BWZFOGAWTCWJFPLQ6CAQVTER36PX5O/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] PEP 1: Relaxing the requirements for being a PEP sponsor

[Barry Warsaw]

PEP 1 currently says that if a PEP is authored by a non-core developer, the 
author must find a core developer to sponsor their PEP.  At today’s Steering 
Council meeting, we proposed to relax this requirement to allow non-core 
developers to sponsor a PEP with the approval of the Council.  There is no 
change if the PEP author is a core developer; in that case the PEP still does 
not require a sponsor.

Here is the PR with the proposed language change:

https://github.com/python/peps/pull/1170

Feel free to weigh in on the PR.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/FUVBANJTHMUC4X7N2H6ELUHAHOXDONPZ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Welcome Abhilash Raj to the Python core team!

[Barry Warsaw]

On Aug 6, 2019, at 15:27, Paul Moore  wrote:
> 
> (BTW, I didn't see an announcement of the closing of the vote and the
> final result on Discourse - did it get announced there?)

The vote closed automatically after one week, as per PEP 13.  However, I was 
traveling and haven’t had a chance to follow up to that Discourse thread yet.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/RQQMXS2F3MIZCZ26S2HDORKSMXLUQC6N/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Welcome Abhilash Raj to the Python core team!

[Barry Warsaw]

Congratulations and welcome Abhilash!  Thanks Brett for setting him up, and 
thanks everyone who voted.

-Barry

> On Aug 6, 2019, at 14:19, Brett Cannon  wrote:
> 
> Assuming I didn't mess anything up, Abhilash is now set up!
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-committers@python.org/message/7DCE4DR7FNLAWXQSNEBRSGOMFOVGKK3F/
> Code of Conduct: https://www.python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/QM25LIFW43T6ODHEK5BK75NMCHAGQO3G/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: [RELEASE] Python 3.8.0b3 is now available for testing

[Barry Warsaw]

I have updated the official docker images with 3.8b3:

https://gitlab.com/python-devs/ci-images/tree/master

-Barry

> On Jul 29, 2019, at 14:48, Łukasz Langa  wrote:
> 
> Signed PGP part
> This time without delays, I present you Python 3.8.0b3:
> 
> https://www.python.org/downloads/release/python-380b3/



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/2T7AXF4D7KIQML5QDNBX7I5KQWJOPKE3/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Promote Abhilash Raj to core developer

[Barry Warsaw]

I have just posted a poll to Discourse proposing to promote Abhilash Raj to 
core developer status.

https://discuss.python.org/t/vote-to-promote-abhilash-raj-as-core-developer/2041

The topic includes his background, my endorsement, and a list of contributions 
to CPython.  I hope that you will vote to confirm him as a core developer.  He 
will be an excellent addition to our team.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/J7U5PAGTQ7E2RJMNL6RTE4EISQ6QQBTF/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: [RELEASE] Python 3.8.0b2 is now available for testing

[Barry Warsaw]

I’ve updated the official images to include 3.8.0b2:

https://gitlab.com/python-devs/ci-images/tree/master

Cheers,
-Barry

> On Jul 4, 2019, at 15:05, Łukasz Langa  wrote:
> 
> Signed PGP part
> After a few days of delay, but somewhat cutely timed with the US Independence 
> Day, I present you Python 3.8.0b2:
> 
> https://www.python.org/downloads/release/python-380b2/ 
> 
> 
> This release is the second of four planned beta release previews. Beta 
> release previews are intended to give the wider community the opportunity to 
> test new features and bug fixes and to prepare their projects to support the 
> new feature release. The next pre-release of Python 3.8 will be 3.8.0b3, 
> currently scheduled for 2019-07-29.
> 
> Call to action
> 
> We strongly encourage maintainers of third-party Python projects to test with 
> 3.8 during the beta phase and report issues found to the Python bug tracker 
>  as soon as possible. While the release is planned 
> to be feature complete entering the beta phase, it is possible that features 
> may be modified or, in rare cases, deleted up until the start of the release 
> candidate phase (2019-09-30). Our goal is have no ABI changes after beta 3 
> and no code changes after 3.8.0rc1, the release candidate. To achieve that, 
> it will be extremely important to get as much exposure for 3.8 as possible 
> during the beta phase.
> 
> Please keep in mind that this is a preview release and its use is not 
> recommended for production environments.
> 
> No more non-bugfixes allowed on the “3.8” branch
> 
> The time has come, team. Please help make Python 3.8 as stable as possible 
> and keep all features not currently landed for Python 3.9. Don’t fret, it’ll 
> come faster than you think.
> 
> 
> - Ł
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/JRX5LSDAUVU6JELT26WACVNGVDSIGZNK/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] PEP 581 (Using GitHub issues for CPython) is accepted

[Barry Warsaw]

As the BDFL-Delegate for PEP 581, and with the unanimous backing of the rest of 
the Steering Council, I hereby Accept this PEP.

We would like to thank Mariatta for championing PEP 581, and to all the 
contributors to the discussion, both pro and con.  We appreciate your candor 
and respect for your fellow developers.  The SC believes that this migration is 
in the best interest of the Python community, and we look forward to the 
elaboration of the detailed migration plan (PEP 588).

We also extend our heartfelt thanks Berker, Ezio, and everyone who has helped 
develop and maintain Roundup and bugs.python.org over the years.  bpo has been 
a critical component for Python development for a very long time, and we all 
greatly appreciate the time, effort, and devotion you have put into this 
resource.

https://www.python.org/dev/peps/pep-0581/

Onward we go!  The migration will be a large effort, with much planning, 
development, and testing, and we welcome volunteers who wish to help make it a 
reality.  I look forward to your contributions on PEP 588 and the actual work 
of migrating issues to GitHub.

Cheers,
-Barry (BDFL-Delegate, and on behalf of the Python Steering Council)



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Promote Mark Sapiro and Abhilash Raj as core developers

[Barry Warsaw]

On May 14, 2019, at 00:46, Antoine Pitrou  wrote:

> Barry, if you trust
> Mark's and Abhilash's competence, it should probably be easy for you to
> merge their first PRs (and guide them along the way).

I do, and that works for me.   Can we give them triage rights on bpo now?

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Promote Mark Sapiro and Abhilash Raj as core developers

[Barry Warsaw]

On May 13, 2019, at 01:14, Victor Stinner  wrote:

> I'm no longer sure myself that I can define them. I prefer to repeat
> what others say :-) Basically, a core developers is someone who
> produces commits :-) That's one definition.

But, IMHO not a correct one.  The full quote from PEP 13:

——snip snip——
Python core team members demonstrate:

• a good grasp of the philosophy of the Python Project
• a solid track record of being constructive and helpful
• significant contributions to the project's goals, in any form
• willingness to dedicate some time to improving Python

As the project matures, contributions go beyond code. Here's an incomplete list 
of areas where contributions may be considered for joining the core team, in no 
particular order:

• Working on community management and outreach
• Providing support on the mailing lists and on IRC
• Triaging tickets
• Writing patches (code, docs, or tests)
• Reviewing patches (code, docs, or tests)
• Participating in design decisions
• Providing expertise in a particular domain (security, i18n, etc.)
• Managing the continuous integration infrastructure
• Managing the servers (website, tracker, documentation, etc.)
• Maintaining related projects (alternative interpreters, core infrastructure 
like packaging, etc.)
• Creating visual designs

Core team membership acknowledges sustained and valuable efforts that align 
well with the philosophy and the goals of the Python project.
——snip snip——

I’m quite convinced that both Mark and Abhilash meet these requirements.  And 
they are almost by definition the experts in the email package.  You can 
certainly see the nature of their work in the Mailman repos, and I would be 
willing to mentor them through the first few commits to the CPython repo, 
though I think it will be mostly perfunctory.

> Having a sustainable Mailman project is great. But how does that
> relate to Python itself? Are you talking about the email module? Do
> Mark Sapiro and Abhilash Raj plan to maintain the email module?

Yes, that is the intent.

> In the meanwhile, they don't have to be core devs to help to maintain
> the email module, no?

Do we have any core developers who want to maintain it?  Not me :) and 
apparently not RDM.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Promote Mark Sapiro and Abhilash Raj as core developers

[Barry Warsaw]

If you like the way mail.python.org and Mailman (both 2 and 3) Just Work, and 
are about as reliable as any service can be, we have our wonderful postmasters 
to thank.  Mark has been a postmaster for years and is currently maintaining 
GNU Mailman, both as a project and as a service on mpo.  Abhilash maintains the 
GNU Mailman 3 branch, has been project leader since I retired in that role back 
in 2017, and also maintains the Mailman 3 instance on mail.python.org.

More than that, because of their roles as Mailman developers, they have a deep 
knowledge of email in general, and in the email package in particular.  As I 
rarely dabble in the email package these days, and RDM --who did a fantastic 
job of implementing the new APIs and features in email for Python 3— has also 
scaled back his involvement, it means that the email package doesn’t get much 
attention these days.  Both Mark and Abhilash have an interest in helping to 
maintain the email package moving forward, and both are eminently qualified to 
do so.

I have worked with both of them for many many years, and I have the utmost 
respect for their technical and social skills, their understanding of Python 
processes, and their love of the Python language and community.  I've sprinted 
with them at many Pycons, until I scaled back my involvement with Mailman.  
Both are here sprinting at Pycon 2019.

Therefore, with their permission, I propose extending core developer rights to 
both Mark and Abhilash.

As per PEP 13, I plan on opening a vote on Discourse next week (once I kind of 
recover from Pycon) for each developer.

Cheers,
-Barry




signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Steering Council Update for April 2019

[Barry Warsaw]

On Apr 26, 2019, at 09:12, Berker Peksağ  wrote:

> I don't think there was a consensus on switching to GitHub Issues last
> time it was discussed. The most recent discussion about PEP 581 only
> has 12 messages. I think the council is making a premature decision
> here.

Technically speaking, the PEP is still in Draft state.  I have a PR up for 
splitting the migration into two separate PEPs, one for the rationale and a 
second one for the migration plan:

https://github.com/python/peps/pull/1013

> I'm strongly against using GitHub Issues. I will change my mind once I
> see a sign that GitHub is actually listening to our feedback. We can't
> even get them to make the use of # and GH- in the commit title
> configurable (https://github.com/maintainers/early-access-feedback/issues/77)
> and have the ability to automatically strip intermediate commit
> messages from the commit message body
> (https://github.com/maintainers/early-access-feedback/issues/153) The
> only time I got a response from them was this:
> https://github.com/python/miss-islington/issues/16#issuecomment-396095622

It would be very helpful if you could add these comments to the PR.

> I volunteered to maintain our Roundup instance a while ago and already
> fixed some bugs: https://hg.python.org/tracker/python-dev/ I've also
> submit patches to improve UX and fix issues. I'd list list them here
> but I can't reach out to http://psf.upfronthosting.co.za/roundup/ at
> the moment. I hope the problem with the hosting is temporary because I
> have several non-trivial patches there.

And as a fan of Roundup and its critical importance to the Python development 
process, I want to personally thank you for all your —and everyone who has 
contributed to it over the years— hard work in maintaining it.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Can we choose between mailing list and discuss.python.org?

[Barry Warsaw]

On Feb 13, 2019, at 15:13, Victor Stinner  wrote:
> 
> I only asked *how can we take a decision*?

We start with a PEP, then the SC will make a determination based on this PEP 13 
Mandate:

"Establish appropriate decision-making processes for PEPs”

which is still a work in progress.  I think for the short term, we just 
continue the status quo.  It’s not ideal to have two forums for the same 
community, but it’s not such a burden that it needs immediate resolution, IMHO.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Can we choose between mailing list and discuss.python.org?

[Barry Warsaw]

On Feb 12, 2019, at 18:01, Ned Deily  wrote:
> 
> On Feb 12, 2019, at 20:36, Barry Warsaw  wrote:
>> On Feb 12, 2019, at 13:59, Antoine Pitrou  wrote:
>> I know I can browse easily through a 161-message mailing-list or
>>> newsgroup thread using a traditional threaded view, read what I want,
>>> come back later to read the rest, etc.  But Discourse's linear
>>> presentation pretty much kills that ability.  It doesn't even allow
>>> *seeing* the structure of the discussion.
>> That’s pretty much my same, biggest gripe about long GitHub issues and PRs. 
>> ;)
> 
> But you realize that this a feature, not a bug? :)
> 
> https://blog.codinghorror.com/web-discussions-flat-by-design/

Unfortunately, that post doesn’t talk about all the problems with flat 
discussions, and there are many.  So if we have to, we can agree that both have 
advantages and disadvantages, both have their proponents and detractors, and 
very likely both are appropriate to some forums and discussions and 
inappropriate (or ineffective) for others.  Or maybe more succinctly: both are 
terrible. ;)

That tells me either that the problem is fundamentally unsolvable due to the 
nature of online discussions, or we’re asking the wrong questions.

As far as software darwinism is concerned, we can also admit that top posting 
has won, but not necessarily because it’s superior (in fact, IMHO it’s not).  
It’s just that mobile and webmail has taken over and either because of laziness 
or U/I difficulties, inline replies are too difficult.

We live with plenty of inferior technology for reasons that aren’t entirely 
based on actual efficiency and ease of use.  Techmology! (with apologies to Ali 
G).

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Can we choose between mailing list and discuss.python.org?

[Barry Warsaw]

On Feb 12, 2019, at 13:59, Antoine Pitrou  wrote:

> I know I can browse easily through a 161-message mailing-list or
> newsgroup thread using a traditional threaded view, read what I want,
> come back later to read the rest, etc.  But Discourse's linear
> presentation pretty much kills that ability.  It doesn't even allow
> *seeing* the structure of the discussion.

That’s pretty much my same, biggest gripe about long GitHub issues and PRs. ;)

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Can we choose between mailing list and discuss.python.org?

[Barry Warsaw]

On Feb 11, 2019, at 09:48, Victor Stinner  wrote:
> 
> tl; dr How can we decide if we should stop using mailing list or if we
> should stop using discuss.python.org?

Point of order: I think we need a PEP for this decision.  Such a PEP would 
organize and consolidate the arguments both pro and con of the three choices.  
It should also cover whether the current Discourse experiment translates to 
larger mailing lists like python-dev, -ideas, and -list (for which I personally 
have uncertainty about).

Once that PEP is written, the SC is the proper forum for deciding the next 
steps, IMHO.

-Barry




signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Timeline to vote for a governance PEP

[Barry Warsaw]

Based on my suggestion on Discourse, I propose that the period between tomorrow 
and November 30th be an official PEP review period, with voting postponed to 
December 1 - 16 AOE 2018.

https://github.com/python/peps/pull/841

I am personally going to start reviewing these PEPs after the flood of 
trypophan is unleashed into my bloodstream following the USA Thanksgiving meal.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Timeline to vote for a governance PEP

[Barry Warsaw]

On Nov 2, 2018, at 20:24, Tim Peters  wrote:

> Nevertheless, I probably won't vote - I object to public ballots on
> principle.  That's been raised by others, so I won't repeat the
> arguments, and I appear to be very much in a minority here.

I also prefer private ballots on principle, but I’ll still vote if they are 
public.  I don’t completely buy into the rationale in PEP 8001 on why they must 
be public.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Please wait for my governance PEP

[Barry Warsaw]

I am planning on finishing up 8010 tomorrow and doing a check in of the initial 
draft.  Happy to have collaborators!

-Barry

> On Oct 4, 2018, at 06:18, Łukasz Langa  wrote:
> 
> There are already three published PEPs:
> - PEP 8012: discussion on 
> https://discuss.python.org/t/pep-8012-the-community-model/156/5
> - PEP 8013: some discussion here
> - PEP 8014: no discussion yet
> 
> I expect PEP 8010 and PEP 8011 to be done by the deadline which was extended 
> to October 8. You are free to write your own PEP but you might save 
> significant effort and time by looking at the existing ones and teaming up 
> with one of them. You can reach out to Mariatta or Barry to learn how far 
> along they are.
> 
> I know I'd be very happy to have you help with PEP 8012 :-)
> 
> --
> Best regards,
> Łukasz Langa
> 
> 
> On Oct 4, 2018, at 15:02, Victor Stinner  wrote:
> 
>> Hi,
>> 
>> I was waiting for other governance PEPs to decide if I would write
>> mine or not. Since I don't see other PEPs, I decided that I will write
>> mine. Please give me between one and three weeks to write it.
>> 
>> Note: Sorry, I didn't follow the Discourse discussion, I'm not sure if
>> this mailing list should be used or not.
>> 
>> Victor
>> ___
>> python-committers mailing list
>> python-committers@python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] python-committers is dead, long live discuss.python.org

[Barry Warsaw]

On Sep 28, 2018, at 15:03, Victor Stinner  wrote:

> It seems like anyone can subscribe. Is the Committer group reserved to
> core developers? If yes, how do you know which accounts are linked to
> core developers?

You must be approved to join python-committers, but its archive is public for 
anyone to read.  Does Discourse provide the same level of access for core 
developers and non-core developers?

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] python-committers is dead, long live discuss.python.org

[Barry Warsaw]

On Sep 28, 2018, at 17:45, Łukasz Langa  wrote:

> Do you use NNTP? Like with IRC, you won't find the next generation of core 
> developers on it. And no, there is no support for it in Discourse.
> 
> We could probably figure something out with Gmane if there's interest.

Yes, I use NNTP to read many of the Python mailing lists.  Gmane, even in its 
current state, is fantastic.

I’m all for supporting the next generation of developers, but not necessarily 
at the expense of *decades* of established workflow for current developers.  
Moving to Discourse breaks this and proliferates browser tab syndrome.  It’s an 
experiment worth conducting, but I do think it’s a bit cavalier to shut down 
python-committers without further discussion.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] 1 week to Oct 1

[Barry Warsaw]

On Sep 26, 2018, at 19:28, Mariatta Wijaya  wrote:
> 
> Really sorry folks, but I also would like to request an extension, by one 
> week to Oct 8.
> It's not because I've been slacking; I've started a five-page document (only 
> Barry has seen it), but I still need his help before it can be ready for the 
> public.
> In addition, I'm facing personal health issue. I'll be unable to work on the 
> proposal for the next few days.

+1 - I just got back from a whirlwind three weeks of the core sprint followed 
by my son’s wedding.  I did get a chance to start fleshing out PEP 8010, but I 
have a lot of catching up to do, plus two talks to give by October 1st, so a 
week’s delay would be very helpful.  I don’t think I’ll need more than that.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Python 4.0 or Python 3.10?

[Barry Warsaw]

On Sep 25, 2018, at 18:57, Victor Stinner  wrote:
> 
> IMHO It's time to discuss again modifying the "python" program to always 
> point to the latest Python version.

This just came up again on linux-sig, but...

> What is the status of Brett's UNIX Python launcher "py" by the way?

...I forgot to mention this.

FWIW, I still think we shouldn’t recommend a change here until 2.7 is done and 
done.  However, the launcher might be a good way out.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Python 4.0 or Python 3.10?

[Barry Warsaw]

On Sep 25, 2018, at 15:31, Antoine Pitrou  wrote:
> 
> So my preference would be on 3.10.

3.9 + 0.1 :)

Renaming it to Python 4 is fraught with knock-on effects, so I think we do 
reserve that for major changes.  I doubt we’ll ever need for a disruptive 
backward incompatible change *at the Python level* in a Python 4, but I 
absolutely can see the possibility of incompatible changes at the public C API 
layer.  I’m not saying it *will* happen, but that’s what we should reserve 
“Python 4” for if or when it happens.

-Barry





signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] 1 week to Oct 1

[Barry Warsaw]

On Sep 24, 2018, at 14:32, Mariatta Wijaya  wrote:
> 
> 1. Is everyone still ok with the Oct 1 as deadline for coming up with 
> governance PEPs?

I’m afraid that I may not be, actually.  I expected to have time to work on my 
PEP while I was on leave for my son’s wedding, but y’know, family! :)  Mariatta 
and I are collaborating a bit on 8011, but I haven’t really had time to work on 
8010.  I don’t want to push it back too far, but a couple of weeks would really 
help.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Reminder of BDFL succession timeline + CFP

[Barry Warsaw]

On Aug 1, 2018, at 12:41, Mariatta Wijaya  wrote:
> 
> Since this is like a CFP I figured we should clarify what's expected the 
> proposal, and I also wanted to be more detailed in the timeline.
> 
> Oct 1 00:00:00 UTC: Deadline of coming up with proposals of governance model.

Thanks for writing this up Mariatta.  I think it’s very useful to put stakes in 
the ground so that these discussions don’t drag on forever.  I agree with those 
who say that the status quo is an implicit choice of governance models, and I 
think we shouldn’t operate under implicit rules for too long.  Like Brett, I 
often have folks coming up to me and asking me what’s going on, and when Python 
will decide on a governance model.  Let’s not underestimate the message this 
sends to the outside world.

OTOH, we do have some flexibility in the timeline, and I still believe that we 
have flexibility in the governance model over the long term.  I’ve no doubt 
that no matter what we choose, the debate will continue, with ebbs and flows as 
situations arise.  That may even lead to new (or adjusted) governance models in 
the future, and that’s fine!  Unlike with Python itself, we aren’t bound to 
strict backward compatibility. :)

That said, I think it’s worthwhile capturing the proposed governance models in 
PEPs so that we all know exactly what we’re debating.  October 1st for that 
round of PEP submissions is quite reasonable IMHO.  Procedurally, I suggest we 
segregate governance model PEPs in their own 4th digit namespace (e.g. like the 
way Python 3k started at the 3000s).  8 seems like a good number; we reserve 
the lower 8ks for “special” PEPs (the problem statement, the choice, the voting 
procedure, etc.).

We can be a little more loose on the voting schedule, but like Brett, I would 
like to have a decision by the end of 2018, even if that decision is an 
explicit choice of status quo.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] And Now for Something Completely Different

[Barry Warsaw]

On Jul 20, 2018, at 00:49, Antoine Pitrou  wrote:
> 
> I find the PEP-delegate to be a powerful concept.  Why wouldn't *every*
> PEP have a PEP-delegate?  This way we don't need a BDFL anymore.  We can
> discuss how to nominate PEP-delegates (Nick had an interesting proposal).

Because IMHO that would lead to a language designed by committee, with a less 
consistent vision.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] An alternative governance model

[Barry Warsaw]

On Jul 18, 2018, at 17:31, Alex Martelli via python-committers 
 wrote:
> Humans do so love to argue!
> 
> No we don't! (cfr http://www.montypython.net/scripts/argument.php)...

I guess that means we do love getting hit on the head…

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Language moratorium

[Barry Warsaw]

On Jul 19, 2018, at 08:41, Brett Cannon  wrote:
> 
> Then we would have to solve our governance problem sooner rather than later. 
> But i don't think every Python release has to make a huge splash.

The other option of course is to push the release date of Python 3.8 back to 
accommodate the new governance structure.

> On Jul 18, 2018, at 19:23, Tim Peters  wrote:

> Unsure!  Governance is needed to resolve conflict.  When there's broad 
> agreement, "leaders" aren't really needed.  For example, there's been a bit 
> of talk on python-ideas about adding a new `intmath` module capturing some 
> frequently reinvented functions for which decent implementations are known 
> but non-obvious (e.g., for generating the primes).  Nobody could sanely fight 
> to death against something like that.  Even whining about it would appear 
> petty ;-)


I don’t necessarily include new modules, other stdlib changes, build or 
performance improvements, and other such “normal development” work (i.e. bug 
fixing) to be affected by a language moratorium.  PEP 572-level decisions would 
very definitely fall under that rubric.

We have plenty of experts still in place that can make more minor decisions.  
In fact, perhaps we should largely operate as if our BDFL were just on a long 
vacation and not pronouncing on PEPs.  That’s never frozen Python development 
before, and shouldn’t now.

If PEP 572 were the only new syntax for 3.8, then so be it.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Barry Warsaw]

On Jul 19, 2018, at 10:19, Terry Reedy  wrote:
> 
> On 7/19/2018 1:10 PM, Mariatta Wijaya wrote:
>> On Thu, Jul 19, 2018 at 8:59 AM Brett Cannon > > wrote:
>> So what about the following timelines:
>> Oct 1: Deadline for people to come up with proposals of governance model, 
>> candidates, and how to vote
>> Dec 1: Deadline to choose a governance model, (and if possible, we choose 
>> the new leader(s) too)
> 
> Why not Nov 1, leaving a month to decide on proposals?
> 
>> Jan 1: Deadline to choose the new leader(s), if not already chosen by Dec 1.

I like the Nov 1 schedule.  I’m +1 with giving plenty of time to process, but I 
share the concern about letting things drag on too long.

IMHO, ideally we’d have the new governance structure and its office holders in 
place by EOY18.  That has to account for various holidays, including 
Thanksgiving in the US and Christmas to New Years.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] An alternative governance model

[Barry Warsaw]

On Jul 18, 2018, at 16:06, Fred Drake  wrote:

> PEP 2 is (currently) the "Procedure for Adding New Modules".  Though
> superseded, recycling the PEP number seems out of character with the
> RFC process from which we derived the PEP process.  Let's be cautious
> about recycling like that; integers are cheap.

Dang, so it is.  :(

I don’t want to recycle numbers, so we’ll likely end up taking the next 
available low ones.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Language moratorium

[Barry Warsaw]

On Jul 18, 2018, at 09:11, Stefan Krah  wrote:

> if I remember correctly, we had a moratorium for language changes around
> versions 3.2-3.3.  I think during that time relatively few BDFL-level
> decisions were required.
> 
> Perhaps we could have one again, say for 12 months so we can figure things
> out. Other Python implementations may welcome the moratorium so they can
> catch up.

I agree that we’ll effectively have language moratorium until we have a new 
governance structure.  But let me ask, what do you propose to do about PEP 572? 
 That’s already been accepted, but not yet implemented.  Would it be exempt 
from the moratorium or scoot in under the wire?

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] An alternative governance model

[Barry Warsaw]

On Jul 18, 2018, at 10:13, Eric Snow  wrote:

> Regardless of when it happens (if ever), what will happen
> in the future when we don't have anyone suitable?  One danger is that
> we will install someone un-suitable because "we've always had a BDFL".
> But what is that "danger"?  What impact could a rogue BDFL have?

I’m not concerned about that, and not just because I’m secretly wishing for a 
filibuster until I get to join Guido on the Isle of Former Pythonistas Who Know 
Prefer To Sip Margaritas In Peace and Quiet and No Internet.

Grooming suitable future leaders is critical to the relevance of Python for the 
next 30 years.  I’m confident that when the time comes, there will be obvious 
choices, just as there has been for Release Managers.  And if there really 
isn’t then future archeologists will point to this thread and say “maybe now we 
can experiment with a Supreme Council”.

> 1. what makes a good BDFL?
> 2. what do we do when we can't find a suitable candidate?
> 3. what negative impact can a BDFL have?
> 4. how do we mitigate that impact?  how do we deal with a "bad" BDFL?

I’d like to add: how do we ensure that we will have many suitable candidates if 
and when the time comes to choose the N+1BDFL?

> However, I supposed I hadn't considered it before, but the BDFL has a
> much more significant role.  The Python community is in many ways a
> reflection of Guido and a result of his leadership (much more than
> technical leadership).  Consequently, a new BDFL must be someone who
> reflects where we want the community to be.

To me, that’s the “vision” question, but I think the BDFL doesn’t just reflect 
the communities wishes, because “the community” will never agree 100% on 
anything.  Which, FTR, I think is okay.  The BDFL uses their intuition, 
compassion, and experience to move Python forward according to their vision for 
what the language should be, deeply informed by —but not subservient to— the 
opinions of all its users and developers, because that’s essentially impossible.

> 2. what do we do when we can't find a suitable candidate?
> 
> This is worth figuring out.  It isn't something we've discussed much.
> I expect most folks feel like it will never be an issue.  I suppose
> they're right.  At the point there isn't a suitable candidate, we have
> larger problems to address. :)

Indeed.  I’d say that we should be proactive so that we never get into that 
position, by beginning to groom future NBDFLs now.

> 3. what negative impact can a BDFL have?
> 
> I was primarily thinking about a "rogue" BDFL, rather that about
> mistakes an otherwise good one might make.  The big question is what
> does it mean for the BDFL to go "rogue".  It definitely isn't "making
> a decision the people don't agree with" as Guido has done that plenty
> of times (to our benefit). :)  In my mind, the main bad that the BDFL
> can do is to hurt the community.  Their possible negative technical
> impact is small and highly recoverable.

That’s a good point, except that there is usually a window of practical 
recoverability.  For example, once Python 3.8 is released, PEP 572 will be very 
very difficult to undo.

> 4. how do we mitigate that impact?  how do we deal with a "bad" BDFL?
> 
> People make mistakes.  We should expect the BDFL to make them too.  We
> should also expect them to care deeply about Python (as well as align
> relatively closely with the community).  We can deal with their
> mistakes. :)
> 
> However, if the BDFL turns out to be not as capable as we expected (no
> judgement, Brett) or appears to be purposefully hurting Python then
> we'd need to act.  On the one hand we'd need to deal with the BDFL
> directly, likely replacing them or more broadly restructuring.  On the
> other had we'd have to deal with the community consequences (the four
> listed in point #3).  The latter is the one with deeper consequences.
> TBH, the same is true of any structure we apply (e.g. council,
> majority rule).
> 
> I suppose the most we could plan for would be quickly removing a rogue
> BDFL (but without such a plan hanging over a good BDFL's head).  I'd
> consider Barry's proposal of advisers to be in the right direction.
> That said, as with #2 this is probably not something that will ever
> come up.

Thanks Eric, these are good points to consider.

> The "benevolent" part is critical though.  Without it none of the rest
> would work for us.  Perhaps I've misunderstood your point?  FWIW, the
> word "dictator" has a lot of negative connotation that does not match
> our usage in BDFL.  I don't mean to suggest that's the only concern
> here, but would it help to use a different name than BDFL?  IIRC, it's
> either a clever Monty Python reference or a tongue-in-cheek expression
> from Barry 20 years ago that stuck.

I’d put my money on Uncle Timmy coining that term, but maybe you’re on to 
something here.  Okay, let’s call our leader “Dinsdale”.  As in, who will be 
the Next Dinsdale?

> Fair enough.  I don't 

Re: [python-committers] An alternative governance model

[Barry Warsaw]

On Jul 18, 2018, at 09:44, Steve Dower  wrote:

> Right now, I imagine Barry is testing the waters to see whether it's worth 
> his time writing this up as a proposed PEP 2. Other people seem to be 
> interested in also proposing alternative PEP 2s, and eventually we as a group 
> will have to select one of them, no doubt by majority vote. And while Barry's 
> long service to this group certainly adds weight to his opinion, it's also 
> likely that we can filibuster for long enough until he retires and then 
> ignore him completely :)

One can only hope! :)

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] An alternative governance model

[Barry Warsaw]

On Jul 18, 2018, at 09:10, Antoine Pitrou  wrote:

> At this point we are not talking about a majority vote.  All I see is a
> rushed plebiscite on a single governance model and a single person.

Antoine, there’s nothing rushed about this.  I made a proposal, and there’s a 
healthy debate going on.  We don’t even know how the decisions will be made, or 
by whom yet.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] An alternative governance model

[Barry Warsaw]

On Jul 18, 2018, at 03:31, Ethan Furman  wrote:
> 
> I think this is the crux of the argument:  getting a group of people, even a 
> small one, to agree on a singular vision can be very difficult.

Yep.

>> I also think a council will be much more risk adverse than a singular BDFL, 
>> and that’s not necessarily a good thing.  While moratoriums and a more
> > conservative approach to change may be appropriate at times, I would prefer 
> > those to be deliberate decisions for a specific purpose, rather than
> > the unintended outcome of groupthink or lack of consensus.  A singular BDFL 
> > with support from the community will have more authority to make
> > decisions which probably will never be universally accepted, and much less 
> > prone to vapor lock due to lack of consensus or internal bickering.
> 
> Community support can be mercurial, and should not be relied upon as an 
> underpinning of our governance model.

No?  I think it’s critical.

Here’s a thought experiment: Pretend that PEP 572 were in front of the Supreme 
Council.  How do you think the discussions would go?  Would your opinion for or 
against be weighed with sufficient deliberation?  Would the PEP have undergone 
the rewrites it did in order to address the concerns early on?  Would you have 
confidence in the decision of the Council, whether it went your way or not?  If 
you lost the argument, how would you react?  How would any of that be different 
with a singular leader?  Would it matter to you if that leader was not Guido?

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] An alternative governance model

[Barry Warsaw]

On Jul 18, 2018, at 03:04, Antoine Pitrou  wrote:
> 
> If we're talking about a dictator (this is Barry's proposal), we're not
> talking about someone that just makes language design decisions, as
> Victor pointed out.

I’m talking about a singular leader who has the responsibility and vision to 
direct Python for as long as they are able and want to.  Just as Guido left 
tons of decisions to others (including this one :), so will the next BDFL.  
Exactly what that mix of delegation will look like is, in my proposal, up to 
the NBDFL.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] An alternative governance model

[Barry Warsaw]

On Jul 18, 2018, at 02:49, Ethan Furman  wrote:

>> (*) (I'm leaving the "benevolent" part out, since clearly it was only
>> tied to Guido's personality, not to any inherent statutory limitations)
> 
> I think that's a mistake.  Clearly, the "benevolent" part is a major criteria 
> for the dictator, triumvirate, CoE, or whatever we come up with, and Guido is 
> not the only benevolent core-dev we have.

+1 - completely agree.  “Benevolence” is critical IMHO.

-Barry




signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] An alternative governance model

[Barry Warsaw]

On Jul 18, 2018, at 01:43, Antoine Pitrou  wrote:
> 
> Why do you think non-BDFL projects have a problem with """ambiguity as
> to the authority of said decision"""?  What is your basis for that
> assertion?

With more people empowered to make a binding decision as part of a Supreme 
Council, there will be more uncertainty in the authority of the person 
pronouncing.  Part of that will be because the pronouncement can come from any 
of the member of the Council, and part may come from more turnover in the 
Council membership.  I’m not at all concerned about *us* accepting that 
authoritative decision because we are are deeply invested in Python’s 
governance.  But I claim that the vast majority of Python users are not, so 
while they recognize Guido’s name as the (former) leader, I question whether 
they will be able to have the same certainty in the authority of a decision 
coming from 3 or 5 people who’s names they are not familiar with.  With a 
singular leader, it will be easier to communicate the authority of that leader.

So yeah, maybe it’s a PR problem, but it’s still important nonetheless.

> I'm worried that you seem to be descending into magical thought,
> believing for some reason that nothing else than monarchy could ever
> work for a software project.

We’re not talking about software project governance in general, we’re talking 
about Python specifically. And Python has had a strong singular leader with a 
clear vision for its entire nearly 30 year life.  Yes, I personally question 
whether a Supreme Council will work for Python.

> Since you're opening this can of worms, I'll say it:
> 
> - I'm -1 on a new dictator-for-life (*)

Let me be clear: “BDFL” is a convenient term with a well-known meaning.  In 
fact, I believe *we* coined that term that’s now often used in other open 
source projects.  But as Guido has eloquently demonstrated, the “For Life” part 
really means “For As Long As They Want To Do It”.  In other words, it’s just a 
title for the job.  In my proposal, it really means “For As Long As They Want 
To Do It And They Don’t Do Something Evil Enough To Get Impeached”.  I’m 
spelling that title with the initialism “BDFL” :)

> - I'm -1 on Brett Cannon as a new dictator-for-life

Of one thing I have absolutely no doubt: no decision in Python will ever be 
unanimous!  That kind of proves my point as to why a singular leader is 
necessary. :)

> You're creating a huge problem here.  Whatever dictator you come up
> with, not everyone will be ok with that choice.  What are they supposed
> to do?  If one doesn't think X is legitimate as a dictator, how does one
> keep contributing to the project?  In other words, you are threatening
> to exclude people, perhaps seasoned contributors.

How is that any different with a Supreme Council rather than a singular leader? 
 Whatever makeup of the Council we come up with, not everyone will be okay with 
those choices.  What are they supposed to do?

Ultimately you’re right.  There are zillions of reasons not to contribute to 
Python, so having no confidence in its leadership is just one more.  
Fortunately, only you get to decide whether your reasons not to contribute 
outweigh your reasons to contribute.  And further, it’s open source, so you are 
*always* welcome to fork.  Look at Devuan 
.

>> I’ve long said — somewhat in jest, since I never expected Guido to actually 
>> ever retire! — that Brett would be my choice for the next BDFL.  I think 
>> he’s the perfect candidate, and he’s already demonstrated qualities that I 
>> think make him a fantastic leader.
> 
> I bed to disagree, Barry.  Brett is a good contributor, that doesn't
> make him legitimate as a dictator.  Only Guido could be, and he has
> stepped down.
> 
> The amount of cheerleading here ("""smart, compassionate, passionate,
> respectful, young, tall, and has the right mix of technical excellence
> and social skills""") is embarrassing.  What if we don't subscribe to
> your views of Brett's qualities: do you expect us to publicly criticize
> Brett so as to justify our opposition?

Also fortunately, I don’t get to unilaterally decide this!  I get to propose a 
plan, make my arguments, try to persuade, and cast my one vote — hopefully, 
depending on the criteria.  Just like all of you. :)

(Maybe we don’t count anybody who has more hair on his chin now than his head 
when he first started using Python, in which case, I’m definitely forking what 
I’ll call UncleTimmython).

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] An alternative governance model

[Barry Warsaw]

On Jul 17, 2018, at 22:55, Kushal Das  wrote:

> +1 to this idea including Brett as BDFL. Though I am wondering if
> anyone asked Brett about it?

I know my email was long, so easy to overlook, but I did ask Brett and he 
didn’t immediately say no.  :)

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] An alternative governance model

[Barry Warsaw]

I’d like to propose an alternative model, and with it a succession plan, that 
IMHO hasn’t gotten enough discussion.  It’s fairly radical in that it proposes 
to not actually change that much!

TL;DR: I propose keeping a singular BDFL and adding a Council of Advisors that 
helps the BDFL in various capacities, with additional responsibilities.  I also 
have someone specific in mind for the NBDFL, but you’ll have to read on for the 
big reveal.

Why keep a singular BDFL?  I think it’s clear that no one can completely 
replace Guido, and neither should we try, nor do we need to.  The discussion to 
date has explored refactoring many of the roles that the BDFL has, and that’s 
all excellent, especially to reduce the burden and burnout factor of the NBDFL. 
 But I think having a singular BDFL making the tough decisions, with the 
support and help of the community, is in the best interests of Python over the 
long term.

A singular BDFL provides clear leadership.  With a council of elders, it will 
be more difficult to communicate both to the Python community, and to the 
larger, more peripheral user base, that any particular individual has the 
authority to make decisions.  Regardless of size, there would ultimately be 
some one person communicating any council decision.  There will inevitably be 
ambiguity as to the authority of said decision.  How will folks, especially on 
the periphery, know that Alice Jones or Bob Smith are members of the council 
and can speak authoritatively on decisions for the language?  “Bob Smith, on 
Behalf of the GUIDO” is IMHO less obviously and unquestionably authoritative 
than “Alice Jones, BDFL”.

This also comes into play for shutting down discussions early.  With a 
committee, it’s possible that you’ll have some disagreement among the members 
as to whether a discussion is fruitful or not, whether it rehashes settled 
questions, or whether the change fits into the overall direction for Python’s 
evolution.  Alice Jones may say “No, that’s not gonna happen” only to be 
overruled or undermined by Bob Smith’s “That’s a good idea”.

Taken together, these fall under the umbrella of having one voice for the 
decision making process.  It may be possible for consensus within the council 
to come across as a single voice, but I think it will generally be harder.  A 
council also opens the door for more back-channel lobbying of a sympathetic 
member.  Yes, such lobbying is possible with a BDFL, but at least there should 
be less contention.

I also think a council will be much more risk adverse than a singular BDFL, and 
that’s not necessarily a good thing.  While moratoriums and a more conservative 
approach to change may be appropriate at times, I would prefer those to be 
deliberate decisions for a specific purpose, rather than the unintended outcome 
of groupthink or lack of consensus.  A singular BDFL with support from the 
community will have more authority to make decisions which probably will never 
be universally accepted, and much less prone to vapor lock due to lack of 
consensus or internal bickering.

I hope Guido won’t mind me relating a comment of his that has really resonated 
with me over the last few days, and for which I think a singular BDFL will be 
much more adept at communicating and shepherding.  The question for any new 
leader is:

What is your vision for Python?

This question keeps coming to mind as I think about how the evolution of the 
language will be governed over the next few years or decades.  Yes, Python is a 
mature language, but it’s far from stagnant.  Guido always had a very clear 
vision of what Python should be, where it should go, and how new proposed 
features (or other changes to the Python ecosystem) fit into that vision, even 
if he didn’t or couldn’t always clearly articulate them.  The NBDFL will 
necessarily have a different vision than Guido, and I think even he would agree 
that that’s okay!  A strong vision is better than no vision.  Python must 
continue to grow and evolve if it is to stay relevant in a rapidly change 
technology environment.  As an almost 30 year old language, Python is already 
facing challenges; how will that vision address those challenges, even if to 
explicitly choose the status quo?

Will a council be able to articular, express, communicate, adapt, and follow 
through on that vision?  Will a council be able to evaluate a proposed change 
as it supports or detracts from that vision?  Will a council be able to break 
out of a primarily maintenance position, to actually move the language and its 
primary implementation forward?  I’m not so sure.

For these reasons I propose that we retain a singular BDFL.

The formation of a formal Council is still a good idea!  I just think that it 
shouldn’t be the ultimate arbiter of decisions for Python.  So what would the 
Council do?

- It would serve as a check on the BDFL.  If Bob Smith were one day employed by 
Evil Corp. and started making decisions that were 

Re: [python-committers] Transfer of power

[Barry Warsaw]

On Jul 14, 2018, at 00:16, Łukasz Langa  wrote:

> Taking a step back, before we talk names, term limits and even numbers of 
> council members, Python needs a "constitution" which will codify what the 
> council is and how it functions. Barry calls it PEP 2 but I'd like to 
> understand who is supposed to author it and who is supposed to accept it.

Yes, I’ve been thinking the same thing.  PEP 2 would serve as the Python 
development constitution.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Identify roles of the BDFL

[Barry Warsaw]

On Jul 13, 2018, at 17:11, Carol Willing  wrote:

> If I look at the many important roles that Guido has played, I personally 
> believe that he has been someone who encouraged many women (and I'm sure 
> others as well) and most importantly provided a safe place to share ideas. If 
> we reflect on Mariatta's PyCon talk and Summit talk, it's clear that we 
> should not overlook this role as growth and improvements still need to happen 
> here.

Maybe we refactor this particular role of the BDFL?  It may be that given 
Guido’s passion for this topic, he would still want to be active.  If so, he 
would certainly still have the stature, respect, and voice to continue to 
promote this within the community.  Of course, we don’t know whether that’ll be 
the case or not.

It’s a good question though: should the Council primarily concern itself with 
technical details of language evolution, or take on more of the other roles 
that Guido traditional performed?  Or do you see more of an overlap there 
(other than through the person embodying that role)?

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Organizing an informational PEP on project governance options (was Re: Transfer of power)

[Barry Warsaw]

On Jul 13, 2018, at 04:31, Nathaniel Smith  wrote:
> 
> I volunteer to co-author such a PEP. But I'm not up to doing it on my
> own. So... who else wants to be a co-author? (I'm not going to
> pressure anyone, but Brett, Mariatta, and Carol, please know that your
> names were the first ones that jumped to my mind when thinking about
> this :-).)

Count me in.

Procedurally, I think an informational PEP numbered in sequence is a good place 
for the “design” of our governance.  Once we’ve settled on a plan, we would 
capture the operational procedures in a new process PEP (I propose PEP 2), 
which would be our working document moving forward.  I think it’s pretty much a 
certainty that whatever we come up with initially will undergo changes as time 
goes on and we gain experience.  PEP 2 would then be the living document for 
our language governance process.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Identify roles of the BDFL

[Barry Warsaw]

On Jul 13, 2018, at 03:40, Victor Stinner  wrote:

> Should we split the role "take the final decision on PEPs" into
> sub-roles for example? Do we need in advance to define BDFL-delegate
> for some kinds of PEPs? Or the BDFL should define per-PEP, which ones
> he doesn't want to handle and need a BDFL-delegate? In my experience,
> the BDFL delegation was done naturally, was not the source of
> conflict, and usually discussed directly with the BDFL.

I don’t think we need to be so formal about delegation.  As you say, it should 
generally happen naturally.

I actually think delegation will be more common, leaving mostly the 
language-level Standards Track PEPs for the BDFL (Benevolent Design Faction 
Lifers - okay, still playing with names :).

One tricky thing with delegation will be when a natural delegate is also the 
author of the PEP. For example, if Yury proposed some changes to async, he 
wouldn’t also be able to pronounce on it.  OTOH, Guido is of course still a 
developer and could be a delegate for such PEPs if he wants.  Just something to 
be aware of.

It’s possible that more decisions that have previously been informal will be 
best served by the PEP process.  For example, the pronouncement that 
dictionaries officially preserve insertion order would likely be handled as a 
succinct PEP.  One of the roles of the council would be to decide whether a 
change is PEP-worthy or not.  It’s possible that ideas that only show up on the 
tracker for example, need to be promoted into a PEP, and it would be up to the 
developer community to help identify those potential changes.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Barry Warsaw]

On Jul 13, 2018, at 02:30, Anthony Baxter  wrote:
> 
> As someone who's not been involved for some time now, but was release manager 
> for a three or four years (2.3.1 through to 2.5.1), trying to have the 
> release manager also be a decider of potentially controversial things doesn't 
> seem scalable.
> 
> I'm not sure what the proper governance structures should be, but they 
> absolutely shouldn't be dumping extra load onto the release manager.

My thinking is that the current RM can serve a useful role on the Council, but 
not in a voting capacity.  Some possible scenarios:

* A Council member wants to author a PEP.  They probably shouldn’t also get to 
vote on the PEP’s acceptance, so the RM can serve as a replacement vote for 
that one PEP.  (Maybe only for Standard Track PEPs).

* If a Council member is temporarily unavailable, the RM can serve in their 
place during that period.

* The RM can give valuable insight that may influence Council members votes.  
Maybe the PEP’s implementation is too difficult for the current release, and 
recommends deferral.

* If the Council also decides on the “PEP-worthiness” of an idea, the RM can 
weigh in based on their unique perspective on the release cycle.

* The RM can provide an independent oversight role on the Council, kind of like 
an ombudsman (or maybe that should be a separate role, although I suspect it 
will be rarely invoked in practice).

I would propose that the RM be involved with Council communications, but does 
not get a vote.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Barry Warsaw]

On Jul 13, 2018, at 15:11, Jack Jansen  wrote:
> 
> How about a triumvirate (or trium*ate if “vir” is seen as too male-centric, 
> and actually the “3” isn’t important either) where unanimity is required for 
> language changes (i.e. basically for accepting a PEP)?

Possibly, but even if unanimity can’t be achieved, I feel strongly that any 
decision coming from the GUIDO/Cabal/Council should be give as a single party.  
E.g. if Alice and Bob +1 PEP 801 and Carol -1’s it, I don’t think any purpose 
is served by breaking that out into individual votes.  I would hope that the 
council members support each other and the body’s decision even if it doesn’t 
go an individual’s way.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Barry Warsaw]

On Jul 12, 2018, at 12:16, Brett Cannon  wrote:
> 
> Maybe another way to label this is design stewards? We seem to be suggesting 
> a cabal of folks who steward the overall design while relying on experts as 
> appropriate to handle finer details.

I like that distinction.

-Barry




signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Barry Warsaw]

On Jul 12, 2018, at 11:21, Tim Peters  wrote:
> 
> If Barry had been BDFL all along, only features useful to Mailman would have 
> gotten in ;-)

I would have stuck around just long enough to kill off !=

diamonds-are-a-flufl’s-best-friend-ly y’rs,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Barry Warsaw]

On Jul 12, 2018, at 11:16, Steven D'Aprano  wrote:
> 
> https://www.python.org/dev/peps/pep-0401/

And of course, Uncle Timmy was the original FLUFL, before Guido and Brett did 
their nefarious edits. :)

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Barry Warsaw]

On Jul 12, 2018, at 07:57, Guido van Rossum  wrote:
> 
> I would like to remove myself entirely from the decision process. I'll still 
> be there for a while as an ordinary core dev, and I'll still be available to 
> mentor people -- possibly more available. But I'm basically giving myself a 
> permanent vacation from being BDFL, and you all will be on your own.

Leaving my emotions out of it for now, and with my heartfelt gratitude for 
everything you’ve done, I am absolutely certain that the community you’ve built 
is strong enough to carry on.

I’m honored that a some of you think I can fill 1/3 of Guido’s shoes, although 
in all humility I have my doubts.  Aside from that, it’s important to recognize 
that we have so many intelligent and compassionate contributors, that much of 
Python’s ongoing development can essentially carry on unchanged.  Yury, for 
example worried about replacing Guido’s extensive knowledge across so much of 
Python, and there’s the concern that Guido’s unique authority as BDFL will be 
difficult to replicate.  E.g even if you still absolutely hate PEP 572 (which I 
don’t), it is now unequivocally part of Python.  It’s up to all of us to accept 
that, move on, and learn to use it tastefully.

I think this change in governance will increase the importance of the 
BDFL-Delegate.  We have trusted experts in many of the sub-topics of Python, 
and I have so much more confidence in letting them make the decisions relevant 
to those sub-topics.  E.g. Nick, and now Paul for packaging, Yury et al for 
async, etc.  I know that experts and BDFL-Delegates will make the right choices 
in these sub-topics, with the right intentions, and the best of their 
abilities.  Even Guido recognizes that we’re all just trying to do our best.

Where the BDFL role is most important is in those holistic decisions about 
global features, such as PEP 572.  These things impact everyone and every 
corner of Python, so having a final arbiter(s) that is accepted by the 
community at large is critical.  I’ve long said that if I had to choose a 
single person to fill that role, it would be Brett.  He has the right mix of 
technical and social chops to make thoughtful, intelligent, compassionate 
decisions, and he has the advantage of being likely more than a decade away 
from Guido in hopeful retirement plans, unlike perhaps that FLUFL guy. :)

That said, I think a triumvirate would work (Guido’s Unworthy Inherited 
Delegation Organization).  Mostly, that group would identify and work with 
Delegates to make the final decisions on such PEPs, and most importantly, 
confidently back them up, even if those decisions are unpopular.

For PEP 572-level language decisions, the group would be the final arbiters, so 
it would have to be an odd number.  I agree with Brett that voting and rotation 
could be problematic due to the tyranny of the majority.  Imagine that PEP 572 
were put in front of this group, and after all the kerfuffle, the same decision 
were made.  Put yourself in that place when you think about the governance of 
Python-the-language over the next 25 years.  I personally value stability and 
certainty over popularity for such features.  PEP 572 won’t destroy Python, and 
I predict most of us will appreciate it being there once in a while.

There’s no rush to decide, and this would make for a fine discussion at the 
core sprint in September.

Cheers,
-Barry





signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] A different way to focus discussions

[Barry Warsaw]

On May 22, 2018, at 12:44, Guido van Rossum  wrote:
> 
> Hm, what's the cost of those extra repos? As long as they have consistent 
> names (e.g. pep-1234) they're easy to ignore right? Or does GitHub have a 
> quota of repos per org?

I think there is a quota for non-paying organizations, but I’m not sure.  I was 
just thinking about clutter on https://github.com/python but maybe it won’t be 
so bad with…

> I was thinking of a workflow where the pep author initially creates the repo 
> under their own username and directs discussion there. Then when their PEP is 
> accepted (or rejected!) they can donate their repo to the python org. I know 
> such a thing is possible (we did it for the mypy and typeshed repos).

… +1!

> Ironically for me GitHub is less linear than email. It's easier to ask people 
> to open a new issue than it is to ask them to start a new thread. So e.g. if 
> a discussion starts about a survey of feature X in various languages, when it 
> veers off into a tutorial for a specific language that could be a separate 
> issue, and the meta-discussion on how the list of languages should be 
> selected could be made another issue.

I see what you’re saying.  Yes, that could work if the PEP author is really 
diligent about shunting detours into new issues.  I’ve just found that within 
PRs or issues, the linearity can be quite difficult to follow.  (FWIW, IMHO, 
GitLab does better here, but that’s besides the point.)

> I think Mark Shannon volunteered PEP 576 (though so far he hasn't created a 
> separate repo, he's just created a PR for the peps repo IIUC). I hope Nick 
> will also volunteer PEP 577 for this.

+1

-Barry


signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] A different way to focus discussions

[Barry Warsaw]

[I think my other response got dropped, so apologies for any duplicates]

Guido van Rossum wrote:
> I wonder if it would make sense to require that for each PEP a new GitHub
> *repo* be created whose contents would just be a draft PEP and whose issue
> tracker and PR manager would be used to debate the PEP and propose specific
> changes.

I don't think I'd want to see tons of new PEP repos under the current `python` 
organization.  Maybe we should create a new organization for this experiment?

Also, since non-core devs can and do create PEPs, the permission management 
will be different than the normal repos.  Clearly the PEP authors should be 
owners of the individual repos, but they should probably also decide how merges 
happen, and who else can contribute to their repo.

It also means that PEP editors probably have an additional responsibility to 
create the PEP repo.

PEP 1's Discussions-To header can probably be co-opted for the URL to the GH 
repo.  Right now, that field is described as an email address, but it would be 
appropriate IMHO to also allow a URL for discussions.

> Thoughts? (We can dogfood this proposal too, if there's interest. :-)

I don't know whether this will help focus rambling PEP discussions.  I 
personally don't love the linearity of GH comments.  Threading is useful!

OTOH, it seems like a low-cost experiment to try so if there's a volunteer who 
wants to be the guinea pig, I'm fine with it.

-Barry


signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Comments on moving issues to GitHub

[Barry Warsaw]

On May 20, 2018, at 10:19, Nathaniel Smith  wrote:
> 
> IIRC, the general reaction was that it was definitely worth exploring, but 
> that it would be a lot of work and require solutions to a lot of problems to 
> make sure people's workflows weren't too impacted, so we'd need a much more 
> detailed proposal before any decision could be made.

Note too that Bryan Clark from GitHub, who I believe is a product manager 
there, was at the packaging mini-summit.  If/when we have a specific set of 
asks for the migration, we can reach out to him and see how they can help.  For 
example, I specifically asked about my favorite GitLab feature “commit when CI 
passes” and it sounded like they were working on that.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Proposing Petr Viktorin as a specialist core developer

[Barry Warsaw]

On Apr 13, 2018, at 05:13, Nick Coghlan  wrote:
> 
> I'd like to propose Petr Viktorin as a specialist core developer,
> focusing on extension module imports.

+1

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] cherry picking, miss islington, and generated files

[Barry Warsaw]

On Feb 6, 2018, at 15:30, Mariatta Wijaya  wrote:

> So, maybe we trust the CI a little bit more now when it comes to checking if 
> regenerated files are needed :)

Great, thanks for checking Mariatta!  It definitely gives me more confidence 
that if the bot and CI pass, the merge will be good.  If it comes up again, 
I’ll run that experiment for real. :)

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] cherry picking, miss islington, and generated files

[Barry Warsaw]

On Feb 5, 2018, at 09:09, Nick Coghlan  wrote:
> 
> Heh, I think I have a plausible theory as to what happened:
> 
> The 3.7 and 3.8 compilers are currently still identical, and this was
> the first post-branch change to importlib (as far as I know), so:
> 
> 1. The patch applied cleanly (because the previously frozen versions
> were the same)
> 2. The regen check passed (because the regenerated version was the same)

Agreed.  I just wasn’t *positive* I could trust a clean merge and passing 
tests.  Maybe we can though.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] cherry picking, miss islington, and generated files

[Barry Warsaw]

On Feb 3, 2018, at 23:16, Mariatta Wijaya  wrote:
> 
> I found the related thread in core mentorship mailing list:
> https://mail.python.org/mm3/archives/list/core-mentors...@python.org/thread/CNK7EWWZTDIRID7MTWLTWXU4H7IH3UIE/

FYI, core-mentorship’s archives can’t be read without a subscription.

> Guido and Victor answered, I guess I got distracted with other things and 
> forgot to do any sort of follow up :P
> 
> If I understand it right, they both suggested running "make regen-all" at 
> each backport.
> But you seem to indicate that you rather do that manually?

Not necessarily.  I think the only option right now is to run it manually, but 
if the bot can do that automatically (and probably add a comment that it’s done 
so), that would be great.

> For the first pass, I think it can detect that when a changeset includes 
> importlib.h, we'll make miss-islington leave a comment about needing to 
> regenerate files.

+1

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] cherry picking, miss islington, and generated files

[Barry Warsaw]

On Feb 2, 2018, at 20:40, Mariatta Wijaya  wrote:
> 
> Sure, I sort of asked this in the past: what are the generated files, how to 
> identify them, is there a pattern?

I’m not sure there’s going to be a pattern so much as a list of such files.

> I need to dig up that thread and find out if anyone answered. It's been a 
> while :)

Cool, thanks!  I definitely missed the discussion the first time around.

> Usually there would be conflict in backport though. It was suggested that 
> cherry-picker can regenerate the files and resolve the conflict.
> Your suggestion of having miss Islington comment on the PR sounds good too.

In my case, there was no conflict, although I actually thought there might have 
been one.  But I was still uncomfortable not manually regenerating those files 
anyway.  The 3.6 auto-merge did have conflicts because the commit touched a 
file that doesn’t exist in 3.6, but cherry_picker worked beautifully so it 
wasn’t difficult to resolve.

I don’t think this is a common situation, since importlib is a bit more of an 
esoteric part of the stdlib, and cherry picking fixes in it is probably even 
more rare.  At least it’s something to be aware of, and anybody who changes 
importlib will already know they have to do something special (i.e. regenerate 
the files).

Thanks for your great work on these tools Mariatta!

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] cherry picking, miss islington, and generated files

[Barry Warsaw]

I’m in the process of back porting a change which touches importlib and 
requires regeneration of Python/importlib.h and Python/importlib_external.h.

The original fix on master:
https://github.com/python/cpython/pull/5481

Miss Islington’s back port to 3.7:
https://github.com/python/cpython/pull/5498

Miss Islington was not able to auto-pick this into 3.6, which makes sense.

I got a little concerned though that the back port touches those two generated 
files, and didn’t feel comfortable just pushing the Big Green Button.  I 
chatted with Brett and he also agreed that the merge should probably be done 
manually.  So for the 3.7 merge, I actually followed the GitHub CLI merge 
instructions, regenerated the .h files, pushed the branch, and opened a new PR:

https://github.com/python/cpython/pull/5503/files

Once CI passed, I hit the BGB and the merge occurred as normal.

For the 3.6 fix, I used cherry_pick, resolved the conflicts manually, regen’d 
the header files, pushed the branch, and submitted a new PR:

https://github.com/python/cpython/pull/5504

This one’s still running CI, but if it passes, I’ll merge it.

I wanted to mention this because maybe Miss Islington should flag, warn, or 
otherwise indicate when autogenerated files are being merged?  Are there any 
other files other than the importlib .h files that we should take extra care 
with?

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] I created the "needs backport to 3.7" label on GitHub

[Barry Warsaw]

On Jan 31, 2018, at 18:58, Mariatta Wijaya  wrote:
> 
> I'm not sure. Maybe the release managers know? There is PEP 101..

I’ll bet Ned is either updating PEP 101 as he goes, or is keeping notes to 
update that PEP once things calm down.  It’s a rare enough event, and this is 
the first time with git, so I’m sure there was a fair bit to figure out.

$ git worktree add ../3.7 3.7  # ftw!

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Welcome the 3.8 and 3.9 Release Manager - Łukasz Langa!

[Barry Warsaw]

On Jan 27, 2018, at 17:04, Guido van Rossum > wrote:
> 
> Hardly a surprising choice! Congrats, Łukasz. (And never forget that at every 
> Mac OS X upgrade I have to install the extended keyboard just so I can type 
> that darn Ł. :-)

Heh, I *just* learned that, at least on macOS High Sierra (and probably going 
back several releases), on a US keyboard you can press and hold the ‘L’ (cap-L) 
key.  A little popup will appear like the attached image (if this doesn’t get 
stripped by Mailman).  Hit ‘1’ and the slashy-L will get entered: Ł.

Cheers
-Barry


signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Welcome the 3.8 and 3.9 Release Manager - Łukasz Langa!

[Barry Warsaw]

As Ned just announced, Python 3.7 is very soon to enter beta 1 and thus feature 
freeze.  I think we can all give Ned a huge round of applause for his amazing 
work as Release Manager for Python 3.6 and 3.7.  Let’s also give him all the 
support he needs to make 3.7 the best version yet.

As is tradition, Python release managers serve for two consecutive releases, 
and so with the 3.7 release branch about to be made, it’s time to announce our 
release manager for Python 3.8 and 3.9.

By unanimous and enthusiastic consent from the Python Secret Underground (PSU, 
which emphatically does not exist), the Python Cabal of Former and Current 
Release Managers, Cardinal Ximénez, and of course the BDFL, please welcome your 
next release manager…

Łukasz Langa!

And also, happy 24th anniversary to Guido’s Python 1.0.0 announcement[1].  It’s 
been a fun and incredible ride, and I firmly believe that Python’s best days 
are ahead of us.

Enjoy,
-Barry

[1] 
https://groups.google.com/forum/?hl=en#!original/comp.lang.misc/_QUzdEGFwCo/KIFdu0-Dv7sJ



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Let's give commit privileges to Nathaniel J. Smith

[Barry Warsaw]

On Jan 24, 2018, at 18:23, Yury Selivanov  wrote:
> 
> I want to propose granting commit privileges to Nathaniel J. Smith.

Wait, he’s not already?!  +1 of course.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Security: please enable 2-factor authentication on GitHub and your email

[Barry Warsaw]

On Jan 6, 2018, at 14:00, Alex Gaynor  wrote:
> 
> Hey Antoine,
> 
> Assuming you're on Firefox57, it requires a pref -- once the WebAuthn spec is 
> finalized we'll drop the pref -- 
> https://mobile.twitter.com/jamespugjones/status/91231495223226

Oh wow, this is exciting!  I’ve been annoyed by the lack of support for my 
Yubikey in FF57, but I just enabled these and quick check by logging into GH 
seems to show that it works, at least for some sites.  Thanks for the link.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Official python-dev docker images

[Barry Warsaw]

On Dec 7, 2017, at 19:00, Christian Heimes  wrote:
> 
> Why is there 'Docker' in the name? Is the container image restricted to
> Docker runtime or can I use it with lxc, systemd-nspawn, rkt, or any
> other container runtime, too?

I honestly don’t know, and I’ve only used it with Docker, but there is the Open 
Container Initiative to promote standards, so maybe it can.

https://www.opencontainers.org/about

> There are likely legal issues with the name, too. After all 'Docker' is
> a registered trademark of Docker, Inc [1]. I'd be careful and call it
> 'Python.Org Official Multiversion Development Supercalifragilistic
> Container Image' instead.

Yeah, that’s a good suggestion.  Well, maybe without the Potential Poppins 
Infringement.

(And yes, I’m going to follow up on python-dev now.)

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Mentoring Julien Palard (core), Cheryl Sabella (bug) and Sanyam Khurana (bug)

[Barry Warsaw]

On Dec 9, 2017, at 20:41, Nick Coghlan  wrote:
> 
> +1 - "Who am I to have this power?" is a pretty common reaction to
> community promotions, so erring on the side of "I trust your
> judgement, so you should trust your judgement" is a good way to go.
> 
> But at the same time, we should make it clear that "Help me better
> calibrate my judgement" is an entirely appropriate use case for the
> core-mentorship list (and we keep those archives closed so they're not
> available to search engines).

Very well said, Nick.  It’s useful to remind new contributors that very few 
things are irreversible, and that there are lots of outlets for asking 
questions.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Official python-dev docker images

[Barry Warsaw]

On Dec 7, 2017, at 19:34, Christian Heimes  wrote:
> 
> Shiny! You'll get extra bonus points for not running as root. :)

Don’t forget, there’s a bug tracker you can submit requests to. 

> I'm curious, what is the reason of compiling CPython yourself? Ubuntu
> has the deadsnakes project. Fedora has packages for Python 3.3, 3.4, and
> 3.5.

I really want clean builds of upstream tarball releases.  Debian/Ubuntu for 
sure, and I would bet Fedora too, has downstream deltas applied, so if 
something fails there, how do you know it’s because of your package or 
something the distro added?  Note that we do install the build dependencies for 
the Pythons so they’ll link against platform libraries and such.

> Could I convince you to put some builds of OpenSSL and LibreSSL into the
> container, too?

You can totally file an issue so we can discuss it. :)

https://gitlab.com/python-devs/ci-images/issues

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Official python-dev docker images

[Barry Warsaw]

[Continuing to CC Abhilash, who is not on this list. -B]
> On Dec 7, 2017, at 14:36, R. David Murray <rdmur...@bitdance.com> wrote:
> 
> On Thu, 07 Dec 2017 13:00:31 -0500, Barry Warsaw <ba...@python.org> wrote:
>> Brett and I want to promote this more widely within the Python
>> community as the “official Python Docker image” that projects can use
>> in their own testing environments, or base their own images on it.  We
>> wanted to give you guys a heads up first to get your feedback, and
>> maybe thoughts on the best places to promote this, e.g. on the
>> python.org website or other places.
> 
> Well, the place to get a python Docker image listed would be
> https://hub.docker.com/_/python/.  That's the first google hit for python
> docker, and it already has a host of images available.  How does yours
> differ from those?  It sounds like it is by having multiple versions
> and tox so you can test your library/ap against multiple Python
> versions using a single container.  That does sound useful :)

There are several differences.  Probably the two biggest are that 1) the ones 
on docker hub are not maintained by *us* but instead by “the Docker Community”; 
2) AFAICT, the ones on docker hub aren’t development focused images, so they 
only have one single version of Python installed.  For any Python-based project 
that wants to e.g. run CI against multiple versions of Python, that isn’t 
helpful (and hence why we built this one).  Our image is bigger, but more 
generally useful to library and application developers, rather than say, 
application deployment users.

> But, be careful with names.  "official Python Docker image" sounds like
> what one would use when one wants to *run* a python application in a docker
> container, which is what the images that are currently listed on the
> page mentioned above seem directed at.

That’s good feedback!  I want to be clear about the purpose of this image, both 
in that it’s blessed and maintained by us, and that its focus is on the Python 
library and application developer (primarily for testing purposes).

So maybe: Python.Org Official Multiversion Development Docker Image Doubleplus 
Good!

:)

Seriously, audience and naming are important to get right.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Official python-dev docker images

[Barry Warsaw]

On Dec 7, 2017, at 13:00, Barry Warsaw <ba...@python.org> wrote:

> He’s an amazing amount of work to improve the quality of this image!

Um, let me rephrase :)

He’s done an amazing amount of work to improve the quality of this image!

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Official python-dev docker images

[Barry Warsaw]

As part of the importlib_resources skunkworks project Brett and I have been 
working on (just announced), we’ve also put together a nice Docker image that 
we’re using for our automated testing.  This image is based on Ubuntu 16.04 and 
provides the latest stable releases of Python 2.7, and 3.4-3.6, along with a 
mostly up-to-date git checkout of master, currently Python 3.7 of course.  Once 
3.7 is released to beta, we intend to track its release tarballs too.

We also install a few other commonly needed tools, like pip, git, unzip, wget, 
mypy, and tox.

Here’s the project repo:

https://gitlab.com/python-devs/ci-images

Huge shout out to Abhilash Raj who helped us clean up and compactify the image, 
and also for setting up automated publishing to quay.io.  In case you weren’t 
aware, Abhilash is who I passed GNU Mailman project leadership to, so he has a 
lot of Python experience, and a ton of expertise in the image space.  He’s an 
amazing amount of work to improve the quality of this image!

Brett and I want to promote this more widely within the Python community as the 
“official Python Docker image” that projects can use in their own testing 
environments, or base their own images on it.  We wanted to give you guys a 
heads up first to get your feedback, and maybe thoughts on the best places to 
promote this, e.g. on the python.org website or other places.

We welcome your participation too of course!  I’m happy to give write access to 
the project to any Python committer who wants to help.

Cheers,
-Barry, Brett, Abhilash



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Statistics: growth of core dev number vs growth of the code size/complexity

[Barry Warsaw]

On Dec 6, 2017, at 18:17, Victor Stinner  wrote:

> I wrote a quick & dirty parser to compute statistics on *new* CPython
> core developer per year using the following page as data:
> https://devguide.python.org/developers/
> 
> 2007: 15
> 2008: 19
> 2009: 11
> 2010: 20
> 2011: 12
> 2012: 9
> 2013: 4
> 2014: 10
> 2015: 2
> 2016: 5
> 2017: 2

Thanks for the analysis.  Let’s do everything we can to get some of these newer 
core devs to the Language Summit in 2018!

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] python-devs/python project on GitLab

[Barry Warsaw]

Back when we were deciding between GitHub and GitLab, we created this project:

https://gitlab.com/python-devs/python

Unless anyone objects, we’re going to delete this project.  We have no need for 
this now that CPython development is on GitHub.

(No, we’re not getting rid of the group, just the project.)

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Should I merge a PR that I approved if it was written by a different core developer?

[Barry Warsaw]

On Sep 20, 2017, at 20:54, Nick Coghlan  wrote:
> 
> On 21 September 2017 at 07:27, Victor Stinner  
> wrote:
>> Hi,
>> 
>> Before the GitHub era, in the old "Mercurial era", the unwritten rule
>> was to not merge a patch written by a developer who has the commit
>> bit, to not "steal" his/her work. The old workflow (patches attached
>> to the bug tracker) didn't allow to easily keep the author. You had to
>> find the author email and full name and specify it manually.
> 
> I'll typically still just leave an "Approve" review rather than
> merging directly, unless it's a PR for an issue I filed, or I'm
> working on a separate change that would end up conflicting with their
> PR if I left theirs open.

In general, I like the unwritten rule.  There’s something very satisfying about 
finally hitting the merge button, and as Nick points out, you may want to do 
some final tweaks.  I’ll usually just leave the Approve review too, and let the 
submitter/committer do the final merge.

That said, there are times when it’s useful to do the merge for them.  If it 
was my PR, I might leave a note in the PR asking for a merge if I know I won’t 
get to it soon (maybe I’m going on vacation), or if as Nick says, it needs to 
get merged soon so as to avoid conflicts or blocking other people’s progress.  
I’d still like it to mostly come from the original submitter.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Travis CI: macOS is now blocking -- remove macOS from Travis CI?

[Barry Warsaw]

On Sep 19, 2017, at 19:33, Alex Gaynor  wrote:
> 
> If you find a macOS CI platform with more capacity, please let me know :-)
> 
> Travis has been totally underwater of late, but I don't know of any 
> alternatives; probably because operating a fleet of macOS builders is a giant 
> pain. You need Apple hardware, and it turns out you can either purchase a 
> trashcan or a mac mini, and neither of those is really designed for a server 
> farm.
> 
> If anyone here can magically whisper in Tim Cook's ear, can you ask him to 
> license macOS to AWS or Google Cloud or something?

Brett will love my musings: one could imagine a fleet of hackintoshes talking 
to a flexible CI runner infrastructure as is available on some alternative 
hosting platforms.  Not that I, ahem, know anything about that.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Travis CI: macOS is now blocking -- remove macOS from Travis CI?

[Barry Warsaw]

On Sep 19, 2017, at 15:32, Victor Stinner  wrote:
> 
> The macOS job has been removed from Travis CI at the beginnig of the
> CPython sprint two weeks ago. Since the macOS build was removed, I'm
> less annoyed by Travis CI: it seems more stable.
> 
> Are you ok to not add again the macOS job to Travis CI?
> 
> Again, my rationale is that we already have 3 macOS buildbots and I'm
> looking closely at all buildbot failures. I try to keep track of *all*
> failures, even random failure. A recent macOS example:
> https://bugs.python.org/issue31510
> 
> Sadly, remaining random failures are the most rare and most difficult
> to reproduce. (I fixed a lot of them last months.)

If the macOS tests aren’t stable, then yes, removing them is better than 
frustrating developers who can’t reproduce CI failures, even on the CI machines 
let alone their own development boxes.

I forget though, was it a problem with macOS CI stability or general 
throughput?  I thought they just couldn’t keep up with the workload, in which 
case it seems like we should be able to throw more resources at it, right?

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Py_UNREACHABLE

[Barry Warsaw]

On Sep 15, 2017, at 12:36, Victor Stinner  wrote:
> 
> The good news is that other C macros are now documented as well!
> 
> https://docs.python.org/dev/c-api/intro.html#useful-macros
> 
> If you look at Include/pymacro.h there are even more crazy macros
> which are not documented yet, like Py_BUILD_ASSERT().
> 
> I like Py_ARRAY_LENGTH() which gives the length of an array and not
> its size in bytes. The macro is nice because it fails with a
> compilation error if the argument is not an array! For example, it
> fails on "char *not_an_array" or "char not_an_array_neither[];".

PRs anyone? :)

-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Py_UNREACHABLE

[Barry Warsaw]

I landed bpo-31338 / PR #3374 which adds a Py_UNREACHABLE() macro to master, 
along with some additional documentation in the C API describing this and a few 
other common macros.  If you’re writing or reviewing C changes that include 
unreachable code paths, please use this macro for consistency, instead of other 
approaches like assert() (which can be compiled out) and `return NULL`, etc.

As part of the PR, I changed a bunch of existing instances in the code:

https://github.com/python/cpython/pull/3374/files

If you find any cases I’ve missed, feel free to submit a PR and I will happily 
review it.  I think this makes our code more consistent and ultimately safer.

(Thanks Victor for the PR review!)

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/