
I have two somewhat unrelated thoughts about PEPs. * Accepted: header When PEP 3147 was accepted, I had a few folks ask that this be recorded in the PEP by including a link to the BDFL pronouncement email. I realized that there's no formal way to express this in a PEP, and many PEPs in fact don't record more than the fact that it was accepted. I'd like to propose officially adding an Accepted: header which should include a URL to the email or other web resource where the PEP is accepted. I've come as close as possible to this (without modifying the supporting scripts or PEP 1) in PEP 3147: http://www.python.org/dev/peps/pep-3147/ I'd be willing to update things if there are no objections. * EOL schedule for older releases. We have semi-formal policies for the lifetimes of Python releases, though I'm not sure this policy is written down in any of the existing informational PEPs. However, we have release schedule PEPs going back to Python 1.6. It seems reasonable to me that we include end-of-life information in those PEPs. For example, we could state that Python 2.4 is no longer even being maintained for security, and we could state the projected date that Python 2.6 will go into security-only maintenance mode. I would not mandate that we go back and update all previous PEPs for either of these ideas. We'd adopt them moving forward and allow anyone who's motivated to backfill information opportunistically. Thoughts? -Barry

Sounds good to me (from my phone on my way to WWW2010). On Apr 27, 2010 10:49 AM, "Barry Warsaw" <barry@python.org> wrote: I have two somewhat unrelated thoughts about PEPs. * Accepted: header When PEP 3147 was accepted, I had a few folks ask that this be recorded in the PEP by including a link to the BDFL pronouncement email. I realized that there's no formal way to express this in a PEP, and many PEPs in fact don't record more than the fact that it was accepted. I'd like to propose officially adding an Accepted: header which should include a URL to the email or other web resource where the PEP is accepted. I've come as close as possible to this (without modifying the supporting scripts or PEP 1) in PEP 3147: http://www.python.org/dev/peps/pep-3147/ I'd be willing to update things if there are no objections. * EOL schedule for older releases. We have semi-formal policies for the lifetimes of Python releases, though I'm not sure this policy is written down in any of the existing informational PEPs. However, we have release schedule PEPs going back to Python 1.6. It seems reasonable to me that we include end-of-life information in those PEPs. For example, we could state that Python 2.4 is no longer even being maintained for security, and we could state the projected date that Python 2.6 will go into security-only maintenance mode. I would not mandate that we go back and update all previous PEPs for either of these ideas. We'd adopt them moving forward and allow anyone who's motivated to backfill information opportunistically. Thoughts? -Barry _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org

On Tue, Apr 27, 2010 at 10:46 AM, Barry Warsaw <barry@python.org> wrote:
I'd rather not build a single point of failure into the process. Instead of insisting on BDFL pronouncement, the community should switch do something like "last call for objections." There should also be a timeline so that unproductive discussion can't be dragged on forever.
SGTM. -- --Guido van Rossum (python.org/~guido)

Guido van Rossum wrote:
I believe the more important part of Barry's suggested change here is requiring a link to the archived message (usually from python-dev) where the PEP was accepted (be it directly by you as BDFL, or by consensus from a "sufficient" number of core developers). This will likely also help with reminding people to announce on python-dev when PEPs are accepted by consensus (or by you) somewhere like PyCon or a sprint.
+1 to both ideas from me, too. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

On Apr 28, 2010, at 09:22 AM, Dirkjan Ochtman wrote:
Good point. What do you think about 'Resolution'? As to Guido's point about the decision making process, Nick's right. I just want to make sure we can capture the resolution in the PEP, be it by BDFL pronouncement or "hey, silence is acceptance" email. Cheers, -Barry

I don't think "silence is acceptance" will work out in practice. For issues where a PEP was written in the first place, somebody will *always* object, and forever so, hoping that what he considers a mistake will not be done. The advantage of Guido acting as BDFL was that somebody would make an decision ultimately, one which both proponents and opponents of the PEP would accept. Without a BDFL, I think we need a committee to make decisions, e.g. by majority vote amongst committers. Regards, Martin

Martin v. Löwis wrote:
Couldn't we just go with the FLUFL? regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/

IIRC in the IETF this is done by the committee chair. I think it's a good idea to have this be a single person to avoid endless indecision.
It then seems that this role should go to the release manager of the upcoming feature release. Assuming Georg can accept this additional responsibility. Regards, Martin

On May 01, 2010, at 07:12 AM, Martin v. Löwis wrote:
I do think it makes sense for the RM to assume these responsibilities where Guido either can't or doesn't want to make the final decision. I think it will fairly substantially increase the workload on the RM, so perhaps there are ways to off-load some of the current responsibilities (e.g. updating the website for each release). I also think that RMs should be term-limited so that we can spread more experience within the community. And past-RMs can provide a sort of consultation group where contentious decisions can be discussed and advice gathered. -Barry

