Re: [Python-Dev] Optimize Unicode strings in Python 3.3

2012-05-30 Thread Serhiy Storchaka 

On 30.05.12 01:44, Victor Stinner wrote:

The "two steps" method is not promising: parsing the format string
twice is slower than other methods.


The "1.5 steps" method is more promising -- first parse the format 
string in an efficient internal representation, and then allocate the 
output string and then write characters (or enlarge and widen the 
buffer, but with more information in any case). The internal 
representation can be cached (as for struct module) that for a repeated 
formatting will reduce the cost of parsing to zero.



___
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] [Python-checkins] cpython: Issue #14744: Use the new _PyUnicodeWriter internal API to speed up str%args

2012-05-30 Thread Serhiy Storchaka 

On 29.05.12 19:55, Victor Stinner wrote:

The following changesets should fix the two errors, but not warnings.


Why not move `TYPE *p` declaration inside WRITE_DIGITS?

___
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] Optimize Unicode strings in Python 3.3

2012-05-30 Thread Victor Stinner 
>> The "two steps" method is not promising: parsing the format string
>> twice is slower than other methods.
>
> The "1.5 steps" method is more promising -- first parse the format string in
> an efficient internal representation, and then allocate the output string
> and then write characters (or enlarge and widen the buffer, but with more
> information in any case). The internal representation can be cached (as for
> struct module) that for a repeated formatting will reduce the cost of
> parsing to zero.

I implemented something like that, and it was not efficient and very complex.

See for example the (incomplete) patch for str%args attached to the
issue #14687:
http://bugs.python.org/file25413/pyunicode_format-2.patch

IMO this approach is less efficient than the "Unicode writer" approach because:

 - you have to create many substrings or temporary strings in the
first step, or (worse) compute each argument twice: the writer
approach is more efficient here because it avoids computing substrings
and temporary strings

 - you have to parse the format string twice, or you have to write two
versions of the code: first create a list of items, then concatenate
items. The PyAccu method concatenates substrings at the end, it is
less efficient than the writer method (e.g. it has to create a string
of N fill characters to pad to WIDTH characters).

 - the code is more complex than the writer method (which is very
similar to what is used in Python 2.7 and 3.2)

I wrote a much more complex patch for str%args to remember variables
of the first step to avoid most of the parsing work in the second
step. The patch was very complex and hard to maintain. I chose to not
publish it and try another approach (the Unicode writer).

Note: I'm talking about str%args and str.format(args), the Unicode
writer is not the most efficient method for *any* function creating
strings!

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

[Python-Dev] Python Language Summit, Florence, July 2012

2012-05-30 Thread Larry Hastings 



Like Python?  Like Italy?  Like meetings?  Then I've got a treat for you!

I'll be chairing a Python Language Summit this July in historic 
Florence, Italy.  It'll be on July 1st (the day before EuroPython 
starts) at the Grand Hotel Mediterraneo conference center.  Language 
Summits are when the Python core contributors step away from their 
computers and get together for a day to argue in person.


Email me if you're interested in attending; I can send you the final 
details and simultaneously get a rough headcount.


Volunteers to take notes are greatly appreciated,


//arry/
___
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] Optimize Unicode strings in Python 3.3

2012-05-30 Thread Serhiy Storchaka 

On 30.05.12 14:26, Victor Stinner wrote:

I implemented something like that, and it was not efficient and very complex.

See for example the (incomplete) patch for str%args attached to the
issue #14687:
http://bugs.python.org/file25413/pyunicode_format-2.patch


I have seen and commented on this patch. That's not what I'm talking about.


IMO this approach is less efficient than the "Unicode writer" approach because:


I brought this approach is not for the opposition of the "Unicode 
writer", and for comparison with a straight "two steps" method. Of 
course, this can be combined with the "Unicode writer" to get the 
benefits of both methods. For example, you can advance to widen the 
output buffer to a width of format string, or disable overallocation 
when formating the last argument with non-empty suffix.



  - you have to create many substrings or temporary strings in the
first step, or (worse) compute each argument twice: the writer
approach is more efficient here because it avoids computing substrings
and temporary strings


