Re: [Python-Dev] Difference in RE between 3.2 and 3.3 (or Aaron Swartz memorial)

2013-03-07 Thread Matej Cepl 
On 2013-03-06, 18:34 GMT, Victor Stinner wrote:
> In short, Unicode was rewritten in Python 3.3 for the PEP 393. It's
> not surprising that minor details like singleton differ. You should
> not use "is" to compare strings in Python, or your program will fail
> on other Python implementations (like PyPy, IronPython, or Jython) or
> even on a different CPython version.

I am sorry, I don't understand what you are saying. Even though 
this has been changed to 
https://github.com/mcepl/html2text/blob/fix_tests/html2text.py#L90 
the tests still fail.

But, Amaury is right: the function doesn't make much sense. 
However, ...

when I have “fixed it” from
https://github.com/mcepl/html2text/blob/master/html2text.py#L95

def onlywhite(line):
 """Return true if the line does only consist of whitespace characters."""
 for c in line:
 if c is not ' ' and c is not '  ':
 return c is ' '
 return line

to 
https://github.com/mcepl/html2text/blob/fix_tests/html2text.py#L90

def onlywhite(line):
 """Return true if the line does only consist of whitespace 
 characters."""
 for c in line:
if c != ' ' and c != ' ':
   return c == ' '
 return line

tests on ALL versions of Python are suddenly failing ...  
https://travis-ci.org/mcepl/html2text/builds/5288190

Curiouser and curiouser! At least, I seem to have the point,
where things are breaking, but I have to admit that condition
really doesn’t make any sense to me.

> Anyway, you spotted a missed optimization: it's now "fixed" in
> Python 3.3 and 3.4 by the following commits.

Well, whatever is the problem, it is not fixed in python 3.3.0
(as you can see in
https://travis-ci.org/mcepl/html2text/builds/4969045) as I can
see on my computer. Actually, good news is that it seems to be
fixed in the master branch of cpython (or the tip, as they say in
the Mercurial world).

Any thoughts?

Matěj
___
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] Difference in RE between 3.2 and 3.3 (or Aaron Swartz memorial)

2013-03-07 Thread Xavier Morel 

On 2013-03-07, at 11:08 , Matej Cepl wrote:

> On 2013-03-06, 18:34 GMT, Victor Stinner wrote:
>> In short, Unicode was rewritten in Python 3.3 for the PEP 393. It's
>> not surprising that minor details like singleton differ. You should
>> not use "is" to compare strings in Python, or your program will fail
>> on other Python implementations (like PyPy, IronPython, or Jython) or
>> even on a different CPython version.
> 
> I am sorry, I don't understand what you are saying. Even though 
> this has been changed to 
> https://github.com/mcepl/html2text/blob/fix_tests/html2text.py#L90 
> the tests still fail.
> 
> But, Amaury is right: the function doesn't make much sense. 
> However, ...
> 
> when I have “fixed it” from
> https://github.com/mcepl/html2text/blob/master/html2text.py#L95
> 
> def onlywhite(line):
> """Return true if the line does only consist of whitespace characters."""
> for c in line:
> if c is not ' ' and c is not '  ':
> return c is ' '
> return line
> 
> to 
> https://github.com/mcepl/html2text/blob/fix_tests/html2text.py#L90
> 
> def onlywhite(line):
> """Return true if the line does only consist of whitespace 
> characters."""
> for c in line:
>if c != ' ' and c != ' ':
>   return c == ' '
> return line

The second test looks like some kind of corruption, it's supposedly
iterating on the characters of a line yet testing for two spaces? Is it
possible that the original was a literal tab embedded in the source code
(instead of '\t') and that got broken at some point?

According to its name + docstring, the implementation of this method
should really be replaced by `return line and line.isspace()` (the first
part being to handle the case of an empty line: in the current
implementation the line will be returned directly if no whitespace is
found, which will be "negative" for an empty line, and ''.isspace() ->
false). Does that fix the failing tests?
___
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] [docs] undocumented argtypes magic in ctypes?

