Re: [python-committers] Github reviews are cannibalizing BPO

On 02.05.2017 00:32, Christian Heimes wrote: > This brings me to my questions > > 1) Should we try to move discussion back to BPO or are we fine with > having major decisions just in Github PRs? We've had that discussion before: discussions always should happen on BPO, not Github PRs. PRs are jus

Re: [python-committers] Github reviews are cannibalizing BPO

On 02.05.2017 04:25, Nick Coghlan wrote: > On 2 May 2017 at 08:32, Christian Heimes wrote: >> This brings me to my questions >> >> 1) Should we try to move discussion back to BPO or are we fine with >> having major decisions just in Github PRs? >> >> 2) How can we retain enough information on BPO

Re: [python-committers] Github reviews are cannibalizing BPO

On 02.05.2017 20:44, Donald Stufft wrote: > > I suspect part of it may simply be that mucking around with b.p.o is far less > streamlined then GitHub issues or PRs. One thing we might want to look at is > making it possible to login with GitHub to b.p.o, as that is one possible > hurdle for som

Re: [python-committers] Github reviews are cannibalizing BPO

ut the ones which have a few more comments do mostly deal with code reviews. On 03.05.2017 10:06, Nick Coghlan wrote: > On 3 May 2017 at 05:09, M.-A. Lemburg wrote: >> This doesn't have much to do with UX/UI. It's mainly a questions >> of culture. > > It'

Re: [python-committers] Proposal for procedures regarding CoC actions

Since this is a matter outside the realm of committers, the PSF board will have to ultimately decide on any actions taken. The committers can report issues to the board and provide information useful for their decisions, the bad actor also has to be given a chance to respond to allegations and be

Re: [python-committers] Proposing Carol Willing to become a core developer

On 23.05.2017 20:15, Brett Cannon wrote: > While at the PyCon US sprints the idea came up of offering Carol Willing > developer privileges. Everyone at the table -- about 6 of us -- liked the > idea and Carol also said she would happy to become a core dev, so I'm > officially putting her forward fo

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

I'm with David on this one. 2FA is good for admin accounts, but doesn't add much protection for regular committers. Think of what you're trying to protect against: git checkins are all audited and can easily be undone. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from t

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

+1 On 25.01.2018 01:00, Victor Stinner wrote: > +1 > > Impressive list of contributions! > > Victor > > 2018-01-25 0:23 GMT+01:00 Yury Selivanov : >> Hi, >> >> I want to propose granting commit privileges to Nathaniel J. Smith. >> He's interested in the idea of becoming a core developer, and gi

Re: [python-committers] Save the date: Core developer sprints

On 18.03.2018 03:16, Larry Hastings wrote: > > > On 03/07/2018 09:25 PM, Steve Dower wrote: >> So far, I have locked in dates and a building. Assuming no disasters, >> we will have Microsoft Building 20 >>

Re: [python-committers] Save the date: Core developer sprints

u can join for the > first few days. You won’t force someone else to miss out completely, > we'll have room. > >   > > Top-posted from my Windows phone > >   > > *From: *M.-A. Lemburg <mailto:[email protected]> > *Sent: *Sunday, March 18, 2018 5:50 &g

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

+1 On 14.04.2018 03:40, Eric Snow wrote: > +1 > > -eric > > On Fri, Apr 13, 2018 at 4:56 PM, Raymond Hettinger > wrote: >> >> >>> On Apr 13, 2018, at 5:13 AM, Nick Coghlan wrote: >>> >>> I'd like to propose Petr Viktorin as a specialist core developer, >>> focusing on extension module imports.

Re: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions?

