Re: [Python-Dev] PEP 405 (pyvenv) and system Python upgrades
On 5/4/2012 9:39 PM, Terry Reedy wrote: The gist of my response is that the venv 'tail' should way the python 'dog' as little as possbile. Yes, that was exactly my thought too. But I'm not sure the technology permits, with Windows not having exec. On the other hand, one might speculate about how venv, instead of copying Python.exe, might instead install the launcher in the place where python.exe is currently copied. The launcher does the next best thing to exec. Plus it would save a wee bit of space, being smaller than python.exe. On platforms that have symlinks, they could be used instead. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (pyvenv) and system Python upgrades
On Sat, May 5, 2012 at 6:49 AM, Carl Meyer c...@oddbird.net wrote: 1) Document it and provide a tool for easily upgrading a venv in this situation. This may be adequate. In practice the situation is quite rare: 2.6.8/2.7.3 is the only actual example in the history of virtualenv that I'm aware of. The disadvantage is that if the problem does occur, the error will probably be quite confusing and seemingly unrelated to pyvenv. I think this is the way to go, for basically the same reasons that we did it this way this time: there's no good reason to pay an ongoing cost to further mitigate the risks associated with an already incredibly rare event. It would become part of the standard venv debugging toolkit: Q X.1: Does the problem only occur inside a particular virtual environment? Q X.2: If yes, did you recently upgrade the system Python to a new point release? Q X.3: If yes, did you run command that updates the Python binary copy in the virtual environment? Q X.4: If no, do so and see if the problem goes away. Even if it still doesn't work, at least you've eliminated this particular error as a possible cause. Personally, I expect that always update your virtual environment binaries after updating the system Python to a new point release will itself become a recommended practice when using virtual environments. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (pyvenv) and system Python upgrades
Nick Coghlan ncoghlan at gmail.com writes: Personally, I expect that always update your virtual environment binaries after updating the system Python to a new point release will itself become a recommended practice when using virtual environments. Of course, the venv update tool will need to only update environments which were set up with the particular version of Python which was updated. ISTM pyvenv.cfg will need to have a version=X.Y.Z line in it, which is added during venv creation. That information will be used by the tool to only update specific environments. Regards, Vinay Sajip ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (pyvenv) and system Python upgrades
On Sat, May 5, 2012 at 6:49 AM, Carl Meyer c...@oddbird.net wrote: 2) In addition to the above, introduce a versioning marker in the standard library (is there one already?) and have some code somewhere (insert hand-waving here) check sys.version_info against the stdlib version, and fail fast with an unambiguous error if there is a mismatch. This makes the failure more explicit, but at the significant cost of making it more common: at every mismatch, not just in the apparently-rare case of a breaking change. Variant: Could the versioning marker give a minimum and/or maximum? It'd then only cause the explicit failure in the actual case of a breaking change, and the rest of the time it could happily use any X.Y.* release. ChrisA ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Debian wheezy, amd64: make not finding files for bz2 and other packages
Hello, On Fri, 04 May 2012 14:07:28 -0400 Edward C. Jones edcjo...@comcast.net wrote: Filelist of package libbz2-dev in wheezy of architecture amd64 /usr/include/bzlib.h /usr/lib/x86_64-linux-gnu/libbz2.a /usr/lib/x86_64-linux-gnu/libbz2.so /usr/share/doc/libbz2-dev setup.py probably doesn't search in the right paths for libbz2.so. I suggest you open a bug at http://bugs.python.org Thanks for your report, Antoine. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PEP 405 (pyvenv) and system Python upgrades
Hi, On Fri, 04 May 2012 14:49:03 -0600 Carl Meyer c...@oddbird.net wrote: 3) Symlink the interpreter rather than copying. I include this here for the sake of completeness, but it's already been rejected due to significant problems on older Windows' and OS X. Perhaps symlinking could be used at least on symlinks-friendly OSes? I expect older Windows to disappear one day :-) So the only left outlier would be OS X. Regards Antoine. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] The step command of pdb is broken
On Mon, Apr 30, 2012 at 12:31 PM, Xavier de Gaye wrote: Issue http://bugs.python.org/issue13183 raises the point that the step command of pdb is broken. This issue is 6 months old. A patch and test case have been proposed. Other pdb commands are also broken for the same reason (no trace function setup in the targeted caller frame). A new http://bugs.python.org/issue14728 has been submitted with a proposed patch for these commands and the corresponding test cases. The patch removes a while loop from the fast path, and that should also provide an improvement of the performance of Pdb. Xavier ___ 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/archive%40mail-archive.com
[Python-Dev] PEP 1 updated to reflect current practices
I just pushed an update to PEP 1 to give additional guidance to core developers that are directly updating a PEP in Mercurial, to account for the automatic generation of PEP 0 and to mention the PEP czar role. Updated PEP: http://www.python.org/dev/peps/pep-0001/ Changes: http://hg.python.org/peps/rev/bdbbd3ce97d9 Any additional feedback here (I'll leave the issue open for a while): http://bugs.python.org/issue14703 (although remember that the bar for this PEP is useful and fairly accurate rather than perfect) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Debian wheezy, amd64: make not finding files for bz2 and other packages
Am 05.05.2012 12:36, schrieb Antoine Pitrou: Hello, On Fri, 04 May 2012 14:07:28 -0400 Edward C. Jones edcjo...@comcast.net wrote: Filelist of package libbz2-dev in wheezy of architecture amd64 /usr/include/bzlib.h /usr/lib/x86_64-linux-gnu/libbz2.a /usr/lib/x86_64-linux-gnu/libbz2.so /usr/share/doc/libbz2-dev setup.py probably doesn't search in the right paths for libbz2.so. I suggest you open a bug at http://bugs.python.org The issue might be caused by Debian's new multiarch libraries. In recent versions of Debian (and Ubuntu), 64bit and 32bit libraries can coexist on the same system. What's the output of dpkg-architecture -qDEB_HOST_MULTIARCH on your system? It should print out x86_64-linux-gnu. setup.py supports multiarch for some time, see PyBuildExt.add_multiarch_paths(). Christian ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Debian wheezy, amd64: make not finding files for bz2 and other packages
On Sat, 05 May 2012 15:31:24 +0200 Christian Heimes li...@cheimes.de wrote: Am 05.05.2012 12:36, schrieb Antoine Pitrou: Hello, On Fri, 04 May 2012 14:07:28 -0400 Edward C. Jones edcjo...@comcast.net wrote: Filelist of package libbz2-dev in wheezy of architecture amd64 /usr/include/bzlib.h /usr/lib/x86_64-linux-gnu/libbz2.a /usr/lib/x86_64-linux-gnu/libbz2.so /usr/share/doc/libbz2-dev setup.py probably doesn't search in the right paths for libbz2.so. I suggest you open a bug at http://bugs.python.org The issue might be caused by Debian's new multiarch libraries. In recent versions of Debian (and Ubuntu), 64bit and 32bit libraries can coexist on the same system. It probably is, but I thought Barry had tackled that in setup.py :-) Regards Antoine. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Debian wheezy, amd64: make not finding files for bz2 and other packages
This is likely because you don't have dpkg-dev installed. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Debian wheezy, amd64: make not finding files for bz2 and other packages
On Sat, May 5, 2012 at 3:43 PM, Tshepang Lekhonkhobe tshep...@gmail.com wrote: This is likely because you don't have dpkg-dev installed. http://bugs.python.org/issue13956 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Debian wheezy, amd64: make not finding files for bz2 and other packages
Am 05.05.2012 15:39, schrieb Antoine Pitrou: On Sat, 05 May 2012 15:31:24 +0200 Christian Heimes li...@cheimes.de wrote: Am 05.05.2012 12:36, schrieb Antoine Pitrou: Hello, On Fri, 04 May 2012 14:07:28 -0400 Edward C. Jones edcjo...@comcast.net wrote: Filelist of package libbz2-dev in wheezy of architecture amd64 /usr/include/bzlib.h /usr/lib/x86_64-linux-gnu/libbz2.a /usr/lib/x86_64-linux-gnu/libbz2.so /usr/share/doc/libbz2-dev setup.py probably doesn't search in the right paths for libbz2.so. I suggest you open a bug at http://bugs.python.org The issue might be caused by Debian's new multiarch libraries. In recent versions of Debian (and Ubuntu), 64bit and 32bit libraries can coexist on the same system. It probably is, but I thought Barry had tackled that in setup.py :-) The fix needs the dpkg-architecture program. As Tshepang pointed out it may not be available on Edward's box. I always install build-essential on all development boxes as it includes GCC, make and dpkg-dev. Christian ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Debian wheezy, amd64: make not finding files for bz2 and other packages
On Sat, 05 May 2012 16:04:40 +0200 Christian Heimes li...@cheimes.de wrote: Am 05.05.2012 15:39, schrieb Antoine Pitrou: On Sat, 05 May 2012 15:31:24 +0200 Christian Heimes li...@cheimes.de wrote: Am 05.05.2012 12:36, schrieb Antoine Pitrou: Hello, On Fri, 04 May 2012 14:07:28 -0400 Edward C. Jones edcjo...@comcast.net wrote: Filelist of package libbz2-dev in wheezy of architecture amd64 /usr/include/bzlib.h /usr/lib/x86_64-linux-gnu/libbz2.a /usr/lib/x86_64-linux-gnu/libbz2.so /usr/share/doc/libbz2-dev setup.py probably doesn't search in the right paths for libbz2.so. I suggest you open a bug at http://bugs.python.org The issue might be caused by Debian's new multiarch libraries. In recent versions of Debian (and Ubuntu), 64bit and 32bit libraries can coexist on the same system. It probably is, but I thought Barry had tackled that in setup.py :-) The fix needs the dpkg-architecture program. As Tshepang pointed out it may not be available on Edward's box. I always install build-essential on all development boxes as it includes GCC, make and dpkg-dev. Perhaps setup.py should detect that? It shouldn't be too hard to parse /etc/debian_version in order to know whether the system is multiarch-enabled. That would avoid confusing build failures. Regards Antoine. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Debian wheezy, amd64: make not finding files for bz2 and other packages
Am 05.05.2012 16:13, schrieb Antoine Pitrou:
Perhaps setup.py should detect that? It shouldn't be too hard to
parse /etc/debian_version in order to know whether the system is
multiarch-enabled. That would avoid confusing build failures.
This sounds like a good idea. dpkg-architecture is available on older
version of Debian and Ubuntu but doesn't support DEB_HOST_MULTIARCH
(which is fine).
We could parse the output of platform.dist() but it's easier to just
search for the apt-get command:
if not find_executable('apt-get'):
# no Debian based distro
return
if not find_executable('dpkg-architecture'):
print Warning, Debian detected but no dpkg-architecture found.
Please run 'sudo apt-get install build-essential'.
return
Christian
___
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/archive%40mail-archive.com
Re: [Python-Dev] Debian wheezy, amd64: make not finding files for bz2 and other packages
On May 05, 2012, at 04:04 PM, Christian Heimes wrote: The fix needs the dpkg-architecture program. As Tshepang pointed out it may not be available on Edward's box. I always install build-essential on all development boxes as it includes GCC, make and dpkg-dev. That's probably it. Certainly Python 2.7, 3.2, and 3.3 build just fine for me on Debian Wheezy and Ubuntu Precise. One other thing: you might want to `apt-get build-dep python3.2` to get all the build dependencies installed first, even if you're building Python from source. If you're building Python 3.3 from source, you'll also want to install liblzma-dev. Cheers, -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/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] peps: Update PEP 1 to better reflect current practice
Thanks for doing this update Nick. I have just a few comments. On May 05, 2012, at 02:57 PM, nick.coghlan wrote: +Developers with commit privileges for the `PEP repository`_ may claim +PEP numbers directly by creating and committing a new PEP. When doing so, +the developer must handle the tasks that would normally be taken care of by +the PEP editors (see `PEP Editor Responsibilities Workflow`_). While I certainly don't mind (in fact, prefer) those with commit privileges to just go ahead and commit their PEP to the repo, I'd like for there to be *some* communication with the PEP editors first. E.g. sanity checks on the basic format or idea (was this discussed on python-ideas first?), or reservation of PEP numbers. When you do contact the PEP editors, please also specify whether you have commit privileges or not. It's too hard to remember or know who has those rights, and too much hassle to look them up. ;) OTOH, I'm also happy to adopt an EAFP style rather than LBYL, so that the PEP editors can re-assign numbers or whatever after the fact. We've done this in a few cases, and it's never been that much of a problem. Still, core developers needn't block (for too long) on the PEP editors. +The final authority for PEP approval is the BDFL. However, whenever a new +PEP is put forward, any core developer that believes they are suitably +experienced to make the final decision on that PEP may offer to serve as +the PEP czar for that PEP. If their self-nomination is accepted by the +other core developers and the BDFL, then they will have the authority to +approve (or reject) that PEP. This process happens most frequently with PEPs +where the BDFL has granted in principle approval for *something* to be done, +but there are details that need to be worked out before the PEP can be +accepted. I'd reword this to something like the following: The final authority for the PEP approval is the BDFL. However, the BDFL may delegate the final approval authority to a PEP czar for that PEP. This happens most frequently with PEPs where the BDFL has granted approval in principle for *something* to be done, and in agreement with the general proposals of the PEP, but there are details that need to be worked out before the final PEP can be approved. When an `PEP-Czar` header must be added to the PEP to record this delegation. The format of this header is the same as the `Author` header. This leave out the whole self-nomination text, which I think isn't very relevant to the official addition of the czar role (sadly, no clever bacronym has come to mind, and BDFOP hasn't really taken off ;). +* Run ``./genpepindex.py`` and ``./pep2html.py PEP Number`` to ensure they + are generated without errors. If either triggers errors, then the web site + will not be updated to reflect the PEP changes. Or just run make on systems that have that handy convenience. :) Cheers, -Barry (Nick, if you agree with these changes, please just go ahead and make them.) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] peps: Update PEP 1 to better reflect current practice
On May 05, 2012, at 12:56 PM, Barry Warsaw wrote: before the final PEP can be approved. When an `PEP-Czar` header must be added to the PEP to record this delegation. The format of this header is the same as the `Author` header. s/When an/A/ -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/archive%40mail-archive.com
Re: [Python-Dev] Debian wheezy, amd64: make not finding files for bz2 and other packages
dpkg-architecture -qDEB_HOST_MULTIARCH gives x86_64-linux-gnu Installing dpkg-dev fixed the problem. Now both 3.3a3 and a developmental clone work. There is already a Debian package for 3.3 alpha3. See http://packages.debian.org/source/experimental/python3.3 A large diff for Debian Python is available at this url. The following should be installed before compiling python3. This list may be incomplete. This list may include unnecessary packages. dpkg-dev sharutils libreadline6-dev libreadline5 libncursesw5-dev libncursesw5 zlib1g-dev zlib1g libbz2-dev bzip2 liblzma-dev liblzma5 libgdbm-dev libgdbm3 libdb5.3-dev libdb5.3 tk8.5-dev tk8.5 blt-dev blt libssl-dev libssl1.0.0 libexpat1-dev libexpat1 libbluetooth-dev libbluetooth3 locales libsqlite3-dev libsqlite3 libffi-dev libffi5 libgpm2 libgpm-dev libtinfo-dev libtinfo5 mime-support netbase gdb xvfb xauth python-sphinx (Implemented in python 2) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #14705: Add 'p' format character to PyArg_ParseTuple* for bool support.
2012/5/5 larry.hastings python-check...@python.org: http://hg.python.org/cpython/rev/bc6d28e726d8 changeset: 76776:bc6d28e726d8 user: Larry Hastings la...@hastings.org date: Sat May 05 16:54:29 2012 -0700 summary: Issue #14705: Add 'p' format character to PyArg_ParseTuple* for bool support. files: Doc/c-api/arg.rst | 9 +++ Lib/test/test_getargs2.py | 31 +++ Modules/_testcapimodule.c | 10 Python/getargs.c | 12 ++ 4 files changed, 62 insertions(+), 0 deletions(-) You forgot Misc/NEWS. -- Regards, Benjamin ___ 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/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Update Misc/NEWS for issues #14127 and #14705. (And, technically, #10148.)
2012/5/5 larry.hastings python-check...@python.org: http://hg.python.org/cpython/rev/709850f1ec67 changeset: 76777:709850f1ec67 user: Larry Hastings la...@hastings.org date: Sat May 05 17:39:09 2012 -0700 summary: Update Misc/NEWS for issues #14127 and #14705. (And, technically, #10148.) files: Modules/posixmodule.c | 372 +++-- Um? -- Regards, Benjamin ___ 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/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Update Misc/NEWS for issues #14127 and #14705. (And, technically, #10148.)
larry.hastings python-check...@python.org wrote: Update Misc/NEWS for issues #14127 and #14705. (And, technically, #10148.) + * De-vararg'd PyArg_ParseTupleAndKeywords() This looks like an accidental commit. Is there an issue number for the varargs changes (just out of interest)? Stefan Krah ___ 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/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Update Misc/NEWS for issues #14127 and #14705. (And, technically, #10148.)
On 05/05/2012 06:17 PM, Stefan Krah wrote: larry.hastingspython-check...@python.org wrote: Update Misc/NEWS for issues #14127 and #14705. (And, technically, #10148.) + * De-vararg'd PyArg_ParseTupleAndKeywords() This looks like an accidental commit. Is there an issue number for the varargs changes (just out of interest)? This was indeed an accidental commit, and OMG I'm so sorry about it. Thanks to Benjamin for swooping in and fixing it--I was in full-on panic mode for a few minutes there. I'll commit the proper MISC/News update when I calm down. The varargs thing is part of a proposed patch I'm working up for issue #14626. In case you look it over, keep in mind it was a bit hacked up just then so I could test the Windows path on my Linux box. //arry/ ___ 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/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] peps: Update PEP 1 to better reflect current practice
On Sun, May 6, 2012 at 2:56 AM, Barry Warsaw ba...@python.org wrote: Thanks for doing this update Nick. I have just a few comments. On May 05, 2012, at 02:57 PM, nick.coghlan wrote: +Developers with commit privileges for the `PEP repository`_ may claim +PEP numbers directly by creating and committing a new PEP. When doing so, +the developer must handle the tasks that would normally be taken care of by +the PEP editors (see `PEP Editor Responsibilities Workflow`_). While I certainly don't mind (in fact, prefer) those with commit privileges to just go ahead and commit their PEP to the repo, I'd like for there to be *some* communication with the PEP editors first. E.g. sanity checks on the basic format or idea (was this discussed on python-ideas first?), or reservation of PEP numbers. When you do contact the PEP editors, please also specify whether you have commit privileges or not. It's too hard to remember or know who has those rights, and too much hassle to look them up. ;) Good point, especially for committers that haven't done much PEP editing in the past. OTOH, I'm also happy to adopt an EAFP style rather than LBYL, so that the PEP editors can re-assign numbers or whatever after the fact. We've done this in a few cases, and it's never been that much of a problem. Still, core developers needn't block (for too long) on the PEP editors. I'll see if I can figure out something - I may just put in text like if you're at all unsure about what needs to be done, email the PEP editors anyway. +The final authority for PEP approval is the BDFL. However, whenever a new +PEP is put forward, any core developer that believes they are suitably +experienced to make the final decision on that PEP may offer to serve as +the PEP czar for that PEP. If their self-nomination is accepted by the +other core developers and the BDFL, then they will have the authority to +approve (or reject) that PEP. This process happens most frequently with PEPs +where the BDFL has granted in principle approval for *something* to be done, +but there are details that need to be worked out before the PEP can be +accepted. I'd reword this to something like the following: The final authority for the PEP approval is the BDFL. However, the BDFL may delegate the final approval authority to a PEP czar for that PEP. This happens most frequently with PEPs where the BDFL has granted approval in principle for *something* to be done, and in agreement with the general proposals of the PEP, but there are details that need to be worked out before the final PEP can be approved. When an `PEP-Czar` header must be added to the PEP to record this delegation. The format of this header is the same as the `Author` header. This leave out the whole self-nomination text, which I think isn't very relevant to the official addition of the czar role (sadly, no clever bacronym has come to mind, and BDFOP hasn't really taken off ;). Including the self-nomination wording was deliberate - it summarises the gist of an off-list conversation between Victor, Guido and myself a while back. At the time, I thought the delegation had to come directly from Guido, but it turned out Guido was happy for people to volunteer for the role (or for PEP authors to suggest someone, which pretty much amounts to the same thing), with the acceptance of nominations covered by the same rough consensus rules as checkins (i.e. silence is taken as assent). That way Guido only has to get involved if he is personally interested, or none of the rest of us feel entitled to make the call. Since the way the czar gets appointed is important, I figured it was worth including. (The conversation was a while ago though, so hopefully Guido will chime in if I'm mischaracterising what he wrote at the time) Agreed we should have a new header field to record the BDFL delegate, but I think I'll go with BDFL-Delegate rather than PEP-Czar. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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/archive%40mail-archive.com
