Re: [Python-Dev] PEP 405 (pyvenv) and system Python upgrades
Nick Coghlan 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 [email protected] 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 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 [email protected] 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" 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 [email protected] 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 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 [email protected] 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 [email protected] 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 | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] 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" 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 [email protected] 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 wrote: > Am 05.05.2012 12:36, schrieb Antoine Pitrou: > > > > Hello, > > > > On Fri, 04 May 2012 14:07:28 -0400 > > "Edward C. Jones" 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 [email protected] 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 [email protected] 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 wrote: > This is likely because you don't have dpkg-dev installed. http://bugs.python.org/issue13956 ___ Python-Dev mailing list [email protected] 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 wrote: >> Am 05.05.2012 12:36, schrieb Antoine Pitrou: >>> >>> Hello, >>> >>> On Fri, 04 May 2012 14:07:28 -0400 >>> "Edward C. Jones" 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 [email protected] 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 wrote: > Am 05.05.2012 15:39, schrieb Antoine Pitrou: > > On Sat, 05 May 2012 15:31:24 +0200 > > Christian Heimes wrote: > >> Am 05.05.2012 12:36, schrieb Antoine Pitrou: > >>> > >>> Hello, > >>> > >>> On Fri, 04 May 2012 14:07:28 -0400 > >>> "Edward C. Jones" 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 [email protected] 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
[email protected]
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 [email protected] 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 `` 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 [email protected] 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 [email protected] 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 [email protected] 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 : > http://hg.python.org/cpython/rev/bc6d28e726d8 > changeset: 76776:bc6d28e726d8 > user: Larry Hastings > 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 [email protected] 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 : > http://hg.python.org/cpython/rev/709850f1ec67 > changeset: 76777:709850f1ec67 > user: Larry Hastings > 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 [email protected] 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 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 [email protected] 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.hastings 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 [email protected] 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 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 | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Recording BDFL delegates for PEPs
At Barry's suggestion (following my PEP 1 updates), I've also updated the PEP 0 generation machinery to handle an explicit "BDFL-Delegate" field. You can see an example here with PEP 3151: http://www.python.org/dev/peps/pep-3151/ I also updated the 3 PEPs that are on my plate (405, 415 and 3144). If there's anyone else that got tapped as a PEP czar, please update the corresponding PEPs in the repo. For the moment, I suggest leaving your email address out of this field. The email obfuscation is applied on a field-by-field basis, and the formatter for reStructuredText PEPs actually lives in the docutils upstream rather than being included directly in the PEPs repo the way the plaintext formatter is. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
