[python-committers] Re: Python 3.11.0a4 is blocked

[Eric Snow]

On Wed, Jan 5, 2022 at 7:04 AM Petr Viktorin  wrote:
> IMO, there should be a PEP for wide-reaching changes like bpo-40521, and
> the PEP should be actually *approved* before such changes are made.

FWIW, I plan on posting a PEP by the end of the week regarding
per-interpreter GIL and the related work.

> In bpo-46006 itself, there are two proposed PRs, each corresponding to a
> slightly different vision of how subinterpreters should be isolated.  I
> don't know which is right. If we had a PEP, I could read it and decide,
> but I can't -- the people driving this effort have different ideas of
> the big picture.

Victor's goal is the same as mine.  The only difference here is the
steps involved.  (In this case, the interned strings were made
per-interpreter prematurely.)  I'm clarifying this in that PEP.

-eroc
___
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/VGOAFPWNOJRTZBX6YH2D4WRKY2CIH22B/
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] PyCon US 2013 attendees

[Eric Snow]

On Mon, Feb 25, 2013 at 12:46 PM, R. David Murray  wrote:
> I'll be there the whole time (summit through the end of the sprints).

Same here.

-eric
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Commit privileges for Roger Serwy for IDLE

[Eric Snow]

Welcome!

-eric
On Mar 21, 2013 9:39 PM, "serwy"  wrote:

> Hi Everyone,
>
> My name is Roger Serwy and I would like to introduce myself. I am a
> graduate student at the University of Illinois in electrical and computer
> engineering. Python has been a primary language for my research in signal
> processing and the auditory system. I use IdleX almost daily for
> prototyping algorithms and data analysis.
>
> I do look forward to working with you to to improve IDLE.
>
> Thank you,
> Roger
> __**_
> python-committers mailing list
> python-committers@python.org
> http://mail.python.org/**mailman/listinfo/python-**committers
>
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] what's going on with Misc/NEWS?

[Eric Snow]

On Fri, May 24, 2013 at 9:46 PM, Raymond Hettinger
 wrote:
> and it recognizes that users don't really need to look across merge
> boundaries.

This is tricky though for any patch that is forward-ported to a
release branch (a la 3.2->3.3).  How can you tell from MISC/News in
which release (e.g. 3.3.0 or 3.3.1) of that branch the bug was fixed?
The entry would only show up in MISC/News for the previous release
(e.g. 3.2.3).

Granted, this would impact much fewer patches than our current pain point does.

-eric
___
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] "Gratuitous"? incompatibilities in the "fix only" releases

[Eric Snow]

On Jul 29, 2015 11:08 AM, "Robert Collins" 
wrote:
>
> On 30 July 2015 at 04:50, Guido van Rossum  wrote:
> > The more recent Python 2.7 bugfix releases have
> > specific exemptions from the backwards compatibility requirements for
> > security fixes -- because their lifespan will still be many years (EOL
of
> > 2.7 is summer 2020).
> [snip]
> https://docs.python.org/devguide/devcycle.html#security-branches
> "...The only changes made to a security branch are those fixing issues
> exploitable by attackers such as crashes, privilege escalation and,
> optionally, other issues such as denial of service attacks. Any other
> changes are not considered a security risk and thus not backported to
> a security branch."
>
> This page doesn't specify the exception for 2.7, and by my poor
> reading of it the http issue wouldn't pass muster - but I think it was
> appropriate to apply. So I'm confused. Help :).

See PEP 466.

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

-eric
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Call For Participants For The 2016 Python Language Summit

[Eric Snow]

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

Thanks for chairing this again!

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

:(

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

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

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

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

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

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

Re: [python-committers] Redoing the C API? (was: Call For Participants For The 2016 Python Language Summit)

[Eric Snow]

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

+1

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

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

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

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

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

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

[Eric Snow]

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

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

-eric
___
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] Welcoming Davin Potts to the Python development team

[Eric Snow]

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

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

-eric
___
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: GitHub migration is scheduled for today

[Eric Snow]

On Fri, Feb 10, 2017 at 9:00 AM, Tim Golden  wrote:
> Good luck, and thanks to you and the team for all the hard work

A big +1!

-eric
___
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] New Roundup notifications on Git commits?

[Eric Snow]

On Mon, Feb 13, 2017 at 11:16 AM, Brett Cannon  wrote:
> if the webhook event for your merge
> got rejected due to the bad cert then it would have been dropped.

