Re: [Python-Dev] *** glibc detected *** gdb: malloc(): smallbin double linked list
Hi, I've compiled Python 2.7 (r27:82500, Nov 2 2010, 09:00:37) [GCC 4.4.3] on linux2 with the following configure options ./configure --prefix=/home/john/local/python-dbg --with-pydebug I've installed numpy and some other packages but when I try to run my extension code under gdb I get the errors below. Does anyone have any ideas of how to track down what's happening here? I imagine I've misconfigured something somewhere. Is valgrind the answer? Thanks, John. Hi John, the right place for asking such questions is the python mailing list python-l...@python.org, please see http://mail.python.org/mailman/listinfo/python-list This python-dev list is for the development *of* python and not development *with* python. For the latter python-list is the appropriate forum. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ 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] adding new function
how can i simply add new functions to module after its initialization (Py_InitModule())? I'm missing something like PyModule_AddCFunction(). This type of question really belongs to python-list aka comp.lang.python which I CC-d now. Please keep the discussion on that list. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ 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] Draft PEP on RSON configuration file format
Finding .ini configuration files too limiting, JSON and XML to hard to manually edit [snip] I call the new format RSON (for Readable Serial Object Notation), and it is designed to be a superset of JSON. Quick question: if JSON is too hard to manually edit, how can RSON be any easier when it is a *superset* of JSON? Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ 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
A question from someone writing C extension modules for python but not involved in python-dev: It has been said that compiling python with --without-llvm would not include unladen swallow and would bypass llvm together with all C++. Basically, as I understand it, --without-llvm gives the 'usual' cpython we have today. Is this correct? If this is correct, I still have one worry: since I wouldn't want to touch the python install most linux distributions ship or most windows/mac users install (or what MS/Apple ships) I will simply have no choice than working with the python variant that is installed. Is it anticipated that most linux distros and MS/Apple will ship the python variant that comes with llvm/US? I suppose the goal of merging llvm/US into python 3.x is this. If this is the case then I, as a C extension author, will have no choice than working with a python installation that includes llvm/US. Which, as far as I undestand it, means dealing with C++ issues. Is this correct? Or the same pure C extension module compiled with C-only compilers would work with llvm-US-python and cpython? Cheers, Danil -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ 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
If this is the case then I, as a C extension author, will have no choice than working with a python installation that includes llvm/US. Which, as far as I undestand it, means dealing with C++ issues. Is this correct? Or the same pure C extension module compiled with C-only compilers would work with llvm-US-python and cpython? As a C extension author you will be fine (the source and linker interface will all still be C-only). Thanks, that is good to hear! Cheers, Daniel C++ extension authors may need to care about making the version of the C++ runtime that they link against match that used internally by CPython/LLVM (although I'm a little unclear on that point myself). -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ 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
A question from someone writing C extension modules for python I doubt that this will have any impact on C extension developers. If this is correct, I still have one worry: since I wouldn't want to touch the python install most linux distributions ship or most windows/mac users install (or what MS/Apple ships) I will simply have no choice than working with the python variant that is installed. Is it anticipated that most linux distros and MS/Apple will ship the python variant that comes with llvm/US? I suppose the goal of merging llvm/US into python 3.x is this. Depends on the distro. My guess is that they will likely provide both as separate packages Yes, it's clear that various packages will be available but what I was asking about is the default python version that gets installed if a user installs a vanilla version of a particular linux distro. It's a big difference for developers of C extension modules to say just install this module and go or first download the python version so-and-so and then install my module and go. But as I understand from you and Nick, this will not be a problem for C extension module authors. (unless one turns out to be clearly 'better'), and potentially even support their parallel installation. That's not unprecedented, just think of different JVM implementations (or even just different Python versions). If this is the case then I, as a C extension author, will have no choice than working with a python installation that includes llvm/US. Which, as far as I undestand it, means dealing with C++ issues. I don't think so. Replacing the eval loop has no impact on the C-API commonly used by binary extensions. It may have an impact on programs that embed the Python interpreter, but not the other way round. Remember that you usually don't have to compile the Python interpreter yourself. Once it's a binary, it doesn't really matter anymore in what language(s) it was originally written. Or the same pure C extension module compiled with C-only compilers would work with llvm-US-python and cpython? That's to be expected. Okay, that's great, basically Nick confirmed the same thing. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ 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] Pronouncement on PEP 389: argparse?
If you're only concerned about 2.X, then yes, optparse will *never* be removed from 2.X. There will be a deprecation note in the 2.X documentation but deprecation warnings will only be issued when the -3 flag is specified. Please see the Deprecation of optparse section of the PEP: http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse I do not think that optparse should be deprecated at. It is good at what it does and its limitations make its starting point less confusing for people with different backgrounds that Python. Compare: http://docs.python.org/library/optparse.html http://argparse.googlecode.com/svn/tags/r101/doc/index.html argparse should be recommended as advanced and more featured variant of optparse - that goes without saying, but forcing people to switch and annoying them with deprecation messages brings only headache. As has been noted already nobody is forcing people to switch. Optparse will be available as a separate package and everybody will be free to install it and will not have any deprecation messages anywhere. Just like optparse is better getopt, the latter could also be useful for people coming from other languages and porting their libraries to Python. I would better concentrate on real code examples how argparse solves problems and would really want to see http://www.python.org/dev/peps/pep-0389/#out-of-scope-various-feature-requests implemented until argparse enters phase where backward incompatible changes in API are impossible. I would prefer to see PEP 389 as a document describing proposed solutions to argument parsing problems rather than petition to replace one library with another. So, it should display common argument parsing scenarios (use cases) with examples that are also useful recipes for documentation. I guess more than 90% people here doesn't have time to read argparse methods descriptions to see what they could be useful for. -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ 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] Sort out formatting differences in decimal and float
Sorry for being a curmudgeon, however...
format(Decimal(1234), '020,g')
'0,000,000,000,001,234'
format(Decimal(1234), '0=20,g')
'0001,234'
Why in the world would you ever want to insert commas as separators and not
use them consistently?
format(Decimal('nan'), '020,g')
' NaN'
format(Decimal('nan'), '0=20,g')
'0NaN'
Why in the world would you ever want to zero pad Nan (or Inf, for that
matter)?
Because you didn't know in advance that the number ending up in your
format call was a nan (or inf)?
Cheers,
Daniel
Stefan The advantage of decimal is that the user has the option to
Stefan suppress commas. The behaviour of float is slightly easier to
Stefan implement in C.
Why? If the user asked for them why would you want to suppress (some of)
them?
--
Psss, psss, put it down! - http://www.cafepress.com/putitdown
___
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 Package Management Roadmap in Python Releases
(*) Remember, however, that Tarek and work on Distribute, and also on bringing pieces of setuptools/Distribute functionality into distutils. But if that's the case then why not work on any third party tool..? like pip or setuptools? It seems are very longwinded process if the only way to work on python is to work on distutils but before doing that you have to first work on distribute and then wait for all the changes to work their way back up the chain.. Actually, I have finally worked out what I want. That is shell support in the python windows distribution so that you can right click an .egg and install it. I don't see how that can be achieved by following the workprocess that you describe above. As has been said by many, you are entirely welcome to work on whatever tool you think is useful. Once you are done you are again welcome to distribute your tool or application to users and see how many users are happy with it. Once you are done with this step as well, you are again encouraged to come back to python-dev and say: In the last X months my app/tool became very popular in the python community. There are Y developers working on the app/tool and there are Z happy users. I'd suggest including it in the python stdlib or I'd suggest coordinating the releases of my app/tool with that of python. At this point a useful conversation can start. Please note that a similarly useful conversation is impossible to take place before all the above steps have been completed. HTH, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ 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] readonly __doc__
Speaking of the __doc__ property, I just noticed the following thing on py3k: class C: pass ... C.__doc__ = hop Traceback (most recent call last): File stdin, line 1, in module AttributeError: attribute '__doc__' of 'type' objects is not writable Happens also with new style classes in python 2.x: Python 2.5.1 (r251:54863, Oct 30 2007, 13:45:26) [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2 Type help, copyright, credits or license for more information. class C(object): pass ... C.__doc__ = 'hello' Traceback (most recent call last): File stdin, line 1, in module AttributeError: attribute '__doc__' of 'type' objects is not writable But not with old style classes: Python 2.5.1 (r251:54863, Oct 30 2007, 13:45:26) [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2 Type help, copyright, credits or license for more information. class C: pass ... C.__doc__ = 'hello' Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ 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] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
My opinion is that this tool exists only because Python doesn't support the installation of multiple versions for the same distributions. This is not at all how I use virtualenv. For me virtualenv is a sandbox so that I don't have to become root whenever I need to install a Python package for testing purposes and to allow me to hop between sets of installed Python packages while developing on multiple Python projects. I also use it as a sandbox for build bots so that multiple bots on the same machine can each build their own projects with just the known dependencies installed. +1 I also don't use virtualenv for supporting multiple versions, but rather for sandboxing, testing and experimentation. To make sure that an app works with the exact dependencies I think it should work with. Also, it's important that the 'global' site-packages typically requires root privileges while installing to a virtualenv doesn't. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ 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 3144 review.
188 (check that, 190) people have downloaded the 2.0 release in the last week (numbers publicly available from the code.google.com). I can't tell you how many (if any) have downloaded it via svn. Downloading and using are not the same thing. Correct, but there is a strong positive correlation between the two. If you have a better method for determining what you would consider an appropriate level of usage, I'm all ears. A good way of determining the level of usage would be pointing to open source projects that are popular in the python community and which incorporate your module. well, the 2.0 release is still new. codesearch.google.com shows some projects using the 1.x release; hopefully some of those 200 downloaders will put up some publicly indexable python code at some point. I think one first needs to wait until this happens, I meana large user base is formed, before a meaningful discussion can be done on whether to include it in the stdlib or not. The long and largely academic thread here I think illustrates this point. Without a large user base it's up to anybody's gut feelings what is 'right' and what 'feels wrong'. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ 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 3144 review.
188 (check that, 190) people have downloaded the 2.0 release in the last week (numbers publicly available from the code.google.com). I can't tell you how many (if any) have downloaded it via svn. Downloading and using are not the same thing. Correct, but there is a strong positive correlation between the two. If you have a better method for determining what you would consider an appropriate level of usage, I'm all ears. A good way of determining the level of usage would be pointing to open source projects that are popular in the python community and which incorporate your module. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ 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] decorator module in stdlib?
Then perhaps you misunderstand the goal of the decorator module. The raison d'etre of the module is to PRESERVE the signature: update_wrapper unfortunately *changes* it. When confronted with a library which I do not not know, I often run over it pydoc, or sphinx, or a custom made documentation tool, to extract the signature of functions. Ah, I see. Personally I rarely trust automatically extracted documentation -- too often in my experience it is out of date or simply absent. Extracting the signatures in theory wouldn't lie, but in practice I still wouldn't trust it -- not only because of what decorators might or might not do, but because it might still be misleading. Call me old-fashioned, but I prefer to read the source code. For instance, if I see a method get_user(self, username) I have a good hint about what it is supposed to do. But if the library (say a web framework) uses non signature-preserving decorators, my documentation tool says to me that there is function get_user(*args, **kwargs) which frankly is not enough [this is the optimistic case, when the author of the decorator has taken care to preserve the name of the original function]. But seeing the decorator is often essential for understanding what goes on! Even if the decorator preserves the signature (in truth or according inspect), many decorators *do* something, and it's important to know how a function is decorated. For example, I work a lot with a small internal framework at Google whose decorators can raise exceptions and set instance variables; they also help me understand under which conditions a method can be called. I *hate* losing information about the true signature of functions, since I also use a lot IPython, Python help, etc. I guess we just have different styles. That's fine. I must admit that while I still like decorators, I do like them as much as in the past. Of course there was a missing NOT in this sentence, but you all understood the intended meaning. (All this BTW is not to say that I don't trust you with commit privileges if you were to be interested in contributing. I just don't think that adding that particular decorator module to the stdlib would be wise. It can be debated though.) Fine. As I have repeated many time that particular module was never meant for inclusion in the standard library. Then perhaps it shouldn't -- I haven't looked but if you don't plan stdlib inclusion it is often the case that the API style and/or implementation details make stdlib inclusion unrealistic. (Though admittedly some older modules wouldn't be accepted by today's standards either -- and I'm not just talking PEP-8 compliance! :-) But I feel strongly about the possibility of being able to preserve (not change!) the function signature. That could be added to functools if enough people want it. My original suggestion for inclusion in stdlib was motivated by this reason alone: I'd like to see an official one way of preserving function signatures by decorators. If there are better ways of doing it than the decorator module, that's totally fine, but there should be one. Cheers, Daniel I do not think everybody disagree with your point here. My point still stands, though: objects should not lie about their signature, especially during debugging and when generating documentation from code. Source code never lies. Debuggers should make access to the source code a key point. And good documentation should be written by a human, not automatically cobbled together from source code and a few doc strings. -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ 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] decorator module in stdlib?
The decorator module [1] written by Michele Simionato is a very useful tool for maintaining function signatures while applying a decorator. Many different projects implement their own versions of the same functionality, for example turbogears has its own utility for this, I guess others do something similar too. Was the issue whether to include this module in the stdlib raised? If yes, what were the arguments against it? If not, what do you folks think, shouldn't it be included? I certainly think it should be. Originally I sent this message to c.l.p [2] and Michele suggested it be brought up on python-dev. He also pointed out that a PEP [3] is already written about this topic and it is in draft form. What do you guys think, wouldn't this be a useful addition to functools? Cheers, Daniel [1] http://pypi.python.org/pypi/decorator [2] http://groups.google.com/group/comp.lang.python/browse_thread/thread/d4056023f1150fe0 [3] http://www.python.org/dev/peps/pep-0362/ -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ 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] Core projects for Summer of Code
Hey guys/gals Summer of Code is ramping up. Every year the common complaint is that not enough Python core projects get proposed by students, and of course a big reason for that is often the only encouragement we offer prospective students is a link to the PEP index. So let's make this year different. Accepted students are paid a total of $4500 to work for roughly 30 hours a week, 12 weeks, on their proposed project. The challenge is finding project ideas for them that could reasonably occupy them for the entire Summer and which the results of their work can be demonstrated. They're being paid for specific projects so Spend the Summer fixing bugs on the tracker is a no-go, and Google has outlined that Summer of Code is about code, not documentation. I've seen and heard that a lot of work is still needed on http://svn.python.org/view/python/trunk both during the 3.1 release cycle, optimization possible all over the place. It'd be great if those of you working closely with this can shout out some ideas, brainstorm a bit. PSF was announced as one of the mentoring orgs today, this week before student applications are open is for students to talk to their prospective mentors and iron out the wrinkles in their plans, so there's not much time to get core project ideas together. How about porting PIL to 3.0? There were many such requests on python-list and image-sig (including mine :)) Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ 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] Core projects for Summer of Code
Summer of Code is ramping up. Every year the common complaint is that not enough Python core projects get proposed by students, and of course a big reason for that is often the only encouragement we offer prospective students is a link to the PEP index. So let's make this year different. Accepted students are paid a total of $4500 to work for roughly 30 hours a week, 12 weeks, on their proposed project. The challenge is finding project ideas for them that could reasonably occupy them for the entire Summer and which the results of their work can be demonstrated. They're being paid for specific projects so Spend the Summer fixing bugs on the tracker is a no-go, and Google has outlined that Summer of Code is about code, not documentation. I've seen and heard that a lot of work is still needed on http://svn.python.org/view/python/trunk both during the 3.1 release cycle, optimization possible all over the place. It'd be great if those of you working closely with this can shout out some ideas, brainstorm a bit. PSF was announced as one of the mentoring orgs today, this week before student applications are open is for students to talk to their prospective mentors and iron out the wrinkles in their plans, so there's not much time to get core project ideas together. How about porting PIL to 3.0? There were many such requests on python-list and image-sig (including mine :)) I have ported it to the stage where its tests passes (which are far from covering all the code) and some of my own tests, there is a git repo on the image-sig that points to it. I wasn't really careful with some of the things (and I would even consider redoing some of them), but only one or two people got a copy of it so apparently people don't want/need it on python 3.0 just yet (not it alone at least). I did a git clone git://gpolo.ath.cx/pil-py3k.git but it failed: gpolo.ath.cx[0: 189.7.18.241]: errno=Connection timed out fatal: unable to connect a socket (Connection timed out) fetch-pack from 'git://gpolo.ath.cx/pil-py3k.git' failed. By the way the reason I think few people checked it out is that people mostly are waiting for an official PIL release that is known to be stable. Did you try making your port part of the official PIL distribution? Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ 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] Core projects for Summer of Code
Summer of Code is ramping up. Every year the common complaint is that not enough Python core projects get proposed by students, and of course a big reason for that is often the only encouragement we offer prospective students is a link to the PEP index. So let's make this year different. Accepted students are paid a total of $4500 to work for roughly 30 hours a week, 12 weeks, on their proposed project. The challenge is finding project ideas for them that could reasonably occupy them for the entire Summer and which the results of their work can be demonstrated. They're being paid for specific projects so Spend the Summer fixing bugs on the tracker is a no-go, and Google has outlined that Summer of Code is about code, not documentation. I've seen and heard that a lot of work is still needed on http://svn.python.org/view/python/trunk both during the 3.1 release cycle, optimization possible all over the place. It'd be great if those of you working closely with this can shout out some ideas, brainstorm a bit. PSF was announced as one of the mentoring orgs today, this week before student applications are open is for students to talk to their prospective mentors and iron out the wrinkles in their plans, so there's not much time to get core project ideas together. How about porting PIL to 3.0? There were many such requests on python-list and image-sig (including mine :)) I have ported it to the stage where its tests passes (which are far from covering all the code) and some of my own tests, there is a git repo on the image-sig that points to it. I wasn't really careful with some of the things (and I would even consider redoing some of them), but only one or two people got a copy of it so apparently people don't want/need it on python 3.0 just yet (not it alone at least). I did a git clone git://gpolo.ath.cx/pil-py3k.git but it failed: gpolo.ath.cx[0: 189.7.18.241]: errno=Connection timed out fatal: unable to connect a socket (Connection timed out) fetch-pack from 'git://gpolo.ath.cx/pil-py3k.git' failed. Thanks for noticing that, maybe more people had this same problem then, I will consider using github or some similar service (or maybe take the chance to bazaar, or mercurial, or svn, or..). By the way the reason I think few people checked it out is that people mostly are waiting for an official PIL release that is known to be stable. Did you try making your port part of the official PIL distribution? I have talked with Fredrik, he said he would be running it on another test suite to check how much of it really works. But, no, I didn't really try pushing it to be integrated into the next PIL release and it also wouldn't be possible without distributing a py3k version only -- I didn't do the port with the ability to work in python 3.x and python 2.x but this can be arranged. Maybe I'm misunderstanding you but I didn't mean to say that this version should work on both python 2.x and python 3.x. Ideally, there would be a PIL distribution for 2.x only and another one for 3.x only. The only thing is that people (myself included) will only be comfortable with the PIL for 3.x version if it comes with the blessings of Fredrik, i.e. if I were you I'd try pushing this with Fredrik. After all if all tests pass including the ones Fredrik has for himself, there should be no problem and I suppose he would be happy to have a PIL for python 3.x. Until then I'd be happy to check out your own port, whenever you have a working repository copy please let us know. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ 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
