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

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

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

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

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

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-committers] Re: Deprecation policy reminder

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

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

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:

[python-committers] Re: status of smtpd

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

[python-committers] Re: Pattern Matching

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

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

gt; 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

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

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 problem

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

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

[python-committers] Re: Resignation from Stefan Krah

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, E

[python-committers] Re: Resignation from Stefan Krah

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

[python-committers] Thank you Larry Hastings!

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

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

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

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

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

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

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

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

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

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

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

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

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

[python-committers] Re: Language Summit

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[python-committers] Promote Abhilash Raj to core developer

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

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

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-committers] PEP 581 (Using GitHub issues for CPython) is accepted

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

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

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

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

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:

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

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.

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

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

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

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

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

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 thre

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

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

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

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

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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! :)

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

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

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

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

Re: [python-committers] An alternative governance model

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

Re: [python-committers] Language moratorium

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

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

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

Re: [python-committers] An alternative governance model

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

Re: [python-committers] Language moratorium

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

Re: [python-committers] An alternative governance model

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

Re: [python-committers] An alternative governance model

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

Re: [python-committers] An alternative governance model

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

Re: [python-committers] An alternative governance model

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

Re: [python-committers] An alternative governance model

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

Re: [python-committers] An alternative governance model

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

Re: [python-committers] An alternative governance model

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,

Re: [python-committers] An alternative governance model

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

[python-committers] An alternative governance model

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

Re: [python-committers] Transfer of power

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

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

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

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

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

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

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

Re: [python-committers] Transfer of power

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

Re: [python-committers] Transfer of power

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

Re: [python-committers] Transfer of power

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

Re: [python-committers] Transfer of power

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

Re: [python-committers] Transfer of power

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

Re: [python-committers] Transfer of power

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 >

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

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

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

[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

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

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

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

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 ___

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

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

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

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

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

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

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

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

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

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:

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

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

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

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*

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

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

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

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

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

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

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

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

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

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,

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

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

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

[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 wit

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

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: Messa

[python-committers] Official python-dev docker images

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

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

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 >

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

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

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

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

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

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

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

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

Re: [python-committers] Py_UNREACHABLE

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

[python-committers] Py_UNREACHABLE

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,

  1   2   3   >