A repo admin should be able to manually request that a failed webhook
be retried.  The webhook's page on GH has a list of all associated
events, including failed attempts.

-eric
___
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 Carol Willing to become a core developer

[Eric Snow]

+1

On Tue, May 23, 2017 at 11:15 AM, 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 for consideration.
>
> For those of you who don't know Carol, she basically knows our developer
> workflow better than most of us. :) ; she's very active on the devguide and
> core-mentorship. Carol has also attended the PyCon US language summit two
> years in a row as a representative for the Jupyter project. She is actually
> so good with new people that she managed to get my wife to make her first
> open source contribution (something I never managed to do).
>
> As usual, if you support/object to this idea, please say so. :)
>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Eric Snow]

On Thu, May 25, 2017 at 4:16 AM, Victor Stinner
 wrote:
> Welcome Carol!

A giant +1 from me!  And a huge thank-you for how much you've already
been doing!  You are an excellent example of what makes this community
great.

-eric
___
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] Cheryl Sabella was promoted to get bug triage permission

[Eric Snow]

On Wed, Dec 6, 2017 at 10:43 AM, Victor Stinner
 wrote:
> To recognize the good contributions of Cheryl Sabella, I gave her the
> bug triage permission on bugs.python.org. (In practice, Ezio gave her
> the permission.)
>
> In the past, such "promotion" wasn't always advertized on
> python-committers, but my intent is to make our process more
> transparent and award people who deserve it!

+1

> IMHO bug triage is the first step/milestone to become a core developer
> in the long term.

+1

> FYI She pushed not less than 14 commits into the master branch since
> August, 2017.

Nice!

> Congrats Cheryl!

A hearty +1!  Keep up the good work, Cheryl.

-eric
___
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!

[Eric Snow]

On Sat, Jan 27, 2018 at 2:02 PM, Barry Warsaw  wrote:
> please welcome your next release manager…
>
> Łukasz Langa!

Congrats, Łukasz!  (or condolences? )

-eric
___
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] [core-workflow] Adding "Co-authored-by" in commit message.

[Eric Snow]

On Mon, Jan 29, 2018 at 4:32 PM, Mariatta Wijaya
 wrote:
> I suggest we start adding this where it makes sense, to give proper credit
> to PR authors.

+1

Thanks for noticing this.  I've bumped into this several times and
look forward to (more clearly) giving credit where credit is due.

-eric
___
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

[Eric Snow]

+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.
>
> +1 This is an area that could use more attention from someone who really 
> cares about it.
>
>
> Raymond
>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
___
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] Welcoming Petr Viktorin as our newest core developer :)

[Eric Snow]

Welcome, Petr!

-eric

On Mon, Apr 23, 2018, 08:39 Nick Coghlan  wrote:

> Hi folks,
>
> With my recent proposal to accept Petr Viktorin as a specialist core
> developer focusing on extension module imports receiving several +1's
> and no concerns being raised, I'm happy to report that Brett has now
> granted Petr his additional access on GitHub, the issue tracker, and
> this mailing list.
>
> Welcome, Petr! :)
>
> Cheers,
> Nick.
>
> P.S. When adjusting the nosy list on the issue tracker, you'll find
> there's also a new "extension modules" topic, which can be selected to
> subscribe both Petr and I to the issue :)
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
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] Poll: Do you like the PEP 572 Assignment Expressions?

[Eric Snow]

On Wed, May 2, 2018 at 3:49 AM, Victor Stinner  wrote:
> The poll is on the *current* PEP. I propose 4 choices:
>
> * +1: you like the PEP
> * -1: you dislike the PEP
> * 0: you are not sure if you like it or not, or you have no opinon
> * don't reply to this poll :-)
>
> Just reply to this email with "+1", "0", "-1". Please don't elaborate
> here, it's just a quick poll, use python-dev if you want to talk :-)

-1

...and thanks for specifically asking for no elaboration.  I was tempted. :)

-eric
___
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] Poll: Do you like the PEP 572 Assignment Expressions?

[Eric Snow]

On Wed, May 2, 2018 at 3:49 AM, Victor Stinner  wrote:
> I propose a poll because I'm unable to track the opinion of each core
> dev, too many emails have been sent to python-dev, and maybe some
> people changed their mind during the long discussion (which started in
> February) :-)