-1 in the current form, since an expression such as [y := f(x), x/y] ... is confusing (I'd read this as [y := (f(x), x/y)] Using explicit parens around it would resolve this issue: [(y := f(x)), x/y] ... but even with that, I'm not excited about the additional line noise this adds - th

Re: [python-committers] Marking issues as "Release Blocker" priority (was Re: FINAL WEEK FOR 3.7.0 CHANGES!)

In terms of process, it's always good to have a method to escalate a question to higher management in a way which doesn't require the manager to first parse long text messages. So a status such as "Potential Release Blocker" or "RM Review" sounds like a good way forward. Of course a friendly ping

[python-committers] Comments on moving issues to GitHub

Reading the comments in the thread and having used Github issues myself for a few years now, I find the idea of moving from a dedicated issue tracker we can easily customize to our needs (or hire someone to do so via the PSF) to a simplistic tracker add-on, which Github issues is, not a very promis

Re: [python-committers] Changing commiter status (was: Missing In Action)

Victor: please make sure that you contact the developers whos status you intend to modify prior to doing so. Being a core developer of Python is a status and not something that should be changed without consent by the developer in question. Also note that the dev list log doesn't include all core

Re: [python-committers] Changing commiter status

th. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/ > On Mon, Jun 18, 2018 at 11:59 AM Brett Cannon wrote: > >> >> >> On Mon, 18 Jun 2018 at 06

Re: [python-committers] Changing commiter status

On 19.06.2018 18:39, Brett Cannon wrote: > On Mon, 18 Jun 2018 at 12:41 M.-A. Lemburg wrote: > >> On 18.06.2018 21:07, Guido van Rossum wrote: >>> Hm, unless I misunderstood, MAL's >>> >>>> Being a core developer of Python is a status >>

Re: [python-committers] An alternative governance model

I find this discussion really interesting from a social perspective. Let's keep it going for a while without jumping to any conclusions. It's too early to head down into one particular rabbit hole yet ;-) There's no rush and if things crystallize only in a year's time, that's perfectly fine. (And

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

Thanks for your action plan, Mariatta, but I'm -1 on having strict timelines for these processes. We need to gradually approach a new model as we've done in the past decades and not push for any possibly borked model right from the start. The processes for this need to stay flexible, easy to adapt

[python-committers] List of all core developers

It's become fairly obvious that we are missing a list of core developers on some site. One we can use as reference and one which core devs can also show to other to prove they are core developers. I guess the natural place for such a list is the dev guide, but we could also use a page on www.pytho

Re: [python-committers] List of all core developers

clude core developers of other Python implementations in such a document, in separate sections, e.g. for Jython, IronPython, PyPy, Stackless, etc. > Mariatta > > > On Wed, Aug 1, 2018 at 2:15 PM M.-A. Lemburg wrote: > >> It's become fairly obvious that we are missi

Re: [python-committers] List of all core developers

On 02.08.2018 03:24, Eric V. Smith wrote: > On 8/1/2018 8:32 PM, Mariatta Wijaya wrote: >>     I think it would also be a good idea to include core developers >>     of other Python implementations in such a document, in >>     separate sections, e.g. for Jython, IronPython, PyPy, >>     Stackless,

Re: [python-committers] List of all core developers

On 02.08.2018 23:07, Brett Cannon wrote: > On Wed, 1 Aug 2018 at 14:44 M.-A. Lemburg wrote: > >> On 01.08.2018 23:28, Mariatta Wijaya wrote: >>> See also an open issue to revamp the Developer log: >>> https://github.com/python/devguide/issues/390 >>>

Re: [python-committers] List of all core developers

On 02.08.2018 23:16, Brett Cannon wrote: > On Thu, 2 Aug 2018 at 00:32 M.-A. Lemburg wrote: > >> On 02.08.2018 03:24, Eric V. Smith wrote: >>> On 8/1/2018 8:32 PM, Mariatta Wijaya wrote: >>>> I think it would also be a good idea to include core de

Re: [python-committers] List of all core developers

nition of it > being a lifetime title), then the subscription list for this mailing list > is probably good enough with some manual grooming as long we are okay with > long-dormant folk who predate this list not voting (which I'm personally > fine with). But if we wanted a w

Re: [python-committers] CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause)

On 21.09.2018 14:59, Paul Moore wrote: > Balance, forgiveness, and a mature level of empathy are what's > *really* needed ("among the things that are needed...":-)). Not > policies. Policies should be weapons of last resort. Agreed. I guess we'll also have to learn that flamebait as we had it in