On Mon, May 3, 2010 at 8:57 AM, Barry Warsaw <barry@python.org> wrote:
While I certainly won't object if a release manager volunteers to also be the final PEP arbiter, I don't want to make it a job requirement (or even an implied expectation). The responsibility of a release manager is very much in the here and now and the near future -- stability and consistency of the current release. Being PEP arbiter requires a somewhat different mindset, more focused on the long-term health of the language and its community. -- --Guido van Rossum (python.org/~guido)

2010/5/3 Guido van Rossum <guido@python.org>:
I'm very -1 on the release manager making decisions on PEPs. The RM right now basically makes a release schedule and cuts releases. The little power he has is mostly used for rejecting features in the beta period. This task should not be politicized. -- Regards, Benjamin

Benjamin Peterson wrote:
That seems reasonable, but it also seems reasonable to try and simplify the task of updating the web site for each release. There's plenty to do without having to fight that issue too. I'm copying this message to Rich Leland, who is currently making a study of the PSF's web requirements, to make sure this gets folded in. Many of the tasks are essentially macrogeneration, and unless automated will remain error-prone. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/

Am 03.05.2010 18:40, schrieb Guido van Rossum:
I agree, and I wouldn't want to make these decisions. That person (or group) needs to have some weight in the community, or there will be a feeling of "... and who is he to decide anyway". We haven't emphasized RMship in the past; it's not a special position, except when something about a release goes wrong and blame must be placed ;) I think, being Guido, you are still the best single person to do this job. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

Georg Brandl wrote:
Not to wish anything bad on Guido, but I think it does behoove us as responsible stewards of the reference interpreter to at least consider the "bus" factor (as in "hit by a..."). I suspect Martin is right that some form of committee (at least initially) would be inevitable. While I doubt that we could find any one person that everyone would agree to defer to, I suspect we could find a small group of 3 or 4 people who's consensus everyone else would respect. And if that small group couldn't agree on whether or not something was a good idea, then the old "status quo wins a stalemate" would kick in. That said, this is hopefully something that we won't have to worry about for real until some time well into the future when Guido decides he wants to retire. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

On 05/05/2010 12:15, Nick Coghlan wrote:
Sounds like a sensible arrangement.
Well, we (or more specifically Guido) may want to transition to some system where Guido doesn't have to make *every* decision. We only need this for PEPs where there isn't a community consensus. Michael
Regards, Nick.
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

Am 05.05.2010 13:24, schrieb Michael Foord:
Sure, but I think we wouldn't have too much trouble finding a replacement if and when that happens. (Let's hope it doesn't.) This is not something that requires weeks of preparation, and even if it did, no pronouncement on a PEP for a few weeks isn't the doom of Python.
Yes, I could imagine that too. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

On Fri, Apr 30, 2010 at 11:25 PM, Guido van Rossum <guido@python.org> wrote: [..]
BPD = Benevolent Pep Dictator BPC = Benevolent Pep Caliph (sounds good in French, not sure in English ;) ) What about naming several BPD + and have one BPC elected each year by all the core devs ? == BPD == I am not sure if this would work for all areas in Python-core, but looking at the maintainers.rst file, it looks like we could name for example Brett for all the import machinery things, Marc-André for all the unicode things, I could be the one about packaging, etc. If we could manage to split the python-core development into categories, and add these categories in the PEP metadata, that would define who takes the final decision in case we can't reach consensus. == BPC == Of course some PEPs could concern several categories, so we would still need some kind of Pep dictator if there's no consensus. So what about electing a BPC every year ? Tarek -- Tarek Ziadé | http://ziade.org

Martin v. Löwis <martin <at> v.loewis.de> writes:
The issue is more a question of personal bandwidth. Giving an informed decision requires reading and listening to a lot of advice, material etc. Then it's not obvious that we will have many PEPs in the future. The syntax is pretty much frozen (even after the moratorium, it seems unlikely anything big will happen -- except if we want to add first-class coroutines). Many enhancements (e.g. new APIs in existing library modules) can be done, and are done, without PEPs at all. Regards Antoine.

On Sat, May 1, 2010 at 12:34 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Yes that was the idea. For instance in packaging matters, I don't expect other core devs to have the time to learn about every aspect of a particular packaging problem to be able to make the best decision. Now if the release manager takes the decision, I guess the result will be the same at the end, as Martin says: he'll ask for the opinion of the respective experts so I guess it works too.
-- Tarek Ziadé | http://ziade.org