FWIW, contrary to the many -1 responses, I don't think the actual
sentiment is all torches-and-pitchforks. :)  There are a variety of
well-reasoned opinions that mostly result in "meh" and "I don't like
the idea of it but don't know how it will actually work out" (or maybe
I'm just projecting myself onto everyone else).  This is the point
where I have a lot of respect for Guido's uncanny intuition as
reflected in Python's history.

-eric
___
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] My opinion about "binding expressions" (was Poll: Do you like the PEP 572 Assignment Expressions?)

[Eric Snow]

On Wed, May 2, 2018 at 3:49 AM, Victor Stinner  wrote:
> I propose a poll because I'm unable to track the opinion of each core
> dev, too many emails have been sent to python-dev, and maybe some
> people changed their mind during the long discussion (which started in
> February) :-)

Victor said "Please don't elaborate here" so I've opened yet another*
thread for this topic. :)  My apologies to all for that.  However, I
didn't feel like the poll captured my opinion well.  In the interest
of not adding too much more noise to the discussion on this specific
topic, I'll provide a (relatively) brief opinion here and then bow
out.  (I don't feel like I have anything else to contribute on the
subject.)  If you feel similarly, feel free to do likewise (e.g. be
concise).  Please don't engage in discussion here.  There are plenty
of other threads for that.  If no one else registers their opinion
here that's fine with me too. :)

As to my actual opinion, ultimately I don't think "binding
expressions" are such a big deal either way.  I doubt abuse will be as
common or frustrating as that of list comprehensions and ternary
expressions; but either way code review will mitigate that risk (and I
doubt binding expressions will be a major distraction there).  Anyway,
I'll probably use them occasionally if we get them.

-eric

* Yeah, it's like when someone says "the problem is there are too many
file formats" so they write their own to render the rest irrelevant...

___
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 Mark Shannon to be a core developer

[Eric Snow]

+1

-eric

On Mon, May 14, 2018 at 4:41 PM, Larry Hastings  wrote:
>
>
> Dr. Mark Shannon contributed the "key sharing dictionary" to Python, writing
> both the PEP and the implementation.  This shipped in Python 3.3 and was
> listed as one of the top features of that release as according to the
> "What's New?" document.
>
> We've asked Mark in the past if he'd be interested in becoming a core
> developer--and he actually said no.  At the time he said he didn't like our
> antiquated workflow.  Now that we've switched to the git-based core dev
> workflow, this objection is gone, and he's now interested in accepting the
> commit bit and the responsibilities that it entails.
>
> I suspect you, my colleagues in CPython core development, will be surprised
> at the current state of affairs.  I'm expecting a load of "you mean Mark
> *isn't* a core developer yet?" replies.
>
>
> Submitted for your consideration,
>
>
> /arry
>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Vote to promote Pablo Salingo Salgado as core developer

[Eric Snow]

On Wed, Jun 13, 2018 at 10:16 AM Victor Stinner  wrote:
> I propose to promote Pablo Salingo Salgado as a core developer and so
> open a vote during one week. If there is no strong opposition, I will
> promote him but also continue to mentor him for a least one month.
>
> [snip]
>
> I am mentoring Pablo Salingo Salgado since January. I am watching his
> hard work since last September. He made many non trivial and useful
> contributions to Python.
>
> I think that he understands well how Python is developed, is
> respectful, try to find answers alone before asking, and is eager to
> learn. In case of doubt, he ask others before doing something, like
> closing an issue. I trust that Pablo will respect opinions of others,
> like not merging a PR if someone disagree.
>
> [snip]
>
> If Pablo is promoted as a core developer, I propose to continue to be
> his mentor for at least one month, and ask him before merging any PR.

+1

I have had no negative (or any) experiences with Pablo and otherwise
trust Victor's judgement and mentoring.

Regarding if Pablo has done "enough", ultimately folks get commit
privileges at the point that they show they will be a benefit to
Python development and we trust them enough to merge PRs.  Any other
criteria feels rather secondary, considering the variety of ways a
core developer can contribute.  We don't need to aim for exclusivity.
(It's not like we have a limit on the number of people that can have
commit privileges.)  In this case we have a respected core developer
(Victor) expressing his trust, suggesting that Python will benefit via
Pablo, and offering to mentor him.  Unless someone says they do not
trust Pablo, I don't see any reason here to object.