2013-03-07 Thread Thomas Heller 

Am 06.03.2013 18:19, schrieb Eli Bendersky:




On Wed, Mar 6, 2013 at 8:33 AM, Andrew Svetlov mailto:[email protected]>> wrote:

Looks like bug for me.


ctypes seems to auto-convert arguments when argtypes is specified. This
fact is documented. However, I'm not sure whether this auto-conversion
is advanced enough to apply byref. Because otherwise, DIRENT is
certainly not convertible to DIRENT_p


If argtypes specify a 'POINTER(X)' type as an argument, then ctypes
automatically applies byref() if an 'X' instance is passed to the
actual call.  This is by design, but I'm not sure if it is documented
or not.

However, if argtypes is not given, this does (and of course cannot) work.

Thomas


___
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] [docs] undocumented argtypes magic in ctypes?

2013-03-07 Thread Eli Bendersky 
On Thu, Mar 7, 2013 at 3:37 AM, Thomas Heller  wrote:

> Am 06.03.2013 18:19, schrieb Eli Bendersky:
>
>>
>>
>>
>> On Wed, Mar 6, 2013 at 8:33 AM, Andrew Svetlov > > wrote:
>>
>> Looks like bug for me.
>>
>>
>> ctypes seems to auto-convert arguments when argtypes is specified. This
>> fact is documented. However, I'm not sure whether this auto-conversion
>> is advanced enough to apply byref. Because otherwise, DIRENT is
>> certainly not convertible to DIRENT_p
>>
>
> If argtypes specify a 'POINTER(X)' type as an argument, then ctypes
> automatically applies byref() if an 'X' instance is passed to the
> actual call.  This is by design, but I'm not sure if it is documented
> or not.
>
> However, if argtypes is not given, this does (and of course cannot) work.
>

Great, thanks for confirming this, Thomas. I had the feeling it's a
documentation issue (hence I sent it to the docs@ list first), because the
behavior seems very deliberate and looking at the code of ctypes I did see
conversions going on.

Have I missed that this is documented somewhere, or should I open a docs
issue?

Eli
___
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] Difference in RE between 3.2 and 3.3 (or Aaron Swartz memorial)

2013-03-07 Thread Victor Stinner 
You should try to write a simple test not using your library (just
copy/paste code) reproducing the issue. If you can do that, please
fill an issue on bugs.python.org.

Victor

2013/3/7 Matej Cepl :
> On 2013-03-06, 18:34 GMT, Victor Stinner wrote:
>> In short, Unicode was rewritten in Python 3.3 for the PEP 393. It's
>> not surprising that minor details like singleton differ. You should
>> not use "is" to compare strings in Python, or your program will fail
>> on other Python implementations (like PyPy, IronPython, or Jython) or
>> even on a different CPython version.
>
> I am sorry, I don't understand what you are saying. Even though
> this has been changed to
> https://github.com/mcepl/html2text/blob/fix_tests/html2text.py#L90
> the tests still fail.
>
> But, Amaury is right: the function doesn't make much sense.
> However, ...
>
> when I have “fixed it” from
> https://github.com/mcepl/html2text/blob/master/html2text.py#L95
>
> def onlywhite(line):
>  """Return true if the line does only consist of whitespace characters."""
>  for c in line:
>  if c is not ' ' and c is not '  ':
>  return c is ' '
>  return line
>
> to
> https://github.com/mcepl/html2text/blob/fix_tests/html2text.py#L90
>
> def onlywhite(line):
>  """Return true if the line does only consist of whitespace
>  characters."""
>  for c in line:
> if c != ' ' and c != ' ':
>return c == ' '
>  return line
>
> tests on ALL versions of Python are suddenly failing ...
> https://travis-ci.org/mcepl/html2text/builds/5288190
>
> Curiouser and curiouser! At least, I seem to have the point,
> where things are breaking, but I have to admit that condition
> really doesn’t make any sense to me.
>
>> Anyway, you spotted a missed optimization: it's now "fixed" in
>> Python 3.3 and 3.4 by the following commits.
>
> Well, whatever is the problem, it is not fixed in python 3.3.0
> (as you can see in
> https://travis-ci.org/mcepl/html2text/builds/4969045) as I can
> see on my computer. Actually, good news is that it seems to be
> fixed in the master branch of cpython (or the tip, as they say in
> the Mercurial world).
>
> Any thoughts?
>
> Matěj
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com
___
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] [docs] undocumented argtypes magic in ctypes?