On Sat, May 1, 2010 at 02:00, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
This sounds like the lieutenant setup they have for the Linux kernel. I have no clue how that works out for them.
So there is a "single voice" issue here (that also applies to Martin's idea of having the release manager make the call as that is a rotating position). One of the reasons, I think, the BDFL style of decision making has worked out is that it lets Guido keep Python consistent; the language is always striving to meet his mental model of the language more and more. Having this rotate amongst us will not allow us to have this benefit. It also raises the chance of arguing over who takes over the rotating position and that just falls down into the hellish hole of politics that I don't think any of us want to see happen. But even ignoring my worry/point, what are we even discussing here? Guido has said multiple time he is not retiring, simply scaling back his involvement. So are we trying to figure out how to make our own decisions about Python when Guido is not available to make one or simply doesn't care enough to pronounce? If that's the case then we should probably choose a vice BDFL (sort of a Benevolent Dicatator at Guido's Discretion) to keep the voice of Python as uniform as possible. I guess this person would become the assumed successor of the BDFL title if Guido ever does retire and the decision is made to continue on with active development of the language instead of just going into maintenance mode, but hopefully that problem will be a long ways off. If we are discussing something else, then I don't know what we are all talking about here other than measurements of standard pieces of wood. =) -Brett

Martin v. Löwis wrote:
If he isn't then we can depose him and replace him with a puppet. regards Steve PS: Barry: sorry I can't make the gig tonight. Hope it went well ... -- Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/

On Apr 30, 2010, at 04:28 PM, Steve Holden wrote:
We could of course, and I would serve honorably <wink>. But Guido's not *that* much older than me, so you'd probably only get a few useful years out of me before I start getting increasingly eccentric, re-opening and approving PEPs like 313, 336, and 666. In the meantime, let's groom Benjamin to be the Sacred Next Uncle Galvanizing the Gamut of Language Evolution. -Barry

On 01/05/2010 00:10, Maciej Fijalkowski wrote:
You we would probably strike with 100x50mm boards instead. Michael
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Noller wrote:
Lumber is, oddly, named for its "wet size" (when cut), rather than "dry size" (when you buy it at the lumber yard after it dries). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvcYOwACgkQ+gerLs4ltQ5SAgCdHnPJZ+UqTgjcTmW21iphpO1Y BQ8An07mX/cy3opSpNyt0FE2jtVMtLIu =Qqq1 -----END PGP SIGNATURE-----

On 01/05/2010 00:08, Benjamin Peterson wrote:
And 2x4 refers to a board with cross-section of 4 inches x 2 inches; the inch being an obsolete unit of measure from the old British imperial system now defunct throughout the civilized world. Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

Michael Foord wrote:
The last time I was in a UK builders' yard I hear someone asking for "two meter pieces of two by four". At the time the UK was notionally metric (and the timber was planed to the nearest metric size) but the old names still survived. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/

Steve Holden wrote:
Yeah, a 2x4 is still a 2x4 here as well. It's English, even the native speakers don't really expect it to make sense all the time ;) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

On Apr 30, 2010, at 12:51 PM, Martin v. Löwis wrote:
Without a BDFL, I think we need a committee to make decisions, e.g. by majority vote amongst committers.
I like Guido's idea. Just appoint have one of the experienced developers who is independent of the proposal and have them be the final arbiter. For example, Guido had earlier suggested that I decide the fate of the "yield from" proposal because I had experience in the topic but was not not personally involved in the proposal. Guido has set a good example for others to follow: * let a conversation evolve until an outcome is self-evident * or kill it early if it has no chance * or if discussion teases out all of the meaningful thinking but doesn't reach a clear conclusion, just make a choice based on instinct * have biases toward real-world use cases, towards ideas proven in other languages (category killers), towards slow rates of language evolution, and think about the long-term. It is better to have one experienced developer decide than to have a committee. Raymond

On Thu, Sep 2, 2010 at 9:08 PM, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
+1. BTW, Barry just asked me about PEP 3149 and we decided to leave the ultimate decision to Georg and Benjamin. That's about as large a committee I'd be comfortable to appoint for any specific PEP. -- --Guido van Rossum (python.org/~guido)

I feel that the concept of a BDFM (benevolent dictator for the moment) has the advantage of a clear visible responsibility, which most times leads to better decisions than if nobody is sure which ammunituion is the real one while shooting in a committee. Harald (tldr:+1) -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - Using PostgreSQL is mostly about sleeping well at night.