That said, I agree that core developers in particular should be active
on the issue tracker and reviewing PRs, and it makes sense to reward
folks you show a commitment to helping there.  I just don't think that
is necessarily a major criteria for becoming a core developer,
especially when someone like Victor vouches for the candidate.
Sometimes I wonder if we scare off otherwise amazing folks because
they think we expect a significant sacrifice of time or we
inadvertently make them feel like they aren't good enough.  It's easy
for us to mess this up! :/

-eric
___
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] How to Increase Triage and Code Review Activity? (was: Vote to promote Pablo Salingo Salgado as core developer)

[Eric Snow]

On Thu, Jun 14, 2018 at 8:06 PM Nathaniel Smith  wrote:
> On Thu, Jun 14, 2018 at 4:40 AM, Berker Peksağ  
> wrote:
> > This isn't about my or someone else's high standards. We keep saying
> > we need more triagers and reviewers, and we keep promoting people who
> > didn't do any issue triaging and code review. It's not fair to
> > contributors who have spent so much time working on these areas.

Just to be clear, Berker, I really appreciate the time folks
(including you) put into the more thankless (and often tedious) tasks
like bug triage and code review (and triaging buildbot failures).  I
for one need to spend more of my open-source time on that.  No one
should ever feel like they have to do more than their fair share.

> Surely the solution is to promote more people who do those things, not
> to turn away people making other contributions? We need more
> contributors of all kinds.

I agree completely.  However, Berker's concern is a real (and honest)
one, regardless of its bearing on accepting new core developers.  It
also reflects a real, continuing problem: a shortage of folks doing
bug triage/curation and code review.  Unfortunately, this has a chain
reaction effect by discouraging people from pursuing more involvement
in core development.  For instance, if someone creates a PR but it
sits there for a year they eventually give up.  On the other hand,
sometimes aspiring core contributors question the value of giving a PR
a review if a core committer is going to review it themself before
possibly merging.  (I realize there are good reasons for any code
review, but that is the reaction I've gotten from people on occasion.)

The consequent question is how to get more people resolving open
tracker issues and giving PR reviews?  Off-hand, I'm not sure. :/
We've discussed this before and it's probably time to discuss it
again.  Any ideas?

-eric
___
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

[Eric Snow]

On Thu, Jul 12, 2018 at 10:55 AM Yury Selivanov  wrote:
>
> Thank you, Guido.  This is a sad day for me personally; I really hoped
> you'd lead Python for a few more years.  On the other hand, Python is
> in good hands, you've built a large enough and diverse community
> around it!

+1

Thank you for putting so much time, effort, and care into both the
language and its community!  We cannot thank you enough.

> As for the new governing model, I imagine that we don't need to make
> any decisions *right now*.  As Victor suggested, core devs can simply
> count +1/-1 on any language feature and we'll see how it goes.  Or
> maybe the first such vote should be on the new governing model? :)  I
> really hope that we won't have an excruciating debate on the mailing
> list about the governing model though; maybe we can discuss it on the
> upcoming core dev sprint.

