Re: [Python-Dev] trunc()
On Jan 25, 2008 11:21 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: ... int() for making ints from the non-fractional portion of a float. To me, the concept of the integer part of a float isn't all that well defined. It's really a property of a particular representation rather than the number itself. You think of it as a string of digits and chop off the part after the point, then turn what's left back into a number. If negative floats were represented in two's complement, for example, then chopping off the digits after the point would give a result more like floor than trunc. -- Greg ___ 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] Incorrect documentation of the raw_input built-in function
Isaac Morland wrote: What about an option (maybe even a default) to send the prompt to stdin? The Postgres command line interface psql appears to do this: $ psql 21 /dev/null Password: $ No, it's probably using the C stdlib routine getpass(). From the man page: The getpass() function displays a prompt to, and reads in a password from, /dev/tty. If this file is not accessible, getpass() displays the prompt on the standard error output and reads from the standard input. So it appears that the official Unix Way prefers using stderr over stdout for prompting, if using the std files for it at all. Writing to stdin would be wrong, since it's usually read-only, even when connected to a terminal. -- Greg ___ 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] refleaks and caches
-On [20080128 03:13], Christian Heimes ([EMAIL PROTECTED]) wrote: Do the int/float free lists cause any trouble or can they eat lots of memory? I hope I am interpreting it correctly, but it seems http://evanjones.ca/memoryallocator/ explanation on that still applies: The worst offenders are integers and floats. These two object types allocate their own blocks of memory of approximately 1kB, which are allocated with the system malloc(). These blocks are used as arrays of integers and float objects, which avoids waste from pymalloc rounding the object size up to the nearest multiple of 8. These objects are then linked on to a simple free list. When an object is needed, one is taken from the list or a new block is allocated. When an object is freed, it is returned to the free list. This scheme is very simple and very fast, however, it exhibits a significant problem: the memory that is allocated to integers can never be used for anything else. That means if you write a program which goes and allocates 100 integers, then frees them and allocates 100 floats, Python will hold on to enough memory for 200 numerical objects. The solution is to apply a similar approach as was described above. Pools could be requested from pymalloc, so they are properly aligned. When freeing an integer or a float, the object would be put on a free list for its specific pool. When the pool was no longer needed, it could be returned to pymalloc. The challenge is that these types of objects are used frequently, so care is required to ensure good performance. Dictionaries and lists use a different scheme. Python always keeps a maximum of 80 free lists and dictionaries, any extra are freed. This is not optimal because some applications would perform better with a larger list, while others need less. It is possible that self-tuning the list size could be more efficient. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ We have met the enemy and they are ours... ___ 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] trunc()
On 2008-01-27 08:14, Raymond Hettinger wrote: . You may disagree, but that doesn't make it nuts. Too many thoughts compressed into one adjective ;-) Deprecating int(float)--int may not be nuts, but it is disruptive. Having both trunc() and int() in Py2.6 may not be nuts, but it is duplicative and confusing. The original impetus for facilitating a new Real type being able to trunc() into a new Integral type may not be nuts, but the use case seems far fetched (we're never had a feature request for it -- the notion was born entirely out of numeric tower considerations). The idea that programmers are confused by int(3.7)--3 may not be nuts, but it doesn't match any experience I've had with any programmer, ever. The idea that trunc() is beneficial may not be nuts, but it is certainly questionable. In short, the idea may not be nuts, but I think it is legitimate to suggest that it is unnecessary and that it will do more harm than good. All this reminds me a lot of discussions we've had when we needed a new way to spell out string.join(). In the end, we ended up adding a method to strings (thanks to Tim Peters, IIRC) instead of adding a builtin join(). Since all of the suggested builtins are only meant to work on floats, why not simply add methods for them to the float object ?! E.g. x = 3.141 print x.trunc(), x.floor(), x.ceil() etc. This approach also makes it possible to write types or classes that expose the same API without having to resort to new special methods (we have too many of those already). Please consider that type constructors have a different scope than helper functions. Helper functions should only be made builtins if they are really really useful and often needed. If they don't meet this criteria, they are better off in a separate module. I don't see any of the suggested helper functions meeting this criteria and we already have math.floor() and math.ceil(). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 28 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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] Upcoming 2.4.5 and 2.3.7 releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 27, 2008, at 2:27 PM, Martin v. Löwis wrote: Along with the release of 2.5.2, I would also like to release new versions of 2.3 and 2.4. These will be security-only releases, and include a few security-relevant bug fixes that are still being finalized. As we don't have the infrastructure to produce full releases of 2.3 or 2.4 anymore, this will be a source release only. As such, it will likely see less testing than other releases, and users will have more difficulties in obtaining the software for their system - the releases will be targeted primarily at system vendors who can chose to include them as security patches in their system updates. If the intent is really to do a source-only releases mostly for system vendors, then I don't see the harm in leaving those changes in. I mean, a vendor is going to cherry pick the ones they want anyway, so let's just make it easy for them to do this. That might mean publishing the svn logs a long with the source release, or publishing each diff and log message separately. I would be bummed to rollback the email package changes. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR50rxnEjvBPtnXfVAQK4UQP/Xbj6YhXAbhqdZBdirgTw3O9dqocgzgT/ 7Sky4fl0WaSTxRJc3/P0E4uR69TixZ5E7z3pt4G0QeKZCjub3l6xzKiJ7dccAWbW V8otTxCyavXN8wW99orBqgB2J+H0BFkHlPJdYOOBigBuWrSn/Ew2wrZeXRnBfz// qBvWbwlA+sE= =u/23 -END 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] refleaks and caches
Jeroen Ruigrok van der Werven wrote: -On [20080128 03:13], Christian Heimes ([EMAIL PROTECTED]) wrote: Do the int/float free lists cause any trouble or can they eat lots of memory? I hope I am interpreting it correctly, but it seems http://evanjones.ca/memoryallocator/ explanation on that still applies: [snip] Yes, the explanation still applies. It took me a while to understand how the free lists are working. Some genius came up with the idea to (ab)use the op_type field of the PyObject struct to link the freed objects. All the time I wondered why it assigns something complete different than a type object to the type field. In patch http://bugs.python.org/issue1953 I've moved the compact code from the PyFloat/Int_Fini functions to two new functions and exposed them as a single Python function gc.compact_freelists(). It doesn't solve the problem described in the text but at least it gives a user the chance to free some memory manually. 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] Upcoming 2.4.5 and 2.3.7 releases
On Sun, Jan 27, 2008 at 08:27:27PM +0100, Martin v. Löwis wrote: For 2.3, there are only few revisions that would be rolled back: r52798, r52803, r52824, r54342. These changes can be reverted if you like; they were added for Jython's sake, but it looks like they've now decided to skip directly to 2.5 compatibility. For 2.4, the list is longer; all changes on the branch since r52382 are candidate for roll-back. I would like to prepare a white-list of patches that should be preserved; if you think any of the patches committed in the 2.4 branch is a security fix, please let me know. r55350 is a security fix for cgitb. --amk ___ 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] Upcoming 2.4.5 and 2.3.7 releases
On Jan 27, 2008 5:11 PM, Barry Warsaw [EMAIL PROTECTED] wrote: On Jan 27, 2008, at 2:27 PM, Martin v. Löwis wrote: Along with the release of 2.5.2, I would also like to release new versions of 2.3 and 2.4. These will be security-only releases, and include a few security-relevant bug fixes that are still being finalized. As we don't have the infrastructure to produce full releases of 2.3 or 2.4 anymore, this will be a source release only. As such, it will likely see less testing than other releases, and users will have more difficulties in obtaining the software for their system - the releases will be targeted primarily at system vendors who can chose to include them as security patches in their system updates. If the intent is really to do a source-only releases mostly for system vendors, then I don't see the harm in leaving those changes in. I mean, a vendor is going to cherry pick the ones they want anyway, so let's just make it easy for them to do this. That might mean publishing the svn logs a long with the source release, or publishing each diff and log message separately. I would be bummed to rollback the email package changes. But which vendor would cherry-pick those changes for 2.3 or 2.4? I presume vendors are also in security-fixes-only mode. Are any of the email package fixes security fixes? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Incorrect documentation of the raw_input built-in function
On Jan 28, 2008 12:35 AM, Greg Ewing [EMAIL PROTECTED] wrote: Isaac Morland wrote: What about an option (maybe even a default) to send the prompt to stdin? The Postgres command line interface psql appears to do this: $ psql 21 /dev/null Password: $ No, it's probably using the C stdlib routine getpass(). From the man page: The getpass() function displays a prompt to, and reads in a password from, /dev/tty. If this file is not accessible, getpass() displays the prompt on the standard error output and reads from the standard input. So it appears that the official Unix Way prefers using stderr over stdout for prompting, if using the std files for it at all. That's a dangerous generalization from just one example. I'd prefer it if you could unearth some POSIX or Linux base document saying this. Writing to stdin would be wrong, since it's usually read-only, even when connected to a terminal. Nowadays, it often is writable I've found, but we still shouldn't assume that. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Py2.6 release schedule
What is the current thinking on this? Is the target still April 2008 as mentioned in PEP361? Are we going to have an alpha sometime soonish? Raymond ___ 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] Incorrect documentation of the raw_input built-in function
-On [20080128 18:57], Guido van Rossum ([EMAIL PROTECTED]) wrote: On Jan 28, 2008 12:35 AM, Greg Ewing [EMAIL PROTECTED] wrote: So it appears that the official Unix Way prefers using stderr over stdout for prompting, if using the std files for it at all. That's a dangerous generalization from just one example. I'd prefer it if you could unearth some POSIX or Linux base document saying this. I cannot find anything explicitly in favour of or against this in POSIX. The stuff quoted below is what I could find. I do not think there's a hard mandate either way, but from my experience of having been a committer for both FreeBSD and DragonFly BSD for a number of years stderr was not preferred for prompting. stderr was always the domain of diagnostics. 3.105 Command Language Interpreter An interface that interprets sequences of text input as commands. It may operate on an input stream or it may interactively prompt and read commands from a terminal. It is possible for applications to invoke utilities through a number of interfaces, which are collectively considered to act as command interpreters. POSIX defines per utility what stdin, stdout and stderr do. The default definition for these is: STDIN There is no additional rationale provided for this section. STDOUT The format description is intended to be sufficiently rigorous to allow post-processing of output by other programs, particularly by an awk or lex parser. STDERR This section does not describe error messages that refer to incorrect operation of the utility. Consider a utility that processes program source code as its input. This section is used to describe messages produced by a correctly operating utility that encounters an error in the program source code on which it is processing. However, a message indicating that the utility had insufficient memory in which to operate would not be described. Some utilities have traditionally produced warning messages without returning a non-zero exit status; these are specifically noted in their sections. Other utilities shall not write to standard error if they complete successfully, unless the implementation provides some sort of extension to increase the verbosity or debugging level. The format descriptions are intended to be sufficiently rigorous to allow post-processing of output by other programs. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ We have met the enemy and they are ours... ___ 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] trunc()
In article [EMAIL PROTECTED], Martin v. Lowis [EMAIL PROTECTED] wrote: If the ambiguity is that 'int' behaviour is unspecified for floats - is it naive to suggest we specify the behaviour? The concern is that whatever gets specified is arbitrary. There are many ways how an int can be constructed from a float, so why is any such way better than the others, and deserves to be the meaning of int()? But something should be specified. Users should be able to expect consistent behavior. Surely there must be some efficiency reason why it is not specified (e.g. it uses a low-level C call that is not specified)??? I agree with the idea of putting trunc in the math library since it seems to similar to floor. -- Russell ___ 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] Incorrect documentation of the raw_input built-in function
-On [20080128 19:51], Jeroen Ruigrok van der Werven ([EMAIL PROTECTED]) wrote: I cannot find anything explicitly in favour of or against this in POSIX. The stuff quoted below is what I could find. I do not think there's a hard mandate either way, but from my experience of having been a committer for both FreeBSD and DragonFly BSD for a number of years stderr was not preferred for prompting. stderr was always the domain of diagnostics. Sorry, I made a mental typo here: but from my experience of having been a committer for both FreeBSD and DragonFly BSD for a number of years stdout was not preferred for prompting. stderr was always the domain of diagnostics. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ We have met the enemy and they are ours... ___ 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] trunc()
In article [EMAIL PROTECTED], Paul Moore [EMAIL PROTECTED] wrote: On 24/01/2008, Jeffrey Yasskin [EMAIL PROTECTED] wrote: int has to be a builtin because it's a fundamental type. trunc() followed round() into the builtins. I have no opinion on whether ceil and floor should move there; it probably depends on how often they're used. Suggestion: - int() has to stay in builtins for obvious reasons. - put *all* of trunc, ceil, floor, round into math. - make int(float) an error I like all of your suggestions except the last one. Remember the problem with a/b depending on whether b happened to be a float or an int? I think you'll be creating a very similar problem here. In my opinion int(foo) should do its best to turn foo into an int with *predictable* behavior. The least surprising behavior for int(float) is probably trunc(float). Personally I prefer round(float), but I doubt it is worth breaking code and retraining everybody. -- Russell ___ 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] refleaks and caches
On Jan 27, 2008 6:08 PM, Christian Heimes [EMAIL PROTECTED] wrote: Brett Cannon wrote: Ignoring whether this is the right thing to do, should this be in sys or in gc? Yeah, good idea. The gc module makes sense. Does it? The gc module is specific to the cyclic-gc system. I don't see that this method is. If cyclic-gc is unavailable, should this function be unavailable too? -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] Incorrect documentation of the raw_input built-in function
On Jan 28, 2008 11:17 AM, Steve Holden [EMAIL PROTECTED] wrote: That's a dangerous generalization from just one example. I'd prefer it if you could unearth some POSIX or Linux base document saying this. While I couldn't locate such a document, it makes sense when you consider that if such a process is part of a pipeline you really don't want the prompts being handled as input by the downstream processes. That's why mv and similar utilities prompt on standard error. I'd be very surprised if you can find a UNIX or Linux shell, for example, that prompts on standard output. Ah, indeed. It looks like Python's prompt indeed gets written to stderr, at least when stdout is redirected to a file. Oddly, when stderr is redirected to a file, the prompt gets written to stdout. This seems backwards then (and not what the shells do -- when stderr isn't interactive, they don't write a prompt at all). But fixing it is delicate -- e.g. getpass very carefully makes sure to write to stdout, not stderr (and to avoid raw_input() and hence GNU readline). And cmd.py (used by pdb.py) also assumes the prompt should go to stdout when it is not using raw_input. I'm beginning to think that, despite the example of the shells, we'd be better off if Python *always* prompted to stdout (or not at all if that's not a tty). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Incorrect documentation of the raw_input built-in function
Guido van Rossum wrote: On Jan 28, 2008 12:35 AM, Greg Ewing [EMAIL PROTECTED] wrote: Isaac Morland wrote: What about an option (maybe even a default) to send the prompt to stdin? The Postgres command line interface psql appears to do this: $ psql 21 /dev/null Password: $ No, it's probably using the C stdlib routine getpass(). From the man page: The getpass() function displays a prompt to, and reads in a password from, /dev/tty. If this file is not accessible, getpass() displays the prompt on the standard error output and reads from the standard input. So it appears that the official Unix Way prefers using stderr over stdout for prompting, if using the std files for it at all. That's a dangerous generalization from just one example. I'd prefer it if you could unearth some POSIX or Linux base document saying this. While I couldn't locate such a document, it makes sense when you consider that if such a process is part of a pipeline you really don't want the prompts being handled as input by the downstream processes. That's why mv and similar utilities prompt on standard error. I'd be very surprised if you can find a UNIX or Linux shell, for example, that prompts on standard output. Writing to stdin would be wrong, since it's usually read-only, even when connected to a terminal. Nowadays, it often is writable I've found, but we still shouldn't assume that. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ 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] Upcoming 2.4.5 and 2.3.7 releases
Martin v. Löwis wrote: If the intent is really to do a source-only releases mostly for system vendors, then I don't see the harm in leaving those changes in. I mean, a vendor is going to cherry pick the ones they want anyway, so let's just make it easy for them to do this. That might mean publishing the svn logs a long with the source release, or publishing each diff and log message separately. It's not just vendors, also end-users who are concerned about the security of their installations. I would be bummed to rollback the email package changes. You don't have to - I will do it for you (although I don't understand fully what to be bummed means). It means I'd be sad. ;) The problem is that I make separate releases of the standalone email package from these branches, so that means that email 3.0.3 or 2.5.10 will have regressions. Unless you're offering to also re-apply these changes after you make the Python releases wink. -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] Incorrect documentation of the raw_input built-in function
While I couldn't locate such a document, it makes sense when you consider that if such a process is part of a pipeline you really don't want the prompts being handled as input by the downstream processes. That's why mv and similar utilities prompt on standard error. No, that doesn't really make sense. If you are in the middle of a pipe, what good does it do to write the prompt to stderr, yet read the user input from stdin? If you really care about processes that run in a pipe, interact with /dev/tty. Regards, Martin ___ 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] Upcoming 2.4.5 and 2.3.7 releases
On Jan 28, 2008 1:47 PM, Barry Warsaw [EMAIL PROTECTED] wrote: Martin v. Löwis wrote: If the intent is really to do a source-only releases mostly for system vendors, then I don't see the harm in leaving those changes in. I mean, a vendor is going to cherry pick the ones they want anyway, so let's just make it easy for them to do this. That might mean publishing the svn logs a long with the source release, or publishing each diff and log message separately. It's not just vendors, also end-users who are concerned about the security of their installations. I would be bummed to rollback the email package changes. You don't have to - I will do it for you (although I don't understand fully what to be bummed means). It means I'd be sad. ;) The problem is that I make separate releases of the standalone email package from these branches, so that means that email 3.0.3 or 2.5.10 will have regressions. Unless you're offering to also re-apply these changes after you make the Python releases wink. This sounds like a special case that we might consider. Though I also wonder if it wouldn't be easiest for you to just create separate branches for the email package rather than rely on the core Python branching structure and release rules. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Upcoming 2.4.5 and 2.3.7 releases
If the intent is really to do a source-only releases mostly for system vendors, then I don't see the harm in leaving those changes in. I mean, a vendor is going to cherry pick the ones they want anyway, so let's just make it easy for them to do this. That might mean publishing the svn logs a long with the source release, or publishing each diff and log message separately. It's not just vendors, also end-users who are concerned about the security of their installations. I would be bummed to rollback the email package changes. You don't have to - I will do it for you (although I don't understand fully what to be bummed means). Regards, Martin ___ 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] Upcoming 2.4.5 and 2.3.7 releases
The problem is that I make separate releases of the standalone email package from these branches, so that means that email 3.0.3 or 2.5.10 will have regressions. Unless you're offering to also re-apply these changes after you make the Python releases wink. If they are there primarily to track any changes that you want to release in the future (i.e. they are the repository of standalone email package), then a solution must be found, I agree. Would it help if I branch branches/release23-maint/Lib/email to branches/email-2.3 ? Or should I branch the entire release23-maint to email-2.3? (branches are cheap in subversion) (*) It would mean that you have to check in future 2.3 fixes of the email package into a different branch, and if you run into security fixes, you need to commit them into two branches (email-2.3 and release23-maint). Same for 2.4. For 2.5, bug fixes could be added until that branch also goes into the security-only mode (i.e. after 2.6 is released). Please let me know what you think. Regards, Martin (*) other locations are possible as well, such as branches/email/2.3 or /email/branches/2.3 ___ 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] functions vs methods (was Re: trunc())
[MvL] I wouldn't want to propose removal of len(), no. However, I do think that adding more builtins (trunc in particular) is bad, especially when they make perfect methods. +1 Raymond ___ 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] Upcoming 2.4.5 and 2.3.7 releases
On Jan 28, 2008, at 4:47 PM, Barry Warsaw wrote: The problem is that I make separate releases of the standalone email package from these branches, so that means that email 3.0.3 or 2.5.10 will have regressions. Releasing the email package from the Python maintenance branches is probably insane. This kind of thing would be less of a problem if the standard library were smaller, and the email package only available separately. It's also why some of us want a smaller standard library. -Fred -- Fred Drake fdrake at acm.org ___ 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] functions vs methods (was Re: trunc())
This is why len() is not a method: map(len, list_of_strings) That's a good use case - but is that the reason? I would think that the true historical reason is that when len() was introduced, there weren't methods in the language. And even when support for methods was added, many types supporting len wouldn't easily support methods (e.g. the string type). What I don't know is to what extent this argument still holds in the presence of listcomps and genexps: [s.len() for s in list_of_strings] However, you still need ``len`` as a function to pass around as a callback in other cases where you need a generic function because the type of your data is not predetermined. You don't *need* it for that; you could also pass around lambda x:x.len() It's clear that you need functions for a functional programming style. However, I would question that typical Python code is inherently functional, and instead I believe that it could just as well or better be object-oriented - it's just that Python mandates functions at certain places. In any event, I consider dropping len() from builtins to be gratuitous breakage, even in 3.0. I wouldn't want to propose removal of len(), no. However, I do think that adding more builtins (trunc in particular) is bad, especially when they make perfect methods. Regards, Martin ___ 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] functions vs methods (was Re: trunc())
On Jan 28, 2008 1:54 PM, Martin v. Löwis [EMAIL PROTECTED] wrote: This is why len() is not a method: map(len, list_of_strings) That's a good use case - but is that the reason? I would think that the true historical reason is that when len() was introduced, there weren't methods in the language. And even when support for methods was added, many types supporting len wouldn't easily support methods (e.g. the string type). Well, there were methods, but there were no special methods, and the length of a sequence was intended to be implemented in C. The very first version of the language (used internally at CWI for a while) didn't even have classic classes -- the only way to add a new type was to write a C extension. What I don't know is to what extent this argument still holds in the presence of listcomps and genexps: [s.len() for s in list_of_strings] However, you still need ``len`` as a function to pass around as a callback in other cases where you need a generic function because the type of your data is not predetermined. You don't *need* it for that; you could also pass around lambda x:x.len() It's clear that you need functions for a functional programming style. However, I would question that typical Python code is inherently functional, and instead I believe that it could just as well or better be object-oriented - it's just that Python mandates functions at certain places. I think that for certain things (e.g. len()) the functional notation is just more readable than the method notation, because it provides more information to the reader: len(x) guarantees to return an int. x.len() has no such guarantee, it could be an unrelated len method on an object that has nothing in common with sequences. In any event, I consider dropping len() from builtins to be gratuitous breakage, even in 3.0. I wouldn't want to propose removal of len(), no. However, I do think that adding more builtins (trunc in particular) is bad, especially when they make perfect methods. No, using trunc(x) makes it clear that the argument and return value are numbers. Using x.trunc() doesn't. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] functions vs methods (was Re: trunc())
One thing I'm beginning to feel more and more strongly about is that round, trunc, ceil and floor all belong in the same category, and either should all be builtins or should all be in math. I should also admit that the 2-arg version of round() was borrowed from ABC, but the use case for it there doesn't map to Python: in ABC it's the only tool you have for floating point formatting on output, while in Python the same thing would typically be done with %.2f % x rather than round(x, 2). New idea: * Drop the existing second argument for round. * Fold ceil(), floor(), trunc(), and round() into a single function: def round(x, mode=): if mode==CEIL: return math.ceil(x) elif mode==FLOOR: return math.floor(x) elif mode==TRUNC: return math.floor(x) if x0 else math.ceil(x) elif mode==ROUND_TO_EVEN: . . . Maybe we don't need a separate function and magic method for every possible rounding mode. Also, I think there was some discussion of changing round() to use statistician's rounding. We might as well make it explicit that this is the new default. Raymond P.S. One place to attach the constants is to the function object, so we would write: x = round(3.1) # ROUND_TO_EVEN x = round(3.1, round.CEIL) . . . ___ 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] Re: functions vs methods (was Re: trunc())
Raymond Hettinger wrote: [snip..] P.S. One place to attach the constants is to the function object, so we would write: x = round(3.1) # ROUND_TO_EVEN x = round(3.1, round.CEIL) . . . Or Python could gain a first class enumeration structure, a type which has proved useful in other languages. ;-) Michael Foord ___ 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/fuzzyman%40voidspace.org.uk -- http://www.manning.com/foord http://www.voidspace.org.uk http://www.ironpython.info ___ 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] functions vs methods (was Re: trunc())
On Jan 28, 2008 4:00 PM, Guido van Rossum [EMAIL PROTECTED] wrote: No, using trunc(x) makes it clear that the argument and return value are numbers. Using x.trunc() doesn't. How often do you expect someone to be looking at code where a trunc() method is being called and the variable could plausibly be both a number or something else? (a Google Code search for def trunc(self) lang:python returns 1 hit) How does the that additional value weigh against the cost of adding another builtin and trying to explain trunc() versus int() to new users? -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises LLC ___ 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] Incorrect documentation of the raw_input built-in function
Jeroen Ruigrok van der Werven wrote: I cannot find anything explicitly in favour of or against this in POSIX. The stuff quoted below is what I could find. 3.105 Command Language Interpreter STDERR This section does not describe error messages that refer to incorrect operation of the utility. What document did this come from? This sounds more like it's talking about what should be described in various sections of a man page, not what should be written to the various streams by a program. Otherwise, a message indicating that the utility had insufficient memory in which to operate would not be described. sounds like an out-of-memory message shouldn't be written to stderr, which I'm fairly sure is not the case! -- Greg ___ 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] functions vs methods (was Re: trunc())
On Jan 28, 2008 2:28 PM, Daniel Stutzbach [EMAIL PROTECTED] wrote: On Jan 28, 2008 4:00 PM, Guido van Rossum [EMAIL PROTECTED] wrote: No, using trunc(x) makes it clear that the argument and return value are numbers. Using x.trunc() doesn't. How often do you expect someone to be looking at code where a trunc() method is being called and the variable could plausibly be both a number or something else? (a Google Code search for def trunc(self) lang:python returns 1 hit) How does the that additional value weigh against the cost of adding another builtin and trying to explain trunc() versus int() to new users? It's all pretty hypothetical at this point. I do think that the *concept* of trunc() is very easy to understand so the cost to the user of having to learn it (only when they encounter code that uses it or feel the need to use it themselves) is negligible. One thing I'm beginning to feel more and more strongly about is that round, trunc, ceil and floor all belong in the same category, and either should all be builtins or should all be in math. I should also admit that the 2-arg version of round() was borrowed from ABC, but the use case for it there doesn't map to Python: in ABC it's the only tool you have for floating point formatting on output, while in Python the same thing would typically be done with %.2f % x rather than round(x, 2). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Incorrect documentation of the raw_input built-in function
Guido van Rossum wrote: On Jan 28, 2008 12:35 AM, Greg Ewing [EMAIL PROTECTED] wrote: So it appears that the official Unix Way prefers using stderr over stdout for prompting, if using the std files for it at all. That's a dangerous generalization from just one example. I'd prefer it if you could unearth some POSIX or Linux base document saying this. Well, it makes sense in the context of the general Unix philosophy that stdout is for the result that the program is computing, and therefore shouldn't be polluted by error messages or other extraneous things. Also, the Python interpreter itself appears to write its prompts to stderr, both with and without readline. -- Greg ___ 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] Py2.6 release schedule
Guido van Rossum wrote: I do think that another (final) 3.0 alpha before PyCon would also be a good idea. This way we can gel the release some more. For 2.6 I think we'll need more alpha releases after PyCon; I doubt the backporting from 3.0 (which has only started seriously quite recently) will be done by PyCon. I've back ported class decorators (http://bugs.python.org/issue1759). Two tests are failing and I need some help to solve the riddle. Several back ports like the bytearray type and the new io module depend on a back port of the new buffer protocol. Travis, can you please increase your priority on the port of your PEP to 2.6? 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] functions vs methods (was Re: trunc())
Please ignore my last email. The idea for combining trunc, ceil, floor, etc was probably just a distractor. [GvR] One thing I'm beginning to feel more and more strongly about is that round, trunc, ceil and floor all belong in the same category, and either should all be builtins or should all be in math. +1 for all four going into the math module. I should also admit that the 2-arg version of round() was borrowed from ABC, but the use case for it there doesn't map to Python: in ABC it's the only tool you have for floating point formatting on output, while in Python the same thing would typically be done with %.2f % x rather than round(x, 2). +1 for deprecating the second argument to round(). Raymond ___ 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] Upcoming 2.4.5 and 2.3.7 releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 28, 2008, at 5:08 PM, Martin v. Löwis wrote: Would it help if I branch branches/release23-maint/Lib/email to branches/email-2.3 ? Or should I branch the entire release23-maint to email-2.3? (branches are cheap in subversion) (*) I just realized there's a good solution to this. The sandbox has an emailpkg directory with subdirectories for each of the email package releases. Currently, the actual code gets svn:external'd in from the Python branches, but for email 2.5 and 3.0 we should just svn copy the branches into here and remove the svn:external definitions. I'm not able to do this right now, but I should be able to do this in the next day or so if you don't beat me to it. It would mean that you have to check in future 2.3 fixes of the email package into a different branch, and if you run into security fixes, you need to commit them into two branches (email-2.3 and release23-maint). Using the above scenario, that would be fine. Same for 2.4. For 2.5, bug fixes could be added until that branch also goes into the security-only mode (i.e. after 2.6 is released). So for now, we'll leave email 4.0 external'd in from the Python 2.5 branch. When 2.6 is released, we'll svn copy that in like we did above. The only catch is that it would probably be best to rev the email package version number in Python 2.6 just to be clear it's a different branch. 4.1.0 would be a fine number even if it's mostly just a bookkeeping trick. Please let me know what you think. What do you think of the above? Thanks! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR558knEjvBPtnXfVAQL1vQQAmjNPN27scZ2Tl/ayEnggZOym8U1MEdgP zvBvfbCrp0V4dSF/zddYjB61+9uRP4bN10oNEbwPKUifJ/me5o6qkguLeO56qzqH fs2rTWUlRXKR27g8WDV0B/KL0F5vpd+3PglQI/TfmSbcZjzAlGIMIY/k27bCL4Hy z9XE+LOmNjU= =ZCyu -END 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
[Python-Dev] Announcing the Python core sprint at PyCon 2008
As has occurred since the inception of PyCon, there will be a sprint on the Python core at this year's conference! If you will be attending PyCon (or will be in Chicago during the dates of the sprints), attending the sprint is a great way to give back to Python. Working on Python itself tends to deepens one knowledge of the language and the standard library. Plus it is just plain fun getting to sit around some tables with fellow Python programmers for several days (the sprint will last four days, but you do not need to attend all four days to participate). The sprint is open to everyone of all skill levels. We can always use help with things from updating documentation to preparing for the next release of Python 3.0. On Sunday evening of the conference there will not only be a sprint intro session, but also a tutorial on how to develop for Python. Details will be covered from where to look in the code base for things to some best practices tips. If you are interested enough to want to sign up to attend, please go to http://wiki.python.org/moin/PyCon2008/SprintSignups/Python and add your name and email address. If you have questions you may email me. Please sign up for the sprint by the end of February as an email on what you need to do beforehand will be sent at that time based on the sprint sign-up page. And if you are not attending PyCon, we will most likely have several people in attendance on IRC, thus allowing even people not at PyCon to participate! -Brett Cannon Python core sprint coach, PyCon 2008 ___ 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] functions vs methods (was Re: trunc())
No, using trunc(x) makes it clear that the argument and return value are numbers. Using x.trunc() doesn't. Not sure where this is notion comes from. Terry Reedy's post provides a datapoint to the contrary. Besides, there is no problem along these lines that can't be cured by a better method name: f.integer_portion() Also, if you go the method route, then the API can easily be expanded to cover all the normal rounding methods: f.round_to_even() f.round_half_up() ... These are all specific and explicit. Also, we can take advantage of the ABC mixin capabilities to automatically provide all of these given one or two of them as primitives. Raymond P.S I get no shortage of hits for searches like: http://www.google.com/search?q=truncate+string ___ 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] trunc()
[Terry Reedy] For one data point, I asked my bright 13-year-old for the 'integer part' of 3.1, 3.9, -3.1, and -3.9 and got the expected 3,3,-3,-3 (as with int()). But asking 'truncate' the same numbers or even 'truncate toward zero' got a blank stare, which did not surprise me too much as it is not a common (American) English word. Even to adults, the word has other meanings: http://en.wikipedia.org/wiki/Truncation_%28disambiguation%29 Raymond ___ 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] trunc()
On Jan 27, 2008 3:37 PM, Terry Reedy [EMAIL PROTECTED] wrote:
The actual claim seems to have been that the semantics of int(float)
itself is fuzzy. This in turn seems to be based one of two ideas (I am not
sure which)
a. 'int' might either mean to some people 'some int associated with the
float input' rather than the more precise 'the integer part of the float
input', or
Just like set(sequence) is the set associated with that sequence, not
the set part of that sequence, and float('3.14') is the float
associated with '3.14', not the float part of '3.14', etc. Type names
do not normally retrieve pieces of other objects. When there's no
unique or otherwise special instance of a given type associated with
an instance of another type, the first should not take the second in
its constructor. (This does not imply the inverse.)
On the other hand, to retrieve a piece of another object, you do
normally call a member on that object, so I'd have no objections to
changing trunc() and round() (although the second isn't strictly
retrieving a piece) to methods.
b. that some people might think the latter means the same as the former.
I don't understand this sentence. I haven't seen anyone advocating
trunc() say that some int associated with means the same as the
integer part of.
Possibility a is easy taken care of by documentation, especially when the
behavior is what people expect.
I'll grant that the behavior is relatively easily learned. It'll take
some more evidence to convince me that it's what people expect, given
that it _looks_ like a type conversion, and many systems implement
that conversion by rounding.
Possibility b conflicts with what I
believe to be both the plain English meaning of 'integer part' and what I
believe Americans, at least, learn in elementary school.
You may understand the same thing from int and integer part, but
that's a learned association that I didn't have before either you or
Raymond brought it up. Among their other differences, int is not an
English word.
Moreover, I challenge the notion that 'truncate' is unambiguous. It simply
means to cut off, without specifying how much. '3.141' is pi truncated to
3 decimal places. Indeed, it would not be unreasonable to expect trunc()
to have a second parameter specifying where to cut.
No more unreasonable than round() having the same second parameter.
And it would be reasonable to default it to 0 as round() does, since
that's the only distinguished point in its range.
For one data point, I asked my bright 13-year-old for the 'integer part' of
3.1, 3.9, -3.1, and -3.9 and got the expected 3,3,-3,-3 (as with int()).
But asking 'truncate' the same numbers or even 'truncate toward zero' got a
blank stare, which did not surprise me too much as it is not a common
(American) English word.
You asked a different question than the one we're talking about. You
should have asked your 13-year-old what the int of 3.9 was, or, even
better, how to convert 3.9 to an integer. For the first, you'd likely
have gotten the same blank stare. For the second, I expect you'd have
gotten either 4, or an objection that it's simply not an integer and
can't be converted to one.
--
Namasté,
Jeffrey Yasskin
___
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] trunc()
On Jan 28, 2008 8:00 PM, Steve Holden [EMAIL PROTECTED] wrote: I wish this thread could be truncated. It's got me going round and round. I'm completely floored, and will doubtless end up barking mad - you know, like a ceil. Me too. All the arguments have been repeated over and over. It really isn't worth more energy at this point; I see a use for trunc() separate from int() and I really don't care if Raymond doesn't see it. Let's move trunc() to the math module and be done with it, leaving round() a built-in with both the one- and two-argument versions intact. PS. There's something wrong with Raymond's mailer that creates a thread in gmail whenever he responds. I suspect it's not correctly adding an In-reply-to header. That makes the thread feel much more disconnected than most, because often the quoted text is in a different thread. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] trunc()
Raymond Hettinger wrote: [Terry Reedy] For one data point, I asked my bright 13-year-old for the 'integer part' of 3.1, 3.9, -3.1, and -3.9 and got the expected 3,3,-3,-3 (as with int()). But asking 'truncate' the same numbers or even 'truncate toward zero' got a blank stare, which did not surprise me too much as it is not a common (American) English word. Even to adults, the word has other meanings: http://en.wikipedia.org/wiki/Truncation_%28disambiguation%29 I wish this thread could be truncated. It's got me going round and round. I'm completely floored, and will doubtless end up barking mad - you know, like a ceil. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ 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] Upcoming 2.4.5 and 2.3.7 releases
What do you think of the above? Sounds fine to me. I won't touch this then for the moment, please let me know when you are done rearranging things. Regards, Martin ___ 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] functions vs methods (was Re: trunc())
Raymond Hettinger wrote: Please ignore my last email. The idea for combining trunc, ceil, floor, etc was probably just a distractor. I was going to suggest the same round(n, mode=round_method_of choice) to both round and int(), where int is more forgiving for input. But wasn't convinced. [GvR] One thing I'm beginning to feel more and more strongly about is that round, trunc, ceil and floor all belong in the same category, and either should all be builtins or should all be in math. +1 for all four going into the math module. Works for me. It seems simple enough to just do ... from math import round_even as round This gives me the specific rounding behavior I want without a lot of noise. Ron I should also admit that the 2-arg version of round() was borrowed from ABC, but the use case for it there doesn't map to Python: in ABC it's the only tool you have for floating point formatting on output, while in Python the same thing would typically be done with %.2f % x rather than round(x, 2). +1 for deprecating the second argument to round(). Raymond ___ 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/rrr%40ronadam.com ___ 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