On Sep 02, 2010, at 09:08 PM, Raymond Hettinger wrote:
I completely agree that it's good we're beginning to give Guido a break so that he doesn't have to follow every thread, think hard about every PEP and make every decision. Having just gone through this as a PEP author with 3149, I have a couple of thoughts on how we might begin to formalize this process. Of course, we want to keep it lightweight, but also effective and as always in the best interest of Python. One thing that would help would be for Guido to let us know early on when he'd prefer to delegate the decision. This goes along with identifying the ultimate PEP arbiter (UPA? :) as early as possible. As Raymond says, it should be someone independent of the proposal, but with the interest, time, and experience necessary to make an informed decision. We might even want to capture the arbiter selection in a PEP header (similar to the new Resolution header for capturing the final decision reference). While I agree that we don't want decision by committee, I think we should consider a preference for paired arbiters. I have the highest respect for all the senior developers who would likely make up the pool of PEP deciders, but it gave me great confidence to have both Benjamin and Georg decide the fate of PEP 3149. As someone who might serve a similar role in the future, I would value a second person to sanity check my own thoughts on the matter and to identify any holes in my understanding (or <shudder> missed emails :). I'd say, let's state a preference (not a requirement) for two arbiters for any PEP that's not decided by Guido. We'd talked before about allowing the RM for the target version to make the decision. Maybe the RM can serve as that second arbiter when no other obvious candidate is available. Raymond, you identified a great set of criteria that the arbiters should use to guide them to a decision. I'm willing to write up an informational PEP that codifies this and any other guidelines we come up with for non-BDFL PEP decisions. Finally a reminder to PEP authors that it is your responsibility to shepherd your PEP through the process. Don't be a pest, but do keep an eye on the release calendar so that you're not scrambling for a snap decision at the last minute. 18 months can go by quickly. :) -Barry

On Fri, Sep 3, 2010 at 8:15 AM, Barry Warsaw <barry@python.org> wrote:
One thing that would help would be for Guido to let us know early on when he'd prefer to delegate the decision.
Hey! I'm still here! :-) More to the point, you can assume that I'm happy to have every PEP decision made by someone else *except* if you see me participate in the thread. If I don't show up in the thread, you can assume that either (a) I don't care or know enough about the topic, or (b) I am confident that it's going in the right direction.
This goes along with identifying the ultimate PEP arbiter (UPA? :) as early as possible.
I prefer acronyms derived from BDFL, like BDFM ("BD for the moment") or perhaps BDFP ("BD for the PEP"). (BDFM sounds better but BDFP is more accurate. I'll leave it up to the FLUFL to pick one.)
Hm... As long as we can make sure not to pick the same pair all the time this makes sense. (Not that I have any objections to how the Georg+Benjamin pair decided PEP 3149 -- to the contrary -- but I think it would be good to spread the power.) But if a pair can't be found I think a single BDFM/BDFP will work too.
Good fallback plan.
Well, realistically, there's only so much grief that anyone PEP author can be expected to put up with. I expect that a lot of PEPs won't be written or will be withdrawn in the face of prolonged discussion. Early selection of a BDFM (maybe the M can also refer to mentorship) ought to help in encouraging where encouragement would help -- and of course sometimes the best thing to do is to encourage the PEP author to drop the idea, if no consensus is in view (or if the author is particularly hard-headed). -- --Guido van Rossum (python.org/~guido)

On Fri, Sep 3, 2010 at 08:45, Guido van Rossum <guido@python.org> wrote:
I guess the real question comes down to whether you want us to bug you to select the temp dictator or just make a call amongst ourselves?
I personally like BDFN ("BD for now") or BDAGW ("BD at Guido's whim"), but this will bikeshed into eternity, so I am happy with the FLUFL being the dictator for the new acronym choice. =)
I agree, and a RM as the backup/sanity check would not spread it out. Considering the position is held for 1.5 years (or more) and has in the past been held sequentially by the same person, that wouldn't exactly spread it about. It also limits trying to bring new people into the process as RMs tend to be old-hands and not new blood. Plus we are not about to make the lead on a PEP decision be a new person either.
But if a pair can't be found I think a single BDFM/BDFP will work too.
I agree. I would trust anyone who is given the ability to make a call to listen to reason enough to not necessarily need the sanity check. But a duopoly is not a bad thing overall either.
As long as it gets spread around and the fallback is not the default, I agree.
Hopefully PEPs like this will get stopped before they even get checked in. The PEP editors have been sending PEPs back to their authors to share on python-ideas first for a little while now and that seems to have helped make sure the PEPs that do reach us are of sufficient quality.

On Fri, Sep 3, 2010 at 12:50 PM, Brett Cannon <brett@python.org> wrote:
I guess the real question comes down to whether you want us to bug you to select the temp dictator or just make a call amongst ourselves?
It's okay to bug me only if you can't find or agree on a temp dictator. -- --Guido van Rossum (python.org/~guido)

On May 01, 2010, at 08:58 AM, Dirkjan Ochtman wrote:
I've updated PEP 1 and the supporting scripts to accept a Resolution: header. Note that in PEP 1 I wrote: *Note: The Resolution header is required for Standards Track PEPs only. It contains a URL that should point to an email message or other web resource where the pronouncement about the PEP is made.* but in fact, the scripts make Resolution optional (it's kind of a pain to make it required just for Standards Track PEPs - contributions welcome). -Barry