Re: [python-committers] Council / board (Was: 1 week to Oct 1)

On 25.09.2018 16:28, Mariatta Wijaya wrote: > My proposal is taking into consideration The PSF's mission and diversity > statement. I will not remove the diversity clause from PEP 8011. I cannot comment on what you actually have in PEP 8011 as diversity clause, since the page is just a placeholder

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

Could the authors of those PEPs please at least publish a rough outline of what their model is all about ? It doesn't help if we set a deadline only to find that we should have written up a competing PEP shortly before the deadline passes. The only text we have at this point is PEP 8013: https://

Re: [python-committers] [PEP 8013] The External Council Governance Model

Thanks, Steve, for writing this up: https://www.python.org/dev/peps/pep-8013/ A couple of comments: I like the council model, but don't understand why the core developers should be stripped from any decision powers. External people will not have the institutional knowledge core developers have,

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

On 29.09.2018 03:21, Barry Warsaw wrote: > 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 py

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

On 29.09.2018 11:40, Łukasz Langa wrote: > >> On Sep 29, 2018, at 09:53, Nick Coghlan wrote: >> >> Especially on the eve of critical governance discussions that will heavily >> impact the future of python-dev. > > Ironically it's the very gravity of those upcoming discussions that made us > de

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

o discuss.python.org and to python-committers... And now we > can enjoy discussions splitted between the two :-) > > Victor > Le sam. 29 sept. 2018 à 09:50, M.-A. Lemburg a écrit : >> >> On 29.09.2018 03:21, Barry Warsaw wrote: >>> On Sep 28, 2018, at 15:03, Victo

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

On 09.10.2018 05:33, Ronald Oussoren wrote: > > >> On 9 Oct 2018, at 03:29, M.-A. Lemburg wrote: >> >> FYI: I did sign up on Discourse and have enabled email notifications, >> but it seems that you have to do this on a per forum entry basis, >> since I hav

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

which won’t set them to watching, but will email you for *only* > the first post in any new topic, unless you set a topic to watching after > that. Thanks, I'll give that a try. >> On Oct 8, 2018, at 9:29 PM, M.-A. Lemburg wrote: >> >> FYI: I did sign up on Disco

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

I find it rather unusual that we are pushed to vote on PEPs which will just have been finished in writing tonight. Shouldn't people who were not involved in the individual creation processes at least get two weeks to review the final work to make up their mind before entering a voting period ? It

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

On 15.11.2018 19:55, Brett Cannon wrote: > > It seems like we're completely skipping the review phase of the > regular PEP process and going straight from PEP writing to > a vote: > > https://www.python.org/dev/peps/pep-0001/#id38 > > which is odd given the importance of this

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

On 15.11.2018 19:39, Barry Warsaw wrote: > 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 g

[python-committers] Fwd: EPS: Announcing the Guido van Rossum Core Developer Grant

FYI... perhaps you now understand why I was keen to get the committers listed somewhere :-) Forwarded Message Subject: EPS: Announcing the Guido van Rossum Core Developer Grant Date: Thu, 31 Jan 2019 10:25:52 +0100 From: M.-A. Lemburg Organization: EuroPython Society (EPS) To

Re: [python-committers] Fwd: EPS: Announcing the Guido van Rossum Core Developer Grant

Happy to see that you like the idea. Our hope is that more conferences will pick it up as well. On 31.01.2019 18:41, Raymond Hettinger wrote: > > >> On Jan 31, 2019, at 2:15 AM, M.-A. Lemburg wrote: >> >> To help with growing the team, putting it more into the spot

[python-committers] Learning from PostgreSQL community: How to address the review bottleneck

I've attended FOSDEM over the weekend, where Jon Conway (one of the PostgreSQL committers) gave a talk about, among other things, the PG community and how it is structured: https://fosdem.org/2019/schedule/event/postgresql11/ (the community part starts at around 8 min into the video) What struck

Re: [python-committers] Vote to promote Stéphane Wirtel as a core dev

