Re: [Python-Dev] Making builtins more efficient
| [ Raymond Hettinger ]: | > If someone really cared about the double lookup, they could | > flatten a level by starting their modules with: | > | >from __builtin__ import * | > | > However, we don't see people writing this kind of code. That | > could mean that the double lookup hasn't been a big concern. [ Steven Elliott <[EMAIL PROTECTED]> ]: | It could mean that. I think what you are suggesting is sufficiently | cleaver that the average Python coder may not have thought of it. | | # small cut | | And the "from __builtin__ import *" additionally imposes a startup | cost and memory cost (at least a word per builtin, I would guess). I suppose that if someone decided to use "from __builtin__ import *" to avoid double lookup, this person *knows* what builtins should be optmized, and therefore could use import specific builtins "from __builtin__ import len, max" avoiding a startup/memory penalty. Otherwise, the startup/memory penalty might be non-issues. cheers, Rod Senra ___ 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 340 keyword: after
On Thu, 05 May 2005 14:58:02 +0200
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I haven't followed the PEP 340 discussion in detail,
> but as the PEP doesn't list keywords that have been
> considered and rejected, I'd like to propose my own:
> use "after" instead of "block":
>
> after opening("/etc/passwd") as f:
> for line in f:
> print line.rstrip()
>
> after locking(myLock):
> # code that needs to hold the lock
>
And *after* fits very nice for the examples above.
However, it might get weird for:
after transaction(db):
# code inbetween new_trasn/ commit_or_abort
The code pattern that will 'wrap' the block might
not always make sense with the chosen keyword, if
that keyword is not semantically neutral.
(not time-related, not function-related, etc).
Notice that is _no keyword_ is chosen, nothing prevents us
from using (even if by aliasing):
after_opening("/etc/passwd") as f:
for line in f:
print line.rstrip()
after_locking(myLock):
# code that needs to hold the lock
My two cents.
Senra
--
Rodrigo Senra
--
MSc Computer Engineerrodsenra(at)gpr.com.br
GPr Sistemas Ltdahttp://www.gpr.com.br/
Personal Blog http://rodsenra.blogspot.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] PEP 340 -- loose ends
[ Reinhold Birkenfeld ]: > Well, with it you could create suites with _any_ introducing > identifier. Consider: > > with: > (...) > > synchronized: > (...) > > try: > (...) > > transaction: > (...) > > > Do you understand my concern? I definetely see your point. However,... > It would be very, very hard to discern > these "user-defined statements" from real language constructs. - today it is hard to distinguish a user-defined function from a builtin function. What is the problem with the former (anonymous blocks) that is accepted for the later (functions). I guess the solution is the same for both: documentation. - 'try' would probably be an invalid identifier/expression in a block, as well as any other reserved words. So no confusion arises from '''try:''' nor '''while''' nor '''for''' nor '''except''' etc [ Ka-Ping Yee ]: > My point is There are good reasons why the language has keywords, why it > distinguishes statements from expressions, uses indentation, and > so on. All of these properties cause Python programs to be made > of familiar and easily recognizable patterns instead of degenerating > into a homogeneous pile of syntax. I am completely in favour of preserving Python's readability and simplicity. But metaclasses and decorators introduced opportunities for some magical spells. Either you know their definition and how they modify its subjects or your code understanding might be harmed to a certain degree. They were born without being baptized with a keyword, why should blocks ? I think that the absence of 'name clashing', alone, is the strong argument in favour of the __no keyword__ proposal. Recognizing a __no keyword__ block would be very easy. If you did not recognize it as something you already knew, then it was a block <0.2 wink>. best regards, Senra -- Rodrigo Senra -- MSc Computer Engineerrodsenra(at)gpr.com.br GPr Sistemas Ltdahttp://www.gpr.com.br/ Personal Blog http://rodsenra.blogspot.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] PEP 340: Breaking out.
[ Shane Hathaway ]: > I'd like to suggest a small language enhancement that would fix this > example. Allow the break and continue statements to use a keyword, > either "for" or "while", to state that the code should break out of both > the block statement and the innermost "for" or "while" statement. The > example above would change to: > > for name in filenames: > opening(name) as f: > if f.read(2) == 0xFEB0: > break for > > This could be a separate PEP if necessary. When a "break for" is used > in a block statement, it should raise a new kind of exception, > BreakForLoop, and the block statement should propagate the exception. > When used outside a block statement, "break for" can use existing Python > byte code to jump directly to the next appropriate statement. What about nested blocks ? When they act as iterators that would be desireable too. What to do then: - baptize blocks -> break - keep them anonymous -> break #enclosing_scope_counter - do not support them cheers, Senra -- Rodrigo Senra -- MSc Computer Engineerrodsenra(at)gpr.com.br GPr Sistemas Ltdahttp://www.gpr.com.br/ Personal Blog http://rodsenra.blogspot.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] PEP 340 -- loose ends
[ Senra ]:
> > [ Guido ]:
> > > 1. Decide on a keyword to use, if any.
> >
> > Shouldn't be the other way around ?
> > Decide to use *no* keyword, if that could be avoided.
[ Reinhold ]:
> There is one problem with using no keyword: You cannot use arbitrary
> expressions
> in the new statement. Consider:
>
> resource = opening("file.txt")
> block resource:
> (...)
>
> resource = opening("file.txt")
> resource:
> (...)
>
> The latter would have to be forbidden.
I'm not quite sure why, but there seem to be a
workaround (forseen in PEP 340). And people seem
to be "using" this already <0.5 wink>:
[Alex Martelli]:
> for name in filenames:
> opening(name) as f:
> if f.read(2) == 0xFEB0: break
Moreover, an anonymous block should have
no <> (neither 'block', 'with', 'using')
to be true anonymous <1.0-Tim-Peter'ly wink>
cheers,
Senra
--
Rodrigo Senra
--
MSc Computer Engineerrodsenra(at)gpr.com.br
GPr Sistemas Ltdahttp://www.gpr.com.br/
Personal Blog http://rodsenra.blogspot.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] Pre-PEP: Unifying try-except and try-finally
[ Guido ]: > Nice one. Should be a piece of cake to implement. Please talk to > [EMAIL PROTECTED] about getting it checked into the PEP database. > > I'm +1 on accepting this now -- anybody against? +1 Last week, while I was giving a Python course (in Rio de Janeiro-Brazil) some students attempted to use try/except/finally blocks. I had to dig the grammar to prove to them that it was __not already__ supported. cheers, Senra -- Rodrigo Senra -- MSc Computer Engineerrodsenra(at)gpr.com.br GPr Sistemas Ltdahttp://www.gpr.com.br/ Personal Blog http://rodsenra.blogspot.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] PEP 340 -- loose ends
[ Guido ]: > 1. Decide on a keyword to use, if any. Shouldn't be the other way around ? Decide to use *no* keyword, if that could be avoided. In my large inexperience *no keyword* is much better (if feasible): 1) No name conflicts with previous code: block, blocktemplate, whatever 2) ':' is already a block (broader sense) indication 3) Improved readbility: <> def locking_opening(lock, filename, mode="r"): block locking(lock): block opening(filename) as f: yield f <> def locking_opening(lock, filename, mode="r"): locking(lock): opening(filename) as f: yield f 4) Better to make the language parser more complex than the language exposed to end-users Following the PEP and this thread, it seems to me that __no keyword__ is less preferable than __some keyword__(=='block' so far), and I wonder why is not the reverse. Perhaps I missed something ? Besides, I think this solves many issues AOP was trying to tackle in a much cleaner, elegant -- therefore pythonic -- way. Outstanding. best regards, Senra -- Rodrigo Senra -- MSc Computer Engineerrodsenra(at)gpr.com.br GPr Sistemas Ltdahttp://www.gpr.com.br/ Personal Blog http://rodsenra.blogspot.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] defmacro (was: Anonymous blocks)
[ Michael Walter ]: > A couple of examples out of my tired head (solely from a user perspective) :-) > > Embedding domain specific language (ex.: state machine): > ... > > Embedding domain specific language (ex.: markup language): > ... > > Embedding domain-specific language (ex.: badly-designed database table): > ... > > ..., which might actually prove someone's point that the > language designer shouldn't allow people to do such things. The whole macros issue comes to a tradeoff between power+expressiviness X readability. IMVHO, macros are readability assassins. The power (for any developer) to introduce new syntax is *not* a desirable feature, but something to be avoided. And that alone should be a stronger argument than a hundred use cases. cheers, Senra -- Rodrigo Senra -- MSc Computer Engineerrodsenra(at)gpr.com.br GPr Sistemas Ltdahttp://www.gpr.com.br/ Personal Blog http://rodsenra.blogspot.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] Re: anonymous blocks
[ Simon Percivall ]: > [ Terry Reedy ]: > > with as : > > > > would parallel the for-statement header and read smoother to me. > > > > for as : > > > > would not need new keyword, but would require close reading to > > distinguish > > 'as' from 'in'. > > But it also moves the value to the right, removing focus. Wouldn't > "from" > be a good keyword to overload here? > > "in"/"with"/"for"/"" from : > I do not have strong feelings about this issue, but for completeness sake... Mixing both suggestions: from as : That resembles an import statement which some may consider good (syntax/keyword reuse) or very bad (confusion?, value focus). cheers, Senra -- Rodrigo Senra -- MSc Computer Engineerrodsenra(at)gpr.com.br GPr Sistemas Ltdahttp://www.gpr.com.br/ Personal Blog http://rodsenra.blogspot.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] Re: webbrowser.py
| > On Thu, Mar 24, 2005 at 11:36:41AM -0300, Rodrigo Dias Arruda Senra wrote: | > > Edit libwebbrowser.tex as you see fit, then send it to me | > > and I'll TeXify it back to you. | > | >Uploaded to http://python.org/sf/754022 . I am not a native English | > speaker, and this is the first time I've edited a TeX file. Please | > correct my grammar, spelling, TeX, whatever... Outstanding work Oleg. I read it through and wouldn't change a bit. I have revised: libwebbrowser.tex.patch and webbrowser.py.patch. They are Ok regarding grammar, TeX and ... whatever . I recommend to apply both files. However, I would withdraw the third file -- webbrowser wrapper script, since the same functionality can be accomplished with: python -m webbrowser http://www.python.org best regards, Senra -- ,_ | ) Rodrigo Senra |(__ --- _((|__|] GPr Sistemas http://www.gpr.com.br _ |(|___|] IC - Unicamp http://www.ic.unicamp.br/~921234 ___(|__|] L___(|_|]--- ___ 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] Re: webbrowser.py
On Thu, 24 Mar 2005 17:13:30 +0300 Oleg Broytmann <[EMAIL PROTECTED]> wrote: > On Thu, Mar 24, 2005 at 11:11:11AM -0300, Rodrigo Dias Arruda Senra wrote: > > However, if you could make the necessary changes to the documentation, > >I'll try, but certainly not in TeX format... Edit libwebbrowser.tex as you see fit, then send it to me and I'll TeXify it back to you. tchau, Rod -- Rodrigo Senra MSc Computer Engineer [EMAIL PROTECTED] GPr Sistemas Ltda http://www.gpr.com.br ___ 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] Re: webbrowser.py
On Thu, 24 Mar 2005 16:30:35 +0300 Oleg Broytmann <[EMAIL PROTECTED]> wrote: >I've reworked the patch once more. I moved some common functionality > into the UnixBrowser class and added two new features ... I do not want to abuse your generosity. However, if you could make the necessary changes to the documentation, since it will be easier to you than anyone else right know, I'll gladly check the consistency between code and docs. tchau, Senra -- Rodrigo Senra rsenra _at_ acm _dot_ org http://www.ic.unicamp.br/~921234 ___ 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] Re: webbrowser.py
On Wed, 23 Mar 2005 21:29:30 +0300 Oleg Broytmann <[EMAIL PROTECTED]> wrote: > Suggested resolutions: > http://python.org/sf/754022 >Review and apply! ;) Reviewed. Thank you Oleg, fine integration job. I added a +1 comment to the tracker and copied your remaining obs to 754022 history. So a commiter-dev just have to mind about 754022. >I also added elinks support - currently it is very similar to links, > but I am going to extend its remote capabilities. (Yes, that small > text-mode broswer supports remoting, windows and tabs! Who'd think?!.) >Also I'm going to add "new-tab" support similar to "new-window" for > Mozilla/Firefox and elinks. Excellent. cheers, Rod Senra ___ 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@python.org
[Rod Senra]: > > Under some linux distros (I'm positive for some Mdk releases), Mozilla is > > compiled dumping a lot of info to stdout/stderr. Since one of the goals of > > webbrowser is to give the end-user a stress-free experience, there goes the > > mentioned nullification . [Oleg Broytmann]: > > I see the point. Still I don't know what is worse and more stressful > to hide errors or to show errors. > MandrakeZilla spits too much to stdout/err? That's certainly a > problem. Should we "fix" it and hide from the user? I don't think so. That is undoubtly a good argument. In general, if the end user could fix or report a problem based on a stdout/stderror message, I couln't agree more on keeping them flowing. However, there are two other issues: 1) If a *graphical* application dumps messages to the console, that might be disruptive to other console applications. IMVHO, a log file should be used instead. (strong argument) 2) If a dummy user sees a warning or info message in stdout/stdin that is not necessarily critical, it might interpret it wrongly as a error message and generate a false bug report. (weak argument) In the case of webbrowser.py, since detection process might face a diverse plethora of browsers (even unknown if defined by environment variables), we cannot predict if 1) or 2) will ever happen. Therefore, my -1 vote in my previous reply. But I do see your point . Has this same issue been dealt in another stdlib module ? best regards, Rod Senra ___ 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@python.org
On Wed, 23 Mar 2005 15:40:20 +0300 Oleg Broytmann <[EMAIL PROTECTED]> wrote: > Hello! > >While I'm working on webbrowser... Great. > Why do all graphical browsers are called with their stdout/stderr redirected > to /dev/null? Under some linux distros (I'm positive for some Mdk releases), Mozilla is compiled dumping a lot of info to stdout/stderr. Since one of the goals of webbrowser is to give the end-user a stress-free experience, there goes the mentioned nullification . In a development environment, a developer should not find difficulty to reverse that if needed. >I'd like to remove all those redirects. Any opinion? -1 for me. best regards, Rod Senra ___ 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] Change 'env var BROWSER override' semantics in webbrowser.py
Hi, I propose a small change in webbrowse.py module. At the present time: """ Under Unix, if the environment variable BROWSER exists, it is interpreted to override the platform default list of browsers,... """ (extract from Python-2.4/Doc/html/lib/module-webbrowser.html) I propose the following change: ''' --- webbrowser.py 2005-03-18 17:43:58.736854784 -0300 +++ webbrowser.py.new 2005-03-18 17:29:57.016815680 -0300 @@ -355,7 +355,7 @@ if "BROWSER" in os.environ: # It's the user's responsibility to register handlers for any unknown # browser referenced by this value, before calling open(). -_tryorder = os.environ["BROWSER"].split(os.pathsep) +_tryorder = os.environ["BROWSER"].split(os.pathsep) + _tryorder for cmd in _tryorder: if not cmd.lower() in _browsers: ''' This changes the semantics a bit, but in a positive way: - When the environment variable BROWSER is messed up, there is no reason not to try the other detected browser alternatives - If the BROWSER variable is Ok, than it is respected If nobody stand against it, or would like to propose an alternative (optimized) implementation, I can submit a patch to sf to alter both code and documentation. I'd appreciate to know if you consider this a bug or a new feature ? I consider this a bug: """ The webbrowser module provides a very high-level interface to allow displaying Web-based documents to users. The controller objects are easy to use and are platform-independent. Under most circumstances, simply calling the open() function from this module will do the right thing. """ (extract from Python-2.4/Doc/html/lib/module-webbrowser.html) Ignoring valid *already* detected browsers, due to a broken environment variable does not sound like _do the right thing_. cheers, Senra -- Rodrigo Senra MSc Computer Engineer [EMAIL PROTECTED] GPr Sistemas Ltda http://www.gpr.com.br ___ 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 any() and all()
[ Pierre Barbier de Reuille ]: They are called "sometrue" and "alltrue" ... IMHO, it explicits more what it means : alltrue(i<5 for i in l) sometrue(i<5 for i in l) +1 [ from a comment in GvR's blog ] > > Why not, > > if True in (x > 42 for x in S): > > instead of "any" and why not > > if not False in (x > 42 for x in S): > > instead of "all"? > > Because "any" and "all" have shortcut semantics (they > return as soon as they can determine the final result). [ Guido ]: -- > See my blog: > http://www.artima.com/forums/flat.jsp?forum=106&thread=98196 > Do we even need a PEP ? In the absence of a PEP, soon will see in c.l.p discussions like: """ For completeness sake shouldn't there be a optimiztion version for nonetrue() ? def nonetrue(S): for x in S: if x: return False return True why not allfalse() ? Due to the previous use of sometrue(), guess it becomes easier to remeber nonetrue() than allfalse(). One may argue for aliasing(nonetrue, allfalse), and we are back to _builtin pollution_. """ So, people might fallback to any() and all(),realising that: '''not all()''' meaning somefalse() '''not any()''' meaning nonetrue()==allfalse() All I'm saying: +1 for the PEP. OFF-TOPIC: It is curious though that we choose to read an *implicit* True in [all(), any()] instead of an implicit False. I guess that is a moral or ethical choice coming from the Human realm, favouring Truth instead of Falsity. But that difference does not hold in the Boolean realm . best regards, Senra -- Rodrigo Senra MSc Computer Engineer [EMAIL PROTECTED] GPr Sistemas Ltda http://www.gpr.com.br ___ 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] Improving the Python Memory Allocator
[Evan Jones] : -- 2. Every N memory operations (or some other measurement of "time"), reset this value and calculate a moving average of the number of pages. This estimates the current memory requirements of the application. > The challenge is how to determine a good measurement of "time." > Ideally, if the application was idle for a while, you would perform some housekeeping like this. Does Python's cyclic garbage collector currently do this? If so, I could hook this "management" stuff on to its calls to gc.collect() IMVHO, any measurement of "time" chosen would hurt performance of non-memory greedy applications. OTOH, makes sense for the developers of memory greedy applications (they should be aware of it ) to call gc.collect() periodically. Therefore, *hooking* gc.collect() sounds about right to me, let the janitoring pace be defined by those who really care about it. Looking forward to see this evolve, Senra -- Rodrigo Senra MSc Computer Engineer [EMAIL PROTECTED] GPr Sistemas Ltda http://www.gpr.com.br ___ 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] Improving the Python Memory Allocator
Evan Jones wrote: This message is a follow up to a thread I started on python-dev back in October, archived here: First, there is slightly more overhead with programs that allocate a lot of memory, release it, then reallocate it. Summary of the changes: - When freeing a page, if the arena is completely unused, the arena is deallocated. Depending on the cost of arena allocation, it might help to define a lower threshold keeping a minimum of empty arena_objects permanently available. Do you think this can bring any speedup ? cheers, Senra -- Rodrigo Senra MSc Computer Engineer [EMAIL PROTECTED] GPr Sistemas Ltda http://www.gpr.com.br ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4 news reaches interesting places
[ Guido van Rossum <[EMAIL PROTECTED]> ]
---
| One thing that bugs me: the article says 3 or 4 times that Python is
| slow, each time with a refutation ("but it's so flexible", "but it's
| fast enough") but still, they sure seem to harp on the point.
That reminds me of this joke:
"""Couple of guys find themselves being chased by a lion. The first one
starts to strecth out preparing to run, the second one finds that ridicule.
- No way you'll run faster than that lion. While, the other replies:
- I don't need to run faster than the lion, I just need to run faster than you.
"""
I love to see Python getting faster and faster. Eventually (if...when PyPy
succedes)
faster-than-C ! But after over 4 years of making-ends-meet with Python, our
Brazilian
customers never complained of our Python solutions being slow. Perhaps because
they were glad enough with projects delivered 5 to 10 times faster than usual.
But, but to the joke: I believe Python must strive to run at least as fast as
the crowd --
Java, Perl, Ruby, Lua, Boo, etc
Maybe we could visit the language shootout sites, translate Python snipets to
modern 2.4
idioms and rerun the test suites:
http://www.bagley.org/~doug/shootout/ # classic
http://shootout.alioth.debian.org/# modern
My 2 cents.
best regards,
Senra
--
,_
| ) Rodrigo Senra
|(__ ---
_((|__|] GPr Sistemas http://www.gpr.com.br
_ |(|___|] IC - Unicamp http://www.ic.unicamp.br/~921234
___(|__|]
L___(|_|]---
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