Not on the first step but on the second step (and this is the only 
single step if you use caching), if you use the "Unicode writer".



  - you have to parse the format string twice, or you have to write two
versions of the code: first create a list of items, then concatenate
items. The PyAccu method concatenates substrings at the end, it is
less efficient than the writer method (e.g. it has to create a string
of N fill characters to pad to WIDTH characters).


The code is divided into the compiler and the interpreter. Only the 
first one parses the format string. See Modules/_struct.c.



  - the code is more complex than the writer method (which is very
similar to what is used in Python 2.7 and 3.2)


The code that uses the writer method to be rather complicated, the 
difference in the total complexity of these approaches has become 
smaller. ;-)


But it is really not easy work, not assure success, so let waits for its 
time.


___
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] cpython: Issue #14744: Fix compilation on Windows (part 2)

2012-05-30 Thread Kristján Valur Jónsson 
Curiously, the 64bit debug windows build cannot run the unittests either.
There are crash bugs in the release build and I wanted to repro it using the 
debug version , but failed.
This is likely to be related to the virtualenv changes, perhaps.
see http://bugs.python.org/issue14952


> -Original Message-
> From: [email protected]
> [mailto:[email protected]] On
> Behalf Of Georg Brandl
> Sent: 30. maí 2012 06:52
> To: [email protected]
> Subject: Re: [Python-Dev] cpython: Issue #14744: Fix compilation on
> Windows (part 2)
> 
> Am 29.05.2012 18:54, schrieb victor.stinner:
> > http://hg.python.org/cpython/rev/df0144f68d76
> > changeset:   77231:df0144f68d76
> > user:Victor Stinner 
> > date:Tue May 29 18:53:56 2012 +0200
> > summary:
> >   Issue #14744: Fix compilation on Windows (part 2)
> 
> All Windows buildbots are still failing the test suite, with an "invalid 
> format
> string" ValueError, so I assume that is related to your string formatting
> speedups -- can you please have a look at it before I can tag the alpha?
> 
> thanks,
> Georg
> 
> 
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-
> dev/kristjan%40ccpgames.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] cpython: Issue #14744: Fix compilation on Windows (part 2)

2012-05-30 Thread R. David Murray 
On Wed, 30 May 2012 14:03:44 -, =?iso-8859-1?Q?Kristj=E1n_Valur_J=F3nsson?= 
 wrote:
> > -Original Message-
> > From: [email protected]
> > [mailto:[email protected]] On
> > Behalf Of Georg Brandl
> > Sent: 30. maí 2012 06:52
> > To: [email protected]
> > Subject: Re: [Python-Dev] cpython: Issue #14744: Fix compilation on
> > Windows (part 2)
> > 
> > Am 29.05.2012 18:54, schrieb victor.stinner:
> > > http://hg.python.org/cpython/rev/df0144f68d76
> > > changeset:   77231:df0144f68d76
> > > user:Victor Stinner 
> > > date:Tue May 29 18:53:56 2012 +0200
> > > summary:
> > >   Issue #14744: Fix compilation on Windows (part 2)
> > 
> > All Windows buildbots are still failing the test suite, with an "invalid 
> > format
> > string" ValueError, so I assume that is related to your string formatting
> > speedups -- can you please have a look at it before I can tag the alpha?
>
> Curiously, the 64bit debug windows build cannot run the unittests either.
> There are crash bugs in the release build and I wanted to repro it using the 
> debug version , but failed.
> This is likely to be related to the virtualenv changes, perhaps.
> see http://bugs.python.org/issue14952

The "ValueError: Invalid format string" was coming from a
broken-on-windows test_calendar test I checked in.  It is fixed now and
the stable windows buildbots are green.

--David
___
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] Property inheritance in Python

2012-05-30 Thread Guido van Rossum 
Agreed this could go on the tracker, but I don't see the need for a
Python-Ideas detour. It seems worth fixing (and I vaguely recall there was
some follow-up last time?).

--Guido van Rossum (sent from Android phone)
On May 29, 2012 11:58 PM, "Terry Reedy"  wrote:

> On 5/30/2012 1:58 AM, [email protected] wrote:
>
>> Hi,
>>
>> I apologize if I violate (or am violating) some sacred mailing list rules.
>>
>> Torsten wrote back in 2010
>> (http://mail.python.org/**pipermail/python-dev/2010-**April/099672.html)
>> about
>> property inheritance behavior and super().  Specifically, only fget()
>> behavior
>> of properties work with super(), not fset() or fdel().
>>
>> I apologize if there's some obvious reason this has not been addressed
>> since
>> then, but it seems to be expected behavior and most Pythonic, and
>> confused me
>> greatly when I ran into it recently.  Torsten's original thread seems to
>> have
>> gone as if unseen, so I hesitantly bump this topic in the hopes of a
>> resolution.
>>
>
> This sort of idea should either be posted on python-ideas to get support
> or put on the tracker if the proposal is specific enough to write a patch
> (or both, with a patch making it more likely to happen).
>
> --
> 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/**
> guido%40python.org
>
___
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] cpython: Issue #14744: Fix compilation on Windows (part 2)

2012-05-30 Thread Kristján Valur Jónsson 


> -Original Message-
> From: R. David Murray [mailto:[email protected]]
> 
> 
> The "ValueError: Invalid format string" was coming from a broken-on-
> windows test_calendar test I checked in.  It is fixed now and the stable
> windows buildbots are green.
> 
> --David

Hm, there appear to be no x64 buildbots.

K

___
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] cpython: Issue #14744: Fix compilation on Windows (part 2)

2012-05-30 Thread Brian Curtin 
On Wed, May 30, 2012 at 10:46 AM, Kristján Valur Jónsson
 wrote:
>
>
>> -Original Message-
>> From: R. David Murray [mailto:[email protected]]
>>
>>
>> The "ValueError: Invalid format string" was coming from a broken-on-
>> windows test_calendar test I checked in.  It is fixed now and the stable
>> windows buildbots are green.
>>
>> --David
>
> Hm, there appear to be no x64 buildbots.

Antoine asked about one several weeks ago. I have a Windows 8 x64
machine that I am planning on setting up once I have the time. I'll
try to shift things around and get it back into the fleet.

The machine used to be the 2008 x64 build slave we had last year.
___
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] ur'string literal' in 3.3: make same as in 2.x?

2012-05-30 Thread Terry Reedy 

In 2.7, 'r' and 'ur' string literal prefixes have different effects:

"When an 'r' or 'R' prefix is present, a character following a backslash 
is included in the string without change, and all backslashes are left 
in the string."


"When an 'r' or 'R' prefix is used in conjunction with a 'u' or 'U' 
prefix, then the \u and \U escape sequences are processed 
while all other backslashes are left in the string."


When 'u' was deleted in 3.0, the first meaning was kept.

Was any thought given to restoring this difference in 3.3, along with 
restoring 'u', so that code using 'ur' prefixes would truly be 
cross-compatible? (I checked, and it has not been.) Cross-compatibility 
is the point of adding 'u' back, and this would give 'u' prefixes an 
actual, useful function even in Python 3.


This issue came up today in python-list thread 'python3 raw strings and 
\u escapes' by 'rurpy', who uses 'ur' for re strings with unicode chars 
and is trying to port his code to 3.x.


--
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] VS 11 Express is Metro only.

2012-05-30 Thread Martin v. Löwis 

I hereby predict that Microsoft will revert this decision, and that
VS Express
11 will be able to build CPython.

But will it be able to target Windows XP?


I'll still need to try. I couldn't easily find a Windows XP installation 
to try out whether a hello world application runs on XP.


Please understand that Visual Studio never had the notion of 
"targetting" an operating system. The Windows SDK has that notion,
and it appears that targetting XP continues to be supported. Visual 
Studio C/C++ only targets Debug vs. Release, and Win32 vs. IA-64 vs.

x64 (leaving CE/Windows Mobile/WP7 aside).

The only place where platform support matters is the CRT, and this is
what I still want to test. E.g. it might be that the C RT works on XP,
and the C++ RT might use newer API.

Regards,
Martin

___
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] cpython: Issue #14744: Fix compilation on Windows (part 2)

2012-05-30 Thread Georg Brandl 
Am 30.05.2012 16:03, schrieb Kristján Valur Jónsson:
> Curiously, the 64bit debug windows build cannot run the unittests either.
> There are crash bugs in the release build and I wanted to repro it using the 
> debug version , but failed.
> This is likely to be related to the virtualenv changes, perhaps.
> see http://bugs.python.org/issue14952

For alpha4, I don't see that as a blocker (better give the venv stuff testing
on all other platforms than to revert it now), but of course it has to be
resolved before beta.

Here's hoping for a Windows x64 buildbot...

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

Re: [Python-Dev] cpython: Issue #14744: Fix compilation on Windows (part 2)

2012-05-30 Thread Georg Brandl 
Am 30.05.2012 16:40, schrieb R. David Murray:
> On Wed, 30 May 2012 14:03:44 -, 
> =?iso-8859-1?Q?Kristj=E1n_Valur_J=F3nsson?=  wrote:
>> > -Original Message-
>> > From: [email protected]
>> > [mailto:[email protected]] On
>> > Behalf Of Georg Brandl
>> > Sent: 30. maí 2012 06:52
>> > To: [email protected]
>> > Subject: Re: [Python-Dev] cpython: Issue #14744: Fix compilation on
>> > Windows (part 2)
>> > 
>> > Am 29.05.2012 18:54, schrieb victor.stinner:
>> > > http://hg.python.org/cpython/rev/df0144f68d76
>> > > changeset:   77231:df0144f68d76
>> > > user:Victor Stinner 
>> > > date:Tue May 29 18:53:56 2012 +0200
>> > > summary:
>> > >   Issue #14744: Fix compilation on Windows (part 2)
>> > 
>> > All Windows buildbots are still failing the test suite, with an "invalid 
>> > format
>> > string" ValueError, so I assume that is related to your string formatting
>> > speedups -- can you please have a look at it before I can tag the alpha?
>>
>> Curiously, the 64bit debug windows build cannot run the unittests either.
>> There are crash bugs in the release build and I wanted to repro it using the 
>> debug version , but failed.
>> This is likely to be related to the virtualenv changes, perhaps.
>> see http://bugs.python.org/issue14952
> 
> The "ValueError: Invalid format string" was coming from a
> broken-on-windows test_calendar test I checked in.  It is fixed now and
> the stable windows buildbots are green.

Indeed. Sorry Victor, bad David ;)

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

Re: [Python-Dev] cpython: Issue #14744: Fix compilation on Windows (part 2)

2012-05-30 Thread Kristján Valur Jónsson 


-Original Message-
From: Brian Curtin [mailto:[email protected]] 
Sent: 30. maí 2012 15:56
To: Kristján Valur Jónsson
Cc: [email protected]
Subject: Re: [Python-Dev] cpython: Issue #14744: Fix compilation on Windows 
(part 2)
appear to be no x64 buildbots.

>Antoine asked about one several weeks ago. I have a Windows 8 x64 machine that 
>I am planning on setting up once I have the time. I'll try to shift things 
>around and get it back into the >fleet.

>The machine used to be the 2008 x64 build slave we had last year.

I freely admit to not being a buildbot specialist, haven't touched those things 
for some years.  Hence my perhaps silly question:  Why do we need multiple 
windows machines, since they can cross compile and cross run left right and 
centre?  
Virtual PCs can be used to test compatibility with earlier versions.
K

___
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] Property inheritance in Python

2012-05-30 Thread Nick Coghlan 
On May 31, 2012 1:31 AM, "Guido van Rossum"  wrote:
>
> Agreed this could go on the tracker, but I don't see the need for a
Python-Ideas detour.

+1

> It seems worth fixing (and I vaguely recall there was some follow-up last
time?).

You may be thinking of the abstract property fixes that went in - I'm
fairly sure this specific problem report fell through the cracks.

Cheers,
Nick.

--
Sent from my phone, thus the relative brevity :)
___
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] ur'string literal' in 3.3: make same as in 2.x?

2012-05-30 Thread Nick Coghlan 
Sounds reasonable and within the intent of the PEP, so a tracker issue
would be the next step.

Cheers,
Nick.

--
Sent from my phone, thus the relative brevity :)
___
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] cpython: Issue #14744: Fix compilation on Windows (part 2)

2012-05-30 Thread Brian Curtin 
On Wed, May 30, 2012 at 3:35 PM, Kristján Valur Jónsson
 wrote:
>
>
> -Original Message-
> From: Brian Curtin [mailto:[email protected]]
> Sent: 30. maí 2012 15:56
> To: Kristján Valur Jónsson
> Cc: [email protected]
> Subject: Re: [Python-Dev] cpython: Issue #14744: Fix compilation on Windows 
> (part 2)
> appear to be no x64 buildbots.
>
>>Antoine asked about one several weeks ago. I have a Windows 8 x64 machine 
>>that I am planning on setting up once I have the time. I'll try to shift 
>>things around and get it back into the >fleet.
>
>>The machine used to be the 2008 x64 build slave we had last year.
>
> I freely admit to not being a buildbot specialist, haven't touched those 
> things for some years.  Hence my perhaps silly question:  Why do we need 
> multiple windows machines, since they can cross compile and cross run left 
> right and centre?
> Virtual PCs can be used to test compatibility with earlier versions.
> K

I don't have the quality of hardware or the knowledge and time to set
any of that up, so that's my excuse.

I just turn my computer on and write code. When it doesn't work I
reboot it. That's the extent of my system administration skills.
___
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] VS 11 Express is Metro only.

2012-05-30 Thread Larry Hastings 

On 05/30/2012 12:43 PM, "Martin v. Löwis" wrote:
Please understand that Visual Studio never had the notion of 
"targetting" an operating system. The Windows SDK has that notion, and 
it appears that targetting XP continues to be supported.


I may be misremembering, but--the C API of necessity calls the Win32 
API.  So if Microsoft chooses to call new Win32 APIs as part of the C 
API, this can force you to require a minimum Windows version.  I dimly 
recall an incident some years back where part of the startup code for a 
C program (code called before main / WinMain) was calling a newish API, 
and thus programs generated with that version of the compiler could not 
support older Windows versions.



//arry/
___
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] VS 11 Express is Metro only.

2012-05-30 Thread Neil Hodgson 
Curt:

>> But will it be able to target Windows XP?

   It will likely be possible in a reasonable manner at some point. From 
http://blogs.msdn.com/b/visualstudio/archive/2012/05/18/a-look-ahead-at-the-visual-studio-11-product-lineup-and-platform-support.aspx
 :

"""C++ developers can also use the multi-targeting capability included in 
Visual Studio 11 to continue using the compilers and libraries included in 
Visual Studio 2010 to target Windows XP and Windows Server 2003. 
Multi-targeting for C++ applications currently requires a side-by-side 
installation of Visual Studio 2010. Separately, we are evaluating options for 
C++ that would enable developers to directly target XP without requiring a 
side-by-side installation of Visual Studio 2010 and intend to deliver this 
update post-RTM. """

Martin v. Löwis wrote:

> The only place where platform support matters is the CRT, and this is
> what I still want to test. E.g. it might be that the C RT works on XP,
> and the C++ RT might use newer API.

   C++ runtime is more dependent on post-XP features than C runtime but even 
the C runtime currently needs some thunks:
http://tedwvc.wordpress.com/

   Neil

___
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] [Python-checkins] cpython: Make parameterized tests in email less hackish.

2012-05-30 Thread Nick Coghlan 
I'm not clear on why this is a metaclass rather than a simple class decorator.

On Thu, May 31, 2012 at 11:54 AM, r.david.murray
 wrote:
> +    In a _params dictioanry, the keys become part of the name of the 
> generated
> +    tests.  In a _params list, the values in the list are converted into a
> +    string by joining the string values of the elements of the tuple by '_' 
> and
> +    converting any blanks into '_'s, and this become part of the name.  The
> +    full name of a generated test is the portion of the _params name before 
> the
> +    '_params' portion, plus an '_', plus the name derived as explained above.

Your description doesn't match your examples or implementation.
Assuming the example and implementation are correct (and they look
more sensible than the currently described approach), I believe that
last sentence should be:

"The  full name of a generated test is a 'test_' prefix, the portion
of the test function name after the  '_as_' separator, plus an '_',
plus the name derived as explained above."

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
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