On Mon, May 3, 2010 at 11:30 AM, Barry Warsaw <barry@python.org> wrote:
but in fact, the scripts make Resolution optional (it's kind of a pain to make it required just for Standards Track PEPs - contributions welcome).
It will also be a pain to retroactively update older PEPs with the newly-required metadata; leaving it optional (in practice) seems acceptable. It should only apply to newly-resolved PEPs, which is also likely a pain to build into the script. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller

Sounds good to me (from my phone on my way to WWW2010). On Apr 27, 2010 10:49 AM, "Barry Warsaw" <barry@python.org> wrote: I have two somewhat unrelated thoughts about PEPs. * Accepted: header When PEP 3147 was accepted, I had a few folks ask that this be recorded in the PEP by including a link to the BDFL pronouncement email. I realized that there's no formal way to express this in a PEP, and many PEPs in fact don't record more than the fact that it was accepted. I'd like to propose officially adding an Accepted: header which should include a URL to the email or other web resource where the PEP is accepted. I've come as close as possible to this (without modifying the supporting scripts or PEP 1) in PEP 3147: http://www.python.org/dev/peps/pep-3147/ I'd be willing to update things if there are no objections. * EOL schedule for older releases. We have semi-formal policies for the lifetimes of Python releases, though I'm not sure this policy is written down in any of the existing informational PEPs. However, we have release schedule PEPs going back to Python 1.6. It seems reasonable to me that we include end-of-life information in those PEPs. For example, we could state that Python 2.4 is no longer even being maintained for security, and we could state the projected date that Python 2.6 will go into security-only maintenance mode. I would not mandate that we go back and update all previous PEPs for either of these ideas. We'd adopt them moving forward and allow anyone who's motivated to backfill information opportunistically. Thoughts? -Barry _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org

On Tue, Apr 27, 2010 at 10:46 AM, Barry Warsaw <barry@python.org> wrote:
I'd rather not build a single point of failure into the process. Instead of insisting on BDFL pronouncement, the community should switch do something like "last call for objections." There should also be a timeline so that unproductive discussion can't be dragged on forever.
SGTM. -- --Guido van Rossum (python.org/~guido)

Guido van Rossum wrote:
I believe the more important part of Barry's suggested change here is requiring a link to the archived message (usually from python-dev) where the PEP was accepted (be it directly by you as BDFL, or by consensus from a "sufficient" number of core developers). This will likely also help with reminding people to announce on python-dev when PEPs are accepted by consensus (or by you) somewhere like PyCon or a sprint.
+1 to both ideas from me, too. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

On Apr 28, 2010, at 09:22 AM, Dirkjan Ochtman wrote:
Good point. What do you think about 'Resolution'? As to Guido's point about the decision making process, Nick's right. I just want to make sure we can capture the resolution in the PEP, be it by BDFL pronouncement or "hey, silence is acceptance" email. Cheers, -Barry

I don't think "silence is acceptance" will work out in practice. For issues where a PEP was written in the first place, somebody will *always* object, and forever so, hoping that what he considers a mistake will not be done. The advantage of Guido acting as BDFL was that somebody would make an decision ultimately, one which both proponents and opponents of the PEP would accept. Without a BDFL, I think we need a committee to make decisions, e.g. by majority vote amongst committers. Regards, Martin

Martin v. Löwis wrote:
Couldn't we just go with the FLUFL? regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/

IIRC in the IETF this is done by the committee chair. I think it's a good idea to have this be a single person to avoid endless indecision.
It then seems that this role should go to the release manager of the upcoming feature release. Assuming Georg can accept this additional responsibility. Regards, Martin

On May 01, 2010, at 07:12 AM, Martin v. Löwis wrote:
I do think it makes sense for the RM to assume these responsibilities where Guido either can't or doesn't want to make the final decision. I think it will fairly substantially increase the workload on the RM, so perhaps there are ways to off-load some of the current responsibilities (e.g. updating the website for each release). I also think that RMs should be term-limited so that we can spread more experience within the community. And past-RMs can provide a sort of consultation group where contentious decisions can be discussed and advice gathered. -Barry

On Mon, May 3, 2010 at 8:57 AM, Barry Warsaw <barry@python.org> wrote:
While I certainly won't object if a release manager volunteers to also be the final PEP arbiter, I don't want to make it a job requirement (or even an implied expectation). The responsibility of a release manager is very much in the here and now and the near future -- stability and consistency of the current release. Being PEP arbiter requires a somewhat different mindset, more focused on the long-term health of the language and its community. -- --Guido van Rossum (python.org/~guido)

2010/5/3 Guido van Rossum <guido@python.org>:
I'm very -1 on the release manager making decisions on PEPs. The RM right now basically makes a release schedule and cuts releases. The little power he has is mostly used for rejecting features in the beta period. This task should not be politicized. -- Regards, Benjamin

Benjamin Peterson wrote:
That seems reasonable, but it also seems reasonable to try and simplify the task of updating the web site for each release. There's plenty to do without having to fight that issue too. I'm copying this message to Rich Leland, who is currently making a study of the PSF's web requirements, to make sure this gets folded in. Many of the tasks are essentially macrogeneration, and unless automated will remain error-prone. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/

Am 03.05.2010 18:40, schrieb Guido van Rossum:
I agree, and I wouldn't want to make these decisions. That person (or group) needs to have some weight in the community, or there will be a feeling of "... and who is he to decide anyway". We haven't emphasized RMship in the past; it's not a special position, except when something about a release goes wrong and blame must be placed ;) I think, being Guido, you are still the best single person to do this job. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

Georg Brandl wrote:
Not to wish anything bad on Guido, but I think it does behoove us as responsible stewards of the reference interpreter to at least consider the "bus" factor (as in "hit by a..."). I suspect Martin is right that some form of committee (at least initially) would be inevitable. While I doubt that we could find any one person that everyone would agree to defer to, I suspect we could find a small group of 3 or 4 people who's consensus everyone else would respect. And if that small group couldn't agree on whether or not something was a good idea, then the old "status quo wins a stalemate" would kick in. That said, this is hopefully something that we won't have to worry about for real until some time well into the future when Guido decides he wants to retire. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

On 05/05/2010 12:15, Nick Coghlan wrote:
Sounds like a sensible arrangement.
Well, we (or more specifically Guido) may want to transition to some system where Guido doesn't have to make *every* decision. We only need this for PEPs where there isn't a community consensus. Michael
Regards, Nick.
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

Am 05.05.2010 13:24, schrieb Michael Foord:
Sure, but I think we wouldn't have too much trouble finding a replacement if and when that happens. (Let's hope it doesn't.) This is not something that requires weeks of preparation, and even if it did, no pronouncement on a PEP for a few weeks isn't the doom of Python.
Yes, I could imagine that too. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

On Fri, Apr 30, 2010 at 11:25 PM, Guido van Rossum <guido@python.org> wrote: [..]
BPD = Benevolent Pep Dictator BPC = Benevolent Pep Caliph (sounds good in French, not sure in English ;) ) What about naming several BPD + and have one BPC elected each year by all the core devs ? == BPD == I am not sure if this would work for all areas in Python-core, but looking at the maintainers.rst file, it looks like we could name for example Brett for all the import machinery things, Marc-André for all the unicode things, I could be the one about packaging, etc. If we could manage to split the python-core development into categories, and add these categories in the PEP metadata, that would define who takes the final decision in case we can't reach consensus. == BPC == Of course some PEPs could concern several categories, so we would still need some kind of Pep dictator if there's no consensus. So what about electing a BPC every year ? Tarek -- Tarek Ziadé | http://ziade.org