In the short term we could appoint a *temporary* triumvirate to fill
in as BDFL (with the intent to re-assess the situation in September if
we haven't resolved on a permanent solution by then).  That would
allow us to maintain business-as-usual (and try out a triumvirate).
If we go that route then I'd recommend Brett, Nick, and Barry.

-eric
___
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

[Eric Snow]

On Thu, Jul 12, 2018 at 11:55 AM Brett Cannon  wrote:
> One other idea if we go the BDFL or triumvirate route is we could ask Guido 
> to choose (if he's willing). I think Guido's key point is he wants us to 
> choose how we want to keep this team going, but that may not preclude us to 
> essentially naming him BDFL-delegate in this instance. :)

+1

-eric
___
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

[Eric Snow]

On Thu, Jul 12, 2018 at 1:29 PM Brett Cannon  wrote:
> On Thu, 12 Jul 2018 at 10:42 Eric Snow  wrote:
>> In the short term we could appoint a *temporary* triumvirate to fill
>> in as BDFL (with the intent to re-assess the situation in September if
>> we haven't resolved on a permanent solution by then).  That would
>> allow us to maintain business-as-usual (and try out a triumvirate).
>> If we go that route then I'd recommend Brett, Nick, and Barry.
>
> I don't think we need a temporary solution while we digest this and figure 
> out how we want to manage ourselves. Short of some horrible CoC catastrophe 
> we can just hold off on making any final decisions on PEPs until a decision 
> is made in how we want to handle PEPs going forward since Python 3.8 isn't 
> hitting beta until May 2019 (and even if it was close we don't need to ever 
> rush anything into a release as there's always the next release :) .

Agreed.  I was hasty in posting that and don't foresee any issues
where a temporary BDFL would matter. :)

-eric
___
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

[Eric Snow]

On Tue, Jul 17, 2018 at 8:15 PM Eric V. Smith  wrote:
> On 7/17/2018 10:02 PM, Barry Warsaw wrote:
> > 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.
>
> I've come to this same conclusion. I think Brett would be a good choice,
> and I'd support him, but I think the more important part is that it be a
> single person.

+1

IMHO, if we can have someone we can trust then a BDFL is the best
option.  Brett definitely fits that criteria for me. (Plus Canadians
are "Benevolent" by definition, right?)  Barry's proposal to have the
council supporting (and guarding against) the BDFL gives the proposal
better stability in the face of the unknown future.

-eric
___
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

[Eric Snow]

On Wed, Jul 18, 2018 at 2:43 AM Antoine Pitrou  wrote:
> Le 18/07/2018 à 04:02, Barry Warsaw a écrit :
> > 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.
>
> 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?
>
> 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.

tl;dr  We worry too much :)

While I do not feel quite the same way on your point, Antoine, I'm
glad you brought this up.  A blanket policy of monarchy would be a
serious problem at the point that a BDFL goes "rogue".  However, a
blanket opposition to monarchy leads to its own problems.  Relative to
the BDFL's power, context is significant here.

There is apparently a lot of support (mine included) for Barry's
proposal.  However, we might be blinded, now and in general, to the
possibility of a rogue BDFL by the availability of good candidates
(that "clearly" would not go rogue) in the present and struggle to
imagine a time that there isn't such a candidate or that we were wrong
about them.  In fact, IIUC some reputable core devs do not feel like
there's any such candidate now (no disrespect, Brett), based on what
they expect a BDFL to be.  We need to respect that and consider that
viewpoint.  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?

Before diving in to that, consider that change has a directly
proportional relationship with disruption.  Disruption to any
organization has a pretty high cost, so the effect should be carefully
considered before deciding to make changes (which is what we're doing,
hopefully).  In our case, figuring out how to proceed
post-Guido-as-BDFL, we should make sure there's a good reason to
change our "governance model".  [Really quick: python-dev is rather
ad-hoc as an org, so calling it a "governance model" is a bit
misleading.]  We've been operating (successfully) for decades with a
BDFL.  As others have indicated, Python greatly owes its success to
having a BDFL.  Assuming we find a suitable replacement (I think we
can), why otherwise disrupt things?  "this is our chance to change so
we should" is an extremely weak argument on its own (and a dangerous
one), as is "monarchs are always bad".  There needs to be a stronger
reason (one that applies concretely to us).  Otherwise, at the least
"status quo wins a stalemate" here.  Arguably the best course of
action would be to change as little as possible.

All that said, I strongly affirm that we should not dismiss concerns
and differing opinions.  We need to consider them and be respectful.
We must resist the temptation to say "let's be real, that isn't
something we need to worry about".  That's why I'm glad you said what
you did, Antoine.  It made me think about a few aspects of the status
quo that may be worth addressing sooner rather than later.  Along
those lines, I consider the following questions to be significant.
I'll address them a little, but not conclusively.

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?

In my mind the key question is #3 (see my comments below).

--

1. what makes a good BDFL?

This is already being discussed in other threads, e.g. about the
"roles" of the BDFL.  I'll add that the BDFL is someone we trust to
lead Python into the future, even when it's hard and even when we
strongly disagree with them.  As a core team we rely on the BDFL to
help us make hard technical decisions.

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.

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

3. what negative impact can a BDFL have?

I was primarily thinking about a "ro

Re: [python-committers] An alternative governance model

[Eric Snow]

On Wed, Jul 18, 2018 at 10:36 AM Łukasz Langa  wrote:
> A simple majority vote is wildly insufficient for this case. Python is a 
> large project with many contributors and alienating maybe tens of them is not 
> acceptable, especially if we are talking about a "for life" choice.

+1

-eric
___
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