2013-03-07 Thread Thomas Heller 

ctypes seems to auto-convert arguments when argtypes is
specified. This
fact is documented. However, I'm not sure whether this
auto-conversion
is advanced enough to apply byref. Because otherwise, DIRENT is
certainly not convertible to DIRENT_p

If argtypes specify a 'POINTER(X)' type as an argument, then ctypes
automatically applies byref() if an 'X' instance is passed to the
actual call.  This is by design, but I'm not sure if it is documented
or not.

However, if argtypes is not given, this does (and of course cannot)
work.

Great, thanks for confirming this, Thomas. I had the feeling it's a
documentation issue (hence I sent it to the docs@ list first), because
the behavior seems very deliberate and looking at the code of ctypes I
did see conversions going on.

Have I missed that this is documented somewhere, or should I open a docs
issue?


I didn't find anything in the docs (in the two minutes I spent for 
that), so please open a docs issue, or, better, fix it.


Thomas


___
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] [docs] undocumented argtypes magic in ctypes?

2013-03-07 Thread Eli Bendersky 
On Thu, Mar 7, 2013 at 5:53 AM, Thomas Heller  wrote:

> ctypes seems to auto-convert arguments when argtypes is
>> specified. This
>> fact is documented. However, I'm not sure whether this
>> auto-conversion
>> is advanced enough to apply byref. Because otherwise, DIRENT is
>> certainly not convertible to DIRENT_p
>>
>> If argtypes specify a 'POINTER(X)' type as an argument, then ctypes
>> automatically applies byref() if an 'X' instance is passed to the
>> actual call.  This is by design, but I'm not sure if it is documented
>> or not.
>>
>> However, if argtypes is not given, this does (and of course cannot)
>> work.
>>
>> Great, thanks for confirming this, Thomas. I had the feeling it's a
>> documentation issue (hence I sent it to the docs@ list first), because
>> the behavior seems very deliberate and looking at the code of ctypes I
>> did see conversions going on.
>>
>> Have I missed that this is documented somewhere, or should I open a docs
>> issue?
>>
>
> I didn't find anything in the docs (in the two minutes I spent for that),
> so please open a docs issue, or, better, fix it.


http://bugs.python.org/issue17378, has a patch already. Please take a look.

Eli
___
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] VC++ 2008 Express Edition now locked away?

2013-03-07 Thread Steve Dower 
> From: Terry Reedy
> On 3/6/2013 12:29 PM, Steve Dower wrote:
> > From: Case Van Horsen
> 
> >> The "Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1"
> >> is still available for download. It includes the command line
> >> compilers that are used with VS 2008. I have used to create extensions for
> Python 2.6 to 3.2.
> >> There is a later version of the SDK (for .NET
> >> 4.x) that includes the compilers from VS 2010.
> >
> > This is the same response that I got internally.
> >
> > The download link is
>  > http://www.microsoft.com/en-us/download/details.aspx?id=3138
>  > and you can choose to only download and install the compilers.
> 
> The C++ compiler appears to the the full compiler that will build both
> 32 and 64 bits apps. Will downloading just the compiler(s) allow one to build
> Python with the project files in PCBuild or does something else need to be
> checked also?

Just testing this now, but 