+1 (not exactly sure how the vote would work, so at this point just an indication of support) On 22.03.2019 16:40, Victor Stinner wrote: > Oh. I forgot to mention that I offer to mentor Stéphane once he would > become a core dev for 1 month for help him to deal with his new > responsibilities. I w

Re: [python-committers] Votes on new core dev candidates

I must say, I'm a bit surprised by the discussion around the voting process and the candidates. First, we've been complaining about lack of core devs for a long time. Now we have two great candidates with proven track record of contributing to Python and people complain again. As a small group, we

Re: [python-committers] Votes on new core dev candidates

On 25.03.2019 16:20, Steve Dower wrote: > On 25Mar2019 0217, M.-A. Lemburg wrote: >> I must say, I'm a bit surprised by the discussion around the voting >> process and the candidates. >> >> First, we've been complaining about lack of core devs for a long >

Re: [python-committers] Votes on new core dev candidates

On 25.03.2019 23:58, Steve Dower wrote: > On 25Mar2019 1503, M.-A. Lemburg wrote: >> On 25.03.2019 16:20, Steve Dower wrote: >>> To be clear, my pushback (on Discourse, since I can only send email from >>> an actual laptop these days but can participate over there

Re: [python-committers] Vote to promote Stéphane Wirtel as a core dev

On 26.03.2019 05:20, Raymond Hettinger wrote: > >> On Mar 22, 2019, at 8:34 AM, Victor Stinner wrote: >> >> Julien Palard and me (Victor) propose to promote Stéphane Wirtel as >> core developer. We open a vote until March 31 (~one week). "[A >> promotion] is granted by receiving at least two-thir

Re: [python-committers] Votes on new core dev candidates

On 26.03.2019 18:54, Antoine Pitrou wrote: > > Le 26/03/2019 à 09:58, M.-A. Lemburg a écrit : >> >>>> Asking people who have voted -1 or +1 to publicly tell the world why >>>> they did so is not helpful in this respect, since it just creates bias. >>

Re: [python-committers] [Python-Dev] Farewell, Python 3.4

Thank you for having been 3.4 release manager, Larry ! On 08.05.2019 17:36, Larry Hastings wrote: > > It's with a note of sadness that I announce the final retirement of > Python 3.4.  The final release was back in March, but I didn't get > around to actually closing and deleting the 3.4 branch u

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

I think Mark and Abhilash would be the perfect choice to (help) maintain the email package. They have done a great job on making sure Mailman works for us and know from real world experience what the issues are you face nowadays with email (such as having to deal with the wonderful technology call

[python-committers] Re: proposed canonical list of Python core team members

Note that details about commits predating opening up the repository for external commits which happened sometime in 2000 IIRC are not necessarily correct. Before opening up the repo, patches were submitted to the repo via the team around Guido. This Misc/ACKS file was used in those times to give c

[python-committers] Re: PEP 13 and approval voting.

Hi Thomas, to get more votes, it may help to start a new thread specifically for voting and prefixing the subject with "ACTION NEEDED: Please vote - ". We're using this approach in several PSF WGs and it's working better than voting emails deep inside discussion threads. Cheers, -- Marc-Andre L

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

I had been waiting for the ballot email, but have not received any. I then checked the voters list and came across this section in the readme: """ According to PEP 13, active membership is defined as "any non-trivial contribution in two years". As such, the coredev active command will create a pi

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

On 10.12.2019 23:57, Nick Coghlan wrote: > On Wed, 11 Dec 2019 at 06:52, M.-A. Lemburg wrote: >> The conversion to an inactive dev is something that core devs need >> to be asked to agree to, and thus needs to be managed as a status >> flag, not depend on commits to the repo

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

On 11.12.2019 00:58, Brett Cannon wrote: > We discussed the situation on the steering council and we are fine with > making an exception for folks who felt caught off-guard asking Ernest to be > added to the voter roll even though voting has already started. Thanks. > In the new year I will wor

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

On 11.12.2019 20:19, Brett Cannon wrote: > As for the "please email everyone personally", I just don't have the time to > email 30 people that Giampolo listed or the 89 total people who could vote > but didn't commit or author something in the past two years . But do note > that me lacking the t

[python-committers] Re: Language Summit

Thanks for sending those references. On 4/16/2020 2:04 PM, Pablo Galindo Salgado wrote: > Here are the slides for our talk about the new PEG parser: > > https://docs.google.com/presentation/d/1N_GaMjrLt1HUicbSwqC6QWGB751qj2RqtEqo_lGI0js/edit?usp=drivesdk > > Pablo > > On Thu, 16 Apr 2020, 12:44

[python-committers] Guido van Rossum Core Developer Grant & EuroPython

Dear follow core developers, I would like to invite you to attend this year's EuroPython conference: https://ep2020.europython.eu/ The conference will be held online from July 23-26 and we took special care to add slots which can easily be followed from pretty all around the world. The first tw

[python-committers] Re: MSDN Subscription renewals

On 13.08.2020 21:18, Nathaniel Smith wrote: > On Thu, Aug 13, 2020 at 11:04 AM Zachary Ware wrote: >> >> On Thu, Aug 13, 2020 at 12:29 PM Steve Dower wrote: >>> While most of the tooling necessary for working on CPython is freely >>> available (as Visual Studio Community), this will also include

[python-committers] Re: Farewell, Python 3.5

Thank you, Larry and the whole release team, for putting so much work into this ! On 01.10.2020 19:49, Larry Hastings wrote: > > At last!  Python 3.5 has now officially reached its end-of-life.  Since there > have been no checkins or PRs since I tagged 3.5.10, 3.5.10 will stand as the > final rel

[python-committers] Re: Resignation from Stefan Krah

On 08.10.2020 00:26, Ethan Furman wrote: > On 10/7/20 2:47 PM, Antoine Pitrou wrote: > >> Apparently, Stefan Krah (core developer and author of the C _decimal >> module) was silently banned or moderated from posting to python.org >> mailing-lists. > > This seems odd -- does the Steering Council c

[python-committers] Re: Performance benchmarks for 3.9

Hi Pablo, thanks for pointing this out. Would it be possible to get the data for older runs back, so that it's easier to find the changes which caused the slowdown ? Going to the timeline, it seems that the system only has data for Oct 14 (today): https://speed.python.org/timeline/#/?exe=12&ben

[python-committers] Re: Performance benchmarks for 3.9

gt; automated and it didn't run in a long time :( Make sense. Would it be possible rerun the tests with the current setup for say the last 1000 revisions or perhaps a subset of these (e.g. every 10th revision) to try to binary search for the revision which introduced the change ? >

[python-committers] Re: Performance benchmarks for 3.9

On 14.10.2020 17:59, Antoine Pitrou wrote: > > Le 14/10/2020 à 17:25, M.-A. Lemburg a écrit : >> >> Well, there's a trend here: >> >> [...] >> >> Those two benchmarks were somewhat faster in Py3.7 and got slower in 3.8 >> and then again in 3.

[python-committers] Re: Performance benchmarks for 3.9

On 14.10.2020 16:14, Antoine Pitrou wrote: > Le 14/10/2020 à 15:16, Pablo Galindo Salgado a écrit : >> Hi! >> >> I have updated the branch benchmarks in the pyperformance server and now >> they include 3.9. There are >> some benchmarks that are faster but on the other hand some benchmarks >> are su

[python-committers] Re: Performance benchmarks for 3.9

On 15.10.2020 15:50, Victor Stinner wrote: > Le mer. 14 oct. 2020 à 17:59, Antoine Pitrou a écrit : >> unpack-sequence is a micro-benchmark. (...) > > I suggest removing it. > > I removed other similar micro-benchmarks from pyperformance in the > past, since they can easily be misunderstood and

[python-committers] Re: Making it easier to track who is currently considered "active" for voting

FYI: There's a ticket open to address the remaining missing parts of the process that is defined in PEP 13 vs. the what the voting script implements: https://github.com/python/voters/issues/16 I've implemented some extra logic to enable tracking the inactivity status as per PER 13 and creating a

[python-committers] Python Core Developer Status Inquiry

FYI: I have sent out the Python Code Developer status inquiries to these core developers, which have not committed to the CPython Github repo in the last two years and for which we don't have a status answer using the new inactivity reply feature in the voter roll script yet: Alex Martelli

[python-committers] Re: Python Core Developer Status Inquiry

On 11.11.2020 22:04, Guido van Rossum wrote: > I wonder what Marc-André Lemburg is going to respond... :-) I already did :-) People who replied with "stay active" will receive an email as well and the list below is proof that it works as indented ;-) > On Wed, Nov 11, 2020

[python-committers] Re: Python Core Developer Status Inquiry

Meador Inge PJ Eby Philip Jenvey Sjoerd Mullender Steven D'Aprano Thomas Heller Trent Nelson who have not replied yet. The deadline is Nov 25 AoE, when I'll merge the PR with the updates: https://github.com/python/voters/pull/30 Thanks. On 11.11.2020

[python-committers] Re: Python Core Developer Status Inquiry

ed, Nov 18, 2020 at 7:44 AM M.-A. Lemburg <mailto:[email protected]>> wrote: > > I've sent a reminder to these core devs: > >      Alexandre Vassalotti >      Amaury Forgeot d'Arc >      Armin Ronacher >      David Wolever >    

[python-committers] Re: Python Core Developer Status Inquiry

On 18.11.2020 16:52, Paul Moore wrote: > I'm pretty sure I saw an email from Steven D'Aprano on this list recently. Yes, this was a mistake on my part. I forgot to merge master into my branch before running the script. Sorry. > On Wed, 18 Nov 2020 at 15:44, M.-A. Lemburg wrote:

[python-committers] Re: Python Core Developer Status Inquiry

https://www.egenix.com/company/contact/ https://www.malemburg.com/ On 18.11.2020 16:44, M.-A. Lemburg wrote: > I've sent a reminder to these core devs: > > Alexandre Vassalotti > Amaury Forgeot d'Arc > Armin Ronacher >

[python-committers] Re: Publish better than md5sums of Python builds?

On 17.03.2021 18:53, Benjamin Peterson wrote: > > > On Wed, Mar 17, 2021, at 09:29, Victor Stinner wrote: >> On Tue, Mar 16, 2021 at 9:16 PM Gregory P. Smith wrote: >>> The benefit of listing the sha256 for files is that it prevents this >>> question coming up again and again because md5 is old

[python-committers] Re: CI tests are broken

On 31.03.2021 15:54, Ethan Furman wrote: > Because I could not find any error in the documentation that would cause the > problem (the first three cases succeeded, using the same construct). > >> Why is that even allowed? > > Because the tests are not perfect. > > I did post a message to python-

[python-committers] Re: CI tests are broken

On 31.03.2021 16:29, Ethan Furman wrote: > On 3/31/21 6:59 AM, M.-A. Lemburg wrote: > >> It seems that some of the doc tests are missing imports of >> e.g. Flag from enum. > > My understanding of doctest is that the global execution environment is > cumulative.  For

[python-committers] Re: PEP 563 and Python 3.10.

On 21.04.2021 12:16, Thomas Wouters wrote: > The idea that we should warn before significant changes to behaviour -- > documented behaviour, like function annotations being evaluated at definition > time, or behaviour commonly depended on, like 'with' being allowed as an > identifier because it was

[python-committers] Re: PEP 563 and Python 3.10.

On 21.04.2021 13:14, Paul Moore wrote: > On Wed, 21 Apr 2021 at 12:05, M.-A. Lemburg wrote: > >> Perhaps we should reconsider making deprecation warnings only >> visible by explicitly enabling them and instead make them visible >> by default. >> >> This would

[python-committers] Re: PEP 563 and Python 3.10.

On 21.04.2021 13:35, Paul Moore wrote: > On Wed, 21 Apr 2021 at 12:24, M.-A. Lemburg wrote: >> >> Isn't that an educational problem ? Adjusting reporting of >> warnings isn't all that hard: >> >> https://docs.python.org/3/library/warnings.html#th

[python-committers] Re: Consider adding a Tier 3 to tiered platform support

On 09.04.2022 02:13, Brett Cannon wrote: On Fri, Apr 8, 2022 at 5:03 AM Marc-Andre Lemburg > wrote: On 06.04.2022 20:48, Brett Cannon wrote: > Last chance on whether my tier 3 proposal make sense! I will take silence as > acceptance and plan to conver

Re: [python-committers] PQM?

On 2008-08-14 10:37, Brett Cannon wrote: On Wed, Aug 13, 2008 at 11:54 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: [SNIP] Anyway, if we're going to change policies around submitting code, I would much rather see peer review become a habit than adopt a tool like PQM. The part where I'm skep

Re: [python-committers] 3.0rc2 schedule

On 2008-10-02 19:08, Fred Drake wrote: > On Oct 2, 2008, at 9:39 AM, Nick Coghlan wrote: >> If you don't make a habit of borking your own filesystems with dodgy >> filenames, it runs fine. > > I really hope the individuals making this argument are being facetious. > I don't think this is the sour

Re: [python-committers] [snakebite] I've got a surprise for you!

On 2009-01-27 21:01, Trent Nelson wrote: > I've just set up a mailing list for those that want to carry on with > discussions; this CC list is getting a bit unwieldy. Subscription > URL: http://groups.google.com/group/snakebite-list. E-mail address > is snakebite-l...@googlegroups

Re: [python-committers] Survey about DVCSs compared to svn

On 2009-02-25 23:31, Brett Cannon wrote: > To see if people actually want to switch off of svn to a DVCS, I have put > together a survey for everyone to state for each DVCS if they think it is > better, worse, or equal to svn (and an option to not say anything if you > have no experience with the D

Re: [python-committers] Survey about DVCSs compared to svn

Slightly corrected :-) On 2009-02-26 00:14, M.-A. Lemburg wrote: > There's an option missing in that survey: > > [ ] I don't see a need to switch to a DVCS at all. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 26 20

Re: [python-committers] Survey about DVCSs compared to svn

On 2009-02-26 00:35, Mark Hammond wrote: >> There's an option missing in that survey: >> >> [ ] I don't see a need to switch to a DVCS at all. > > To be fair, the survey isn't asking about a switch, just how they compare > against svn. > > But I must admin that seems a little strange; while I jus

Re: [python-committers] Survey about DVCSs compared to svn

On 2009-02-26 00:46, Brett Cannon wrote: > On Wed, Feb 25, 2009 at 15:35, Mark Hammond wrote: > >>> There's an option missing in that survey: >>> >>> [ ] I see a need to switch to a DVCS at all. >> To be fair, the survey isn't asking about a switch, just how they compare >> against svn. >> >> But

Re: [python-committers] Survey about DVCSs compared to svn

, Barry Warsaw wrote: > On Feb 26, 2009, at 6:03 AM, M.-A. Lemburg wrote: > >> Looking at the PEP 374, the DVCSes don't appear to make life easier for >> common repo tasks (they each require more or less the same number of >> commands), so the argument for using a DVCS is mor

Re: [python-committers] Survey about DVCSs compared to svn

On 2009-02-26 15:50, Antoine Pitrou wrote: > Hi, > > I'm no trying to advocate switching to a DVCS, but really: > >> I think that's a much better approach and one that reduces the >> load on the python.org repo sys-admins. > > How does having 4 more-or-less supported VCSes, rather than 1, lighte

Re: [python-committers] Survey about DVCSs compared to svn

On 2009-02-26 16:36, Antoine Pitrou wrote: > Le jeudi 26 février 2009 à 16:10 +0100, M.-A. Lemburg a écrit : >> I didn't know that and was under the impression that those other >> systems simply hook up to the svn repo via the standard Subversion >> interfaces. > &

Re: [python-committers] Survey about DVCSs compared to svn

On 2009-02-27 20:56, Georg Brandl wrote: > M.-A. Lemburg schrieb: > >> IMHO, those are all feel-good factors which can easily be had by >> installing a local Subversion repo copy (sync'ed using svnsync (*)), >> except perhaps regarding merging - but I don't know

Re: [python-committers] Doug Hellmann

Jesse Noller wrote: > I would like to propose we give the commit bit to Doug Hellmann in > order for him to help out with documentation and GHOP style tasks > (he's helped in the past). > > You might know him from the "Python Module of the Week" series here: > > http://www.doughellmann.com/PyMOTW

Re: [python-committers] [Python-Dev] On track for Python 2.6.4 final this Sunday?

Barry Warsaw wrote: > Are we on track to release 2.6.4 final this Sunday or do we need another > rc? > > Yesterday, Tarek committed another setuptools related fix and said that > he was going to run a bunch of build tests locally. Tarek, how did that > go? > > Please note that issue 7064 is stil

Re: [python-committers] [Python-Dev] On track for Python 2.6.4 final this Sunday?

"Martin v. Löwis" wrote: > >> It would be nice to get this issue resolved out for 2.6.4: >> >> http://bugs.python.org/issue4120 >> >> The problem is that extensions built with 2.6.x will not work >> when used with a User-only installation of Python on machines that >> don't already have the MS VC9

Re: [python-committers] [Python-Dev] On track for Python 2.6.4 final this Sunday?

"Martin v. Löwis" wrote: > >>> As this bug already exists in 2.6.2, I don't think the change is >>> eligible for 2.6.4. >>> >>> In addition, I want to review it, which I won't be able to until >>> Sunday. >> >> Then I'd suggest to wait another week with 2.6.4 to give you a >> chance to look at the

Re: [python-committers] [Python-Dev] On track for Python 2.6.4 final this Sunday?

Barry Warsaw wrote: > On Oct 13, 2009, at 11:01 AM, M.-A. Lemburg wrote: > >> Then I'd suggest to wait another week with 2.6.4 to give you a >> chance to look at the patch. > > That's not a good option, IMO. We have a known broken 2.6.3 out there > and

Re: [python-committers] [Python-Dev] On track for Python 2.6.4 final this Sunday?

Barry Warsaw wrote: > On Oct 13, 2009, at 1:07 PM, M.-A. Lemburg wrote: > >> Would it be reasonable to shorten that period, if the fix for the >> mentioned problem gets ready for prime time earlier ? > > I think there are many 2.6.x bugs queued up for after 2.6.4 is >

Re: [python-committers] SSH keys and Keychain

Vinay Sajip wrote: > Jesus Cea jcea.es> writes: > >> >> I would use "ssh-agent" directly, via "ssh-add". It is what I do. >> > > Hi Jesus, > > Thanks for the response. I've tried that, with no luck. The key is added to > ssh-agent, which I verified using "ssh-add -l" - but I still get prompted

Re: [python-committers] Delaying 3.2 release

"Martin v. Löwis" wrote: >> I'm delaying the 3.2 alpha1 release by one week; I don't have enough time >> to sort through all the possible issues and get acquainted with the release >> machinery this weekend. > > Should we perhaps delay the entire schedule by one month? A number of > things that pe

Re: [python-committers] changes after 2.7 final

Benjamin Peterson wrote: > After I tag 2.7 this Saturday, I will effect the following changes in > the repository: > - I will make the 2.7 maintenance branch. > - I will remove svnmerge from trunk -> py3k. > - I will initialize svnmerge from py3k -> 2.7maint. > - The trunk will be officially closed

Re: [python-committers] changes after 2.7 final

M.-A. Lemburg wrote: > Benjamin Peterson wrote: >> After I tag 2.7 this Saturday, I will effect the following changes in >> the repository: >> - I will make the 2.7 maintenance branch. >> - I will remove svnmerge from trunk -> py3k. >> - I will initialize svnm

Re: [python-committers] Eric Araujo (merwok) as Distutils commiter

Tarek Ziadé wrote: > On Tue, Jul 27, 2010 at 11:54 AM, Antoine Pitrou wrote: >> Le mardi 27 juillet 2010 à 01:50 +0200, Tarek Ziadé a écrit : >>> Hello, >>> >>> I don't want to maintain Distutils anymore for various reasons. I >>> will focus for now on on Distutils2, shutil and sysconfig. >>> >>>

  1   2   >