Re: [Python-Dev] syntactic support for sets
On Fri, 2006-02-03 at 11:56 -0800, Josiah Carlson wrote: Donovan Baarda [EMAIL PROTECTED] wrote: [...] Nuff was a fairy... though I guess it depends on where you draw the line; should [1,2,3] be list(1,2,3)? Who is Nuff? fairynuff... :-) Along the lines of not every x line function should be a builtin, not every builtin should have syntax. I think that sets have particular uses, but I don't believe those uses are sufficiently varied enough to warrant the creation of a syntax. I suggest that people take a walk through their code. How often do you use other sequence and/or mapping types? How many lists, tuples and dicts are there? How many sets? Ok, now how many set literals? The absence of sets in early Python, the requirement to import sets when they first appeared, and the lack of a set syntax now all mean that people tend to avoid using sets and resort to lists, tuples, and dicts of None instead, even though they really want a set. Anywhere you see if value in sequence:, they probably mean sequence is a set, and this code would run much faster if it really was, and might even avoid potential bugs because it would prevent duplicates... -- Donovan Baarda [EMAIL PROTECTED] http://minkirri.apana.org.au/~abo/ ___ 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] syntactic support for sets
On Fri, 2006-02-03 at 20:02 +0100, Martin v. Löwis wrote:
Donovan Baarda wrote:
Before set() the standard way to do them was to use dicts with None
Values... to me the {1,2,3} syntax would have been a logical extension
of the a set is a dict with no values, only keys mindset. I don't know
why it wasn't done this way in the first place, though I missed the
arguments where it was rejected.
There might be many reasons; one obvious reason is that you can't spell
the empty set that way.
Hmm... how about {,}, which is the same trick tuples use for the empty
tuple?
--
Donovan Baarda [EMAIL PROTECTED]
http://minkirri.apana.org.au/~abo/
___
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] syntactic support for sets
On Mon, 2006-02-06 at 15:36 +0100, Ronald Oussoren wrote:
On Monday, February 06, 2006, at 03:12PM, Donovan Baarda [EMAIL PROTECTED]
wrote:
On Fri, 2006-02-03 at 20:02 +0100, Martin v. Löwis wrote:
Donovan Baarda wrote:
Before set() the standard way to do them was to use dicts with None
Values... to me the {1,2,3} syntax would have been a logical extension
of the a set is a dict with no values, only keys mindset. I don't know
why it wasn't done this way in the first place, though I missed the
arguments where it was rejected.
There might be many reasons; one obvious reason is that you can't spell
the empty set that way.
Hmm... how about {,}, which is the same trick tuples use for the empty
tuple?
Isn't () the empty tuple? I guess you're confusing this with a single element
tuple: (1,) instead of (1) (well actually it is 1,)
Yeah, sorry.. nasty brainfart...
BTW. I don't like your proposal for spelling the empty set as {,} because
that is entirely non-obvious. If {1,2,3} where a valid way to spell a set
literal, I'd expect {} for the empty set.
yeah... the problem is differentiating the empty set from an empty dict.
The only alternative that occured to me was the not-so-nice and
not-backwards-compatible {:} for an empty dict and {} for an empty
set.
--
Donovan Baarda [EMAIL PROTECTED]
http://minkirri.apana.org.au/~abo/
___
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] syntactic support for sets
Donovan Baarda [EMAIL PROTECTED] wrote: On Fri, 2006-02-03 at 11:56 -0800, Josiah Carlson wrote: Along the lines of not every x line function should be a builtin, not every builtin should have syntax. I think that sets have particular uses, but I don't believe those uses are sufficiently varied enough to warrant the creation of a syntax. I suggest that people take a walk through their code. How often do you use other sequence and/or mapping types? How many lists, tuples and dicts are there? How many sets? Ok, now how many set literals? The absence of sets in early Python, the requirement to import sets when they first appeared, and the lack of a set syntax now all mean that people tend to avoid using sets and resort to lists, tuples, and dicts of None instead, even though they really want a set. Anywhere you see if value in sequence:, they probably mean sequence is a set, and this code would run much faster if it really was, and might even avoid potential bugs because it would prevent duplicates... Maybe they mean set, maybe they don't. 'if obj in seq' is used for various reasons. A quick check of the Python standard library shows that some of the uses of 'if obj in tuple_literal' could certainly be converted into sets, but that ignores the performance impact of using sets instead of short tuples (where short, if I remember correctly, is a length of 3, check the python-dev archives), as well as the module-level contant creation that occurs with tuples. There was probably a good reason why such a thing hasn't happened with lists and dicts (according to my Python 2.4 installation), and why it may not happen with sets. A nontrivial number of other 'if obj in seq' instances actually need dictionaries, the test is for some sort of data handler or headers with a particular name. - Josiah ___ 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] syntactic support for sets
On 2/6/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 2/6/06, Donovan Baarda [EMAIL PROTECTED] wrote:
yeah... the problem is differentiating the empty set from an empty dict.
The only alternative that occured to me was the not-so-nice and
not-backwards-compatible {:} for an empty dict and {} for an empty
set.
How about spelling the empty set as ``set()''? Wouldn't that solve the
ambiguity and the backwards compatibility nicely?
And of course, thanks to the time machine, it has always worked that way:
hesperos:~$ python2.4
Python 2.4.1 (#1, Apr 21 2005, 11:14:17)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type help, copyright, credits or license for more information.
set()
set([])
just like dict(), tuple(), list(), str(), int(), float(), bool(),
complex() -- each type, called without args, returns an instance F of
that type such that bool(F) is False holds (meaning len(F)==0 for
container types, F==0 for number types).
Alex
___
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] syntactic support for sets
On Wed, 2006-02-01 at 13:55 -0500, Greg Wilson wrote:
Hi,
I have a student who may be interested in adding syntactic support for
sets to Python, so that:
x = {1, 2, 3, 4, 5}
and:
y = {z for z in x if (z % 2)}
Personally I'd like this. currently the set(...) syntax makes sets
feel tacked on compared to tuples, lists, dicts, and strings which have
nice built in syntax support. Many people don't realise they are there
because of this.
Before set() the standard way to do them was to use dicts with None
Values... to me the {1,2,3} syntax would have been a logical extension
of the a set is a dict with no values, only keys mindset. I don't know
why it wasn't done this way in the first place, though I missed the
arguments where it was rejected.
As for frozenset vs set, I would be inclined to make them normal mutable
sets. This is in line with the dict without values idea.
Frozensets are to sets what tuples are to lists. It would be nice if
there was another type of bracket that could be used for frozenset...
something like ':1,2,3:'... yuk... I dunno.
Alternatively you could to the same thing we do with strings; add a
prefix char for different variants; {1,2,3} is a set, f{1,2,3} is a
frozen set...
For Python 3000 you could extend this approach to lists and dicts;
[1,2,3] is a list, f[1,2,3] is a frozen list or tuple, {1:'a',2:'b'}
is a dict, f{1:'a',2:'b'} is a frozen dict which can be used as a key
in other dicts... etc.
--
Donovan Baarda [EMAIL PROTECTED]
http://minkirri.apana.org.au/~abo/
___
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] syntactic support for sets
Donovan Baarda wrote:
For Python 3000 you could extend this approach to lists and dicts;
[1,2,3] is a list, f[1,2,3] is a frozen list or tuple, {1:'a',2:'b'}
is a dict, f{1:'a',2:'b'} is a frozen dict which can be used as a key
in other dicts... etc.
Traceback (most recent call last):
File pythondev.py, line 219, in monitor
HyperGeneralizationViolationError: please let your brain cool down before
proceeding
___
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] syntactic support for sets
On Fri, 2006-02-03 at 12:04 +, Donovan Baarda wrote: On Wed, 2006-02-01 at 13:55 -0500, Greg Wilson wrote: [...] Personally I'd like this. currently the set(...) syntax makes sets feel tacked on compared to tuples, lists, dicts, and strings which have nice built in syntax support. Many people don't realise they are there because of this. [...] Frozensets are to sets what tuples are to lists. It would be nice if there was another type of bracket that could be used for frozenset... something like ':1,2,3:'... yuk... I dunno. One possible bracket option for frozenset would be 1,2,3 which I initially rejected because of the possible syntactic clash with the and operators... however, there may be a way this could work... dunno. The other thing that keeps nagging me is set, frozenset, tuple, and list all overlap in functionality to fairly significant degrees. Sometimes it feels like just implementation or application differences... could a list that is never modified be optimised under the hood as a tuple? Could the immutability constraint of tuples be just acquired by a list when it is used as a key? Could a set simply be a list with unique values? etc. -- Donovan Baarda [EMAIL PROTECTED] http://minkirri.apana.org.au/~abo/ ___ 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] syntactic support for sets
Donovan Baarda [EMAIL PROTECTED] wrote:
On Wed, 2006-02-01 at 13:55 -0500, Greg Wilson wrote:
Hi,
I have a student who may be interested in adding syntactic support for
sets to Python, so that:
x = {1, 2, 3, 4, 5}
and:
y = {z for z in x if (z % 2)}
Personally I'd like this. currently the set(...) syntax makes sets
feel tacked on compared to tuples, lists, dicts, and strings which have
nice built in syntax support. Many people don't realise they are there
because of this.
Sets are tacked on. That's why you need to use 'import sets' to get to
them, in a similar fashion that you need to use 'import array' to get
access to C-like arrays.
People don't realize that sets are there because they tend to not read
the what's new in Python X.Y, and also fail to read through the
global module index every once and a while.
I personally object to making syntax for sets for the same reasons I
object to making arrays, heapqs, Queues, deques, or any of the other
data structure-defining modules in the standard library into syntax.
- Josiah
___
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] syntactic support for sets
On Fri, 2006-02-03 at 09:00 -0800, Josiah Carlson wrote: [...] Sets are tacked on. That's why you need to use 'import sets' to get to them, in a similar fashion that you need to use 'import array' to get access to C-like arrays. No you don't; $ python Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 Type help, copyright, credits or license for more information. v=set((1,2,3)) f=frozenset(v) set and frozenset are now builtin. I personally object to making syntax for sets for the same reasons I object to making arrays, heapqs, Queues, deques, or any of the other data structure-defining modules in the standard library into syntax. Nuff was a fairy... though I guess it depends on where you draw the line; should [1,2,3] be list(1,2,3)? -- Donovan Baarda [EMAIL PROTECTED] http://minkirri.apana.org.au/~abo/ ___ 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] syntactic support for sets
Donovan Baarda wrote:
Before set() the standard way to do them was to use dicts with None
Values... to me the {1,2,3} syntax would have been a logical extension
of the a set is a dict with no values, only keys mindset. I don't know
why it wasn't done this way in the first place, though I missed the
arguments where it was rejected.
There might be many reasons; one obvious reason is that you can't spell
the empty set that way.
Frozensets are to sets what tuples are to lists. It would be nice if
there was another type of bracket that could be used for frozenset...
something like ':1,2,3:'... yuk... I dunno.
Readability counts.
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] syntactic support for sets
Raymond: Accordingly,Guido rejected the braced notation for set comprehensions. See: http://www.python.org/peps/pep-0218.html Greg: ...however, the issue could be revisited for Python 3000 (see PEP 3000). So I'm only 1994 years early ;-) Alex: Don't be such a pessimist, it's ONLY 994 years to go! Greg: I was allowing for likely schedule slippage... ;-) G ___ 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] syntactic support for sets
Generator expressions make syntactic support irrelevant: Not when you're teaching the language to undergraduates: I haven't actually done the study yet (though I may this summer), but I'm willing to bet that allowing math notation for sets will more than double their use. (Imagine having to write list(1, 2, 3, 4, 5)...) Accordingly,Guido rejected the braced notation for set comprehensions. See: http://www.python.org/peps/pep-0218.html ...however, the issue could be revisited for Python 3000 (see PEP 3000). So I'm only 1994 years early ;-) Thanks, 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] syntactic support for sets
The PEP records that Tim argued for leaving the extra parentheses. What
would you do with {'title'} -- create a four element set consisting of
letters or a single element set consisting of a string?
This is a moderately-fertile source of bugs for newcomers: judging from
the number of students who come into my office with code that they think
ought to work, but doesn't, most people believe that:
set(1, 2, 3)
is right. I believe curly-brace notation would eliminate this problem.
Thanks,
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] syntactic support for sets
Like many things in Python where people pre-emptively believe one thing or another, the interpreter's corrective feedback is immediate: Yup, that's the theory; it's a shame practice is different. Once the students have progressed beyond academic finger drills and have started writing real code, have you observed a shift in emphasis away from hard-coded literals and towards something like s=set(data) where the data is either read-in from outside the script or generated by another part of the program? The problem is that once people classify something as hard or fragile, they (consciously or unconsciously) avoid it thereafter, which of course means that it doesn't get any easier or more robust, since they're not practicing it. This has been observed in many arenas, not just programming. I agree it's not a compelling reason to add set notation to the language, but I'd rather eliminate the sand traps than reuqire people to learn to recognize and avoid them. Thanks, 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] syntactic support for sets
On Wed, 1 Feb 2006, Greg Wilson wrote: Like many things in Python where people pre-emptively believe one thing or another, the interpreter's corrective feedback is immediate: Yup, that's the theory; it's a shame practice is different. So what mistake(s) *do* your students make? As people have pointed out, the mistake you complain about *does* usually result in an immediate traceback: set(1, 2, 3) Traceback (most recent call last): File stdin, line 1, in ? TypeError: set expected at most 1 arguments, got 3 set(1) Traceback (most recent call last): File stdin, line 1, in ? TypeError: iteration over non-sequence Perhaps this? set(argh) set(['a', 'h', 'r', 'g']) [...] the language, but I'd rather eliminate the sand traps than reuqire people to learn to recognize and avoid them. I'm sure nobody would disagree with you, but of course the devil is in the detail. John ___ 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] syntactic support for sets
On Wed, 1 Feb 2006, Greg Wilson wrote: [...] (Imagine having to write list(1, 2, 3, 4, 5)...) [...] I believe that was actually proposed on this list for Python 3. John ___ 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] syntactic support for sets
On 2/1/06, Greg Wilson [EMAIL PROTECTED] wrote: Generator expressions make syntactic support irrelevant: Not when you're teaching the language to undergraduates: I haven't actually done the study yet (though I may this summer), but I'm willing to bet that allowing math notation for sets will more than double their use. (Imagine having to write list(1, 2, 3, 4, 5)...) Actually, as far as I'm concerned, I'd just love to remove the [ ... ] notation for building lists if good ways could be found to distinguish a list with this one item from a list with the same items as this iterable. list(1, 2, 3) is perfectly easy to explain, more readable, and just as likely to be used, if not more, than cryptic shorthand [1,2,3]. If you want APL, you know where to find it (==on IBM's online store, called APL2!-). Accordingly,Guido rejected the braced notation for set comprehensions. See: http://www.python.org/peps/pep-0218.html ...however, the issue could be revisited for Python 3000 (see PEP 3000). So I'm only 1994 years early ;-) Don't be such a pessimist, it's ONLY 994 years to go! Alex ___ 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] syntactic support for sets
[Greg Wilson]
I have a student who may be interested in adding syntactic support for
sets to Python, so that:
x = {1, 2, 3, 4, 5}
and:
y = {z for z in x if (z % 2)}
would be legal. There are of course issues (what's the syntax for a
frozen set? for the empty set?), but before he even starts, I'd like to
know if this would ever be considered for inclusion into the language.
Generator expressions make syntactic support irrelevant:
x = set(xrange(1,6))
y = set(z for z in x if (z % 2))
y = frozenset(z for z in x if (z % 2))
Accordingly,Guido rejected the braced notation for set comprehensions.
See: http://www.python.org/peps/pep-0218.html
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] syntactic support for sets
At 01:55 PM 2/1/2006 -0500, Greg Wilson wrote:
I have a student who may be interested in adding syntactic support for
sets to Python, so that:
x = {1, 2, 3, 4, 5}
and:
y = {z for z in x if (z % 2)}
would be legal. There are of course issues (what's the syntax for a
frozen set? for the empty set?),
Ones that work now:
frozenset(z for z in x if (z%2))
set()
The only case that looks slightly less than optimal is:
set((1, 2, 3, 4, 5))
But I'm not sure that it warrants a special syntax just to get rid of the
extra ().
___
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] syntactic support for sets
[Phillip J. Eby]
The only case that looks slightly less than optimal is:
set((1, 2, 3, 4, 5))
But I'm not sure that it warrants a special syntax just to get rid of the
extra ().
The PEP records that Tim argued for leaving the extra parentheses.
What would you do with {'title'} -- create a four element set consisting
of letters or a single element set consisting of a string?
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] syntactic support for sets
Raymond Hettinger wrote:
[Phillip J. Eby]
The only case that looks slightly less than optimal is:
set((1, 2, 3, 4, 5))
But I'm not sure that it warrants a special syntax just to get rid of the
extra ().
The PEP records that Tim argued for leaving the extra parentheses.
What would you do with {'title'} -- create a four element set consisting
of letters or a single element set consisting of a string?
I think the answer to this one is clearly that it is a single element
set consisting of a string, just as ['title'] is a single element list
consisting of a string.
I believe the confusion arises if Brett's proposal for ``set(1, 2, 3,
4, 5)`` is considered. Currently, set('title') is a five element set
consisting of letters. But set('title', 'author') would be a two
element set consisting of two strings? The problem is in calling the
set constructor, not in writing a set literal.
That said, I don't think there's really that much of a need for set
literals. I use sets almost exclusively to remove duplicates, so I
almost always start with empty sets and add things to them. And I'm
certainly never going to write ``set([1, 1, 2])`` when I could just
write ``set([1, 2])`.
STeVe
--
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
___
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] syntactic support for sets
[Greg Wilson]
This is a moderately-fertile source of bugs for newcomers: judging from
the number of students who come into my office with code that they think
ought to work, but doesn't, most people believe that:
set(1, 2, 3)
Like many things in Python where people pre-emptively believe one thing
or another, the interpreter's corrective feedback is immediate:
set(1, 2, 3)
Traceback (most recent call last):
set(1, 2, 3)
TypeError: set expected at most 1 arguments, got 3
There is futher feedback in the repr string which serves as a reminder
of how to construct a literal:
set(xrange(3))
set([0, 1, 2])
Once the students have progressed beyond academic finger drills and
have started writing real code, have you observed a shift in emphasis
away from hard-coded literals and towards something like s=set(data)
where the data is either read-in from outside the script or generated by
another part of the program?
For academic purposes, I think the genexp form also has value in that
it is broadly applicable to more than just sets (i.e. dict comprehensions)
and that it doesn't have to grapple with arbitrary choices about whether
{1,2,3} would be a set or frozenset.
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] syntactic support for sets
On Wed, Feb 01, 2006 at 03:03:22PM -0500, Phillip J. Eby wrote: The only case that looks slightly less than optimal is: set((1, 2, 3, 4, 5)) But I'm not sure that it warrants a special syntax just to get rid of the extra (). In any case I don't think it's possible to differentiate between the current calling convention and the 'parenless' one reliably, eg.: S = set([]) There is no way to tell if that is a set containing an empty list created using the parenless syntax, or an empty set, as is created with the current calling convention. -- DISOBEY, v.t. To celebrate with an appropriate ceremony the maturity of a command. ___ 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