Any version of Visual Studio (Professional or higher), OR
Visual Studio 2012 Express for Desktop 
(http://www.microsoft.com/visualstudio/eng/products/visual-studio-express-for-windows-desktop)
 OR
Visual C++ 2010 Express 
(http://www.microsoft.com/visualstudio/en-us/express-cpp/overview) (maybe - 
haven't confirmed this yet)

For Python 3.3: the compilers and headers from the "Windows SDK for Windows 7 
and .NET Framework 4" 
(http://www.microsoft.com/en-us/download/details.aspx?id=8279)
For earlier versions: the compilers and headers from the "Windows SDK for 
Windows 7 and .NET Framework 3.5" 
(http://www.microsoft.com/en-us/download/details.aspx?id=3138)
(You can install both compilers on the same machine.)

Once these compilers have been installed, VS will let you choose which one your 
project will use. In Project Properties there is a "Platform Toolset" list that 
will include all of the installed compilers. For Python 3.3, you'll want VC100, 
and earlier versions will want VC90.

If you open an existing project (including PCBuild.sln), VS will offer to 
update it. If you don't update it, and you have the earlier compilers 
installed, it will use them. Right now, I've only tested this with 3.3, which 
used a different project format to earlier versions (.vcxproj, rather than 
.vcproj). I assume we know how to upgrade the project files without changing 
the platform target, but I haven't confirmed that yet.

> >> To use the SDK compiler, you need to do a few manual steps first.
> >>
> >> After starting a command window, you need to run a batch file to
> >> configure your environment. Choose the appropriate option from
> >>
> >> C:\Program Files (x86)\Microsoft Visual Studio
> >> 9.0\VC\bin\vcvars64.bat
> >>
> >> or
> >>
> >> C:\Program Files (x86)\Microsoft Visual Studio
> >> 9.0\VC\bin\vcvars32.bat
> >>
> >> Then set two environment variables:
> >>
> >> set MSSdk=1
> >> set DISTUTILS_USE_SDK=1
> >>
> >> After these steps, the standard python setup.py install should work.
> 
> This may be fine for building extensions, but it appears that more 
> instructions
> are needed for a novice to build python itself.

I'm not even sure that these variables are necessary - certainly without the 
compilers installed setup.py looks in the right place for them. I'll try this 
as well.

> Following the instruction in the developer's guide,
> http://docs.python.org/devguide/setup.html#windows
> I was able to download and install vc express, double click on
> /PCBuild/pcbuild.sln to bring up the VS GUI, and use the menu
> to build a debug version of that branch. The new python is put in the same
> directory and can be run with another menu selection. Any alternate path
> should be that easy too.

I'll admit I'm not a huge fan of the current Windows build setup, but since so 
few people seem to use it I understand why it hasn't changed.

As for the documentation, I'd be happy to provide an update for this section 
once I've checked out that everything works.


Cheers,
Steve

> --
> Terry Jan Reedy


___
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] Difference in RE between 3.2 and 3.3 (or Aaron Swartz memorial)

2013-03-07 Thread Georg Brandl 
Am 07.03.2013 11:08, schrieb Matej Cepl:

>> Anyway, you spotted a missed optimization: it's now "fixed" in
>> Python 3.3 and 3.4 by the following commits.
> 
> Well, whatever is the problem, it is not fixed in python 3.3.0
> (as you can see in
> https://travis-ci.org/mcepl/html2text/builds/4969045) as I can
> see on my computer. Actually, good news is that it seems to be
> fixed in the master branch of cpython (or the tip, as they say in
> the Mercurial world).

It's not a "fix", it's an optimization.  Please understand that
using the "is" operator on strings is entirely wrong.

Georg

___
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] PEP 434: IDLE Enhancement Exception

2013-03-07 Thread Terry Reedy 
This re-write of Todd's draft focuses better on the specific proposal 
and motivation. It tries to take into account comments posted both here 
and on python-ideas




PEP: 434
Title: IDLE Enhancement Exception for All Branches
Version: $Revision$
Last-Modified: $Date$
Author: Todd Rovito ,
Terry Reedy 
BDFL-Delegate: Nick Coghlan
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 16-Feb-2013
Post-History: 16-Feb-2013


Abstract


Most CPython tracker issues are classified as behavior or
enhancement.  Most behavior patches are backported to branches for
existing versions.  Enhancement patches are restricted to the default
branch that becomes the next Python version.

This PEP proposes that the restriction on applying enhancements be
relaxed for IDLE code, residing in .../Lib/idlelib/.  In practice,
this would mean that IDLE developers would not have to classify or
agree on the classification of a patch but could instead focus on
what is best for IDLE users and future IDLE developement. It would
also mean that IDLE patches would not necessarily have to be split
into 'bugfix' changes and enhancement changes.

The PEP would apply to changes in existing features and addition of
small features, such as would require a new menu entry, but not
necessarily to possible major re-writes such as switching to themed
widgets or tabbed windows.


Motivation
==

This PEP was prompted by controversy on both the tracker and pydev
list over adding Cut, Copy, and Paste to right-click context menus
(Issue 1207589, opened in 2005 [1]_; pydev thread [2]_).  The
features were available as keyboard shortcuts but not on the context
menu. It is standard, at least on Windows, that they should be when
applicable (a read-only window would only have Copy), so users do not
have to shift to the keyboard after selecting text for cutting or
copying or a slice point for pasting.  The context menu was not
documented until 10 days before the new options were added (Issue
10405 [3]_).

Normally, behavior is called a bug if it conflicts with documentation
judged to be correct. But if there is no doc, what is the standard?
If the code is its own documentation, most IDLE issues on the tracker
are enhancement issues.  If we substitute reasonable user expectation,
(which can, of course, be its own subject of disagreement), many more
issues are behavior issues.

For context menus, people disagreed on the status of the additions --
bugfix or enhancement. Even people who called it an enhancement
disagreed as to whether the patch should be backported.  This PEP
proposes to make the status disagreement irrelevant by explicitly
allowing more liberal backporting than for other stdlib modules.


Rationale
=

People primarily use IDLE by running the gui application, rather than
by directly importing the effectively private (undocumented)
implementation modules in idlelib. Whether they use the shell, the
editor, or both, we believe they will benefit more from consistency
across the latest releases of current Python versions than from
consistency within the bugfix releases for one Python version. This
is especially true when existing behavior is clearly unsatisfactory.

When people use the standard interpreter, the OS-provided frame works
pretty much the same for all Python versions. If, for instance,
Microsoft were to upgrade the Command Prompt gui, the improvements
would be present regardless of which Python were running within it.
Similarly, if one edits Python code with editor X, behaviors such as
the right-click context menu and the search-replace box do not depend
on the version of Python being edited or even the language being
edited.

The benefit for IDLE developers is mixed. On the one hand, testing
more versions and possibly having to adjust a patch, especially for
2.7, is more work. (There is, of course, the option on not
backporting everything. For issue 12510, some changes to calltips for
classes were not included in the 2.7 patch because of issues with
old-style classes [4]_.)  On the other hand, bike-shedding can be an
energy drain. If the obvious fix for a bug looks like an enhancement,
writing a separate bugfix-only patch is more work. And making the
code diverge between versions makes future multi-version patches more
difficult.

These issue are illustrated by the search-and-replace dialog box.
It used to raise an exception for certain user entries [5]_. The
uncaught exception caused IDLE to exit.  At least on Windows, the
exit was silent (no visible traceback) and looked like a crash if
IDLE was started normally, from an icon.

Was this a bug?  IDLE Help (on the current Help submenu) just says
"Replace... Open a search-and-replace dialog box", and a box *was*
opened. It is not, in general, a bug for a library method to raise an
exception.  And it is not, in general, a bug for a library method to
ignore an exception raised by f

[Python-Dev] pytracemalloc 0.7: new tool to track memory leaks in Python

2013-03-07 Thread Victor Stinner 
Hi,

See below for a copy of my email posted to python-list and
python-announce mailing lists. pytracemalloc tool requires a patch on
Python to hook memory allocation functions. I posted the patch there:
http://bugs.python.org/issue3329

Thanks to this patch, it would also be possible to enable or disable
debug memory allocators (ex: _PyMem_DebugMalloc vs PyMem_Malloc) at
runtime, instead of having to decide at compile time.

Ezio proposed a similar idea for the "[X refs, Y blocks]" message
display at Python (compiled in debug mode) exit. He proposed to
disable the message by default, and add a (command line) option to
show the message:
http://bugs.python.org/issue17323

--

Wyplay is proud to announce the release of a new tool to track Python
memory allocations: "pytracemalloc".

https://pypi.python.org/pypi/pytracemalloc
https://github.com/wyplay/pytracemalloc

pytracemalloc provides the following information:

- Allocated size and number of allocations per file,
  or optionally per file and line number
- Compute the average size of memory allocations
- Compute delta between two "snapshots"
- Get the source of a memory allocation: filename and line number

It helps to track memory leaks: show directly in which Python files
the memory increases.

Example of pytracemalloc output (compact):

2013-02-28 23:40:18: Top 5 allocations per file
#1: .../Lib/test/regrtest.py: 3998 KB
#2: .../Lib/unittest/case.py: 2343 KB
#3: .../ctypes/test/__init__.py: 513 KB
#4: .../Lib/encodings/__init__.py: 525 KB
#5: .../Lib/compiler/transformer.py: 438 KB
other: 32119 KB
Total allocated size: 39939 KB

Example of pytracemalloc output (full):

2013-03-04 01:01:55: Top 10 allocations per file and line
#1: .../2.7/Lib/linecache.py:128: size=408 KiB (+408 KiB),
count=5379 (+5379), average=77 B
#2: .../unittest/test/__init__.py:14: size=401 KiB (+401 KiB),
count=6668 (+6668), average=61 B
#3: .../2.7/Lib/doctest.py:506: size=319 KiB (+319 KiB), count=197
(+197), average=1 KiB
#4: .../Lib/test/regrtest.py:918: size=429 KiB (+301 KiB),
count=5806 (+3633), average=75 B
#5: .../Lib/unittest/case.py:332: size=162 KiB (+136 KiB),
count=452 (+380), average=367 B
#6: .../Lib/test/test_doctest.py:8: size=105 KiB (+105 KiB),
count=1125 (+1125), average=96 B
#7: .../Lib/unittest/main.py:163: size=77 KiB (+77 KiB),
count=1149 (+1149), average=69 B
#8: .../Lib/test/test_types.py:7: size=75 KiB (+75 KiB),
count=1644 (+1644), average=46 B
#9: .../2.7/Lib/doctest.py:99: size=64 KiB (+64 KiB), count=1000
(+1000), average=66 B
#10: .../Lib/test/test_exceptions.py:6: size=56 KiB (+56 KiB),
count=932 (+932), average=61 B
3023 more: size=1580 KiB (+1138 KiB), count=12635 (+7801), average=128 B
Total: size=3682 KiB (+3086 KiB), count=36987 (+29908), average=101 B

To install pytracemalloc, you need to patch and recompile your own
version of Python to be able to hook all Python memory allocations.

--

Wyplay was created in March 2006 in the south of France. Independent,
Europe-based, and internationally recognized, Wyplay’s TV-centric
software solutions power the world’s most popular operator and
consumer electronic brand names. Targeted products includes:
Connected-HDTVs, Media Center CE devices, HD IPTV boxes, DVB-S/C/T HD
STBs, and in-home media-HDD products.
http://www.wyplay.com/

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