Re: [Python-Dev] reST limitations? (was Re: status of development documentation)

2005-12-23 Thread Fredrik Lundh 
Martin Blais wrote:

> > So, definitions of functions, classes, and other structured stuff would
> > just use fields under a directive, and references to those definitions
> > would just be reST links.
>
> So you end up with a document with a bunch of custom directives, like::
>
> .. python-class::  MyClass
>:arg: comfobulator
>:arg optional: bliptor
>
>My Class description.
>
> This does not look significantly better to me than the LaTeX code, and
> the docutils directives are not as flexible as the commands provided
> by tex/latex.

Except that tex/latex don't give you the same structure.  Using the real-
life example from the documentation list again:

- LaTeX with Python extensions:

   \begin{funcdesc}{dumps}{params\optional{, methodname\optional{,
methodresponse\optional{, encoding
Convert \var{params} into an XML-RPC request.
or into a response if \var{methodresponse} is true.
\var{params} can be either a tuple of arguments or an instance of the
\exception{Fault} exception class.  If \var{methodresponse} is true,
only a single value can be returned, meaning that \var{params} must be of 
length 1.
\var{encoding}, if supplied, is the encoding to use in the generated
XML; the default is UTF-8.
\end{funcdesc}

- hypothetical ReST (based on martin's example and the above LaTeX
  markup):

.. python-function:: dumps
:arg: params
:arg optional: methodname
:arg optional: methodresponse
:arg optional: encoding

Convert _`params` into an XML-RPC request, or into a response if
_`methodresponse` is true.
_`params` can be either a tuple of arguments or an instance of the
`:exception: _`Fault` exception class.  If _`methodresponse` is true,
only a single value can be returned, meaning that _`params` must be
of length 1.
_`encoding`, if supplied, is the encoding to use in the generated
XML; the default is UTF-8.
.. python-function-end

Informationwise, this is mostly identical to the latex example, except that
you can use existing tools to get an XML structure from this markup.

- JavaDoc/PythonDoc markup:

Converts a Python tuple or a Fault instance to an XML-RPC request.

@def dumps(params, **options)
@param params A tuple or [EMAIL PROTECTED] Fault} instance.
@keyparam methodname If given, create a call request for
this method name.
@keyparam methodresponse If given, create a response request.
If used with a tuple, the tuple must be a singleton (that is,
it must contain exactly one element).
@keyparam encoding The encoding to use for this request. Defaults to
UTF-8.
@return A string containing marshalled data.

The LaTeX solution is one line shorter, but the JavaDoc/PythonDoc solution
squeezes a lot more structural information into those 11 lines.

Also note that the JavaDoc/PythonDoc version is the only one that reflects
the designer's intent: all arguments but the first are keyword options, not
optional positional arguments (I don't know how to express that efficiently
in today's LaTeX markup).

It's also the only one here where existing tools can be used to get a clean
information model

   

dumps
Convert a Python tuple or a Fault instance to an
XML-RPC request.
Convert a Python tuple or a Fault instance to an
XML-RPC request.
dumps(params, **options)
A tuple or Fault instance.
If given, create a methodCall
request for this method name.
If given, create a
methodResponse request. If used with a tuple, the tuple must
be a singleton (that is, it must contain exactly one element).

The request encoding. Defaults to
UTF-8.
A string containing marshalled data.



for further processing (using XSLT to turn this into nice HTML is trivial, for
example).  It's impossible to extract this level of information from the given
LaTeX and ReST examples.





___
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

Re: [Python-Dev] status of development documentation

2005-12-23 Thread Reinhold Birkenfeld 
Robey Pointer wrote:
> On 22 Dec 2005, at 3:51, Michael Hudson wrote:
> 
>> "Fredrik Lundh" <[EMAIL PROTECTED]> writes:
>>
>>> Checked the python-list archives lately?  If you google c.l.python  
>>> for the
>>> word "documentation", you'll find recent megathreads with subjects  
>>> like
>>> "bitching about the documentation", "opensource documentation  
>>> problems"
>>> and "python documentation should be better" among the top hits.   
>>> But if
>>> you check the bug and patch trackers, you don't find many  
>>> contributions.
>>> Something's definitely broken.
>>
>> Hmm, it's this discussion again!  Let me make my point again!
>>
>> Writing good documentation is hard.
> 
> I can only speak for my own experience, but maybe it will help.  I  
> once tried to help fix a piece of the python docs.  The description  
> of Py_UNICODE on  was  
> -- and still is -- incorrect.

The current docs were released on September 28. They are not updated until
the next Python release, so that's probably why your patch doesn't show up 
there.

That may not be a good thing. Documentation fixes should go online much
quicker than with every Python release, or am I mistaken?

Reinhold

-- 
Mail address is perfectly valid!

___
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

Re: [Python-Dev] status of development documentation

2005-12-23 Thread Fredrik Lundh 
Reinhold Birkenfeld wrote:

> > I can only speak for my own experience, but maybe it will help.  I
> > once tried to help fix a piece of the python docs.  The description
> > of Py_UNICODE on  was
> > -- and still is -- incorrect.
>
> The current docs were released on September 28. They are not updated until
> the next Python release, so that's probably why your patch doesn't show up 
> there.
>
> That may not be a good thing. Documentation fixes should go online much
> quicker than with every Python release, or am I mistaken?

as was noted at the top of this thread, the "trunk" documentation on python.org
is even older.  a bit further down the thread, Trent Mick came to the rescue:

http://trentm.com/python/





___
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

Re: [Python-Dev] status of development documentation

2005-12-23 Thread skip 

Robey> I can only speak for my own experience, but maybe it will help.
Robey> I once tried to help fix a piece of the python docs.  The
Robey> description of Py_UNICODE on
Robey>  was
Robey> -- and still is -- incorrect.

Check here:

http://www.trentm.com/python/dailyhtml/api/unicodeObjects.html

Is it up-to-date?  If so, your changes have made it into the documentation
source.

Skip
___
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

Re: [Python-Dev] status of development documentation

2005-12-23 Thread Robey Pointer 

On 23 Dec 2005, at 0:53, Reinhold Birkenfeld wrote:

> Robey Pointer wrote:
>> On 22 Dec 2005, at 3:51, Michael Hudson wrote:
>>
>>> "Fredrik Lundh" <[EMAIL PROTECTED]> writes:
>>>
 Checked the python-list archives lately?  If you google c.l.python
 for the
 word "documentation", you'll find recent megathreads with subjects
 like
 "bitching about the documentation", "opensource documentation
 problems"
 and "python documentation should be better" among the top hits.
 But if
 you check the bug and patch trackers, you don't find many
 contributions.
 Something's definitely broken.
>>>
>>> Hmm, it's this discussion again!  Let me make my point again!
>>>
>>> Writing good documentation is hard.
>>
>> I can only speak for my own experience, but maybe it will help.  I
>> once tried to help fix a piece of the python docs.  The description
>> of Py_UNICODE on  was
>> -- and still is -- incorrect.
>
> The current docs were released on September 28. They are not  
> updated until
> the next Python release, so that's probably why your patch doesn't  
> show up there.
>
> That may not be a good thing. Documentation fixes should go online  
> much
> quicker than with every Python release, or am I mistaken?

Yes, I think that's obviously ridiculous on the face of it, since  
fixes to the python 2.4 docs may be useless by the time 2.5 comes  
out, and may be too late to help anyone anyway. :)

I'm glad I'm not the only one who found the process completely  
broken, at least.

robey

___
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

Re: [Python-Dev] Patch reviews & request for patch review

2005-12-23 Thread Neal Norwitz 
On 12/5/05, John J Lee <[EMAIL PROTECTED]> wrote:
>
> I'm hoping one of those nice people who offered 'review 5 get 1 free'
> might look at a patch of mine.

Oooh, ooh, do I count?!?  (Well, you can drop the nice part. :-)

> http://python.org/sf/1157027

Checked in to 2.5.

> http://python.org/sf/1117398

Checked in to 2.4 and 2.5.

> Thanks in advance to anybody who has time to look at these,

Sorry it took so long.

n
___
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

Re: [Python-Dev] status of development documentation

2005-12-23 Thread skip 

>> That may not be a good thing. Documentation fixes should go online
>> much quicker than with every Python release, or am I mistaken?

Robey> Yes, I think that's obviously ridiculous on the face of it, since
Robey> fixes to the python 2.4 docs may be useless by the time 2.5 comes
Robey> out, and may be too late to help anyone anyway. :)

So for at least the time being they go up nightly
(http://www.trentm.com/python).  I don't know what Trent did to make that
happen, but he did it fairly quickly.  I doubt it would be hard to replicate
on the docs server.

Skip

___
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

Re: [Python-Dev] status of development documentation

2005-12-23 Thread Neal Norwitz 
On 12/23/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> So for at least the time being they go up nightly
> (http://www.trentm.com/python).  I don't know what Trent did to make that
> happen, but he did it fairly quickly.  I doubt it would be hard to replicate
> on the docs server.

I couldn't let Trent have all the fun.

http://docs.python.org/dev/

And hopefully of interest to many here:

http://docs.python.org/dev/results/

These are the results of svn update, configure, build, test, install
and the doc run.
Run on the PSFs box and updated every 12 hours.  I currently have it
send mail to me if there are any test failures.  I will probably
update that to python-checkins or maybe even python-dev depending on
what people think.  I'm not likely to be around much for the rest of
the year, so I don't want to turn it on just yet.

The script should be updated to handle more types of failures. 
configure should probably specify CFLAGS of --std=c89 and maybe others
too.

I should check this script in somewhere, but I'm not sure where.

n
___
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

Re: [Python-Dev] status of development documentation

2005-12-23 Thread Brett Cannon 
On 12/23/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 12/23/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > So for at least the time being they go up nightly
> > (http://www.trentm.com/python).  I don't know what Trent did to make that
> > happen, but he did it fairly quickly.  I doubt it would be hard to replicate
> > on the docs server.
>
> I couldn't let Trent have all the fun.
>
> http://docs.python.org/dev/
>

Cool!  Thanks to Trent for sparking Neal, and thanks to Neal for
feeling the fire under our arses for getting this done.

> And hopefully of interest to many here:
>
> http://docs.python.org/dev/results/
>
> These are the results of svn update, configure, build, test, install
> and the doc run.
> Run on the PSFs box and updated every 12 hours.  I currently have it
> send mail to me if there are any test failures.  I will probably
> update that to python-checkins or maybe even python-dev depending on
> what people think.  I'm not likely to be around much for the rest of
> the year, so I don't want to turn it on just yet.
>

python-checkins seems the most reasonable.  But I would have no
problem with it going to python-dev.

> The script should be updated to handle more types of failures.
> configure should probably specify CFLAGS of --std=c89 and maybe others
> too.
>

With the recent issues in the compiler not being C89 compatible that
would probably be good.

-Brett
___
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

[Python-Dev] Weekly Python Patch/Bug Summary

2005-12-23 Thread Kurt B. Kaiser 
Patch / Bug Summary
___

Patches :  379 open ( -4) /  3002 closed (+12) /  3381 total ( +8)
Bugs:  914 open (-13) /  5452 closed (+37) /  6366 total (+24)
RFE :  204 open ( +0) /   193 closed ( +1) /   397 total ( +1)

New / Reopened Patches
__

Some fixes for the binary distribution builder  (2005-12-14)
   http://python.org/sf/1380777  opened by  Ronald Oussoren

Fix bug read() would hang on ssl socket if settimeout() used  (2005-12-15)
   http://python.org/sf/1380952  opened by  Arkadiusz Miskiewicz

bind() for netlink sockets  (2005-12-15)
   http://python.org/sf/1381398  opened by  Timo Metsälä

list.count() patch for feature request 1370948  (2005-12-15)
CLOSED http://python.org/sf/1382087  opened by  Mike Fondo

Expose Subversion revision number  (2005-12-16)
CLOSED http://python.org/sf/1382163  opened by  Barry A. Warsaw

Specify new reference return value for PyObject_Call  (2005-12-17)
CLOSED http://python.org/sf/1383115  opened by  Farshid Lashkari

Make unittest.TestCase easier to subclass  (2005-12-22)
   http://python.org/sf/1388073  opened by  Collin Winter

add more readline support  (2005-12-22)
   http://python.org/sf/1388440  opened by  Sebastien Boving

Patches Closed
__

PyXxx_Check() speed-up  (2005-02-27)
   http://python.org/sf/1153056  closed by  arigo

[PATCH] mmap fails on AMD64  (2005-11-24)
   http://python.org/sf/1365916  closed by  nnorwitz

list.count() patch for feature request 1370948  (2005-12-15)
   http://python.org/sf/1382087  closed by  gvanrossum

Expose Subversion revision number  (2005-12-16)
   http://python.org/sf/1382163  closed by  bwarsaw

fix description of format_exc in traceback doc  (2005-12-09)
   http://python.org/sf/1376914  closed by  birkenfeld

xml.parsers.expat documentation fix  (2005-12-10)
   http://python.org/sf/1377848  closed by  birkenfeld

correct display of pathnames in SimpleHTTPServer  (2005-11-18)
   http://python.org/sf/1360443  closed by  birkenfeld

PEP 341 - Unification of try/except and try/finally  (2005-11-13)
   http://python.org/sf/1355913  closed by  nnorwitz

Specify new reference return value for PyObject_Call  (2005-12-17)
   http://python.org/sf/1383115  closed by  effbot

LibRef: reworked chapter organization  (2005-12-07)
   http://python.org/sf/1375417  closed by  akuchling

cookielib LWPCookieJar and MozillaCookieJar exceptions  (2005-02-06)
   http://python.org/sf/1117398  closed by  nnorwitz

cookielib mis-handles RFC 2109 cookies in Netscape mode  (2005-03-04)
   http://python.org/sf/1157027  closed by  nnorwitz

New / Reopened Bugs
___

split() description not fully accurate  (2005-12-14)
   http://python.org/sf/1380970  opened by  K.C.

csv.reader endless loop   (2005-12-15)
   http://python.org/sf/1381476  opened by  Christian Harms

mode 't' not documented as posssible mode for file built-in  (2005-12-15)
   http://python.org/sf/1381717  opened by  Simo Salminen

cElementTree only supports a few encodings  (2005-12-15)
CLOSED http://python.org/sf/1381939  opened by  Fredrik Lundh

MacRoman Encoding Bug (OHM vs. OMEGA)  (2005-12-16)
CLOSED http://python.org/sf/1382096  opened by  Sean B. Palmer

Tutorial section 9.5.1 ignores MRO for new-style classes  (2005-12-16)
   http://python.org/sf/1382213  opened by  GaryD

--install-base not honored on win32  (2005-12-16)
   http://python.org/sf/1382562  opened by  John Ehresman

len() on class broken  (2005-12-16)
   http://python.org/sf/1382740  reopened by  kquick

len() on class broken  (2005-12-16)
   http://python.org/sf/1382740  opened by  Kevin Quick

len() on class broken  (2005-12-16)
CLOSED http://python.org/sf/1382815  opened by  Kevin Quick

MacOS.WMAvailable() doesn't launch Python.app properly  (2005-12-17)
CLOSED http://python.org/sf/1383644  opened by  has

random module - Provider DLL failed to initialize correctly  (2005-12-18)
   http://python.org/sf/1384175  opened by  Greg Hazel

exec statement link in index broken  (2005-12-19)
   http://python.org/sf/1385004  opened by  Harri Pasanen

compiler module does not detect a syntax error  (2005-12-19)
   http://python.org/sf/1385040  opened by  Harri Pasanen

execfile anomaly with "from __future__ import division"  (2005-12-19)
CLOSED http://python.org/sf/1385055  opened by  Harri Pasanen

_winreg specifies EnvironmentError instead of WindowsError  (2005-12-21)
   http://python.org/sf/1386675  opened by  Tony Meyer

sys.path[0] when executed thru a symbolic link  (2005-12-21)
CLOSED http://python.org/sf/1387483  opened by  Tomasz Kowaltowski

weird behavior when assigning locals() to a variable  (2005-12-22)
CLOSED http://python.org/sf/1387650  opened by  Samuel Bayer

Minor error in md5 docs  (2005-12-22)
CLOSED http://python.org/sf/1388141  opened by  Kent Johnson

bug in rstrip & lstrip  (2005-12-23)
CLOSED http://python.

Re: [Python-Dev] status of development documentation

2005-12-23 Thread Trent Mick 
[Neal Norwitz wrote]
> I couldn't let Trent have all the fun.
> 
> http://docs.python.org/dev/

Yah, I'd had a great time.  Back to Xmas drinking.

Cheers,
Trent

-- 
Trent Mick
[EMAIL PROTECTED]
___
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

Re: [Python-Dev] status of development documentation

2005-12-23 Thread Tim Peters 
[Neal Norwitz]
> ...
> I couldn't let Trent have all the fun.
>
> http://docs.python.org/dev/
>
> And hopefully of interest to many here:
>
> http://docs.python.org/dev/results/

Wow!  You get no test failures!  I guess nobody tests on Windows
anymore.  I've been getting test failures for months, and just
_assumed_ this was known damage everywhere so was waiting for someone
else to fix it ;-)  (A parenthentical question:  is there a reason you
don't pass -uall to regrtest.py?)

On WinXP Pro SP2 today, passing -uall, and after fixing all the MS
compiler warnings that have crept in:

251 tests OK.
12 tests failed:
test_builtin test_coding test_compiler test_pep263
test_univnewlines test_urllib test_urllib2 test_urllibnet
test_userlist test_wave test_whichdb test_zipfile
39 tests skipped:
test__locale test_aepack test_al test_applesingle test_bsddb185
test_cd test_cl test_commands test_crypt test_curses test_dbm
test_dl test_fcntl test_fork1 test_gdbm test_gl test_grp
test_hashlib_speed test_imgfile test_ioctl test_linuxaudiodev
test_macfs test_macostools test_mhlib test_nis test_openpty
test_ossaudiodev test_plistlib test_poll test_posix test_pty
test_pwd test_resource test_scriptpackages test_signal
test_sunaudiodev test_threadsignals test_timing test_xml_etree_c
1 skip unexpected on win32:
test_xml_etree_c

Where to begin?  Let's start with the first:

C:\Code\python\PCbuild>rt -q test_builtin

C:\Code\python\PCbuild>python  -E -tt ../lib/test/regrtest.py test_builtin
test_builtin
test test_builtin failed -- errors occurred; run in verbose mode for details
1 test failed:
test_builtin

OK, try again:

C:\Code\python\PCbuild>rt -q -v test_builtin

C:\Code\python\PCbuild>python  -E -tt ../lib/test/regrtest.py -v test_builtin
test_builtin
test_abs (test.test_builtin.BuiltinTest) ... ok
...
==
ERROR: test_compile (test.test_builtin.BuiltinTest)
--
Traceback (most recent call last):
  File "C:\Code\python\lib\test\test_builtin.py", line 237, in test_compile
compile(bom + 'print 1\n', '', 'exec')
  File "", line 1
∩�[┐print 1
^
SyntaxError: invalid syntax

==
ERROR: test_eval (test.test_builtin.BuiltinTest)
--
Traceback (most recent call last):
  File "C:\Code\python\lib\test\test_builtin.py", line 306, in test_eval
self.assertEqual(eval(bom + 'a', globals, locals), 1)
  File "", line 1
∩�[┐a
^
SyntaxError: invalid syntax

I have no idea what those are trying to test, and remember guessing
the first time I saw this that it was fallout from the AST-branch
merge.  Apparently it wasn't :-(.  Anyone have a clue on this one? 
The code up to the first failure is short:

bom = '\xef\xbb\xbf'
compile(bom + 'print 1\n', '', 'exec')

Curiously, that sequence doesn't blow up under the released Windows
Python 2.4.2, so somebody broke something here since then ...
___
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

Re: [Python-Dev] status of development documentation

2005-12-23 Thread Neal Norwitz 
On 12/23/05, Tim Peters <[EMAIL PROTECTED]> wrote:
> >
> > http://docs.python.org/dev/results/
>
> Wow!  You get no test failures!  I guess nobody tests on Windows
> anymore.  I've been getting test failures for months, and just

Hmmm, I thought others were running the tests on Windows too.  There
was one report on Nov 22 about running Purify on Windows 2k (subject:
ast status, memory leaks, etc).  He had problems with a stack overflow
in test_compile.  He was going to disable the test and re-run.  I
never heard back though.  Based on that info, I would guess that
test_builtin was working on Win 2k on Nov 22.

> _assumed_ this was known damage everywhere so was waiting for someone
> else to fix it ;-)  (A parenthentical question:  is there a reason you
> don't pass -uall to regrtest.py?)

It's calling make test.  I thought about calling regrtest.py instead
and doing as you suggest.  Is there a benefit to running make test?  I
know it runs with and without -O.  I guess it's only machine time, I
could run make test and regrtest.py -uall.

> On WinXP Pro SP2 today, passing -uall, and after fixing all the MS
> compiler warnings that have crept in:
>
> 251 tests OK.
> 12 tests failed:
> test_builtin test_coding test_compiler test_pep263
> test_univnewlines test_urllib test_urllib2 test_urllibnet
> test_userlist test_wave test_whichdb test_zipfile
> 1 skip unexpected on win32:
> test_xml_etree_c

Ouch!  I'm might be to blame for at least some of those. :-(

> ERROR: test_compile (test.test_builtin.BuiltinTest)
> --
> Traceback (most recent call last):
>   File "C:\Code\python\lib\test\test_builtin.py", line 237, in test_compile
> compile(bom + 'print 1\n', '', 'exec')
>   File "", line 1
> ∩�[┐print 1
> ^
> SyntaxError: invalid syntax

> I have no idea what those are trying to test, and remember guessing
> the first time I saw this that it was fallout from the AST-branch
> merge.  Apparently it wasn't :-(.  Anyone have a clue on this one?

This test code was added a while ago by Just.  So the test code isn't new.
I changed some compile code wrt unicode that was a memory leak (r41553).
I just ran valgrind and it didn't report any problems.  So I don't
think that change broke Windows.

Do you know if the tests were broken before the AST merge (about Oct
22 I think)?

> The code up to the first failure is short:
>
> bom = '\xef\xbb\xbf'
> compile(bom + 'print 1\n', '', 'exec')
>
> Curiously, that sequence doesn't blow up under the released Windows
> Python 2.4.2, so somebody broke something here since then ...

There were a bunch of changes to Parser/tokenizer.c to handle error
conditions.  Those go back to Oct 1.  I don't *think* those would
cause these, but I'm not sure.

Sorry, I don't know any more.  I guess you might have to binary search
by date to try and find the problem.

n
___
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