I think having a single body/person pronounce on all PEPs is sufficient; as that person should certainly listen to the opinions of the respective experts. See also my proposal that the release manager of the next feature release automatically assumes that role. Regards, Martin

Martin v. Löwis <martin <at> v.loewis.de> writes:
The issue is more a question of personal bandwidth. Giving an informed decision requires reading and listening to a lot of advice, material etc. Then it's not obvious that we will have many PEPs in the future. The syntax is pretty much frozen (even after the moratorium, it seems unlikely anything big will happen -- except if we want to add first-class coroutines). Many enhancements (e.g. new APIs in existing library modules) can be done, and are done, without PEPs at all. Regards Antoine.

On Sat, May 1, 2010 at 12:34 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Yes that was the idea. For instance in packaging matters, I don't expect other core devs to have the time to learn about every aspect of a particular packaging problem to be able to make the best decision. Now if the release manager takes the decision, I guess the result will be the same at the end, as Martin says: he'll ask for the opinion of the respective experts so I guess it works too.
-- Tarek Ziadé | http://ziade.org

On Sat, May 1, 2010 at 02:00, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
This sounds like the lieutenant setup they have for the Linux kernel. I have no clue how that works out for them.
So there is a "single voice" issue here (that also applies to Martin's idea of having the release manager make the call as that is a rotating position). One of the reasons, I think, the BDFL style of decision making has worked out is that it lets Guido keep Python consistent; the language is always striving to meet his mental model of the language more and more. Having this rotate amongst us will not allow us to have this benefit. It also raises the chance of arguing over who takes over the rotating position and that just falls down into the hellish hole of politics that I don't think any of us want to see happen. But even ignoring my worry/point, what are we even discussing here? Guido has said multiple time he is not retiring, simply scaling back his involvement. So are we trying to figure out how to make our own decisions about Python when Guido is not available to make one or simply doesn't care enough to pronounce? If that's the case then we should probably choose a vice BDFL (sort of a Benevolent Dicatator at Guido's Discretion) to keep the voice of Python as uniform as possible. I guess this person would become the assumed successor of the BDFL title if Guido ever does retire and the decision is made to continue on with active development of the language instead of just going into maintenance mode, but hopefully that problem will be a long ways off. If we are discussing something else, then I don't know what we are all talking about here other than measurements of standard pieces of wood. =) -Brett

Martin v. Löwis wrote:
If he isn't then we can depose him and replace him with a puppet. regards Steve PS: Barry: sorry I can't make the gig tonight. Hope it went well ... -- Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/

On Apr 30, 2010, at 04:28 PM, Steve Holden wrote:
We could of course, and I would serve honorably <wink>. But Guido's not *that* much older than me, so you'd probably only get a few useful years out of me before I start getting increasingly eccentric, re-opening and approving PEPs like 313, 336, and 666. In the meantime, let's groom Benjamin to be the Sacred Next Uncle Galvanizing the Gamut of Language Evolution. -Barry

On 01/05/2010 00:10, Maciej Fijalkowski wrote:
You we would probably strike with 100x50mm boards instead. Michael
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jesse Noller wrote:
Lumber is, oddly, named for its "wet size" (when cut), rather than "dry size" (when you buy it at the lumber yard after it dries). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvcYOwACgkQ+gerLs4ltQ5SAgCdHnPJZ+UqTgjcTmW21iphpO1Y BQ8An07mX/cy3opSpNyt0FE2jtVMtLIu =Qqq1 -----END PGP SIGNATURE-----

On 01/05/2010 00:08, Benjamin Peterson wrote:
And 2x4 refers to a board with cross-section of 4 inches x 2 inches; the inch being an obsolete unit of measure from the old British imperial system now defunct throughout the civilized world. Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

Michael Foord wrote:
The last time I was in a UK builders' yard I hear someone asking for "two meter pieces of two by four". At the time the UK was notionally metric (and the timber was planed to the nearest metric size) but the old names still survived. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/

Steve Holden wrote:
Yeah, a 2x4 is still a 2x4 here as well. It's English, even the native speakers don't really expect it to make sense all the time ;) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

