Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]
On Fri, Dec 07, 2012 at 05:02:26PM -0500, PJ Eby wrote: > If the packages have files in conflict, they won't be both installed. > If they don't have files in conflict, there's nothing important to be > informed of. If one is installing pexpect-u, then one does not need > to discover that it is a successor of pexpect. In the specific case of pexpect and pexpect-u, the files don't actually conflict. The pexpect package includes a "pexpect.py" file, while pexpect-u includes a "pexpect/" directory. These conflict, but not in the easily detectable sense. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 ___ 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] folding cElementTree behind ElementTree in 3.3
On Wed, Feb 22, 2012 at 04:24:38AM +0200, Eli Bendersky wrote: > > Andrew, could you elaborate on your use case? Are you using cElementTree to > do the parsing, or ElementTree (the Python implementation). Can you show a > short code sample? I'm mostly using ElementTree because several classes/functions that I need are not in cElementTree or behave differently. Specifically, the program loads TreeBuilder, XMLParser, iterparse from ElementTree; the only class from cElementTree that works is Element. A shortened version of the program is available here: http://aml.cs.byu.edu/~amcnabb/gutenberg-short.py By the way, this code is just one example of how one might rely on the documented extensibility of ElementTree. There are probably many other examples out there that look nothing like mine. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 ___ 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] folding cElementTree behind ElementTree in 3.3
On Tue, Feb 21, 2012 at 10:47:43PM +0100, "Martin v. Löwis" wrote: > > I can't fathom why someone would do it though, since bar tiny > > differences (like this one) cET is just a faster ET and it's available > > practically everywhere with CPython. I mean, is it really important to > > be able to subclass ET.Element? What goal does it serve? > > Statements like this make me *extremely* worried. Please try to adopt > a position of much higher caution, accepting that a change is > "incompatible" if there is a remote possibility that someone might > actually rely on the original behavior. Otherwise, I predict that you > will get flooded with complaints that you broke ET for no good reason. I'm happy to stand up as an example of someone who uses a custom Element class. My specific use case is loading the project Gutenberg database, which is a 210MB XML file. I created a custom Element class which I use for the top-level element (a custom element_factory passed to TreeBuilder distinguishes between the top-level element and all others). The custom Element class doesn't add children, so it keeps ElementTree from storing all of the elements its seen so far. On a system with 1 GB of RAM, there was no other way to get the file to load. So, I would be one of those people who would flood in the complaints. :) -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 ___ 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] Proposal for Python 3.3: dependence injection
On Thu, Mar 24, 2011 at 10:12:18AM -0700, Guido van Rossum wrote: > On Thu, Mar 24, 2011 at 9:46 AM, Benjamin Peterson > wrote: > >> I want to test the dev community interest in modifying the stdlib to > >> ease dependence injection. > > > > I, for one, am -1. Code shouldn't be uglified for the purposes of > > testing. > > Well, the philosophy of dependency injection requires exactly that. > Personally I am on the fence; I've seen is used effectively but I've > also seen code, indeed, uglified with little benefits. (Same for other > extreme testing practices like TDD.) I agree with the comments about uglification, but testing was only one of the use cases that Jesus provided. He also mentioned using alternative network implementations, integrating with event loops, etc. Another use case that I've run into before is setting socket options. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 ___ 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 3146: Merge Unladen Swallow into CPython
On Wed, Jan 20, 2010 at 10:13:56PM -0500, Reid Kleckner wrote:
> 2) As a command line option, you can pass -j never. If you have a
> short-lived script, you can just stick this in your #! line and forget
> about it. This has more overhead, since all of the JIT machinery is
> loaded into memory but never used. Right now we record feedback that
> will never be used, but we could easily make that conditional on the
> jit control flag.
Shebang lines are much less useful than they appear because they only
split on the first space. Consider the following script:
#!/usr/bin/env python -tt
print "hello, world"
Running it gives the error because env is given the single argument
("python -tt") instead of two arguments ("python" and "-tt"):
/usr/bin/env: python -tt: No such file or directory
--
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868
___
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] buildtime vs runtime in Distutils
On Sun, Nov 15, 2009 at 03:35:00AM +0100, Christian Heimes wrote: > > Do we really want to change distutils to solve a problem of a third > party packaging system when the problem was created by the very same > third party in the first place? In other words: Should you spend your > precious development time with fixing a problem that isn't our fault? > The decision to split the header files into a separate package, that > isn't installed by default, has already created tons of bad user > experience in the past. Do you want to endorse the split even further? The problem being addressed is that distutils is using an artefact of the build system (a Makefile) as a data file. I think the issue of whether or not to "endorse the split" is a red herring. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 ___ 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] 2.7 Release? 2.7 == last of the 2.x line?
On Tue, Nov 03, 2009 at 12:28:47PM -0500, Arc Riley wrote: > > The main thing holding back the community are lazy and/or obstinate package > maintainers. If they spent half the time they've put into complaining about > Py3 into actually working to upgrade their code they'd be done now. The main reason the package maintainers are so "lazy and/or obstinate" is that Python 2 is much more available than Python 3. For example, work is being completed on a python3 RPM, but it will first appear in Fedora 13, not Fedora 12. RHEL is still using Python 2.4 and won't even get Python 2.6 until RHEL 6 comes out. I don't think it's worth worrying about packages being upgraded to Python 3 when many or most users still don't have access to Python 3. In my opinion, the best place for current efforts is on infrastructure: 1) Python 3 packages for all Linux distributions (I've recently been involved with bringing Python 3 to Fedora) 2) WSGI/mod_python, etc.: according to http://wsgi.org/wsgi/Amendments_1.0 and various blog posts, the WSGI standard isn't defined for Python 3 yet, and the modwsgi page at http://code.google.com/p/modwsgi/ does not yet list a Python 3 release. 3) Numpy/scipy: as others have mentioned, numpy is essential for scientific work, and apparently the project needs help to add support for Python 3 Before basic infrastructure is available for Python 3, it's absurd to expect package maintainers to flock to it. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 ___ 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 389: argparse - new command line parsing module
On Wed, Sep 30, 2009 at 02:40:20PM -0700, Steven Bethard wrote: > > > Also, is it possible to add these subparsers dynamically? For example, > > you would want to be able to load a module immediately after parsing the > > name instead of having to keep a predetermined list of all module names. > > I'm pretty sure that bzr dynamically loads modules this way. Can > > argparse help with this? > > You can probably already do this. I'm not 100% sure what you want to > do, but it's certainly possible to define an argparse.Action that > loads a module when it's invoked. It might look something like:: > > class MyAction(argparse.Action): > def __call__(self, parser, namespace, value, option_string=None): > mod = __import__(value) # or whatever This looks much easier than what I was able to do in optparse. Cool. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 ___ 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 389: argparse - new command line parsing module
On Wed, Sep 30, 2009 at 02:22:53PM -0400, Barry Warsaw wrote: > > Right. I've made it kind of work in Mailman 3, but it would be nice for > argparse to support this out of the box. Note that I think you want two > forms: > > foo help subcommand > foo subcommand --help > > to basically print the same help text. This is the way bzr does it for > example and it works great. In some commands, options as well as subcommands can change subsequent parsing. The iptables command is a good example of a command-line program that follows this practice. From the man page: after [a module name is specified], various extra command line options become available, depending on the specific module. You can specify multiple extended match modules in one line, and you can use the -h or --help options after the module has been specified to receive help specific to that module. In the case of iptables, module names are specified as options, not as subcommands. >From my cursory reading of the documentation, it looks like argparse can only add subparsers for subcommands. Is there any way to add subparsers based on options instead (as iptables does)? Also, is it possible to add these subparsers dynamically? For example, you would want to be able to load a module immediately after parsing the name instead of having to keep a predetermined list of all module names. I'm pretty sure that bzr dynamically loads modules this way. Can argparse help with this? Sorry for all of the questions. I ask them because I have some experience with adding the above features to optparse, and it was a lot of work to get it right. It also seems like there are a lot of programs that need to load modules dynamically. I would be really excited if argparse made this easier than optparse did. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 ___ 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] standard library mimetypes module pathologically broken?
On Fri, Jul 31, 2009 at 09:16:02PM +, Jacob Rus wrote: > > * The operation is crazy: It defines a MimeTypes class which > actually stores the type mappings, but this class is designed to > be a singleton. The way that such a design is enforced is > through the use of the module-global 'init' function, which > makes an instance of the class, and then maps all of the > functions in the module global namespace to instance methods. > But confusingly, all such functions are also defined > independently of the init function, with definitions such as: > > def guess_type(url, strict=True): > if not inited: > init() > return guess_type(url, strict) I can't speak for any of your other complaints, but I know that this weird init stuff is fixed in trunk. For the other stuff, you seem to have some very good points. I'm sure a patch would be welcome. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 ___ 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] Ext4 data loss
On Fri, Mar 13, 2009 at 07:31:21PM +0100, "Martin v. Löwis" wrote: > > Think about the security implications of a file name that is in advance > > known to an attacker as well as the fact that the said file will replace > > an *important* system file. > > You should always use O_EXCL in that case. Relying on random name will > be a severe security threat to the application. But mkstemp does open files with O_EXCL, so the two approaches really aren't that different. Using tempfile can be a little simpler because it will eventually succeed. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 ___ 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] What's New in 2.6 link wasn't what I expected
On Fri, Sep 19, 2008 at 12:49:28AM +0200, "Martin v. Löwis" wrote: > > I clicked the link labelled "What's new in Python 2.6rc2". This didn't take > > me to the What's New page. Instead it took me to: > > > > http://www.python.org/download/releases/2.6/NEWS.txt > > > > Seems a bit mislabelled if nothing else. > > How so? The first major heading in that file reads > > "What's New in Python 2.6 release candidate 2?" > > > Am I missing something? > > Perhaps reading the file that was linked might have helped. I ran into this, too (and I did read the file that was linked to). I had expected to find the "What's New" page describing what was new in Python 2.6, and I would have expected a "Release Notes" link to point to the NEWS.txt page. That's how things were in the past, anyway: http://www.python.org/download/releases/2.5.2/#what-s-new It's a minor thing, but I did have to go hunt down the What's New file. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 pgp2b0NCOqYoh.pgp Description: PGP signature ___ 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] Mini-Pep: Simplifying the Integral ABC
On Thu, Jun 05, 2008 at 09:41:44AM -0700, Bill Janssen wrote: > > I think I agree with Raymond on the basic principle that simple ABC's > > are easier to use than simple ones. > > I don't think he was saying that. He was saying that simple ABC's are > easier to implement to. Sorry; I used the wrong word. I should have said "implement to" rather than "use." I agree with you. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 signature.asc Description: Digital signature ___ 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] Mini-Pep: Simplifying the Integral ABC
On Wed, Jun 4, 2008 at 12:57 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > Not sure how to generate more discussion. It seems self-evident > that an abc with lots of abstract methods is inherently less usable > and that bitwise operations go beyond the basic notion of "integeriness". > Requiring all those methods to be defined makes it harder to write > a compliant class. > > Other than int/long, no currently existing type > matches-up with Integral. Does anyone care about this? > > Hopefully, some discussion gets generated. But if no one cares, I'll > happily drop it. I'm just responding out of duty to add more discussion on the topic. I think I agree with Raymond on the basic principle that simple ABC's are easier to use than simple ones. Anyway, it's hard to add anything to the discussion when I haven't seen many applications of the Integral ABC, but in principle, but if I had to vote I'd say that the bitwise operators aren't particularly integery. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 signature.asc Description: Digital signature ___ 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] Addition of "pyprocessing" module to standard lib.
On Wed, May 14, 2008 at 08:06:15AM -0400, Jesse Noller wrote: > > Overwhelmingly, many of the python programmers I spoke to are looking > for "a solution" that does not require the alteration of a known > programming paradigm (i.e: threads) to allow them to take advantage of > systems which are not getting "faster" - instead, they are getting > wider. Simply put due to the GIL - pure python applications can not > take advantage of these machines which are now more common than not > without switching to an alternative interpreter - which for many - > myself included - is not an attractive option. On Newegg, there are currently 15 single core processors listed, but there are 57 dual core processors and 52 quad core processors. By the time Python 2.6 comes out, it will be hard to buy a new computer without multiple cores. In my opinion, the sooner Python has a nice simple library for inter-process communication, the better. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 pgp4U92STA7VZ.pgp Description: PGP signature ___ 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] Addition of "pyprocessing" module to standard lib.
On Wed, May 14, 2008 at 05:46:25PM +0200, M.-A. Lemburg wrote: > > What I'm missing with the processing module is a way to spawn processes > on clusters (rather than just on a single machine). > > In the scientific world, MPI is the standard API of choice for doing > parallel processing, so if we're after standards, supporting MPI > would seem to be more attractive than the processing module. Think of the processing module as an alternative to the threading module, not as an alternative to MPI. In Python, multi-threading can be extremely slow. The processing module gives you a way to convert from using multiple threads to using multiple processes. If it made people feel better, maybe it should be called threading2 instead of multiprocessing. The word "processing" seems to make people think of parallel processing and clusters, which is missing the point. Anyway, I would love to see the processing module included in the standard library. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 pgp42e26gDfkd.pgp Description: PGP signature ___ 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] Problems with the new super()
On Thu, May 01, 2008 at 12:55:22PM -0700, Guido van Rossum wrote: > > I'm not proud of this, but I don't see a way around it. The > alternative would be to make it a keyword, which seemed excessive > (plus, it would be odd if super() were a keyword when self is not). > There were long discussions about various possible ways to implement > something like this, and they all had their downsides. (The PEP still > isn't fixed to describe the status quo.) I remember some brainstorms about treating more like self. I'm not sure if these were thought through all the way, but I remember seeing something like: class MyClass(Super1, Super2): # This method requires super: @requires_super def __init__(self, super, **kwds): super(**kwds) # This method doesn't require super: def some_method(self): pass I'm sure there are drawbacks, but it fits in my head. Using super in Python 2.0 is verbose but simple. However, I'm a little scared of super in Python 3.0. I guess I'm probably just a wimp. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 signature.asc Description: Digital signature ___ 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] how to easily consume just the parts of eggs that are good for you
On Wed, Apr 09, 2008 at 11:37:07AM +1000, Ben Finney wrote: > > Moreover, many of us already have a database of *all* packages on the > system, not just Python-language ones: the package database of our > operating system. Adding another, parallel, database which needs > separate maintenance, and only applies to Python packages, is not a > step forward in such a situation. I agree with you completely. There are three things I can see myself wanting from an easy_install command: 1) To download and install an RPM/dpkg to a system-wide location. The package is then removable using the normal system package manager. 2) To download the source of a package. 3) To install a package to my home directory. I would much rather that this hypothetical easy_install did `rpm --prefix "$HOME/.local" -ivh some_package.rpm` than have a Python-specific database. > > They both agreed that it made perfect sense. I told one of them > > about the alternate proposal to define a new database file to > > contain a list of installed packages, and he sighed and rolled his > > eyes and said "So they are planning to reinvent apt!". > > That's pretty much my reaction, too. Me, too. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 pgpNRz0ZLDRLL.pgp Description: PGP signature ___ 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] Improved thread switching
On Thu, Mar 20, 2008 at 09:58:46AM -0400, Jesse Noller wrote: > FYI: I shot an email to stdlib-sig about the fact I am proposing the > inclusion of the pyProcessing module into the stdlib. Comments and > thoughts regarding that would be welcome. I've got a rough outline of > the PEP, but I need to spend more time with the code examples. Since we officially encourage people to spawn processes instead of threads, I think that this would be a great idea. The processing module has a similar API to threading. It's easy to use, works well, and most importantly, gives us some place to point people to when they complain about the GIL. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 signature.asc Description: Digital signature ___ 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] trunk-math
On Fri, Feb 15, 2008 at 10:53:14PM -0500, Mark Dickinson wrote: >* New float methods: is_finite, is_inf, is_integer and is_nan. >* New cmath functions: phase, polar and rect, isinf and isnan. >* New complex method: is_finite. This may be a dumb question, but is there any particular reason that the float methods are "is_inf" and "is_nan" but the cmath methods are "isinf" and "isnan"? Anyway, this all looks very useful. Thanks. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 signature.asc Description: Digital signature ___ 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] \u and \U escapes in raw unicode string literals
On Sat, May 12, 2007 at 01:30:52AM +0200, M.-A. Lemburg wrote: > > I wonder how we managed to survive all these years with > the existing consistent and concise definition of the > raw-unicode-escape codec ;-) > > There are two options: > > * no one really uses Unicode raw strings nowadays > > * none of the existing users has ever stumbled across the >"problem case" that triggered all this > > Both ways, we're discussing a non-issue. Sure, it's a non-issue for Python 2.x. However, when Python 3 comes along, and all strings are Unicode, there will likely be a lot more users stumbling into the problem case. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 pgpBqD8o8hnO1.pgp Description: PGP signature ___ 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