[Eric Snow]

On Wed, Jul 18, 2018 at 10:44 AM Steve Dower  wrote:
> Your contributions to this part of the discussion are also very useful -
> we need to know what concerns people have, and often those concerns may
> not have occurred to those of us who approach it with a more idealistic
> idea of how everything will work out.

This is a critical point, especially as we are without a BDFL to rely
on for this discussion and decision. :)  We need all the viewpoints,
mutual respect, and patience.

-eric
___
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] List of all core developers

[Eric Snow]

On Wed, Aug 1, 2018 at 3:44 PM 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
> >
> > Someone has also said that they're working on tracking down the dormant
> > core devs, but now I can't find that email.
>
> I think the log is fine at it is, since it serves a different
> purpose.
>
> The list should be in addition to the log, not replacing it.
>
> Resources we already have:
>
> * https://devguide.python.org/developers/
> *
> https://bugs.python.org/user?%40action=search&iscommitter=1&%40pagesize=300&%40sort=username
> * python-committers Subscribers List (but this is currently only
>   for list admins to see - perhaps we could make that available
>   to list members ?!)
> * https://hg.python.org/committers.txt
> * for the early days:
>
> https://raw.githubusercontent.com/python/cpython/e42b705188271da108de42b55d9344642170aa2b/Misc/HISTORY
>   in combination with
>
> https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Misc/ACKS
>   (in those times, there was no direct access to the repo
>   and all patches had to go through the team around Guido)

There's also:

* the members of the github team
* folks marked as committers as BPO

I don't recall if these are exposed via public lists though.

-eric

> 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, etc.
___
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] New core developers: Lisa Roach and Emily Morehouse-Valcarcel

[Eric Snow]

Welcome, Emily and Lisa!

My interactions with Lisa have been limited to several conversations,
albeit positive ones.  I've been working closely with Emily since
PyCon and have come to respect her intelligence, thoughtfulness, and
insight.  Furthermore I'm glad that we have another member of the core
team with a deep understanding of the compiler and runtime. :)

Anyway, congratulations to both for the well-deserved recognition.
I'll looking forward to further collaboration.

-eric

On Fri, Sep 14, 2018 at 12:28 PM Raymond Hettinger
 wrote:
>
> At the developer sprints this week, we collectively decided to grant core 
> committer status to Emily and Lisa.
>
> Please join me in welcoming them to the team.
>
>
> Raymond
>
>
> ---
>
> Emily is the Director of Engineering at Cuttlesoft. She has previously 
> attended two Language Summits and three core development sprints at PyCon. 
> Since July, Emily has worked with Guido's guidance to implement PEP 572, 
> Assignment Expressions.  She has also worked with Eric Snow to dive into 
> CPython's runtime as well as subinterpreters.  This year at PyCon she gave a 
> talk on Python's AST.  Here is her speaker bio 
> https://us.pycon.org/2018/speaker/profile/283/ and a link to her talk video: 
> https://www.youtube.com/watch?v=XhWvz4dK4ng
>
> Lisa has a background in network engineering and supported the Cisco sale 
> engineer team to develop high quality Python product demonstrations.  Later 
> she moved to the Facebook security team.  This is her third core developer 
> sprint.  She and Guido are co-authors of PEP 526, Syntax for Variable 
> Annotations. Last year, she worked with Eric Smith on PEP 557, Data Classes. 
> Here is her speaker bio https://us.pycon.org/2018/speaker/profile/824/  and a 
> link to her Pycon talks: https://www.youtube.com/watch?v=hKxbO4rRlpg and 
> https://www.youtube.com/watch?v=ww1UsGZV8fQ
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Eric Snow]

On Tue, Sep 25, 2018 at 1:30 PM Yury Selivanov  wrote:
> What's the current plan for what version of Python we release after 3.9?

One idea I've heard is to switch to calendar versioning after 3.9.  So
we'd start with something like "2021" (year) or "2021.06" (year +
month).  sys.version_info would stay monotonic and so would the
version macro in the C-API.  The executable would still be "python3"
so it may still make sense to incorporate "3" into the version.  When
we do get to a major/breaking change we'd change the executable to
"python4" and incorporate "4" into the version.

Switching to calver doesn't necessarily mean we'd tie ourselves to a
fixed release schedule, but doing so would probably fit better with
calver. :)

Anyway, this is just something I've heard discussed which I kind of liked.