On Apr 30, 2010, at 12:51 PM, Martin v. Löwis wrote:
Without a BDFL, I think we need a committee to make decisions, e.g. by majority vote amongst committers.
I like Guido's idea. Just appoint have one of the experienced developers who is independent of the proposal and have them be the final arbiter. For example, Guido had earlier suggested that I decide the fate of the "yield from" proposal because I had experience in the topic but was not not personally involved in the proposal. Guido has set a good example for others to follow: * let a conversation evolve until an outcome is self-evident * or kill it early if it has no chance * or if discussion teases out all of the meaningful thinking but doesn't reach a clear conclusion, just make a choice based on instinct * have biases toward real-world use cases, towards ideas proven in other languages (category killers), towards slow rates of language evolution, and think about the long-term. It is better to have one experienced developer decide than to have a committee. Raymond

On Thu, Sep 2, 2010 at 9:08 PM, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
+1. BTW, Barry just asked me about PEP 3149 and we decided to leave the ultimate decision to Georg and Benjamin. That's about as large a committee I'd be comfortable to appoint for any specific PEP. -- --Guido van Rossum (python.org/~guido)

I feel that the concept of a BDFM (benevolent dictator for the moment) has the advantage of a clear visible responsibility, which most times leads to better decisions than if nobody is sure which ammunituion is the real one while shooting in a committee. Harald (tldr:+1) -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - Using PostgreSQL is mostly about sleeping well at night.

On Sep 02, 2010, at 09:08 PM, Raymond Hettinger wrote:
I completely agree that it's good we're beginning to give Guido a break so that he doesn't have to follow every thread, think hard about every PEP and make every decision. Having just gone through this as a PEP author with 3149, I have a couple of thoughts on how we might begin to formalize this process. Of course, we want to keep it lightweight, but also effective and as always in the best interest of Python. One thing that would help would be for Guido to let us know early on when he'd prefer to delegate the decision. This goes along with identifying the ultimate PEP arbiter (UPA? :) as early as possible. As Raymond says, it should be someone independent of the proposal, but with the interest, time, and experience necessary to make an informed decision. We might even want to capture the arbiter selection in a PEP header (similar to the new Resolution header for capturing the final decision reference). While I agree that we don't want decision by committee, I think we should consider a preference for paired arbiters. I have the highest respect for all the senior developers who would likely make up the pool of PEP deciders, but it gave me great confidence to have both Benjamin and Georg decide the fate of PEP 3149. As someone who might serve a similar role in the future, I would value a second person to sanity check my own thoughts on the matter and to identify any holes in my understanding (or <shudder> missed emails :). I'd say, let's state a preference (not a requirement) for two arbiters for any PEP that's not decided by Guido. We'd talked before about allowing the RM for the target version to make the decision. Maybe the RM can serve as that second arbiter when no other obvious candidate is available. Raymond, you identified a great set of criteria that the arbiters should use to guide them to a decision. I'm willing to write up an informational PEP that codifies this and any other guidelines we come up with for non-BDFL PEP decisions. Finally a reminder to PEP authors that it is your responsibility to shepherd your PEP through the process. Don't be a pest, but do keep an eye on the release calendar so that you're not scrambling for a snap decision at the last minute. 18 months can go by quickly. :) -Barry

On Fri, Sep 3, 2010 at 8:15 AM, Barry Warsaw <barry@python.org> wrote:
One thing that would help would be for Guido to let us know early on when he'd prefer to delegate the decision.
Hey! I'm still here! :-) More to the point, you can assume that I'm happy to have every PEP decision made by someone else *except* if you see me participate in the thread. If I don't show up in the thread, you can assume that either (a) I don't care or know enough about the topic, or (b) I am confident that it's going in the right direction.
This goes along with identifying the ultimate PEP arbiter (UPA? :) as early as possible.
I prefer acronyms derived from BDFL, like BDFM ("BD for the moment") or perhaps BDFP ("BD for the PEP"). (BDFM sounds better but BDFP is more accurate. I'll leave it up to the FLUFL to pick one.)
Hm... As long as we can make sure not to pick the same pair all the time this makes sense. (Not that I have any objections to how the Georg+Benjamin pair decided PEP 3149 -- to the contrary -- but I think it would be good to spread the power.) But if a pair can't be found I think a single BDFM/BDFP will work too.
Good fallback plan.
Well, realistically, there's only so much grief that anyone PEP author can be expected to put up with. I expect that a lot of PEPs won't be written or will be withdrawn in the face of prolonged discussion. Early selection of a BDFM (maybe the M can also refer to mentorship) ought to help in encouraging where encouragement would help -- and of course sometimes the best thing to do is to encourage the PEP author to drop the idea, if no consensus is in view (or if the author is particularly hard-headed). -- --Guido van Rossum (python.org/~guido)

On Fri, Sep 3, 2010 at 08:45, Guido van Rossum <guido@python.org> wrote:
I guess the real question comes down to whether you want us to bug you to select the temp dictator or just make a call amongst ourselves?
I personally like BDFN ("BD for now") or BDAGW ("BD at Guido's whim"), but this will bikeshed into eternity, so I am happy with the FLUFL being the dictator for the new acronym choice. =)
I agree, and a RM as the backup/sanity check would not spread it out. Considering the position is held for 1.5 years (or more) and has in the past been held sequentially by the same person, that wouldn't exactly spread it about. It also limits trying to bring new people into the process as RMs tend to be old-hands and not new blood. Plus we are not about to make the lead on a PEP decision be a new person either.
But if a pair can't be found I think a single BDFM/BDFP will work too.
I agree. I would trust anyone who is given the ability to make a call to listen to reason enough to not necessarily need the sanity check. But a duopoly is not a bad thing overall either.
As long as it gets spread around and the fallback is not the default, I agree.
Hopefully PEPs like this will get stopped before they even get checked in. The PEP editors have been sending PEPs back to their authors to share on python-ideas first for a little while now and that seems to have helped make sure the PEPs that do reach us are of sufficient quality.

On Fri, Sep 3, 2010 at 12:50 PM, Brett Cannon <brett@python.org> wrote:
I guess the real question comes down to whether you want us to bug you to select the temp dictator or just make a call amongst ourselves?
It's okay to bug me only if you can't find or agree on a temp dictator. -- --Guido van Rossum (python.org/~guido)

On May 01, 2010, at 08:58 AM, Dirkjan Ochtman wrote:
I've updated PEP 1 and the supporting scripts to accept a Resolution: header. Note that in PEP 1 I wrote: *Note: The Resolution header is required for Standards Track PEPs only. It contains a URL that should point to an email message or other web resource where the pronouncement about the PEP is made.* but in fact, the scripts make Resolution optional (it's kind of a pain to make it required just for Standards Track PEPs - contributions welcome). -Barry

On Mon, May 3, 2010 at 11:30 AM, Barry Warsaw <barry@python.org> wrote:
but in fact, the scripts make Resolution optional (it's kind of a pain to make it required just for Standards Track PEPs - contributions welcome).
It will also be a pain to retroactively update older PEPs with the newly-required metadata; leaving it optional (in practice) seems acceptable. It should only apply to newly-resolved PEPs, which is also likely a pain to build into the script. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
participants (18)
-
"Martin v. Löwis"
-
Antoine Pitrou
-
Barry Warsaw
-
Benjamin Peterson
-
Brett Cannon
-
Dirkjan Ochtman
-
Fred Drake
-
Georg Brandl
-
Guido van Rossum
-
Jesse Noller
-
Maciej Fijalkowski
-
Massa, Harald Armin
-
Michael Foord
-
Nick Coghlan
-
Raymond Hettinger
-
Steve Holden
-
Tarek Ziadé
-
Tres Seaver