-eric
___
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

[Eric Snow]

On Sat, Sep 29, 2018, 09:31 Yury Selivanov  wrote:

> Given all the above, Łukasz *volunteered* his own time to help setup
> Discourse and help everyone to migrate to it so that we can all try
> it.


Yes.  Thank-you Łukasz! :)

When he announced that we want to try Discourse at the sprints,
> out of all people there I remember only Barry asking questions about
> email integration.  Everybody else including Guido, Brett, Raymond,
> Victor, Mariatta, and many others were OK to try Discourse.


I expressed reservations as well, while also recognizing the benefits.  I
also didn't consider the impact on governance discussions, nor did I think
there's be an abrupt switch nor so soon.  FWIW, I don't recall being more
than lukewarm on the idea (for the sake of the benefits), but didn't
express strong objections because I figured that, for me personally, it
would mostly be a matter of adjusting (which for me has a real cost in time
and mental energy).

As I can
> see, Łukasz himself doesn't have any interests in this migration
> besides trying to make our communication more enjoyable and welcoming.
>
> Lastly, I understand everybody who likes e-mail and their e-mail
> clients.  I'm such a person myself.  Learning a completely new tool
> and using browser to access it isn't easy for me either.  But I'm
> willing to try to sacrifice some of my convenience in order to see if
> the new medium can enable us to have more polite discussions


+1

The catch is that it's an imposition on folks that don't feel exactly the
same way.

and if
> core developers who don't want to engage now become comfortable to
> join us again.
>

That's definitely worth aiming for.  However, there are real limits to how
much technology can help what is essentially a people/social problem. :/

-eric

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

[Eric Snow]

On Fri, Nov 2, 2018, 21:24 Tim Peters  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.
>

Would it help if we only published who voted, and kept their votes
private?  Publishing the actual votes probably doesn't make a big
difference here, relative to the broader Python/tech community.

-eric
___
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

[Eric Snow]

On Fri, Nov 2, 2018, 21:44 Victor Stinner  Le sam. 3 nov. 2018 à 04:40, Eric Snow  a
> écrit :
> > Would it help if we only published who voted, and kept their votes
> private?  Publishing the actual votes probably doesn't make a big
> difference here, relative to the broader Python/tech community.
>
> The PEP has a whole section explaining the rationale:
> https://www.python.org/dev/peps/pep-8001/#why-should-the-vote-be-public
>
> This PEP has 9 authors and has been discussed in length.
>

Right.  I'm one of the authors. :)  When we discussed this point it was for
the sake of communicating validity to the community.  However, I'm not
convinced that publishing more than the list of voters is needed for that.
If that's something that would make Tim more comfortable with voting then I
suggest we consider it.

-eric

>
___
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] Re: RSVP: CPython core dev sprint

[Eric Snow]

On Mon, Jun 3, 2019 at 12:05 PM Pablo Galindo Salgado
 wrote:
> After we have received all responses, Ewa will reach out to you individually 
> with additional information for booking rooms and getting travel reimbursed 
> if you requested it.

What nights are accommodated for the hotel room?  I'd guess Sunday
night through Thursday night (5 total), but it isn't uncommon for
Friday night to be included too.  Asking for a friend. :)

-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/HQDTSPYG52KCPMSGIVU67UFO5QTV66TV/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Concerns about how we vote on new core developers

[Eric Snow]

I have a growing concern I have about the impact of our current
promotion process on aspiring core developers.  I've opened a
discussion thread about:

https://discuss.python.org/t/concerns-about-how-we-vote-on-new-core-developers/2351

-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/ZNWBO2K66L5NMHXJE6QXV7BHTKGJMXQ5/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Language Summit

[Eric Snow]

On Wed, Apr 15, 2020 at 6:38 PM Eric V. Smith  wrote:
> Here are the slides from my talk: 
> https://github.com/ericvsmith/f-strings-by-default/raw/master/F-strings%20everywhere!.pdf

Here are slides for my lightning talk ("A Retrospective on My
“Multi-core Python” Project"):

https://docs.google.com/presentation/d/16M3v1sEOJO0xoMW9qupAzyPsYLfseeWv9zXXAMee4aE

-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/Z7FVTSOB33LWQZYZ5ITLRGK2KY5BSKQ2/
Code of Conduct: https://www.python.org/psf/codeofconduct/