From guido at python.org  Tue Jan  1 18:15:17 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 1 Jan 2008 09:15:17 -0800
Subject: [Python-3000] Some notes on newline conversion.
In-Reply-To: <acd65fa20712272319q7a10c94j87fbb92e6588a4f4@mail.gmail.com>
References: <acd65fa20712272319q7a10c94j87fbb92e6588a4f4@mail.gmail.com>
Message-ID: <ca471dc20801010915r1b0654a7qa25263a9adc28104@mail.gmail.com>

I thought PEP 3016 spells out all the details necessary. And the
docstring for open() in io.py as well. Aren't those enough?

On Dec 27, 2007 11:19 PM, Alexandre Vassalotti <alexandre at peadrop.com> wrote:
> Hi,
>
> I had a hard time, earlier today, figuring out what was the rules for
> converting newline characters (only from the code of
> io.TextIOWrapper). So, I wrote some notes for myself. I don't know if
> there's any documentation about this yet -- that is why am posting my
> notes to the list. Free it to use them for whatever you want to.
>
> Cheers,
> -- Alexandre
>
>
> Known newline type:
>   LF: \n or "universal newline"
>   CRLF: \r\n
>   CR: \r
>
> Argument |
> value    | Notes
> ---------+-------------------------------------------------------
> None     | Default mode for open().
>          | LF are converted to the value of os.linesep on writes.
>          | Convert any known newline type to LF on reads.
>          | Readline splits on LF.
> ---------+-------------------------------------------------------
> ""       | No conversions on writes.
>          | No conversions on reads.
>          | Readline splits on any known newline type.
> ---------+-------------------------------------------------------
> LF       | Default mode for StringIO.
>          | No conversions on writes.
>          | No conversions on reads.
>          | Readline splits on LF.
> ---------+-------------------------------------------------------
> CRLF     | Convert LF to CRLF on writes.
>          | No conversions on reads.
>          | Readline splits on CRLF.
> ---------+-------------------------------------------------------
> CR       | Convert LF to CR on writes.
>          | No conversions on reads.
>          | Readline splits on CR.
> ---------+-------------------------------------------------------
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From guido at python.org  Tue Jan  1 20:04:11 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 1 Jan 2008 11:04:11 -0800
Subject: [Python-3000] The grand renaming
In-Reply-To: <4777C473.9020604@cheimes.de>
References: <4777C473.9020604@cheimes.de>
Message-ID: <ca471dc20801011104i3ec2a992x2492ef6eb1d5383c@mail.gmail.com>

I don't like renaming PyString to PyBytes right now -- in 2.6 this
sounds wrong since it is publicly known as the str[ing] type. Renaming
only in 3.0 would make merges from the trunk harder. (Unless you have
evidence to the contrary?)

I'm okay with renaming PyBytes -> PyByteArray, PyBuffer ->
PyMemoryView, and the corresponding file renames (make sure to update
all the project files, even for obsolete or minority compilers or
platforms).

There's also a bunch of potential renames in the area of method and
function objects, but I don't have the time to dig up the details.

--Guido

On Dec 30, 2007 8:16 AM, Christian Heimes <lists at cheimes.de> wrote:
> Python 3.0a2 is out and some people are working on backports of Python
> 3.0 features to 2.6. Shouldn't we start to rename the new API functions
> and files to their final names before we back merge code to 2.6?
>
> I'm proposing to change the names and files as following. I'm willing to
> make the necessary changes myself.
>
> API methods:
> PyUnicode - keep the name
> PyBytes - PyByteArray
> PyString - PyBytes
> PyBuffer - PyMemoryView
>
> Files:
> bytesobject.[ch] - bytearrayobject.[ch]
> memoryobject.[ch] - memoryviewobject.[ch]
> stringobject.[ch] - bytesobject.[ch]
>
> Christian
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From lists at cheimes.de  Tue Jan  1 20:32:59 2008
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 01 Jan 2008 20:32:59 +0100
Subject: [Python-3000] The grand renaming
In-Reply-To: <ca471dc20801011104i3ec2a992x2492ef6eb1d5383c@mail.gmail.com>
References: <4777C473.9020604@cheimes.de>
	<ca471dc20801011104i3ec2a992x2492ef6eb1d5383c@mail.gmail.com>
Message-ID: <477A956B.20801@cheimes.de>

Guido van Rossum wrote:
> I don't like renaming PyString to PyBytes right now -- in 2.6 this
> sounds wrong since it is publicly known as the str[ing] type. Renaming
> only in 3.0 would make merges from the trunk harder. (Unless you have
> evidence to the contrary?)
> 
> I'm okay with renaming PyBytes -> PyByteArray, PyBuffer ->
> PyMemoryView, and the corresponding file renames (make sure to update
> all the project files, even for obsolete or minority compilers or
> platforms).
> 
> There's also a bunch of potential renames in the area of method and
> function objects, but I don't have the time to dig up the details.

I was thinking about a backport of the bytes type to Python 2.6. The new
bytes type is going to cause the largest head ache for developers. The
name "bytes" and the b"" literal don't conflict with any 2.5 feature.

A rename of the file would make it harder to merge changes from 2.6's
Objects/stringobject.c to 3.0's Object/byteobject.c but the renaming of
the function names doesn't make it much harder to merge. It's going to
cause some conflicts but they are easy to resolve.

Christian

From alexandre at peadrop.com  Tue Jan  1 21:52:10 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Tue, 1 Jan 2008 15:52:10 -0500
Subject: [Python-3000] Some notes on newline conversion.
In-Reply-To: <ca471dc20801010915r1b0654a7qa25263a9adc28104@mail.gmail.com>
References: <acd65fa20712272319q7a10c94j87fbb92e6588a4f4@mail.gmail.com>
	<ca471dc20801010915r1b0654a7qa25263a9adc28104@mail.gmail.com>
Message-ID: <acd65fa20801011252sf8a4088t781915129ab74205@mail.gmail.com>

On Jan 1, 2008 12:15 PM, Guido van Rossum <guido at python.org> wrote:
> I thought PEP 3016 spells out all the details necessary. And the
> docstring for open() in io.py as well. Aren't those enough?
>

Oh, indeed. I didn't remark that PEP 3116 had a section about newline
conversion. It's my mistake then.

Thanks for the note,
-- Alexandre

From guido at python.org  Tue Jan  1 22:33:02 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 1 Jan 2008 13:33:02 -0800
Subject: [Python-3000] The grand renaming
In-Reply-To: <477A956B.20801@cheimes.de>
References: <4777C473.9020604@cheimes.de>
	<ca471dc20801011104i3ec2a992x2492ef6eb1d5383c@mail.gmail.com>
	<477A956B.20801@cheimes.de>
Message-ID: <ca471dc20801011333h408250e2rfc8647f7c106ee0c@mail.gmail.com>

On Jan 1, 2008 11:32 AM, Christian Heimes <lists at cheimes.de> wrote:
> Guido van Rossum wrote:
> > I don't like renaming PyString to PyBytes right now -- in 2.6 this
> > sounds wrong since it is publicly known as the str[ing] type. Renaming
> > only in 3.0 would make merges from the trunk harder. (Unless you have
> > evidence to the contrary?)
> >
> > I'm okay with renaming PyBytes -> PyByteArray, PyBuffer ->
> > PyMemoryView, and the corresponding file renames (make sure to update
> > all the project files, even for obsolete or minority compilers or
> > platforms).
> >
> > There's also a bunch of potential renames in the area of method and
> > function objects, but I don't have the time to dig up the details.
>
> I was thinking about a backport of the bytes type to Python 2.6. The new
> bytes type is going to cause the largest head ache for developers. The
> name "bytes" and the b"" literal don't conflict with any 2.5 feature.

Are you thinking of adding bytes as an alias of str, or as a whole new
type? I see problems for both, unfortunately. Making it an alias for
str has very different semantics than in 3.0 (where it is incompatible
with the new str, PyUnicode); making it a new type causes problems
because anything that *returns* str in 2.5 will have to return str in
2.6 as well. So only the backported io.py could really use it.

> A rename of the file would make it harder to merge changes from 2.6's
> Objects/stringobject.c to 3.0's Object/byteobject.c but the renaming of
> the function names doesn't make it much harder to merge. It's going to
> cause some conflicts but they are easy to resolve.

That depends. If a call to PyString_WhatEver() is added to 2.6, the
most likely translation in 3.0 is also PyString_WhatEver(). If it has
to be changed into PyBytes_WhatEver() that is just asking for merge
problems.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From alexandre at peadrop.com  Thu Jan  3 20:09:08 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Thu, 3 Jan 2008 14:09:08 -0500
Subject: [Python-3000] Reimplementing TextIOWrapper in C?
In-Reply-To: <acd65fa20712281256i59ae7cf7y90d6cbfc5ad74a05@mail.gmail.com>
References: <acd65fa20712281137q232c5a36p7f29465b85e6f0d4@mail.gmail.com>
	<bbaeab100712281147g700cb289wb9ec567f7f1a88b3@mail.gmail.com>
	<acd65fa20712281256i59ae7cf7y90d6cbfc5ad74a05@mail.gmail.com>
Message-ID: <acd65fa20801031109y7f77c540ufda049b1cc45558d@mail.gmail.com>

On Dec 28, 2007 3:56 PM, Alexandre Vassalotti <alexandre at peadrop.com> wrote:
> Otherwise, could I simply subclass my StringIO and write the newlines
> conversion facilities in Python?

I tried that, and I found out it doesn't work well either. Again, I
can't reuse IncrementalNewlineDecoder since it expects bytes. So, I
will basically have to reimplement it for unicode, which is kind of an
ugly solution. Just by curious, anyone has a better idea? Otherwise, I
am just going to take the ugly solution.

-- Alexandre

From guido at python.org  Fri Jan  4 20:18:27 2008
From: guido at python.org (Guido van Rossum)
Date: Fri, 4 Jan 2008 11:18:27 -0800
Subject: [Python-3000] Need closure on __cmp__ removal
Message-ID: <ca471dc20801041118p63f8c9e5oe25a280be93aea0f@mail.gmail.com>

In the past some folks have been pushing for the resurrection of (some
form of) __cmp__, which is currently removed from Py3k (except for
some remnants which we'll clean up in due time).

I'd like to get closure on this issue. If someone volunteers within a
week to write a PEP, I'll give them a month to write the PEP, and then
I'll review it. The PEP better come with a patch implementing
(roughly) the desired behavior as well, relative to the 3.0 branch.

If I don't hear from a committed volunteer within a week, I'll drop
this and start removing __cmp__ references aggressively (starting with
issue #1717). Saying "if no-one else volunteers, I can give it a shot"
is not sufficient commitment. Saying "I will give it a shot" is. If
someone commits but no PEP+patch is in my possession by February 4
(and no attenuating circumstances have been brought to my attention),
I will assume the PEP won't happen and will start removing __cmp__
references. Once a PEP and patch are presented, I'll review them and
make a decision.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From rhamph at gmail.com  Fri Jan  4 20:35:23 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Fri, 4 Jan 2008 12:35:23 -0700
Subject: [Python-3000] Need closure on __cmp__ removal
In-Reply-To: <ca471dc20801041118p63f8c9e5oe25a280be93aea0f@mail.gmail.com>
References: <ca471dc20801041118p63f8c9e5oe25a280be93aea0f@mail.gmail.com>
Message-ID: <aac2c7cb0801041135g613e2e6ct74a3ce2bc0d89d0a@mail.gmail.com>

On Jan 4, 2008 12:18 PM, Guido van Rossum <guido at python.org> wrote:

> In the past some folks have been pushing for the resurrection of (some
> form of) __cmp__, which is currently removed from Py3k (except for
> some remnants which we'll clean up in due time).
>
> I'd like to get closure on this issue. If someone volunteers within a
> week to write a PEP, I'll give them a month to write the PEP, and then
> I'll review it. The PEP better come with a patch implementing
> (roughly) the desired behavior as well, relative to the 3.0 branch.
>
> If I don't hear from a committed volunteer within a week, I'll drop
> this and start removing __cmp__ references aggressively (starting with
> issue #1717). Saying "if no-one else volunteers, I can give it a shot"
> is not sufficient commitment. Saying "I will give it a shot" is. If
> someone commits but no PEP+patch is in my possession by February 4
> (and no attenuating circumstances have been brought to my attention),
> I will assume the PEP won't happen and will start removing __cmp__
> references. Once a PEP and patch are presented, I'll review them and
> make a decision.


I can't speak for the others, but I know I've decided not to pursue it.

-- 
Adam Olsen, aka Rhamphoryncus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080104/f11e5fea/attachment.htm 

From michele.simionato at gmail.com  Sat Jan  5 08:59:04 2008
From: michele.simionato at gmail.com (Michele Simionato)
Date: Sat, 5 Jan 2008 08:59:04 +0100
Subject: [Python-3000] docutils and Python 3000
Message-ID: <4edc17eb0801042359v57209588s807f2ff5b62e4330@mail.gmail.com>

I would like to know if docutils has been ported to Python 3.0 and if
yes where I can
download the code.

 Michele Simionato

From p.f.moore at gmail.com  Sat Jan  5 12:26:47 2008
From: p.f.moore at gmail.com (Paul Moore)
Date: Sat, 5 Jan 2008 11:26:47 +0000
Subject: [Python-3000] docutils and Python 3000
In-Reply-To: <4edc17eb0801042359v57209588s807f2ff5b62e4330@mail.gmail.com>
References: <4edc17eb0801042359v57209588s807f2ff5b62e4330@mail.gmail.com>
Message-ID: <79990c6b0801050326n5b193c0fk7824a5967e5b02c2@mail.gmail.com>

On 05/01/2008, Michele Simionato <michele.simionato at gmail.com> wrote:
> I would like to know if docutils has been ported to Python 3.0 and if
> yes where I can download the code.

That would be a question for the docutils development list -
docutils-develop at lists.sourceforge.net.

Paul.

From alexandre at peadrop.com  Sun Jan  6 00:50:54 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Sat, 5 Jan 2008 18:50:54 -0500
Subject: [Python-3000] Is pickle's persistent_id worth keeping?
Message-ID: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>

Hi,

I currently trying to clean up the interface of the pickle module for
Python 3K. So far, I haven't done much, except documenting parts the
pickle stream format.

There's still one thing I still don't understand about pickle,
persistent_id. I haven't found any useful use-cases for it. Using
Google's code search, only Zope (or variant of) seems to have found
some obscure way to use it. (Is there a Python feature Zope doesn't
use? <wink>) Personally, I think persistent_id is just a remnant of
the older protocol, which didn't memoize object.

So, would it be okay to remove it from the next version of the protocol?

-- Alexandre

From nas at arctrix.com  Sun Jan  6 03:50:06 2008
From: nas at arctrix.com (Neil Schemenauer)
Date: Sun, 6 Jan 2008 02:50:06 +0000 (UTC)
Subject: [Python-3000] Is pickle's persistent_id worth keeping?
References: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>
Message-ID: <flpfkt$mhl$1@ger.gmane.org>

Alexandre Vassalotti <alexandre at peadrop.com> wrote:
> There's still one thing I still don't understand about pickle,
> persistent_id. I haven't found any useful use-cases for it. Using
> Google's code search, only Zope (or variant of) seems to have found
> some obscure way to use it.

Durus (an object database similar to ZODB) also uses it.  If it's
not expensive to support, I'd prefer it not to go away.

  Neil


From jyasskin at gmail.com  Sun Jan  6 03:57:42 2008
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Sat, 5 Jan 2008 18:57:42 -0800
Subject: [Python-3000] Rounding Decimals
Message-ID: <5d44f72f0801051857i3b13f1b0q8a9e485831dcd603@mail.gmail.com>

On Jan 5, 2008 3:34 PM, Mark Dickinson <dickinsm at gmail.com> wrote:
>
> On Jan 5, 2008 5:54 PM, <glyph at divmod.com> wrote:
> >
> > At first I didn't realize why I'd missed this feature.  While the
> > rounding *modes* are well documented, though, after 20 minutes of
> > reading documentation I still haven't found a method or function that
> > simply rounds a decimal to a given significant digit.  Is there one,
> > should there be one, or is the user simply meant to use Context.quantize
> > with appropriate arguments?
> >
> >
> >
> >
>
> quantize is about as close as it gets.  Note that it's a Decimal method as
> well as a Context method, so you can invoke it directly on a given decimal:
>
>
> >>> Decimal("2.34567").quantize(Decimal("0.01"))
> Decimal("2.35")
>
>
> I've also occasionally felt a need for a simple rounding function that isn't
> affected by context.  Would others be interested in such a function being
> added to Decimal?  I guess there are two possibly useful operations:  (1)
> round to a particular decimal place ( e.g. nearest ten, nearest hundredth,
> ..) and (2) to round to a particular number of significant digits;  in both
> cases, the user should be able to specify the desired rounding mode.  And
> for each operation, it might also be useful to specify whether the result
> should be padded with zeros to the desired length or not.  ( i.e. when
> rounding 3.399 to 3 significant places, should it produce 3.4 or 3.40?)
>
> Any thoughts?

I think pep 3141's round(x, ndigits) does (1). The only thing it
doesn't support yet is specifying the rounding mode. Perhaps the pep
should say that round() passes any extra named arguments on to the
__round__() method so that users can specify a rounding mode for types
that support it?

The Real interface doesn't say anything about significant digits, so
Decimal can do whatever we want. My first guess would be that round
should remove significant digits but not add them. (i.e.
round("3.199", 2) == "3.20" but round("3", 1) == "3".)

As you know, I'm working on a patch to implement 3141 for Decimal at
http://bugs.python.org/issue1623, which I'll update as soon as this
thread comes to a conclusion. Other people who are interested in
getting this right should add themselves to its nosy list so they can
object before I check something dumb in. :) I currently plan to keep
__round__ in 2.6's Decimal with 3.0's behavior because it no longer
affects the round() builtin in 2.6. Users who want it can call it
directly ? or we might provide, in 2.6, a module that provides 3.0
versions of the core library functions that change behavior so that
they can get the new round() explicitly.

-- 
Namast?,
Jeffrey Yasskin

From python at rcn.com  Sun Jan  6 04:11:49 2008
From: python at rcn.com (Raymond Hettinger)
Date: Sat, 5 Jan 2008 19:11:49 -0800
Subject: [Python-3000] [Python-Dev] Rounding Decimals
References: <5d44f72f0801051857i3b13f1b0q8a9e485831dcd603@mail.gmail.com>
Message-ID: <003101c85011$e1572530$6800a8c0@RaymondLaptop1>

> I think pep 3141's round(x, ndigits) does (1). The only thing it
> doesn't support yet is specifying the rounding mode. Perhaps the pep
> should say that round() passes any extra named arguments on to the
> __round__() method so that users can specify a rounding mode for types
> that support it?

That would clutter the interface.  Just specify a universal rounding mode for __round__ and have Decimal's implementation of that 
method comply.

If someone wants more control than that, they can manipulate the decimal object directly.


Raymond 

From pje at telecommunity.com  Sun Jan  6 04:58:10 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sat, 05 Jan 2008 22:58:10 -0500
Subject: [Python-3000] Is pickle's persistent_id worth keeping?
In-Reply-To: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.co
 m>
References: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>
Message-ID: <20080106035755.AF8803A40A4@sparrow.telecommunity.com>

At 06:50 PM 1/5/2008 -0500, Alexandre Vassalotti wrote:
>I currently trying to clean up the interface of the pickle module for
>Python 3K. So far, I haven't done much, except documenting parts the
>pickle stream format.
>
>There's still one thing I still don't understand about pickle,
>persistent_id. I haven't found any useful use-cases for it.

Any system that wants to be able to pickle parts of an object graph 
while retaining references.  Any system that wants to be able to 
handle missing, moved, or renamed classes when unpickling.


>  Using
>Google's code search, only Zope (or variant of) seems to have found
>some obscure way to use it.

Is Chandler considered a Zope variant now, and if so, why?  :)


>So, would it be okay to remove it from the next version of the protocol?

Chandler's .chex (Chandler export) files use this to handle class 
moves, or data for a missing or broken plugin.  If/when we'll ever 
use Python 3 is an open question, but if we did, we'd certainly 
continue to need it.


From hashcollision at gmail.com  Sun Jan  6 07:40:46 2008
From: hashcollision at gmail.com (hashcollision)
Date: Sun, 6 Jan 2008 01:40:46 -0500
Subject: [Python-3000] Need closure on __cmp__ removal
Message-ID: <37f76d50801052240w44bbf29arb80d7e7b1a451710@mail.gmail.com>

David A. Wheeler has already written a draft PEP, which can be found here:
http://www.dwheeler.com/misc/pep-cmp.txt.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080106/b00e8b3b/attachment.htm 

From hashcollision at gmail.com  Sun Jan  6 10:19:31 2008
From: hashcollision at gmail.com (hashcollision)
Date: Sun, 6 Jan 2008 04:19:31 -0500
Subject: [Python-3000] Request for prod()
Message-ID: <37f76d50801060119u201a74f3yc27fa183e81ecdda@mail.gmail.com>

I request the addition of prod():

def prod(seq):
     s = 1
     for x in seq:
         s *= x

prod is always as useful as sum()
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080106/8fd30a2c/attachment.htm 

From jyasskin at gmail.com  Sun Jan  6 10:21:11 2008
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Sun, 6 Jan 2008 01:21:11 -0800
Subject: [Python-3000] [Python-Dev] Rounding Decimals
In-Reply-To: <003101c85011$e1572530$6800a8c0@RaymondLaptop1>
References: <5d44f72f0801051857i3b13f1b0q8a9e485831dcd603@mail.gmail.com>
	<003101c85011$e1572530$6800a8c0@RaymondLaptop1>
Message-ID: <5d44f72f0801060121l39c4d2a0jfdea69f644bc1822@mail.gmail.com>

On Jan 5, 2008 7:11 PM, Raymond Hettinger <python at rcn.com> wrote:
> > I think pep 3141's round(x, ndigits) does (1). The only thing it
> > doesn't support yet is specifying the rounding mode. Perhaps the pep
> > should say that round() passes any extra named arguments on to the
> > __round__() method so that users can specify a rounding mode for types
> > that support it?
>
> That would clutter the interface.  Just specify a universal rounding mode for __round__ and have Decimal's implementation of that
> method comply.

Yeah, thinking about this more, a .round() method on Context objects
seems like a better way to handle the part of Mark's request that the
round builtin doesn't cover. Of course, there may be even better
alternatives that I haven't thought of. I'll post a patch to
http://bugs.python.org/issue1623 tomorrow so we have something
concrete to talk about.

-- 
Namast?,
Jeffrey Yasskin

From hashcollision at gmail.com  Sun Jan  6 11:01:10 2008
From: hashcollision at gmail.com (hashcollision)
Date: Sun, 6 Jan 2008 05:01:10 -0500
Subject: [Python-3000] Default factory that uses key
Message-ID: <37f76d50801060201n54fd6255y437406d8328a8cd@mail.gmail.com>

 The default factory that collections.defaultdict takes cannot use key. Is
there a way to have the default factory take the key into consideration? For
example

d = collections.defaultdict(lambda title: BookShelf(title))

If not, I propose that it be added.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080106/e5e3526a/attachment-0001.htm 

From g.brandl at gmx.net  Sun Jan  6 11:07:40 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 06 Jan 2008 11:07:40 +0100
Subject: [Python-3000] Default factory that uses key
In-Reply-To: <37f76d50801060201n54fd6255y437406d8328a8cd@mail.gmail.com>
References: <37f76d50801060201n54fd6255y437406d8328a8cd@mail.gmail.com>
Message-ID: <flq9a1$9tp$1@ger.gmane.org>

hashcollision schrieb:
> The default factory that collections.defaultdict takes cannot use key. 
> Is there a way to have the default factory take the key into 
> consideration? For example
>  
> d = collections.defaultdict(lambda title: BookShelf(title))
>  
> If not, I propose that it be added.

Note that you can easily write a type like that yourself, using
dict.__missing__:

class DefShelfDict(dict):
     def __missing__(self, key):
         shelf = self[key] = BookShelf(key)
         return shelf

or some such.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From g.brandl at gmx.net  Sun Jan  6 11:08:36 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 06 Jan 2008 11:08:36 +0100
Subject: [Python-3000] Request for prod()
In-Reply-To: <37f76d50801060119u201a74f3yc27fa183e81ecdda@mail.gmail.com>
References: <37f76d50801060119u201a74f3yc27fa183e81ecdda@mail.gmail.com>
Message-ID: <flq9bp$9tp$2@ger.gmane.org>

hashcollision schrieb:
> I request the addition of prod():
>  
> def prod(seq):
>      s = 1
>      for x in seq:
>          s *= x
>  
> prod is always as useful as sum()

It would have to be called product(), and I believe it has been proposed
multiple times and been rejected under the "not every 3-line function
has to be builtin" rule.

It could of course be added to functools...

Georg


-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From p.f.moore at gmail.com  Sun Jan  6 15:53:29 2008
From: p.f.moore at gmail.com (Paul Moore)
Date: Sun, 6 Jan 2008 14:53:29 +0000
Subject: [Python-3000] Request for prod()
In-Reply-To: <flq9bp$9tp$2@ger.gmane.org>
References: <37f76d50801060119u201a74f3yc27fa183e81ecdda@mail.gmail.com>
	<flq9bp$9tp$2@ger.gmane.org>
Message-ID: <79990c6b0801060653n19ccfb20hc8e05b392275deae@mail.gmail.com>

On 06/01/2008, Georg Brandl <g.brandl at gmx.net> wrote:
> hashcollision schrieb:
> > I request the addition of prod():
> It would have to be called product(), and I believe it has been proposed
> multiple times and been rejected under the "not every 3-line function
> has to be builtin" rule.

Please also note that the time for requesting additions like this to
Python 3.0 is long past.

Paul.

From g.brandl at gmx.net  Sun Jan  6 15:55:47 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 06 Jan 2008 15:55:47 +0100
Subject: [Python-3000] Request for prod()
In-Reply-To: <79990c6b0801060653n19ccfb20hc8e05b392275deae@mail.gmail.com>
References: <37f76d50801060119u201a74f3yc27fa183e81ecdda@mail.gmail.com>	<flq9bp$9tp$2@ger.gmane.org>
	<79990c6b0801060653n19ccfb20hc8e05b392275deae@mail.gmail.com>
Message-ID: <flqq68$q1k$1@ger.gmane.org>

Paul Moore schrieb:
> On 06/01/2008, Georg Brandl <g.brandl at gmx.net> wrote:
>> hashcollision schrieb:
>> > I request the addition of prod():
>> It would have to be called product(), and I believe it has been proposed
>> multiple times and been rejected under the "not every 3-line function
>> has to be builtin" rule.
> 
> Please also note that the time for requesting additions like this to
> Python 3.0 is long past.

Not really; standard library additions are yet to be considered.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From p.f.moore at gmail.com  Sun Jan  6 17:30:31 2008
From: p.f.moore at gmail.com (Paul Moore)
Date: Sun, 6 Jan 2008 16:30:31 +0000
Subject: [Python-3000] Request for prod()
In-Reply-To: <flqq68$q1k$1@ger.gmane.org>
References: <37f76d50801060119u201a74f3yc27fa183e81ecdda@mail.gmail.com>
	<flq9bp$9tp$2@ger.gmane.org>
	<79990c6b0801060653n19ccfb20hc8e05b392275deae@mail.gmail.com>
	<flqq68$q1k$1@ger.gmane.org>
Message-ID: <79990c6b0801060830j4bae2268vba378a5900d48f05@mail.gmail.com>

On 06/01/2008, Georg Brandl <g.brandl at gmx.net> wrote:
> Paul Moore schrieb:
> > On 06/01/2008, Georg Brandl <g.brandl at gmx.net> wrote:
> >> hashcollision schrieb:
> >> > I request the addition of prod():
> >> It would have to be called product(), and I believe it has been proposed
> >> multiple times and been rejected under the "not every 3-line function
> >> has to be builtin" rule.
> >
> > Please also note that the time for requesting additions like this to
> > Python 3.0 is long past.
>
> Not really; standard library additions are yet to be considered.

I was responding to the (implicit) suggestion that it be a builtin.
Your response covers a request to add it to a library module
(functools, for example).

Paul.

From g.brandl at gmx.net  Sun Jan  6 22:17:21 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 06 Jan 2008 22:17:21 +0100
Subject: [Python-3000] Request for prod()
In-Reply-To: <79990c6b0801060830j4bae2268vba378a5900d48f05@mail.gmail.com>
References: <37f76d50801060119u201a74f3yc27fa183e81ecdda@mail.gmail.com>	<flq9bp$9tp$2@ger.gmane.org>	<79990c6b0801060653n19ccfb20hc8e05b392275deae@mail.gmail.com>	<flqq68$q1k$1@ger.gmane.org>
	<79990c6b0801060830j4bae2268vba378a5900d48f05@mail.gmail.com>
Message-ID: <flrghm$2k8$1@ger.gmane.org>

Paul Moore schrieb:
> On 06/01/2008, Georg Brandl <g.brandl at gmx.net> wrote:
>> Paul Moore schrieb:
>> > On 06/01/2008, Georg Brandl <g.brandl at gmx.net> wrote:
>> >> hashcollision schrieb:
>> >> > I request the addition of prod():
>> >> It would have to be called product(), and I believe it has been proposed
>> >> multiple times and been rejected under the "not every 3-line function
>> >> has to be builtin" rule.
>> >
>> > Please also note that the time for requesting additions like this to
>> > Python 3.0 is long past.
>>
>> Not really; standard library additions are yet to be considered.
> 
> I was responding to the (implicit) suggestion that it be a builtin.
> Your response covers a request to add it to a library module
> (functools, for example).

I'm sorry, that has been a misunderstanding on my part then.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From martin at v.loewis.de  Sun Jan  6 23:39:34 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Sun, 06 Jan 2008 23:39:34 +0100
Subject: [Python-3000] py3k keyword is gone
Message-ID: <478158A6.3050509@v.loewis.de>

As people had disliked the py3k keyword in the tracker,
I have now changed all items that were still using it to
use the Python 3.0 version instead, and retired that keyword.

So please search for version "Python 3.0" if you want to see
issues related to Python 3000.

Regards,
Martin

From jyasskin at gmail.com  Mon Jan  7 00:26:28 2008
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Sun, 6 Jan 2008 15:26:28 -0800
Subject: [Python-3000] [Python-Dev] Rounding Decimals
In-Reply-To: <5d44f72f0801060121l39c4d2a0jfdea69f644bc1822@mail.gmail.com>
References: <5d44f72f0801051857i3b13f1b0q8a9e485831dcd603@mail.gmail.com>
	<003101c85011$e1572530$6800a8c0@RaymondLaptop1>
	<5d44f72f0801060121l39c4d2a0jfdea69f644bc1822@mail.gmail.com>
Message-ID: <5d44f72f0801061526x788b0a46lbbc17ec5dde44ceb@mail.gmail.com>

On Jan 6, 2008 1:21 AM, Jeffrey Yasskin <jyasskin at gmail.com> wrote:
> On Jan 5, 2008 7:11 PM, Raymond Hettinger <python at rcn.com> wrote:
> > > I think pep 3141's round(x, ndigits) does (1). The only thing it
> > > doesn't support yet is specifying the rounding mode. Perhaps the pep
> > > should say that round() passes any extra named arguments on to the
> > > __round__() method so that users can specify a rounding mode for types
> > > that support it?
> >
> > That would clutter the interface.  Just specify a universal rounding mode for __round__ and have Decimal's implementation of that
> > method comply.
>
> Yeah, thinking about this more, a .round() method on Context objects
> seems like a better way to handle the part of Mark's request that the
> round builtin doesn't cover. Of course, there may be even better
> alternatives that I haven't thought of. I'll post a patch to
> http://bugs.python.org/issue1623 tomorrow so we have something
> concrete to talk about.

The new patch is posted: http://bugs.python.org/file9080/decimal-3141.patch
I'll implement Context.round() in a separate patch. Comment away. :)

-- 
Namast?,
Jeffrey Yasskin

From guido at python.org  Mon Jan  7 00:47:36 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 6 Jan 2008 15:47:36 -0800
Subject: [Python-3000] Request for prod()
In-Reply-To: <37f76d50801060119u201a74f3yc27fa183e81ecdda@mail.gmail.com>
References: <37f76d50801060119u201a74f3yc27fa183e81ecdda@mail.gmail.com>
Message-ID: <ca471dc20801061547ufef6371l4fa99f9e311a3a8c@mail.gmail.com>

On Jan 6, 2008 1:19 AM, hashcollision <hashcollision at gmail.com> wrote:
> I request the addition of prod():
>
> def prod(seq):
>      s = 1
>      for x in seq:
>          s *= x
>
> prod is always as useful as sum()

No it isn't.

This was discussed extensively at the time sum() was proposed and
accepted, and it was found that product() has much less usage than
sum() -- so much less so that it's not worth adding.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From python at rcn.com  Mon Jan  7 02:13:21 2008
From: python at rcn.com (Raymond Hettinger)
Date: Sun, 6 Jan 2008 17:13:21 -0800
Subject: [Python-3000] [Python-Dev] Rounding Decimals
References: <5d44f72f0801051857i3b13f1b0q8a9e485831dcd603@mail.gmail.com>
	<003101c85011$e1572530$6800a8c0@RaymondLaptop1>
	<5d44f72f0801060121l39c4d2a0jfdea69f644bc1822@mail.gmail.com>
	<5d44f72f0801061526x788b0a46lbbc17ec5dde44ceb@mail.gmail.com>
Message-ID: <007601c850ca$7f2ab3e0$6800a8c0@RaymondLaptop1>

FWIW, I don't think all of these patches are helpful.  The implementations are so easy and the effects are so obvious, that it is 
simply better to decide what to do first, then do it afterwards.

My own preference is to leave the decimal module alone (except for a __round__ method to be called by builtin.round).  Adding more 
methods to that module does not make it easier to use -- there are already a mind-numbing range of choices in the current, minimal 
implementation of the spec.  I would support having a separate module of convenience functions or a separate module that uses a 
subset, but growth of the core module will only make it harder to use and more difficult to maintain.  Another idea for 
simplifcation is to write-up a good tutorial to the basics of using the module.

Please show restraint when proposing API changes to decimal -- I think it would be easy to do more harm than good.

Raymond




----- Original Message ----- 
From: "Jeffrey Yasskin" <jyasskin at gmail.com>
To: "Raymond Hettinger" <python at rcn.com>
Cc: "Mark Dickinson" <dickinsm at gmail.com>; "Python 3000" <python-3000 at python.org>; <python-dev at python.org>
Sent: Sunday, January 06, 2008 3:26 PM
Subject: Re: [Python-Dev] Rounding Decimals


> On Jan 6, 2008 1:21 AM, Jeffrey Yasskin <jyasskin at gmail.com> wrote:
>> On Jan 5, 2008 7:11 PM, Raymond Hettinger <python at rcn.com> wrote:
>> > > I think pep 3141's round(x, ndigits) does (1). The only thing it
>> > > doesn't support yet is specifying the rounding mode. Perhaps the pep
>> > > should say that round() passes any extra named arguments on to the
>> > > __round__() method so that users can specify a rounding mode for types
>> > > that support it?
>> >
>> > That would clutter the interface.  Just specify a universal rounding mode for __round__ and have Decimal's implementation of 
>> > that
>> > method comply.
>>
>> Yeah, thinking about this more, a .round() method on Context objects
>> seems like a better way to handle the part of Mark's request that the
>> round builtin doesn't cover. Of course, there may be even better
>> alternatives that I haven't thought of. I'll post a patch to
>> http://bugs.python.org/issue1623 tomorrow so we have something
>> concrete to talk about.
>
> The new patch is posted: http://bugs.python.org/file9080/decimal-3141.patch
> I'll implement Context.round() in a separate patch. Comment away. :)
>
> -- 
> Namast?,
> Jeffrey Yasskin
> 

From jyasskin at gmail.com  Mon Jan  7 03:03:01 2008
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Sun, 6 Jan 2008 18:03:01 -0800
Subject: [Python-3000] [Python-Dev] Rounding Decimals
In-Reply-To: <007601c850ca$7f2ab3e0$6800a8c0@RaymondLaptop1>
References: <5d44f72f0801051857i3b13f1b0q8a9e485831dcd603@mail.gmail.com>
	<003101c85011$e1572530$6800a8c0@RaymondLaptop1>
	<5d44f72f0801060121l39c4d2a0jfdea69f644bc1822@mail.gmail.com>
	<5d44f72f0801061526x788b0a46lbbc17ec5dde44ceb@mail.gmail.com>
	<007601c850ca$7f2ab3e0$6800a8c0@RaymondLaptop1>
Message-ID: <5d44f72f0801061803m2fc7ca45gc6a08f415d5a4901@mail.gmail.com>

On Jan 6, 2008 5:13 PM, Raymond Hettinger <python at rcn.com> wrote:
> FWIW, I don't think all of these patches are helpful.  The implementations are so easy and the effects are so obvious, that it is
> simply better to decide what to do first, then do it afterwards.
>
> My own preference is to leave the decimal module alone (except for a __round__ method to be called by builtin.round).

You must mean __trunc__ to support builtin.trunc(), since
builtin.round no longer calls __round__ in 2.6. The other 3 methods
specified by PEP 3141 aren't strictly necessary for 2.6, but they will
be needed for 3.0. I'd rather not make the two versions of Decimal
gratuitously different, so this patch puts them in the 2.6 version
too. That's basically all of the changes in this patch, so I'm not
sure exactly what you're objecting to. Could you be more precise?

-- 
Namast?,
Jeffrey Yasskin

From python at rcn.com  Mon Jan  7 04:40:31 2008
From: python at rcn.com (Raymond Hettinger)
Date: Sun, 6 Jan 2008 19:40:31 -0800
Subject: [Python-3000] [Python-Dev] Rounding Decimals
References: <5d44f72f0801051857i3b13f1b0q8a9e485831dcd603@mail.gmail.com>
	<003101c85011$e1572530$6800a8c0@RaymondLaptop1>
	<5d44f72f0801060121l39c4d2a0jfdea69f644bc1822@mail.gmail.com>
	<5d44f72f0801061526x788b0a46lbbc17ec5dde44ceb@mail.gmail.com>
	<007601c850ca$7f2ab3e0$6800a8c0@RaymondLaptop1>
	<5d44f72f0801061803m2fc7ca45gc6a08f415d5a4901@mail.gmail.com>
Message-ID: <00a801c850df$0e953e10$6800a8c0@RaymondLaptop1>

[Jeffrey Yasskin]
> The other 3 methods
> specified by PEP 3141 aren't strictly necessary for 2.6, but they will
> be needed for 3.0. I'd rather not make the two versions of Decimal
> gratuitously different, so this patch puts them in the 2.6 version
> too.

If I understand you correctly, then the patch backports magic methods that do not have corresponding invocation methods in Py2.6. 
So, they are basically useless. If that's true, then the patch is clutter -- it makes 2.6 less desirable.  It is not obvious to me 
how this will help someone transition to Py3.0.  I'm curious to hear how Guido makes the call on this.

Also, the goal of keeping versions identical across 2.6 and 3.0 is at odds with previous discussions where I believe we said that 
that is *not* the goal and will likely not even be possible in many cases.  Besides, if the invocation of the magic methods is 
different in 3.0, how are you going to keep the test suite code the same across versions?

There should probably be a PEP sets clearer guidelines about what should be backported from Py3.0.  Perhaps something like this:
* If there is a new feature that can be implemented in both and will make both more attractive, then it should be in both.
* If something is going away or changing in 3.0, then the 2.6 conversion tool mode should warn about it if possible.
* If neither of the above apply, then leave 2.6 alone.

> I'm not
> sure exactly what you're objecting to. Could you be more precise?

You note said: "I'll implement Context.round() in a separate patch. Comment away."

Unless I misread what you're trying to do, that is a gratuitous API build-out (whether talking about Py2.6 or Py3.0) which adds a 
second-way-to-do-it to a module that already has a huge number of methods.  Our goal is to keep that module as a minimal 
implementation of the spec.  Fattening the API will make the module harder to use, not simpler.


Raymond

From guido at python.org  Mon Jan  7 05:01:56 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 6 Jan 2008 20:01:56 -0800
Subject: [Python-3000] Need closure on __cmp__ removal
In-Reply-To: <37f76d50801052240w44bbf29arb80d7e7b1a451710@mail.gmail.com>
References: <37f76d50801052240w44bbf29arb80d7e7b1a451710@mail.gmail.com>
Message-ID: <ca471dc20801062001m148b343ex450a9093c8c1359a@mail.gmail.com>

On Jan 5, 2008 10:40 PM, hashcollision <hashcollision at gmail.com> wrote:
> David A. Wheeler has already written a draft PEP, which can be found here:
> http://www.dwheeler.com/misc/pep-cmp.txt.

Thanks, I'd missed that.

But alas, it's a bit short on the motivation for rich comparisons. For
example it fails to notice that quite a few object types need to be
comparable for equality but need not be orderable. Comparison for
equality only is often much faster than a full three-way-compare,
since there is likely some quick test that decides two instances
cannot possibly be equal (e.g. lists of different lengths). It also
misses the use case of overloading < and <= as set inclusion
operators.

But the biggest thing missing is precise semantics. Saying "exactly
the same semantics as with Python 2.5" doesn't cut it (those semantics
are incredibly hairy and sometimes surprising, and their
implementation was a nightmare -- I've rarely been as relieved as when
I was able to cut those out of the implementation).

A PEP should specify exactly what happens when both __cmp__ and one or
more of the __xx__ operators are defined on the same class; it should
specify what it means to override one or the other in a subclass; and
it should define Python and C APIs for invoking __cmp__ (and what it
should do if __cmp__ isn't defined).

I also notice that, because not-equal can often be decided more
quickly than a full ordering, the argument (which I brought up
myself!) that not having __cmp__ would slow down list comparisons may
be wrong or at least weak. E.g., for the sake of argument, let's
assume that __eq__ is just 10% faster than __cmp__, and __lt__ is as
fast as __eq__. Then comparing two lists using __cmp__ on successive
element pairs would be slower than using __eq__ plus one final __lt__
if the deciding element is beyond the 9th index. If __eq__ is twice as
fast as __cmp__ and __lt__ is the same speed as __cmp__, using __cmp__
would be slower beyond the 2nd index.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From guido at python.org  Mon Jan  7 05:31:36 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 6 Jan 2008 20:31:36 -0800
Subject: [Python-3000] [Python-Dev] Rounding Decimals
In-Reply-To: <00a801c850df$0e953e10$6800a8c0@RaymondLaptop1>
References: <5d44f72f0801051857i3b13f1b0q8a9e485831dcd603@mail.gmail.com>
	<003101c85011$e1572530$6800a8c0@RaymondLaptop1>
	<5d44f72f0801060121l39c4d2a0jfdea69f644bc1822@mail.gmail.com>
	<5d44f72f0801061526x788b0a46lbbc17ec5dde44ceb@mail.gmail.com>
	<007601c850ca$7f2ab3e0$6800a8c0@RaymondLaptop1>
	<5d44f72f0801061803m2fc7ca45gc6a08f415d5a4901@mail.gmail.com>
	<00a801c850df$0e953e10$6800a8c0@RaymondLaptop1>
Message-ID: <ca471dc20801062031q741f099bhbd0451301e5ef797@mail.gmail.com>

On Jan 6, 2008 7:40 PM, Raymond Hettinger <python at rcn.com> wrote:
> [Jeffrey Yasskin]
> > The other 3 methods
> > specified by PEP 3141 aren't strictly necessary for 2.6, but they will
> > be needed for 3.0. I'd rather not make the two versions of Decimal
> > gratuitously different, so this patch puts them in the 2.6 version
> > too.
>
> If I understand you correctly, then the patch backports magic methods that do not have corresponding invocation methods in Py2.6.
> So, they are basically useless. If that's true, then the patch is clutter -- it makes 2.6 less desirable.  It is not obvious to me
> how this will help someone transition to Py3.0.  I'm curious to hear how Guido makes the call on this.
>
> Also, the goal of keeping versions identical across 2.6 and 3.0 is at odds with previous discussions where I believe we said that
> that is *not* the goal and will likely not even be possible in many cases.  Besides, if the invocation of the magic methods is
> different in 3.0, how are you going to keep the test suite code the same across versions?

I tend to agree. 2.6 and 3.0 decimal already differ plenty.

> There should probably be a PEP sets clearer guidelines about what should be backported from Py3.0.

Can you volunteer a draft? It could be PEP 3003. I'm probably too
close to 3.0 to be able to objectively write this, which really
represents end users' desire for stability in 2.6.

> Perhaps something like this:
> * If there is a new feature that can be implemented in both and will make both more attractive, then it should be in both.
> * If something is going away or changing in 3.0, then the 2.6 conversion tool mode should warn about it if possible.
> * If neither of the above apply, then leave 2.6 alone.
>
> > I'm not
> > sure exactly what you're objecting to. Could you be more precise?
>
> You note said: "I'll implement Context.round() in a separate patch. Comment away."
>
> Unless I misread what you're trying to do, that is a gratuitous API build-out (whether talking about Py2.6 or Py3.0) which adds a
> second-way-to-do-it to a module that already has a huge number of methods.  Our goal is to keep that module as a minimal
> implementation of the spec.  Fattening the API will make the module harder to use, not simpler.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From python at rcn.com  Mon Jan  7 06:08:21 2008
From: python at rcn.com (Raymond Hettinger)
Date: Sun, 6 Jan 2008 21:08:21 -0800
Subject: [Python-3000] [Python-Dev] Rounding Decimals
References: <5d44f72f0801051857i3b13f1b0q8a9e485831dcd603@mail.gmail.com>
	<003101c85011$e1572530$6800a8c0@RaymondLaptop1>
	<5d44f72f0801060121l39c4d2a0jfdea69f644bc1822@mail.gmail.com>
	<5d44f72f0801061526x788b0a46lbbc17ec5dde44ceb@mail.gmail.com>
	<007601c850ca$7f2ab3e0$6800a8c0@RaymondLaptop1>
	<5d44f72f0801061803m2fc7ca45gc6a08f415d5a4901@mail.gmail.com>
	<00a801c850df$0e953e10$6800a8c0@RaymondLaptop1>
	<ca471dc20801062031q741f099bhbd0451301e5ef797@mail.gmail.com>
Message-ID: <00bf01c850eb$53b84120$6800a8c0@RaymondLaptop1>

[Raymond]
>> There should probably be a PEP sets clearer guidelines about what should be backported from Py3.0.
>>
>> Perhaps something like this:
>> * If there is a new feature that can be implemented in both and will make both more attractive, then it should be in both.
>> * If something is going away or changing in 3.0, then the 2.6 conversion tool mode should warn about it if possible.
>> * If neither of the above apply, then leave 2.6 alone.

[Guido van Rossum]
> Can you volunteer a draft? It could be PEP 3003. I'm probably too
> close to 3.0 to be able to objectively write this, which really
> represents end users' desire for stability in 2.6.

Yes.  Will do.


Raymond

From jyasskin at gmail.com  Mon Jan  7 06:54:30 2008
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Sun, 6 Jan 2008 21:54:30 -0800
Subject: [Python-3000] [Python-Dev] Rounding Decimals
In-Reply-To: <00a801c850df$0e953e10$6800a8c0@RaymondLaptop1>
References: <5d44f72f0801051857i3b13f1b0q8a9e485831dcd603@mail.gmail.com>
	<003101c85011$e1572530$6800a8c0@RaymondLaptop1>
	<5d44f72f0801060121l39c4d2a0jfdea69f644bc1822@mail.gmail.com>
	<5d44f72f0801061526x788b0a46lbbc17ec5dde44ceb@mail.gmail.com>
	<007601c850ca$7f2ab3e0$6800a8c0@RaymondLaptop1>
	<5d44f72f0801061803m2fc7ca45gc6a08f415d5a4901@mail.gmail.com>
	<00a801c850df$0e953e10$6800a8c0@RaymondLaptop1>
Message-ID: <5d44f72f0801062154n4a1dab9fu60abb3bb4b0d02dc@mail.gmail.com>

On Jan 6, 2008 7:40 PM, Raymond Hettinger <python at rcn.com> wrote:
> [Jeffrey Yasskin]
> > The other 3 methods
> > specified by PEP 3141 aren't strictly necessary for 2.6, but they will
> > be needed for 3.0. I'd rather not make the two versions of Decimal
> > gratuitously different, so this patch puts them in the 2.6 version
> > too.
>
> If I understand you correctly, then the patch backports magic methods that do not have corresponding invocation methods in Py2.6.
> So, they are basically useless. If that's true, then the patch is clutter -- it makes 2.6 less desirable.  It is not obvious to me
> how this will help someone transition to Py3.0.  I'm curious to hear how Guido makes the call on this.
>
> Also, the goal of keeping versions identical across 2.6 and 3.0 is at odds with previous discussions where I believe we said that
> that is *not* the goal and will likely not even be possible in many cases.  Besides, if the invocation of the magic methods is
> different in 3.0, how are you going to keep the test suite code the same across versions?

Given Guido's agreement, expect another version of this patch with
only __trunc__.

> There should probably be a PEP sets clearer guidelines about what should be backported from Py3.0.  Perhaps something like this:
> * If there is a new feature that can be implemented in both and will make both more attractive, then it should be in both.
> * If something is going away or changing in 3.0, then the 2.6 conversion tool mode should warn about it if possible.
> * If neither of the above apply, then leave 2.6 alone.
>
> > I'm not
> > sure exactly what you're objecting to. Could you be more precise?
>
> You note said: "I'll implement Context.round() in a separate patch. Comment away."

Oh, sorry for not being clear then. I don't intend to write or discuss
that separate patch until this one's approved and submitted. I think
it's worth discussing eventually, but this change is more important. I
mentioned this sentiment at http://bugs.python.org/msg59417 too, but
clearly wasn't explicit enough in either case.

-- 
Namast?,
Jeffrey Yasskin

From python at rcn.com  Mon Jan  7 07:51:32 2008
From: python at rcn.com (Raymond Hettinger)
Date: Sun, 6 Jan 2008 22:51:32 -0800
Subject: [Python-3000] [Python-Dev] Rounding Decimals
References: <5d44f72f0801051857i3b13f1b0q8a9e485831dcd603@mail.gmail.com>
	<003101c85011$e1572530$6800a8c0@RaymondLaptop1>
	<5d44f72f0801060121l39c4d2a0jfdea69f644bc1822@mail.gmail.com>
	<5d44f72f0801061526x788b0a46lbbc17ec5dde44ceb@mail.gmail.com>
	<007601c850ca$7f2ab3e0$6800a8c0@RaymondLaptop1>
	<5d44f72f0801061803m2fc7ca45gc6a08f415d5a4901@mail.gmail.com>
	<00a801c850df$0e953e10$6800a8c0@RaymondLaptop1>
	<5d44f72f0801062154n4a1dab9fu60abb3bb4b0d02dc@mail.gmail.com>
Message-ID: <00d001c850f9$bd67e2c0$6800a8c0@RaymondLaptop1>

[Jeffrey Yasskin]
>> > I'm not
>> > sure exactly what you're objecting to. Could you be more precise?
>>
>> You note said: "I'll implement Context.round() in a separate patch. Comment away."
> 
> Oh, sorry for not being clear then. I don't intend to write or discuss
> that separate patch until this one's approved and submitted. I think
> it's worth discussing eventually, but this change is more important. I
> mentioned this sentiment at http://bugs.python.org/msg59417 too, but
> clearly wasn't explicit enough in either case.

It's hard to keep up with all of these patches and I'm growing concerned
that some will sneak by.  In the case of complex proposals, it is often
helpful to have a patch that we can discuss concretely, but in the case of
simple ones like this, they just clutter to patch tracker.  There's no need
to create the patch until the idea has been discussed.

In the case of Context.round(), I've already advised against it.
So, I'm not sure why you still intend write a separate patch
and bring it back up for discussion.  Ideally, it should die right now.

The sentiment is unchanged -- please do not build-out the API for the
decimal module.  It is intended to be minimal and needs to stay that
way.  Further additions will only make it harder to use, harder to
maintain, and will complicate efforts to rewrite the module in C.

Raymond

From python at rcn.com  Mon Jan  7 08:28:57 2008
From: python at rcn.com (Raymond Hettinger)
Date: Sun, 6 Jan 2008 23:28:57 -0800
Subject: [Python-3000] [Python-Dev] Rounding Decimals
References: <5d44f72f0801051857i3b13f1b0q8a9e485831dcd603@mail.gmail.com>
	<003101c85011$e1572530$6800a8c0@RaymondLaptop1>
	<5d44f72f0801060121l39c4d2a0jfdea69f644bc1822@mail.gmail.com>
	<5d44f72f0801061526x788b0a46lbbc17ec5dde44ceb@mail.gmail.com>
	<007601c850ca$7f2ab3e0$6800a8c0@RaymondLaptop1>
	<5d44f72f0801061803m2fc7ca45gc6a08f415d5a4901@mail.gmail.com>
	<00a801c850df$0e953e10$6800a8c0@RaymondLaptop1>
	<5d44f72f0801062154n4a1dab9fu60abb3bb4b0d02dc@mail.gmail.com>
Message-ID: <00ea01c850fe$f98aaf30$6800a8c0@RaymondLaptop1>

[Jeffrey Yasskin]
> Given Guido's agreement, expect another version of this patch with
> only __trunc__.

Why is __trunc__ being backported?  Is a trunc() builtin being backported?  What is the point for a synonym for int() and __int__ in 
Py2.6.

Unless I'm missing something, this doesn't improve Py2.6 in the least.


Raymond 

From jyasskin at gmail.com  Mon Jan  7 10:08:26 2008
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Mon, 7 Jan 2008 01:08:26 -0800
Subject: [Python-3000] [Python-Dev] Rounding Decimals
In-Reply-To: <00d001c850f9$bd67e2c0$6800a8c0@RaymondLaptop1>
References: <5d44f72f0801051857i3b13f1b0q8a9e485831dcd603@mail.gmail.com>
	<003101c85011$e1572530$6800a8c0@RaymondLaptop1>
	<5d44f72f0801060121l39c4d2a0jfdea69f644bc1822@mail.gmail.com>
	<5d44f72f0801061526x788b0a46lbbc17ec5dde44ceb@mail.gmail.com>
	<007601c850ca$7f2ab3e0$6800a8c0@RaymondLaptop1>
	<5d44f72f0801061803m2fc7ca45gc6a08f415d5a4901@mail.gmail.com>
	<00a801c850df$0e953e10$6800a8c0@RaymondLaptop1>
	<5d44f72f0801062154n4a1dab9fu60abb3bb4b0d02dc@mail.gmail.com>
	<00d001c850f9$bd67e2c0$6800a8c0@RaymondLaptop1>
Message-ID: <5d44f72f0801070108j896bb34td7fd82daf696d4d0@mail.gmail.com>

On Jan 6, 2008 10:51 PM, Raymond Hettinger <python at rcn.com> wrote:
> [Jeffrey Yasskin]
> >> > I'm not
> >> > sure exactly what you're objecting to. Could you be more precise?
> >>
> >> You note said: "I'll implement Context.round() in a separate patch. Comment away."
> >
> > Oh, sorry for not being clear then. I don't intend to write or discuss
> > that separate patch until this one's approved and submitted. I think
> > it's worth discussing eventually, but this change is more important. I
> > mentioned this sentiment at http://bugs.python.org/msg59417 too, but
> > clearly wasn't explicit enough in either case.
>
> It's hard to keep up with all of these patches and I'm growing concerned
> that some will sneak by.

You're certainly right to be concerned. The most significant patch,
the original backport of 3141, _did_ sneak through. The only email
I've gotten about it has been in response to my question about a
detail. I don't know how I could have made it more obvious though:
nobody who suggested the backport (http://bugs.python.org/issue1623)
seemed to think it would be contentious enough to suggest emailing
this list first. Since then, I've tried to keep things transparent by
suggesting that you add yourself to the nosy list of
http://bugs.python.org/issue1623, which is where I'll post any patches
before thinking about committing them.

> In the case of complex proposals, it is often
> helpful to have a patch that we can discuss concretely, but in the case of
> simple ones like this, they just clutter to patch tracker.  There's no need
> to create the patch until the idea has been discussed.

I always like to have a patch around because abstract discussions,
even (especially?) on simple topics, have a tendency to run off into
the weeds. A patch keeps things focused and moving forward.

> In the case of Context.round(), I've already advised against it.
> So, I'm not sure why you still intend write a separate patch
> and bring it back up for discussion.  Ideally, it should die right now.

You advised against it. Tim, Mark, and glyph advised for something
like it. I think it's consistent with the fact that most operations on
Decimal instances are mirrored on Context instances, and __round__
will be an operation on Decimal instances. That doesn't sound like
enough agreement to simply drop the discussion.

> The sentiment is unchanged -- please do not build-out the API for the
> decimal module.  It is intended to be minimal and needs to stay that
> way.  Further additions will only make it harder to use, harder to
> maintain, and will complicate efforts to rewrite the module in C.

I am not building out the decimal API. I am adding enough methods to
maintain the comment that "Decimal floating point objects share many
properties with the other builtin numeric types such as float and int.
All of the usual math operations and special methods apply." in both
2.6 and 3.0. After that's done, I am interested in talking about
adding one method that 3 people on this list have been interested in.
I understand that you need to be vigilant against extraneous methods,
but I'm really not just adding these on a whim.

On Jan 6, 2008 11:28 PM, Raymond Hettinger <python at rcn.com> wrote:
> [Jeffrey Yasskin]
> > Given Guido's agreement, expect another version of this patch with
> > only __trunc__.
>
> Why is __trunc__ being backported?  Is a trunc() builtin being backported?  What is the point for a synonym for int() and __int__ in
> Py2.6.
>
> Unless I'm missing something, this doesn't improve Py2.6 in the least.

The trunc() builtin was backported in
http://svn.python.org/view?rev=59671&view=rev and hasn't been rolled
back. All of the reasons to include trunc() in 3.0 apply to 2.6. A
couple that I like are: if trunc had been around in the beginning,
__index__ would have been unnecessary; and the name says what it's
doing, unlike int(). I don't know what Guido's reasoning was for
accepting it into the PEP.

-- 
Namast?,
Jeffrey Yasskin

From python at rcn.com  Mon Jan  7 10:36:41 2008
From: python at rcn.com (Raymond Hettinger)
Date: Mon, 7 Jan 2008 01:36:41 -0800
Subject: [Python-3000] [Python-Dev] Rounding Decimals
References: <5d44f72f0801051857i3b13f1b0q8a9e485831dcd603@mail.gmail.com>
	<003101c85011$e1572530$6800a8c0@RaymondLaptop1>
	<5d44f72f0801060121l39c4d2a0jfdea69f644bc1822@mail.gmail.com>
	<5d44f72f0801061526x788b0a46lbbc17ec5dde44ceb@mail.gmail.com>
	<007601c850ca$7f2ab3e0$6800a8c0@RaymondLaptop1>
	<5d44f72f0801061803m2fc7ca45gc6a08f415d5a4901@mail.gmail.com>
	<00a801c850df$0e953e10$6800a8c0@RaymondLaptop1>
	<5d44f72f0801062154n4a1dab9fu60abb3bb4b0d02dc@mail.gmail.com>
	<00d001c850f9$bd67e2c0$6800a8c0@RaymondLaptop1>
	<5d44f72f0801070108j896bb34td7fd82daf696d4d0@mail.gmail.com>
Message-ID: <011301c85110$cf9c9050$6800a8c0@RaymondLaptop1>

[Jeffrey Yasskin]
> I always like to have a patch around because abstract discussions,
> even (especially?) on simple topics, have a tendency to run off into
> the weeds. A patch keeps things focused and moving forward.

Please recognize that our little system of patches and newsgroup
discussions is easily overwhelmed by someone who is so prolific.
Your work will not receive quality review and discussion if the
volume blows beyond the bandwidth of the other participants.



>> The sentiment is unchanged -- please do not build-out the API for the
>> decimal module.  It is intended to be minimal and needs to stay that
>> way.  Further additions will only make it harder to use, harder to
>> maintain, and will complicate efforts to rewrite the module in C.
> 
> I am not building out the decimal API. I am adding enough methods to
> maintain the comment that "Decimal floating point objects share many
> properties with the other builtin numeric types such as float and int.
> All of the usual math operations and special methods apply." in both
> 2.6 and 3.0. After that's done, I am interested in talking about
> adding one method that 3 people on this list have been interested in.
> I understand that you need to be vigilant against extraneous methods,
> but I'm really not just adding these on a whim.

Arghh!  You seem hell-bent on jamming this in.  Please leave the
decimal module alone.  It does *not* need both a round() method
and a quantize() method.

I read Glyph's note and agree that it wasn't obvious how to round
with the existing API.  That is a documentation problem, not a call
to add duplicate methods.

When one of the module authors asks you to refrain for expanding
the API, please pay special attention.  In this case, you are working
directly against a core philosophy for the design and maintenance
of the module.

I admire your enthusiasm, but please hold it in check.


Raymond


From jim at zope.com  Sun Jan  6 19:35:42 2008
From: jim at zope.com (Jim Fulton)
Date: Sun, 6 Jan 2008 13:35:42 -0500
Subject: [Python-3000] Is pickle's persistent_id worth keeping?
In-Reply-To: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>
References: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>
Message-ID: <17033E0D-6A78-4D66-ACFB-1A5ED150646E@zope.com>

(Note that Alexandre called this thread to my attention.  I wish I had  
more time to pay attention to this list.)

On Jan 5, 2008, at 6:50 PM, Alexandre Vassalotti wrote:

> Hi,
>
> I currently trying to clean up the interface of the pickle module for
> Python 3K. So far, I haven't done much, except documenting parts the
> pickle stream format.
>
> There's still one thing I still don't understand about pickle,
> persistent_id. I haven't found any useful use-cases for it. Using
> Google's code search, only Zope (or variant of) seems to have found
> some obscure way to use it. (Is there a Python feature Zope doesn't
> use? <wink>) Personally, I think persistent_id is just a remnant of
> the older protocol, which didn't memoize object.

Pickle always memoized objects.  persistent_id is useful for  
separating data over multiple pickles as is done in a database.  IOW,  
as its name implies, it is primarily useful for persistence systems.   
I don't think that ZODB is the only persistence system built on  
pickle, but perhaps I'm wrong.

I  suspect ZODB is also the primary user of the pickle module.

> So, would it be okay to remove it from the next version of the  
> protocol?


Well, that would break ZODB (and a few other Zope applications).  I  
think it would break other applications too. Ultimately, it would  
cause a fork.  There would be the version that we use and the version  
that everyone else uses.  I'm not sure that that would be the end of  
the world, OTOH, I don't think it would be a terribly good thing either.

Really, I'd like to see a much smaller standard library.  IMO, pickle  
isn't essential enough to be part of the standard library and I'd be  
happy to see pickle become a separate project. I'd prefer to see most  
of the Python 2 standard library become separate projects.

Jim

--
Jim Fulton
Zope Corporation



From barry at python.org  Mon Jan  7 14:50:38 2008
From: barry at python.org (Barry Warsaw)
Date: Mon, 7 Jan 2008 08:50:38 -0500
Subject: [Python-3000] Is pickle's persistent_id worth keeping?
In-Reply-To: <17033E0D-6A78-4D66-ACFB-1A5ED150646E@zope.com>
References: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>
	<17033E0D-6A78-4D66-ACFB-1A5ED150646E@zope.com>
Message-ID: <7B7B20EA-50BC-4747-9368-19CC001EE8ED@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jan 6, 2008, at 1:35 PM, Jim Fulton wrote:

> Really, I'd like to see a much smaller standard library.  IMO, pickle
> isn't essential enough to be part of the standard library and I'd be
> happy to see pickle become a separate project. I'd prefer to see most
> of the Python 2 standard library become separate projects.

I still think this idea has merit, if only because some packages  
simply have a different lifecycle than the core language.  There are  
advantages and disadvantages to packaging with the core.

I think /if/ we do this, then we need really solid mechanisms for  
installing, uninstalling, and updating packages, for querying what's  
installed, for making assertions about requirements, etc.  Basically  
everything that a good OS package manager does.  PyPI/Cheeseshop/ 
setuptools/easy_install is the closest thing we have, and it's great,  
but it definitely needs polish.

I think it would also be worthwhile getting some OS distro folks  
involved.  I talked with some of the Ubuntu packaging people at our  
company's recent all-hands meeting and they had a very interesting  
perspective on the whole setuptools approach and how it interacts (or  
doesn't) with the distro packagers.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBR4IuLnEjvBPtnXfVAQLzQQQAqntqN6JW/WPK5nso/YWj7ytBfgUP7j0H
YxsgYuAzviHgKbUTEC392UIVPMrEaQRxPg2Fed9wRUfE5yyFA+6L0yzTCG0ahhyK
4NvqhiJqgLKZYXv8nN1bcrGDHm5IWrTL5RnUK6UgxZ45EdTBREzh9QKCMAoEENM6
DtNLMIoAmAc=
=ckf+
-----END PGP SIGNATURE-----

From p.f.moore at gmail.com  Mon Jan  7 15:41:04 2008
From: p.f.moore at gmail.com (Paul Moore)
Date: Mon, 7 Jan 2008 14:41:04 +0000
Subject: [Python-3000] Is pickle's persistent_id worth keeping?
In-Reply-To: <7B7B20EA-50BC-4747-9368-19CC001EE8ED@python.org>
References: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>
	<17033E0D-6A78-4D66-ACFB-1A5ED150646E@zope.com>
	<7B7B20EA-50BC-4747-9368-19CC001EE8ED@python.org>
Message-ID: <79990c6b0801070641j73dca6c7mfcc257244f4fc00d@mail.gmail.com>

On 07/01/2008, Barry Warsaw <barry at python.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Jan 6, 2008, at 1:35 PM, Jim Fulton wrote:
>
> > Really, I'd like to see a much smaller standard library.  IMO, pickle
> > isn't essential enough to be part of the standard library and I'd be
> > happy to see pickle become a separate project. I'd prefer to see most
> > of the Python 2 standard library become separate projects.
>
> I still think this idea has merit, if only because some packages
> simply have a different lifecycle than the core language.  There are
> advantages and disadvantages to packaging with the core.

This has come up before, and I'm still against it. The reality is that
at least in some environments (notably big corporate setups, in my
experience), there's a lot of resistance to getting *any* additional
software installed on boxes. Getting agreement to install "python" can
be a real struggle, and it's incredibly important in that type of
situation that Python *is* "batteries included". Getting agreement to
install Python, and then finding I can't use our standard backup
script without another struggle because it needs datetime, is not
something I want to see. (That was a sort of real example, translated
from Perl - the system had Perl, but Perl's basic time handling is
patchy, and the script needed a better time module from CPAN).

If there were two officially distributed versions of Python,
python-std (basically what we have now) and a python-lite without the
full stdlib, then I could probably live with the situation (but the
big version needs to be flagged as "standard", or the sysadmins will
insist on the other one...) But I'd still prefer the current
situation.

BTW, I'm only really concerned with Windows installers here. The
situation on Unix tends not to be as bad for us (but mainly because
the standard tools are good enough that we get by with them so the
lack of Python isn't worth fighting over :-().

And yes, my experience really has been that bad :-(

Paul.

From facundobatista at gmail.com  Mon Jan  7 15:47:58 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Mon, 7 Jan 2008 12:47:58 -0200
Subject: [Python-3000] [Python-Dev] Rounding Decimals
In-Reply-To: <011301c85110$cf9c9050$6800a8c0@RaymondLaptop1>
References: <5d44f72f0801051857i3b13f1b0q8a9e485831dcd603@mail.gmail.com>
	<5d44f72f0801060121l39c4d2a0jfdea69f644bc1822@mail.gmail.com>
	<5d44f72f0801061526x788b0a46lbbc17ec5dde44ceb@mail.gmail.com>
	<007601c850ca$7f2ab3e0$6800a8c0@RaymondLaptop1>
	<5d44f72f0801061803m2fc7ca45gc6a08f415d5a4901@mail.gmail.com>
	<00a801c850df$0e953e10$6800a8c0@RaymondLaptop1>
	<5d44f72f0801062154n4a1dab9fu60abb3bb4b0d02dc@mail.gmail.com>
	<00d001c850f9$bd67e2c0$6800a8c0@RaymondLaptop1>
	<5d44f72f0801070108j896bb34td7fd82daf696d4d0@mail.gmail.com>
	<011301c85110$cf9c9050$6800a8c0@RaymondLaptop1>
Message-ID: <e04bdf310801070647h44d0d6beg178cca86bcefffde@mail.gmail.com>

2008/1/7, Raymond Hettinger <python at rcn.com>:

> Arghh!  You seem hell-bent on jamming this in.  Please leave the
> decimal module alone.  It does *not* need both a round() method
> and a quantize() method.

Question.

I'm so used to quantize that I don't care. And I'm, in general, -0 to
adding new methods to Decimal and/or Context.

But in Py3, when you make round(x), x.__round__ will be executed. Same
with trunc, ceil and floor. And I think that Decimal should grow these
__xxx__ methods.

Having said that, the only thing that is not clear to me is if we should:

- Diverge 2.6 and 3.0 decimal.py code

- Add these __xxx__ to 2.6, and have still one code of decimal.

Guido voted for this last one, in the issue 1623:

"""
If there aren't too many differences between the 2.6 and 3.0 version of
decimal.py and your patch, do 2.6 first, then the next time we merge
stuff into 3.0 from the trunk it'll be forward-ported automatically.
"""

But, in the light of this thread, and the new PEP that you will be
writing, I think that now it's time to decide this.

Regards,

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From barry at python.org  Mon Jan  7 15:52:57 2008
From: barry at python.org (Barry Warsaw)
Date: Mon, 7 Jan 2008 09:52:57 -0500
Subject: [Python-3000] Is pickle's persistent_id worth keeping?
In-Reply-To: <79990c6b0801070641j73dca6c7mfcc257244f4fc00d@mail.gmail.com>
References: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>
	<17033E0D-6A78-4D66-ACFB-1A5ED150646E@zope.com>
	<7B7B20EA-50BC-4747-9368-19CC001EE8ED@python.org>
	<79990c6b0801070641j73dca6c7mfcc257244f4fc00d@mail.gmail.com>
Message-ID: <87F7D051-7068-4139-9A98-67616938B0E7@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jan 7, 2008, at 9:41 AM, Paul Moore wrote:

> If there were two officially distributed versions of Python,
> python-std (basically what we have now) and a python-lite without the
> full stdlib, then I could probably live with the situation (but the
> big version needs to be flagged as "standard", or the sysadmins will
> insist on the other one...) But I'd still prefer the current
> situation.

I see no reason why this can't be so.

> BTW, I'm only really concerned with Windows installers here. The
> situation on Unix tends not to be as bad for us (but mainly because
> the standard tools are good enough that we get by with them so the
> lack of Python isn't worth fighting over :-().
>
> And yes, my experience really has been that bad :-(

Our Windows installers already include more than the current  
"standard" Python, so I see no reason why we couldn't package and  
bless a sumo-Windows installer.  I suspect it will never be necessary  
for Linux because distros will probably provide all the necessary  
packaging.  There may be other OS's where a sumo distribution is  
needed, but our release process could account for that.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBR4I8yXEjvBPtnXfVAQJDJwP/RtTksLY6IrCGqlPLgJ/rrFYebMGwbc5Q
Y6vILQ9PTnxniRZuL8PntX8C/ZZgIwW6Zg7NTtUkOplrM23gJ4jm2jO8+CuFe8hE
AuOTf6Jk6ZMtG+fWq2+kCGpUT1Zg6evnuhj1Ji01FquqQPVvlpie7g+BS/Y6BJ1j
1OWCmqudAu8=
=sTP3
-----END PGP SIGNATURE-----

From alexandre at peadrop.com  Mon Jan  7 16:17:04 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Mon, 7 Jan 2008 10:17:04 -0500
Subject: [Python-3000] Is pickle's persistent_id worth keeping?
In-Reply-To: <17033E0D-6A78-4D66-ACFB-1A5ED150646E@zope.com>
References: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>
	<17033E0D-6A78-4D66-ACFB-1A5ED150646E@zope.com>
Message-ID: <acd65fa20801070717m7de7ab4fg78627573b48158fb@mail.gmail.com>

On Jan 5, 2008 10:58 PM, Phillip J. Eby <pje at telecommunity.com> wrote:
> Chandler's .chex (Chandler export) files use this to handle class
> moves, or data for a missing or broken plugin.  If/when we'll ever
> use Python 3 is an open question, but if we did, we'd certainly
> continue to need it.


On Jan 6, 2008 1:35 PM, Jim Fulton <jim at zope.com> wrote:
> Pickle always memoized objects.  persistent_id is useful for
> separating data over multiple pickles as is done in a database.  IOW,
> as its name implies, it is primarily useful for persistence systems.
> I don't think that ZODB is the only persistence system built on
> pickle, but perhaps I'm wrong.
>

>From the responses, it is clear that this feature is still needed.

Thanks,
-- Alexandre

From guido at python.org  Mon Jan  7 16:21:52 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 7 Jan 2008 07:21:52 -0800
Subject: [Python-3000] Is pickle's persistent_id worth keeping?
In-Reply-To: <7B7B20EA-50BC-4747-9368-19CC001EE8ED@python.org>
References: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>
	<17033E0D-6A78-4D66-ACFB-1A5ED150646E@zope.com>
	<7B7B20EA-50BC-4747-9368-19CC001EE8ED@python.org>
Message-ID: <ca471dc20801070721v182ff718t620710a7b44c4be2@mail.gmail.com>

On Jan 7, 2008 5:50 AM, Barry Warsaw <barry at python.org> wrote:
> On Jan 6, 2008, at 1:35 PM, Jim Fulton wrote:
>
> > Really, I'd like to see a much smaller standard library.  IMO, pickle
> > isn't essential enough to be part of the standard library and I'd be
> > happy to see pickle become a separate project. I'd prefer to see most
> > of the Python 2 standard library become separate projects.
>
> I still think this idea has merit, if only because some packages
> simply have a different lifecycle than the core language.  There are
> advantages and disadvantages to packaging with the core.
>
> I think /if/ we do this, then we need really solid mechanisms for
> installing, uninstalling, and updating packages, for querying what's
> installed, for making assertions about requirements, etc.  Basically
> everything that a good OS package manager does.  PyPI/Cheeseshop/
> setuptools/easy_install is the closest thing we have, and it's great,
> but it definitely needs polish.
>
> I think it would also be worthwhile getting some OS distro folks
> involved.  I talked with some of the Ubuntu packaging people at our
> company's recent all-hands meeting and they had a very interesting
> perspective on the whole setuptools approach and how it interacts (or
> doesn't) with the distro packagers.

Noooo...! Please start a new thread! Please!

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From fdrake at acm.org  Mon Jan  7 16:26:38 2008
From: fdrake at acm.org (Fred Drake)
Date: Mon, 7 Jan 2008 10:26:38 -0500
Subject: [Python-3000] Is pickle's persistent_id worth keeping?
In-Reply-To: <17033E0D-6A78-4D66-ACFB-1A5ED150646E@zope.com>
References: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>
	<17033E0D-6A78-4D66-ACFB-1A5ED150646E@zope.com>
Message-ID: <52C7B012-8C6A-4530-BE04-ADA9BC54D4E1@acm.org>

On Jan 6, 2008, at 1:35 PM, Jim Fulton wrote:
> Really, I'd like to see a much smaller standard library.  IMO, pickle
> isn't essential enough to be part of the standard library and I'd be
> happy to see pickle become a separate project. I'd prefer to see most
> of the Python 2 standard library become separate projects.


Hear, hear!  Aside from the concerns of the people needing sumo  
releases for political reasons, this is definitely the way to go.


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From guido at python.org  Mon Jan  7 16:29:16 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 7 Jan 2008 07:29:16 -0800
Subject: [Python-3000] Is pickle's persistent_id worth keeping?
In-Reply-To: <52C7B012-8C6A-4530-BE04-ADA9BC54D4E1@acm.org>
References: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>
	<17033E0D-6A78-4D66-ACFB-1A5ED150646E@zope.com>
	<52C7B012-8C6A-4530-BE04-ADA9BC54D4E1@acm.org>
Message-ID: <ca471dc20801070729wbafff27p99e86ff3810b6c0@mail.gmail.com>

On Jan 7, 2008 7:26 AM, Fred Drake <fdrake at acm.org> wrote:
> On Jan 6, 2008, at 1:35 PM, Jim Fulton wrote:
> > Really, I'd like to see a much smaller standard library.  IMO, pickle
> > isn't essential enough to be part of the standard library and I'd be
> > happy to see pickle become a separate project. I'd prefer to see most
> > of the Python 2 standard library become separate projects.
>
>
> Hear, hear!  Aside from the concerns of the people needing sumo
> releases for political reasons, this is definitely the way to go.

Actually I suspect that the people pleading in favor of this are also
doing it for political reasons.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From fdrake at acm.org  Mon Jan  7 16:39:04 2008
From: fdrake at acm.org (Fred Drake)
Date: Mon, 7 Jan 2008 10:39:04 -0500
Subject: [Python-3000] Is pickle's persistent_id worth keeping?
In-Reply-To: <ca471dc20801070729wbafff27p99e86ff3810b6c0@mail.gmail.com>
References: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>
	<17033E0D-6A78-4D66-ACFB-1A5ED150646E@zope.com>
	<52C7B012-8C6A-4530-BE04-ADA9BC54D4E1@acm.org>
	<ca471dc20801070729wbafff27p99e86ff3810b6c0@mail.gmail.com>
Message-ID: <E6E087CA-60FA-4408-88DC-D7CB40C3626A@acm.org>

On Jan 7, 2008, at 10:29 AM, Guido van Rossum wrote:
> Actually I suspect that the people pleading in favor of this are also
> doing it for political reasons.

Perhaps.  The motivating factor is really to be able to decouple  
release cycles, and I think that's a valuable (technical) reason to  
split out packages that aren't essential to make Python a good  
language to work with.


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From aahz at pythoncraft.com  Mon Jan  7 16:53:26 2008
From: aahz at pythoncraft.com (Aahz)
Date: Mon, 7 Jan 2008 07:53:26 -0800
Subject: [Python-3000] [Python-Dev] Rounding Decimals
In-Reply-To: <011301c85110$cf9c9050$6800a8c0@RaymondLaptop1>
References: <003101c85011$e1572530$6800a8c0@RaymondLaptop1>
	<5d44f72f0801060121l39c4d2a0jfdea69f644bc1822@mail.gmail.com>
	<5d44f72f0801061526x788b0a46lbbc17ec5dde44ceb@mail.gmail.com>
	<007601c850ca$7f2ab3e0$6800a8c0@RaymondLaptop1>
	<5d44f72f0801061803m2fc7ca45gc6a08f415d5a4901@mail.gmail.com>
	<00a801c850df$0e953e10$6800a8c0@RaymondLaptop1>
	<5d44f72f0801062154n4a1dab9fu60abb3bb4b0d02dc@mail.gmail.com>
	<00d001c850f9$bd67e2c0$6800a8c0@RaymondLaptop1>
	<5d44f72f0801070108j896bb34td7fd82daf696d4d0@mail.gmail.com>
	<011301c85110$cf9c9050$6800a8c0@RaymondLaptop1>
Message-ID: <20080107155326.GA12886@panix.com>

On Mon, Jan 07, 2008, Raymond Hettinger wrote:
> [Jeffrey Yasskin]
>> 
>> I am not building out the decimal API. I am adding enough methods to
>> maintain the comment that "Decimal floating point objects share many
>> properties with the other builtin numeric types such as float and int.
>> All of the usual math operations and special methods apply." in both
>> 2.6 and 3.0. After that's done, I am interested in talking about
>> adding one method that 3 people on this list have been interested in.
>> I understand that you need to be vigilant against extraneous methods,
>> but I'm really not just adding these on a whim.
> 
> Arghh!  You seem hell-bent on jamming this in.  Please leave the
> decimal module alone.  It does *not* need both a round() method
> and a quantize() method.
> 
> I read Glyph's note and agree that it wasn't obvious how to round
> with the existing API.  That is a documentation problem, not a call
> to add duplicate methods.

Excuse me.  I have always thought that "quantize()" makes Decimal
confusing in the context of the other mechanisms that Python makes
available for other kinds of numbers.  I have refrained from making an
issue of it because I understand and (mostly) support the idea of
keeping Decimal restricted to matching the decimal standard, but at this
point, it seems that Tim Peters likes the idea, too.  While I have a lot
of respect for you, I think Uncle Timmy deserves some special respect,
too.

> When one of the module authors asks you to refrain for expanding
> the API, please pay special attention.  In this case, you are working
> directly against a core philosophy for the design and maintenance
> of the module.

I'm not a current maintainer, but I was one of the instigators for the
existence of Decimal.  I understand that you're feeling frustrated about
changes getting shoved in, but I don't think that discussion should be
shut down because you have a particular point of view: the decimal
module does not represent only your work.

I suggest that the patches get dropped for the moment and the discussion
rebooted.  I haven't been following closely, but it seems that the main
issue is that Python 3.0 is introducing a __round__() method.  How do you
think the decimal module should handle that?  (Although I still like the
idea of a .round() method for decimals, I think that round(Decimal()) is
probably sufficient enough that I won't insist on it.)
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

Weinberg's Second Law: If builders built buildings the way programmers wrote 
programs, then the first woodpecker that came along would destroy civilization.

From python at rcn.com  Mon Jan  7 18:29:18 2008
From: python at rcn.com (Raymond Hettinger)
Date: Mon, 7 Jan 2008 09:29:18 -0800
Subject: [Python-3000] [Python-Dev]   Rounding Decimals
References: <003101c85011$e1572530$6800a8c0@RaymondLaptop1><5d44f72f0801060121l39c4d2a0jfdea69f644bc1822@mail.gmail.com><5d44f72f0801061526x788b0a46lbbc17ec5dde44ceb@mail.gmail.com><007601c850ca$7f2ab3e0$6800a8c0@RaymondLaptop1><5d44f72f0801061803m2fc7ca45gc6a08f415d5a4901@mail.gmail.com><00a801c850df$0e953e10$6800a8c0@RaymondLaptop1><5d44f72f0801062154n4a1dab9fu60abb3bb4b0d02dc@mail.gmail.com><00d001c850f9$bd67e2c0$6800a8c0@RaymondLaptop1><5d44f72f0801070108j896bb34td7fd82daf696d4d0@mail.gmail.com><011301c85110$cf9c9050$6800a8c0@RaymondLaptop1>
	<20080107155326.GA12886@panix.com>
Message-ID: <017e01c85152$d5bf47b0$6800a8c0@RaymondLaptop1>

[Aahz]
>  I have always thought that "quantize()" makes Decimal
> confusing in the context of the other mechanisms that Python makes
> available for other kinds of numbers.

No doubt, the spec made a number of choices that are obvious only if you work at IBM. And, there is no doubt, the module has a high 
level of complexity.

Jeffrey is proposing to add a Context.round() method with the purpose of making the module easier to use. I contend that this is 
self-defeating on the face of it.  Please count the number of existing Context methods ( 
http://docs.python.org/dev/library/decimal.html#context-objects ) and tell me that adding yet another method will reduce complexity 
or shorten the learning curve.  In fact, it will just further confuse which method should be used.

Also, I thought we were committed to a minimal implementation of the spec. One reason for this was that programs could be ported 
back and forth with other implementations of the spec.  Another reason is that the core spec has extensive test cases while 
build-outs have none. And another reason is that we are trying to make life easier for someone (perhaps me) to rewrite the module in 
C.

There is also the principle of having only one way to do it.  However, we already have Decimal.quantize and Context.quantize and are 
about to introduce a number of magic methods callable from builtin functions. Do we really need even more ways to round?  The 
rounding operation is so fundamental to the module that user must grapple with it at some point.  Having multiple ways to do it will 
only make that task more difficult.

I spent about a month of my life cleaning, documenting, and testing the decimal module to get it ready for prime time. I'm not at 
all pleased at the current proposal to add a duplicate method.

If someone really cared about making the module easier to use, I would fully support efforts to write a tutorial on the fundamentals 
or an effort to write a client module implementing only a subset of the spec.


Raymond

From stephen at xemacs.org  Tue Jan  8 02:14:42 2008
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 08 Jan 2008 10:14:42 +0900
Subject: [Python-3000] Splitting out packages [was: Is pickle's
	persistent_id worth keeping?]
In-Reply-To: <E6E087CA-60FA-4408-88DC-D7CB40C3626A@acm.org>
References: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>
	<17033E0D-6A78-4D66-ACFB-1A5ED150646E@zope.com>
	<52C7B012-8C6A-4530-BE04-ADA9BC54D4E1@acm.org>
	<ca471dc20801070729wbafff27p99e86ff3810b6c0@mail.gmail.com>
	<E6E087CA-60FA-4408-88DC-D7CB40C3626A@acm.org>
Message-ID: <873at9t8xp.fsf@uwakimon.sk.tsukuba.ac.jp>

Fred Drake writes:
 > On Jan 7, 2008, at 10:29 AM, Guido van Rossum wrote:
 > > Actually I suspect that the people pleading in favor of this are also
 > > doing it for political reasons.
 > 
 > Perhaps.  The motivating factor is really to be able to decouple  
 > release cycles, and I think that's a valuable (technical) reason to  
 > split out packages that aren't essential to make Python a good  
 > language to work with.

XEmacs has tried splitting out its packages, and we are very satisfied
with the results.

However, splitting out the stdlib has had two problems that haven't
been mentioned here.  It causes internal politics (different
developers have different opinions on which batteries are really
necessary, and on which internal interfaces should *stay* internal).
And maintenance of many packages does tend to deteriorate, because
*nobody* pays *any* attention to their bugs.  IMO this has not been a
major problem for us only because when we need a quick patch, we can
usually import one from GNU Emacs.  Conditions and developer culture
are different for Python; these may not be real problems.

If interested, I could probably get Steve Baur (who shepherded the
transition for us) to discuss his experience.


From python at rcn.com  Tue Jan  8 02:16:02 2008
From: python at rcn.com (Raymond Hettinger)
Date: Mon,  7 Jan 2008 20:16:02 -0500 (EST)
Subject: [Python-3000] Comments on PEP-3108: Standard Library Reorganization
Message-ID: <20080107201602.AEQ32587@ms19.lnh.mail.rcn.net>

1) The repr module is marked as hardly used, but it may have a fan base (not me). It is covered in the tutorial's guided tour, so it has been held-up as being active and useful.  There are a few hits on google's codesearch:
http://www.google.com/codesearch?hl=en&q=+lang:python+%22import+repr%22&start=20&sa=N
http://www.google.com/codesearch?hl=en&lr=&q=lang%3Apython+repr.repr&btnG=Search
So, perhap this one should be discussed further before being zapped.

2) The opcode module is slated for renaming to _opcode on the theory that it doesn't have a documented interface. If needed, I can make docs for the module. I think it should continue to exist with its current name.

3) The PEP says that the idea to introduce new, theme-related packages was tabled for a variety of reasons; however, the active discussions on python-3000 suggest otherwise (i.e. discussion of a database package).  Please expand the rationale to include my earlier comment about how the Library Reference table of contents serves as a strong indicator that introducing package hierarchies will be detrimental. I'm hoping that bit of analysis doesn't get lost.

4) The Cookie module should be considered for removal. It is very short and adds little value -- half of the tools are deprecated -- it appears that this module is no longer receiving love from a maintainer that cares about its future.  Removing it will make space for a better implementation (if needed) in the future.

Raymond

From brett at python.org  Tue Jan  8 04:01:45 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 7 Jan 2008 19:01:45 -0800
Subject: [Python-3000] Comments on PEP-3108: Standard Library
	Reorganization
In-Reply-To: <20080107201602.AEQ32587@ms19.lnh.mail.rcn.net>
References: <20080107201602.AEQ32587@ms19.lnh.mail.rcn.net>
Message-ID: <bbaeab100801071901r636030f7r7a2b015f9116fd33@mail.gmail.com>

On Jan 7, 2008 5:16 PM, Raymond Hettinger <python at rcn.com> wrote:
> 1) The repr module is marked as hardly used, but it may have a fan base (not me). It is covered in the tutorial's guided tour, so it has been held-up as being active and useful.  There are a few hits on google's codesearch:
> http://www.google.com/codesearch?hl=en&q=+lang:python+%22import+repr%22&start=20&sa=N
> http://www.google.com/codesearch?hl=en&lr=&q=lang%3Apython+repr.repr&btnG=Search
> So, perhap this one should be discussed further before being zapped.
>

This can be discussed.  So does anyone use it and want to fight to
keep it around as a separate API?

> 2) The opcode module is slated for renaming to _opcode on the theory that it doesn't have a documented interface. If needed, I can make docs for the module. I think it should continue to exist with its current name.
>

That would be great.  I am fine with saving stuff if people are
willing to put the time and effort into maintaining it.  Doing the
docs falls under that.

> 3) The PEP says that the idea to introduce new, theme-related packages was tabled for a variety of reasons; however, the active discussions on python-3000 suggest otherwise (i.e. discussion of a database package).  Please expand the rationale to include my earlier comment about how the Library Reference table of contents serves as a strong indicator that introducing package hierarchies will be detrimental. I'm hoping that bit of analysis doesn't get lost.
>

Well, as Guido has suggested, any new modules will be to make names
more reasonable (e.g., organizing HTTP modules so we have http.lib or
http.tools, http.server.cgi, etc.).  Adding general organization like
compression.gzip, etc. has essentially been shot down at this point.
Does this address your concern?

> 4) The Cookie module should be considered for removal. It is very short and adds little value -- half of the tools are deprecated -- it appears that this module is no longer receiving love from a maintainer that cares about its future.  Removing it will make space for a better implementation (if needed) in the future.

Fine by me.  Anyone care to fight for saving the Cookie module?

-Brett

From hashcollision at gmail.com  Tue Jan  8 05:48:17 2008
From: hashcollision at gmail.com (hashcollision)
Date: Mon, 7 Jan 2008 23:48:17 -0500
Subject: [Python-3000] Need closure on __cmp__ removal
In-Reply-To: <ca471dc20801062001m148b343ex450a9093c8c1359a@mail.gmail.com>
References: <37f76d50801052240w44bbf29arb80d7e7b1a451710@mail.gmail.com>
	<ca471dc20801062001m148b343ex450a9093c8c1359a@mail.gmail.com>
Message-ID: <37f76d50801072048m77f172eei107167647ad37957@mail.gmail.com>

>
> But the biggest thing missing is precise semantics. Saying "exactly
> the same semantics as with Python 2.5" doesn't cut it (those semantics
> are incredibly hairy and sometimes surprising, and their
> implementation was a nightmare -- I've rarely been as relieved as when
> I was able to cut those out of the implementation).


Why is that so? I might be being naive, but what is wrong with something
like this:

def cmp(a, b):
    if hasattr(a, '__cmp__'):
        return a.__cmp__(b)
    elif hasattr(b, '__cmp__'):
        return -1 * b.__cmp__(a)
    elif hasattr(a, '__le__') and hasattr(a, '__ge__'):
        x = a <= b
        y = a >= b
        if x and y:
            return 0
        elif x:
            return -1
        elif y:
            return 1
    elif hasattr(b, '__le__') and hasattr(b, '__ge__'):
        x = b <= a
        y = b >= a
        if x and y:
            return 0
        elif x:
            return 1
        elif y:
            return -1
    elif hasattr(a, '__eq__'):
        if a == b:
            return 0
        if hasattr(a, '__lt__'):
            if a < b:
                return -1
            else:
                return 1
        elif hasattr(a, '__gt__'):
            if a > b:
                return 1
            else:
                return -1
        else:
            raise NotImplemented()
    elif hasattr(b, '__eq__'):
        if a == b:
            return 0
        if hasattr(b, '__lt__'):
            if b < a:
                return 1
            else:
                return -1
        elif hasattr(b, '__gt__'):
            if b > a:
                return -1
            else:
                return 1
        else:
            raise NotImplemented()
    else:
        raise NotImplemented()
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080107/7b6fdbde/attachment-0001.htm 

From guido at python.org  Tue Jan  8 05:55:44 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 7 Jan 2008 20:55:44 -0800
Subject: [Python-3000] Need closure on __cmp__ removal
In-Reply-To: <37f76d50801072048m77f172eei107167647ad37957@mail.gmail.com>
References: <37f76d50801052240w44bbf29arb80d7e7b1a451710@mail.gmail.com>
	<ca471dc20801062001m148b343ex450a9093c8c1359a@mail.gmail.com>
	<37f76d50801072048m77f172eei107167647ad37957@mail.gmail.com>
Message-ID: <ca471dc20801072055g2275dba6na1207902191d3ff8@mail.gmail.com>

On Jan 7, 2008 8:48 PM, hashcollision <hashcollision at gmail.com> wrote:
>
>
> > But the biggest thing missing is precise semantics. Saying "exactly
> > the same semantics as with Python 2.5" doesn't cut it (those semantics
> > are incredibly hairy and sometimes surprising, and their
> > implementation was a nightmare -- I've rarely been as relieved as when
> > I was able to cut those out of the implementation).
>
>
> Why is that so? I might be being naive, but what is wrong with something
> like this:
>
> def cmp(a, b):
>     if hasattr(a, '__cmp__'):
>         return a.__cmp__(b)
>     elif hasattr(b, '__cmp__'):
>         return -1 * b.__cmp__(a)
>     elif hasattr(a, '__le__') and hasattr(a, '__ge__'):
>         x = a <= b
>         y = a >= b
>         if x and y:
>             return 0
>         elif x:
>             return -1
>         elif y:
>             return 1
>     elif hasattr(b, '__le__') and hasattr(b, '__ge__'):
>         x = b <= a
>         y = b >= a
>         if x and y:
>             return 0
>         elif x:
>             return 1
>         elif y:
>             return -1
>     elif hasattr(a, '__eq__'):
>         if a == b:
>             return 0
>         if hasattr(a, '__lt__'):
>             if a < b:
>                 return -1
>             else:
>                 return 1
>         elif hasattr(a, '__gt__'):
>             if a > b:
>                 return 1
>             else:
>                 return -1
>         else:
>             raise NotImplemented()
>     elif hasattr(b, '__eq__'):
>         if a == b:
>             return 0
>         if hasattr(b, '__lt__'):
>             if b < a:
>                 return 1
>             else:
>                 return -1
>         elif hasattr(b, '__gt__'):
>              if b > a:
>                 return -1
>             else:
>                 return 1
>         else:
>             raise NotImplemented()
>     else:
>         raise NotImplemented()

You don't call that hairy? :-)

Anyway, one of the additional complications is that it is supposed to
be implemented in C, and there is one C slot for all six comparisons
together (which of the six is an argument). The 2.x rules are also
further complicated in that sometimes the RHS is tried before the LHS
(in case the RHS is an instance of a subclass of the class of the
LHS).

And I think you've ignored the possibility that a.__cmp__(b) might
return NotImplemented.

Just believe me, it's hairy.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From guido at python.org  Tue Jan  8 05:59:05 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 7 Jan 2008 20:59:05 -0800
Subject: [Python-3000] Comments on PEP-3108: Standard Library
	Reorganization
In-Reply-To: <bbaeab100801071901r636030f7r7a2b015f9116fd33@mail.gmail.com>
References: <20080107201602.AEQ32587@ms19.lnh.mail.rcn.net>
	<bbaeab100801071901r636030f7r7a2b015f9116fd33@mail.gmail.com>
Message-ID: <ca471dc20801072059t214e3719n29c532b04c8f7172@mail.gmail.com>

Isn't there a separate list for this topic? Are you ignoring it for a
specific reason?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From brett at python.org  Tue Jan  8 09:29:18 2008
From: brett at python.org (Brett Cannon)
Date: Tue, 8 Jan 2008 00:29:18 -0800
Subject: [Python-3000] Comments on PEP-3108: Standard Library
	Reorganization
In-Reply-To: <ca471dc20801072059t214e3719n29c532b04c8f7172@mail.gmail.com>
References: <20080107201602.AEQ32587@ms19.lnh.mail.rcn.net>
	<bbaeab100801071901r636030f7r7a2b015f9116fd33@mail.gmail.com>
	<ca471dc20801072059t214e3719n29c532b04c8f7172@mail.gmail.com>
Message-ID: <bbaeab100801080029r11309a02o5b70ed4758a0c292@mail.gmail.com>

On Jan 7, 2008 8:59 PM, Guido van Rossum <guido at python.org> wrote:
> Isn't there a separate list for this topic?

http://lists.peadrop.com/listinfo.cgi/python-stdlib-reorg-peadrop.com
is where the discussion is about to start.

> Are you ignoring it for a
> specific reason?

No, just replied to Raymond where I got the email. Plus the list just
started being seriously used a day or two ago so it just didn't click
yet to have people move the discussion over there. But we will shift
over there now.

-Brett

From jcd at sdf.lonestar.org  Tue Jan  8 13:54:29 2008
From: jcd at sdf.lonestar.org (J. Clifford Dyer)
Date: Tue, 08 Jan 2008 07:54:29 -0500
Subject: [Python-3000] Is pickle's persistent_id worth keeping?
In-Reply-To: <52C7B012-8C6A-4530-BE04-ADA9BC54D4E1@acm.org>
References: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>
	<17033E0D-6A78-4D66-ACFB-1A5ED150646E@zope.com>
	<52C7B012-8C6A-4530-BE04-ADA9BC54D4E1@acm.org>
Message-ID: <1199796869.6177.25.camel@jcd-desktop>


On Mon, 2008-01-07 at 10:26 -0500, Fred Drake wrote:
> On Jan 6, 2008, at 1:35 PM, Jim Fulton wrote:
> > Really, I'd like to see a much smaller standard library.  IMO, pickle
> > isn't essential enough to be part of the standard library and I'd be
> > happy to see pickle become a separate project. I'd prefer to see most
> > of the Python 2 standard library become separate projects.
> 
> 
> Hear, hear!  Aside from the concerns of the people needing sumo  
> releases for political reasons, this is definitely the way to go.
> 
> 
>    -Fred
> 

-1.  One of the big draws of python has always been that it is a
batteries-included language.  It has been advertised as such.  It has
been developed as such.  It has been used as such.  

There is a tendency among (some) developers to use "political" as a code
word for "unimportant."  This is not the case.  Without addressing
"political" concerns, you will have a beautiful piece of software that
nobody uses.  The downside to coupling pickle to the standard library is
that it makes release cycles more challenging for the developers.  The
downside to isolating it is that it makes python a far less usable
language for programmers, who then have to manage more complex
dependencies.

Aside from the concerns of a few developers wanting simpler release
cycles, this is definitely not the way to go.

My 2?.

Cliff


From fdrake at acm.org  Tue Jan  8 14:15:50 2008
From: fdrake at acm.org (Fred Drake)
Date: Tue, 8 Jan 2008 08:15:50 -0500
Subject: [Python-3000] Is pickle's persistent_id worth keeping?
In-Reply-To: <1199796869.6177.25.camel@jcd-desktop>
References: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>
	<17033E0D-6A78-4D66-ACFB-1A5ED150646E@zope.com>
	<52C7B012-8C6A-4530-BE04-ADA9BC54D4E1@acm.org>
	<1199796869.6177.25.camel@jcd-desktop>
Message-ID: <5ED6A8B1-241E-4FFB-A512-0FF744A4E964@acm.org>

On Jan 8, 2008, at 7:54 AM, J. Clifford Dyer wrote:
> Aside from the concerns of a few developers wanting simpler release
> cycles, this is definitely not the way to go.

I don't mean that "political" (in this case, "business") reasons are  
unimportant, but they can be addressed in other ways.

The advantage of decoupled release cycles isn't simplicity (though  
that's welcome as well, if attainable), but the ability to update  
library packages independently should bug fixes be needed.

I don't think this is a huge deal for the pickle module, but is more  
of an issue for some of the wrappers for external libraries.  The  
database packages (bsddb, sqlite) come to mind here, but aren't the  
only cases where independent releases make sense.  We've certainly  
seen that including the "xml" package in the standard library was  
questionable at best (and the tie to PyXML exacerbated that horribly).


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From p.f.moore at gmail.com  Tue Jan  8 15:29:27 2008
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 8 Jan 2008 14:29:27 +0000
Subject: [Python-3000] Is pickle's persistent_id worth keeping?
In-Reply-To: <5ED6A8B1-241E-4FFB-A512-0FF744A4E964@acm.org>
References: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>
	<17033E0D-6A78-4D66-ACFB-1A5ED150646E@zope.com>
	<52C7B012-8C6A-4530-BE04-ADA9BC54D4E1@acm.org>
	<1199796869.6177.25.camel@jcd-desktop>
	<5ED6A8B1-241E-4FFB-A512-0FF744A4E964@acm.org>
Message-ID: <79990c6b0801080629s37d3e73bo7f5dfe2be9fc2b11@mail.gmail.com>

On 08/01/2008, Fred Drake <fdrake at acm.org> wrote:
> On Jan 8, 2008, at 7:54 AM, J. Clifford Dyer wrote:
> > Aside from the concerns of a few developers wanting simpler release
> > cycles, this is definitely not the way to go.
>
> I don't mean that "political" (in this case, "business") reasons are
> unimportant, but they can be addressed in other ways.

How? Isn't the "business" benefit of the current situation that the
official installer from python.org includes (nearly) all of the basic
tools required for development, without needing additional packages to
be installed as well? [This is for Windows only, which is my concern -
the situation for other platforms isn't something I have any
experience with].

Solutions I've seen offered so far have involved easy download and
installation of spun off packages (not appropriate - each separate
install has a cost in terms of getting approval) or having optional
"sumo" distributions, from python.org or elsewhere (not likely to be
suitable, as "the official distribution" has a credibility that others
don't, for better or worse).

> The advantage of decoupled release cycles isn't simplicity (though
> that's welcome as well, if attainable), but the ability to update
> library packages independently should bug fixes be needed.

Conversely, there's a risk of dilution of developer effort, and a
resulting *reduction* in frequency of bug fixes. There's no clear
evidence either way.

> I don't think this is a huge deal for the pickle module, but is more
> of an issue for some of the wrappers for external libraries.  The
> database packages (bsddb, sqlite) come to mind here, but aren't the
> only cases where independent releases make sense.

Make sense in what way? I was very happy to see sqlite included in the
stdlib, as it made it part of the standard toolkit I could assume was
present. There was community pressure to add it - where is the
community (not developer!) pressure now to remove it?

>  We've certainly seen that including the "xml" package in the standard library
> was questionable at best (and the tie to PyXML exacerbated that horribly).

Have we? I avoid XML like the plague, but having XML support in the
stdlib is certainly useful for me. The PyXML attempt to allow for an
independent release cycle and/or extended functionality for a core
package didn't work, certainly[1], but I don't recall anyone
complaining that XML support shouldn't be in the stdlib in any form
(after all, community requests for the inclusion of elementtree
resulted in that being added, as well).

Actually, the history so far (sqlite, elementtree, email, unittest)
shows people wanting *more* in the stdlib, rather than less. Has
anyone asked on somewhere like c.l.p, whether trimming the standard
distribution would meet with community support?

Actually, if I think about it, such a change would probably need a PEP
- which should be a fun exercise for whoever writes it. So maybe the
topic should be shelved until a PEP surfaces.

Paul.

[1] This is a good argument for rejecting the recently-raised idea of
stdlib namespace packages which can easily be extended via 3rd
parties. But that's about a mutable stdlib, not about what's *in* the
stdlib.

From guido at python.org  Tue Jan  8 18:51:01 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 8 Jan 2008 09:51:01 -0800
Subject: [Python-3000] Is pickle's persistent_id worth keeping?
In-Reply-To: <5ED6A8B1-241E-4FFB-A512-0FF744A4E964@acm.org>
References: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>
	<17033E0D-6A78-4D66-ACFB-1A5ED150646E@zope.com>
	<52C7B012-8C6A-4530-BE04-ADA9BC54D4E1@acm.org>
	<1199796869.6177.25.camel@jcd-desktop>
	<5ED6A8B1-241E-4FFB-A512-0FF744A4E964@acm.org>
Message-ID: <ca471dc20801080951o3f47fe99yaefbcd6c7557ae0d@mail.gmail.com>

On Jan 8, 2008 5:15 AM, Fred Drake <fdrake at acm.org> wrote:
> I don't think this is a huge deal for the pickle module, but is more
> of an issue for some of the wrappers for external libraries.  The
> database packages (bsddb, sqlite) come to mind here, but aren't the
> only cases where independent releases make sense.  We've certainly
> seen that including the "xml" package in the standard library was
> questionable at best (and the tie to PyXML exacerbated that horribly).

pickle should definitely remain part of the core; it is timed in lots
of ways to core datatypes. It is also something that I expect nobody
would be thrilled to maintain if it was separate. And there is a lot
to say for having a "universal" serialization format; e.g. there have
been RPC systems built on top of pickling.

I think ctypes falls in the same category, and see it as a happy
addition to the core.

For things like bsddb I think the argument of release cycles is
stronger. In particular bsddb support in the core is painful, the
tests often fail, they take a long time to run, and I don't see that
many users.

For sqlite I'm on the fence; it has saved my butt a few times in
situations where having to include an external dependency might have
stopped me from using it. And it doesn't seem to be much of a
maintenance issue.

PyXML was IMO an early mistake; I think it's good to have a certain
amount of XML support in the core, and to have more extensive support
separate; the blunder was trying to reuse the same toplevel package
name.

I think the argument of release cycles is very important for reasoning
about these kinds of issues; no two cases are alike.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From hashcollision at gmail.com  Tue Jan  8 23:34:39 2008
From: hashcollision at gmail.com (hashcollision)
Date: Tue, 8 Jan 2008 17:34:39 -0500
Subject: [Python-3000] Need closure on __cmp__ removal
In-Reply-To: <ca471dc20801072055g2275dba6na1207902191d3ff8@mail.gmail.com>
References: <37f76d50801052240w44bbf29arb80d7e7b1a451710@mail.gmail.com>
	<ca471dc20801062001m148b343ex450a9093c8c1359a@mail.gmail.com>
	<37f76d50801072048m77f172eei107167647ad37957@mail.gmail.com>
	<ca471dc20801072055g2275dba6na1207902191d3ff8@mail.gmail.com>
Message-ID: <37f76d50801081434ld99cf1m404f4e21656283a3@mail.gmail.com>

Ok, I do see your point, but how would one pass in a custom comparison
function to sorted?

On Jan 7, 2008 11:55 PM, Guido van Rossum <guido at python.org> wrote:

>  On Jan 7, 2008 8:48 PM, hashcollision <hashcollision at gmail.com> wrote:
> >
> >
> > > But the biggest thing missing is precise semantics. Saying "exactly
> > > the same semantics as with Python 2.5" doesn't cut it (those semantics
> > > are incredibly hairy and sometimes surprising, and their
> > > implementation was a nightmare -- I've rarely been as relieved as when
> > > I was able to cut those out of the implementation).
> >
> >
> > Why is that so? I might be being naive, but what is wrong with something
> > like this:
> >
> > def cmp(a, b):
> >     if hasattr(a, '__cmp__'):
> >         return a.__cmp__(b)
> >     elif hasattr(b, '__cmp__'):
> >         return -1 * b.__cmp__(a)
> >     elif hasattr(a, '__le__') and hasattr(a, '__ge__'):
> >         x = a <= b
> >         y = a >= b
> >         if x and y:
> >             return 0
> >         elif x:
> >             return -1
> >         elif y:
> >             return 1
> >     elif hasattr(b, '__le__') and hasattr(b, '__ge__'):
> >         x = b <= a
> >         y = b >= a
> >         if x and y:
> >             return 0
> >         elif x:
> >             return 1
> >         elif y:
> >             return -1
> >     elif hasattr(a, '__eq__'):
> >         if a == b:
> >             return 0
> >         if hasattr(a, '__lt__'):
> >             if a < b:
> >                 return -1
> >             else:
> >                 return 1
> >         elif hasattr(a, '__gt__'):
> >             if a > b:
> >                 return 1
> >             else:
> >                 return -1
> >         else:
> >             raise NotImplemented()
> >     elif hasattr(b, '__eq__'):
> >         if a == b:
> >             return 0
> >         if hasattr(b, '__lt__'):
> >             if b < a:
> >                 return 1
> >             else:
> >                 return -1
> >         elif hasattr(b, '__gt__'):
> >              if b > a:
> >                 return -1
> >             else:
> >                 return 1
> >         else:
> >             raise NotImplemented()
> >     else:
> >         raise NotImplemented()
>
> You don't call that hairy? :-)
>
> Anyway, one of the additional complications is that it is supposed to
> be implemented in C, and there is one C slot for all six comparisons
> together (which of the six is an argument). The 2.x rules are also
> further complicated in that sometimes the RHS is tried before the LHS
> (in case the RHS is an instance of a subclass of the class of the
> LHS).
>
> And I think you've ignored the possibility that a.__cmp__(b) might
> return NotImplemented.
>
> Just believe me, it's hairy.
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080108/ad438144/attachment.htm 

From guido at python.org  Tue Jan  8 23:41:33 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 8 Jan 2008 14:41:33 -0800
Subject: [Python-3000] Need closure on __cmp__ removal
In-Reply-To: <37f76d50801081434ld99cf1m404f4e21656283a3@mail.gmail.com>
References: <37f76d50801052240w44bbf29arb80d7e7b1a451710@mail.gmail.com>
	<ca471dc20801062001m148b343ex450a9093c8c1359a@mail.gmail.com>
	<37f76d50801072048m77f172eei107167647ad37957@mail.gmail.com>
	<ca471dc20801072055g2275dba6na1207902191d3ff8@mail.gmail.com>
	<37f76d50801081434ld99cf1m404f4e21656283a3@mail.gmail.com>
Message-ID: <ca471dc20801081441u707e9c74tf9fa1ccee030e44f@mail.gmail.com>

list.sort() and built-in sorted() are the least of our problems: even
though the API uses cmp, the implementation actually only ever uses
'<'; and the preferred API is to use the 'key' argument instead of
passing a compare function; that's much more efficient.

Maybe we should retire the compare function completely in 3.0?

On Jan 8, 2008 2:34 PM, hashcollision <hashcollision at gmail.com> wrote:
> Ok, I do see your point, but how would one pass in a custom comparison
> function to sorted?
>
>
>
>
> On Jan 7, 2008 11:55 PM, Guido van Rossum <guido at python.org> wrote:
>
> >
> >
> >
> > On Jan 7, 2008 8:48 PM, hashcollision <hashcollision at gmail.com> wrote:
> > >
> > >
> > > > But the biggest thing missing is precise semantics. Saying "exactly
> > > > the same semantics as with Python 2.5" doesn't cut it (those semantics
> > > > are incredibly hairy and sometimes surprising, and their
> > > > implementation was a nightmare -- I've rarely been as relieved as when
> > > > I was able to cut those out of the implementation).
> > >
> > >
> > > Why is that so? I might be being naive, but what is wrong with something
> > > like this:
> > >
> > > def cmp(a, b):
> > >     if hasattr(a, '__cmp__'):
> > >         return a.__cmp__(b)
> > >     elif hasattr(b, '__cmp__'):
> > >         return -1 * b.__cmp__(a)
> > >     elif hasattr(a, '__le__') and hasattr(a, '__ge__'):
> > >         x = a <= b
> > >         y = a >= b
> > >         if x and y:
> > >             return 0
> > >         elif x:
> > >             return -1
> > >         elif y:
> > >             return 1
> > >     elif hasattr(b, '__le__') and hasattr(b, '__ge__'):
> > >         x = b <= a
> > >         y = b >= a
> > >         if x and y:
> > >             return 0
> > >         elif x:
> > >             return 1
> > >         elif y:
> > >             return -1
> > >     elif hasattr(a, '__eq__'):
> > >         if a == b:
> > >             return 0
> > >         if hasattr(a, '__lt__'):
> > >             if a < b:
> > >                 return -1
> > >             else:
> > >                 return 1
> > >         elif hasattr(a, '__gt__'):
> > >             if a > b:
> > >                 return 1
> > >             else:
> > >                 return -1
> > >         else:
> > >             raise NotImplemented()
> > >     elif hasattr(b, '__eq__'):
> > >         if a == b:
> > >             return 0
> > >         if hasattr(b, '__lt__'):
> > >             if b < a:
> > >                 return 1
> > >             else:
> > >                 return -1
> > >         elif hasattr(b, '__gt__'):
> > >              if b > a:
> > >                 return -1
> > >             else:
> > >                 return 1
> > >         else:
> > >             raise NotImplemented()
> > >     else:
> > >         raise NotImplemented()
> >
> > You don't call that hairy? :-)
> >
> > Anyway, one of the additional complications is that it is supposed to
> > be implemented in C, and there is one C slot for all six comparisons
> > together (which of the six is an argument). The 2.x rules are also
> > further complicated in that sometimes the RHS is tried before the LHS
> > (in case the RHS is an instance of a subclass of the class of the
> > LHS).
> >
> > And I think you've ignored the possibility that a.__cmp__(b) might
> > return NotImplemented.
> >
> > Just believe me, it's hairy.
> >
> >
> >
> >
> > --
> > --Guido van Rossum (home page: http://www.python.org/~guido/)
> >
>
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From brett at python.org  Tue Jan  8 23:55:02 2008
From: brett at python.org (Brett Cannon)
Date: Tue, 8 Jan 2008 14:55:02 -0800
Subject: [Python-3000] Need closure on __cmp__ removal
In-Reply-To: <ca471dc20801081441u707e9c74tf9fa1ccee030e44f@mail.gmail.com>
References: <37f76d50801052240w44bbf29arb80d7e7b1a451710@mail.gmail.com>
	<ca471dc20801062001m148b343ex450a9093c8c1359a@mail.gmail.com>
	<37f76d50801072048m77f172eei107167647ad37957@mail.gmail.com>
	<ca471dc20801072055g2275dba6na1207902191d3ff8@mail.gmail.com>
	<37f76d50801081434ld99cf1m404f4e21656283a3@mail.gmail.com>
	<ca471dc20801081441u707e9c74tf9fa1ccee030e44f@mail.gmail.com>
Message-ID: <bbaeab100801081455m69384e82ia481fac83a4d71ae@mail.gmail.com>

On Jan 8, 2008 2:41 PM, Guido van Rossum <guido at python.org> wrote:
> list.sort() and built-in sorted() are the least of our problems: even
> though the API uses cmp, the implementation actually only ever uses
> '<'; and the preferred API is to use the 'key' argument instead of
> passing a compare function; that's much more efficient.
>
> Maybe we should retire the compare function completely in 3.0?
>

+1 from me. I personally have always hated the whole, -1, 0, 1 style
of comparison anyway.

-Brett

>
> On Jan 8, 2008 2:34 PM, hashcollision <hashcollision at gmail.com> wrote:
> > Ok, I do see your point, but how would one pass in a custom comparison
> > function to sorted?
> >
> >
> >
> >
> > On Jan 7, 2008 11:55 PM, Guido van Rossum <guido at python.org> wrote:
> >
> > >
> > >
> > >
> > > On Jan 7, 2008 8:48 PM, hashcollision <hashcollision at gmail.com> wrote:
> > > >
> > > >
> > > > > But the biggest thing missing is precise semantics. Saying "exactly
> > > > > the same semantics as with Python 2.5" doesn't cut it (those semantics
> > > > > are incredibly hairy and sometimes surprising, and their
> > > > > implementation was a nightmare -- I've rarely been as relieved as when
> > > > > I was able to cut those out of the implementation).
> > > >
> > > >
> > > > Why is that so? I might be being naive, but what is wrong with something
> > > > like this:
> > > >
> > > > def cmp(a, b):
> > > >     if hasattr(a, '__cmp__'):
> > > >         return a.__cmp__(b)
> > > >     elif hasattr(b, '__cmp__'):
> > > >         return -1 * b.__cmp__(a)
> > > >     elif hasattr(a, '__le__') and hasattr(a, '__ge__'):
> > > >         x = a <= b
> > > >         y = a >= b
> > > >         if x and y:
> > > >             return 0
> > > >         elif x:
> > > >             return -1
> > > >         elif y:
> > > >             return 1
> > > >     elif hasattr(b, '__le__') and hasattr(b, '__ge__'):
> > > >         x = b <= a
> > > >         y = b >= a
> > > >         if x and y:
> > > >             return 0
> > > >         elif x:
> > > >             return 1
> > > >         elif y:
> > > >             return -1
> > > >     elif hasattr(a, '__eq__'):
> > > >         if a == b:
> > > >             return 0
> > > >         if hasattr(a, '__lt__'):
> > > >             if a < b:
> > > >                 return -1
> > > >             else:
> > > >                 return 1
> > > >         elif hasattr(a, '__gt__'):
> > > >             if a > b:
> > > >                 return 1
> > > >             else:
> > > >                 return -1
> > > >         else:
> > > >             raise NotImplemented()
> > > >     elif hasattr(b, '__eq__'):
> > > >         if a == b:
> > > >             return 0
> > > >         if hasattr(b, '__lt__'):
> > > >             if b < a:
> > > >                 return 1
> > > >             else:
> > > >                 return -1
> > > >         elif hasattr(b, '__gt__'):
> > > >              if b > a:
> > > >                 return -1
> > > >             else:
> > > >                 return 1
> > > >         else:
> > > >             raise NotImplemented()
> > > >     else:
> > > >         raise NotImplemented()
> > >
> > > You don't call that hairy? :-)
> > >
> > > Anyway, one of the additional complications is that it is supposed to
> > > be implemented in C, and there is one C slot for all six comparisons
> > > together (which of the six is an argument). The 2.x rules are also
> > > further complicated in that sometimes the RHS is tried before the LHS
> > > (in case the RHS is an instance of a subclass of the class of the
> > > LHS).
> > >
> > > And I think you've ignored the possibility that a.__cmp__(b) might
> > > return NotImplemented.
> > >
> > > Just believe me, it's hairy.
> > >
> > >
> > >
> > >
> > > --
> > > --Guido van Rossum (home page: http://www.python.org/~guido/)
> > >
> >
> >
>
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/brett%40python.org
>

From steven.bethard at gmail.com  Wed Jan  9 01:12:47 2008
From: steven.bethard at gmail.com (Steven Bethard)
Date: Tue, 8 Jan 2008 17:12:47 -0700
Subject: [Python-3000] Need closure on __cmp__ removal
In-Reply-To: <bbaeab100801081455m69384e82ia481fac83a4d71ae@mail.gmail.com>
References: <37f76d50801052240w44bbf29arb80d7e7b1a451710@mail.gmail.com>
	<ca471dc20801062001m148b343ex450a9093c8c1359a@mail.gmail.com>
	<37f76d50801072048m77f172eei107167647ad37957@mail.gmail.com>
	<ca471dc20801072055g2275dba6na1207902191d3ff8@mail.gmail.com>
	<37f76d50801081434ld99cf1m404f4e21656283a3@mail.gmail.com>
	<ca471dc20801081441u707e9c74tf9fa1ccee030e44f@mail.gmail.com>
	<bbaeab100801081455m69384e82ia481fac83a4d71ae@mail.gmail.com>
Message-ID: <d11dcfba0801081612s18c3eb06y5da665a0a3291623@mail.gmail.com>

On Jan 8, 2008 3:55 PM, Brett Cannon <brett at python.org> wrote:
> On Jan 8, 2008 2:41 PM, Guido van Rossum <guido at python.org> wrote:
> > list.sort() and built-in sorted() are the least of our problems: even
> > though the API uses cmp, the implementation actually only ever uses
> > '<'; and the preferred API is to use the 'key' argument instead of
> > passing a compare function; that's much more efficient.
> >
> > Maybe we should retire the compare function completely in 3.0?
> >
>
> +1 from me. I personally have always hated the whole, -1, 0, 1 style
> of comparison anyway.

+1 from here too.  I've found it frustrating that the first argument
to sort() and sorted() is the least useful. ;-)

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
        --- Bucky Katt, Get Fuzzy

From hashcollision at gmail.com  Wed Jan  9 01:23:26 2008
From: hashcollision at gmail.com (hashcollision)
Date: Tue, 8 Jan 2008 19:23:26 -0500
Subject: [Python-3000] Need closure on __cmp__ removal
In-Reply-To: <d11dcfba0801081612s18c3eb06y5da665a0a3291623@mail.gmail.com>
References: <37f76d50801052240w44bbf29arb80d7e7b1a451710@mail.gmail.com>
	<ca471dc20801062001m148b343ex450a9093c8c1359a@mail.gmail.com>
	<37f76d50801072048m77f172eei107167647ad37957@mail.gmail.com>
	<ca471dc20801072055g2275dba6na1207902191d3ff8@mail.gmail.com>
	<37f76d50801081434ld99cf1m404f4e21656283a3@mail.gmail.com>
	<ca471dc20801081441u707e9c74tf9fa1ccee030e44f@mail.gmail.com>
	<bbaeab100801081455m69384e82ia481fac83a4d71ae@mail.gmail.com>
	<d11dcfba0801081612s18c3eb06y5da665a0a3291623@mail.gmail.com>
Message-ID: <37f76d50801081623k66311bb3k759336c87b4f6be5@mail.gmail.com>

+1 from me too if you only need to define __lt__ and __eq__ and __le__ and
__gt__, etc, will default to that. If it dosn't default to those, I feel
that one would need to write too many functions.

On Jan 8, 2008 7:12 PM, Steven Bethard <steven.bethard at gmail.com> wrote:

> On Jan 8, 2008 3:55 PM, Brett Cannon <brett at python.org> wrote:
> > On Jan 8, 2008 2:41 PM, Guido van Rossum <guido at python.org> wrote:
> > > list.sort() and built-in sorted() are the least of our problems: even
> > > though the API uses cmp, the implementation actually only ever uses
> > > '<'; and the preferred API is to use the 'key' argument instead of
> > > passing a compare function; that's much more efficient.
> > >
> > > Maybe we should retire the compare function completely in 3.0?
> > >
> >
> > +1 from me. I personally have always hated the whole, -1, 0, 1 style
> > of comparison anyway.
>
> +1 from here too.  I've found it frustrating that the first argument
> to sort() and sorted() is the least useful. ;-)
>
> Steve
> --
> I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
> tiny blip on the distant coast of sanity.
>        --- Bucky Katt, Get Fuzzy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080108/7b0ab80f/attachment.htm 

From guido at python.org  Wed Jan  9 01:35:25 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 8 Jan 2008 16:35:25 -0800
Subject: [Python-3000] Need closure on __cmp__ removal
In-Reply-To: <37f76d50801081623k66311bb3k759336c87b4f6be5@mail.gmail.com>
References: <37f76d50801052240w44bbf29arb80d7e7b1a451710@mail.gmail.com>
	<ca471dc20801062001m148b343ex450a9093c8c1359a@mail.gmail.com>
	<37f76d50801072048m77f172eei107167647ad37957@mail.gmail.com>
	<ca471dc20801072055g2275dba6na1207902191d3ff8@mail.gmail.com>
	<37f76d50801081434ld99cf1m404f4e21656283a3@mail.gmail.com>
	<ca471dc20801081441u707e9c74tf9fa1ccee030e44f@mail.gmail.com>
	<bbaeab100801081455m69384e82ia481fac83a4d71ae@mail.gmail.com>
	<d11dcfba0801081612s18c3eb06y5da665a0a3291623@mail.gmail.com>
	<37f76d50801081623k66311bb3k759336c87b4f6be5@mail.gmail.com>
Message-ID: <ca471dc20801081635s48fdd481lc7de78d1d3b18ac@mail.gmail.com>

That's a different issue altogether (and your wish is not likely going
to be granted unless you write a PEP).

On Jan 8, 2008 4:23 PM, hashcollision <hashcollision at gmail.com> wrote:
> +1 from me too if you only need to define __lt__ and __eq__ and __le__ and
> __gt__, etc, will default to that. If it dosn't default to those, I feel
> that one would need to write too many functions.
>
>
>
>
> On Jan 8, 2008 7:12 PM, Steven Bethard <steven.bethard at gmail.com> wrote:
>
> >
> > On Jan 8, 2008 3:55 PM, Brett Cannon <brett at python.org> wrote:
> > > On Jan 8, 2008 2:41 PM, Guido van Rossum <guido at python.org > wrote:
> > > > list.sort() and built-in sorted() are the least of our problems: even
> > > > though the API uses cmp, the implementation actually only ever uses
> > > > '<'; and the preferred API is to use the 'key' argument instead of
> > > > passing a compare function; that's much more efficient.
> > > >
> > > > Maybe we should retire the compare function completely in 3.0?
> > > >
> > >
> > > +1 from me. I personally have always hated the whole, -1, 0, 1 style
> > > of comparison anyway.
> >
> > +1 from here too.  I've found it frustrating that the first argument
> > to sort() and sorted() is the least useful. ;-)
> >
> >
> >
> >
> > Steve
> > --
> > I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
> > tiny blip on the distant coast of sanity.
> >        --- Bucky Katt, Get Fuzzy
> >
>
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe:
> http://mail.python.org/mailman/options/python-3000/guido%40python.org
>
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From hashcollision at gmail.com  Wed Jan  9 01:43:44 2008
From: hashcollision at gmail.com (hashcollision)
Date: Tue, 8 Jan 2008 19:43:44 -0500
Subject: [Python-3000] What does the "+" mode do?
Message-ID: <37f76d50801081643g15df4f04o42052bdf8b4fb30b@mail.gmail.com>

A quick question:
What does the "+" mode do? I couldn't find much on google (except that it is
called "updating").
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080108/000e040e/attachment.htm 

From tjreedy at udel.edu  Wed Jan  9 01:49:03 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Tue, 8 Jan 2008 19:49:03 -0500
Subject: [Python-3000] What does the "+" mode do?
References: <37f76d50801081643g15df4f04o42052bdf8b4fb30b@mail.gmail.com>
Message-ID: <fm15lu$t5j$1@ger.gmane.org>


"hashcollision" <hashcollision at gmail.com> wrote in message 
news:37f76d50801081643g15df4f04o42052bdf8b4fb30b at mail.gmail.com...
|A quick question:
| What does the "+" mode do? I couldn't find much on google (except that it 
is
| called "updating").

This is a question for comp.lang.python, not the developers' lists. 




From lists at cheimes.de  Wed Jan  9 01:49:44 2008
From: lists at cheimes.de (Christian Heimes)
Date: Wed, 09 Jan 2008 01:49:44 +0100
Subject: [Python-3000] Need closure on __cmp__ removal
In-Reply-To: <ca471dc20801081635s48fdd481lc7de78d1d3b18ac@mail.gmail.com>
References: <37f76d50801052240w44bbf29arb80d7e7b1a451710@mail.gmail.com>	<ca471dc20801062001m148b343ex450a9093c8c1359a@mail.gmail.com>	<37f76d50801072048m77f172eei107167647ad37957@mail.gmail.com>	<ca471dc20801072055g2275dba6na1207902191d3ff8@mail.gmail.com>	<37f76d50801081434ld99cf1m404f4e21656283a3@mail.gmail.com>	<ca471dc20801081441u707e9c74tf9fa1ccee030e44f@mail.gmail.com>	<bbaeab100801081455m69384e82ia481fac83a4d71ae@mail.gmail.com>	<d11dcfba0801081612s18c3eb06y5da665a0a3291623@mail.gmail.com>	<37f76d50801081623k66311bb3k759336c87b4f6be5@mail.gmail.com>
	<ca471dc20801081635s48fdd481lc7de78d1d3b18ac@mail.gmail.com>
Message-ID: <47841A28.9040501@cheimes.de>

Guido van Rossum wrote:
> That's a different issue altogether (and your wish is not likely going
> to be granted unless you write a PEP).

You could write and implement a PEP about exposing the tp_richcompare
slot to Python code.

import sys

class Example:
    def __richcmp__(self, other: object, op: int) -> bool:
        if op == sys.CMP_EQ:
            return self.value == other.value
        ...

Christian

From mark at qtrac.eu  Wed Jan  9 09:04:50 2008
From: mark at qtrac.eu (Mark Summerfield)
Date: Wed, 9 Jan 2008 08:04:50 +0000
Subject: [Python-3000] Need closure on __cmp__ removal
In-Reply-To: <47841A28.9040501@cheimes.de>
References: <37f76d50801052240w44bbf29arb80d7e7b1a451710@mail.gmail.com>
	<ca471dc20801081635s48fdd481lc7de78d1d3b18ac@mail.gmail.com>
	<47841A28.9040501@cheimes.de>
Message-ID: <200801090804.51141.mark@qtrac.eu>

On 2008-01-09, Christian Heimes wrote:
> Guido van Rossum wrote:
> > That's a different issue altogether (and your wish is not likely going
> > to be granted unless you write a PEP).
>
> You could write and implement a PEP about exposing the tp_richcompare
> slot to Python code.
>
> import sys
>
> class Example:
>     def __richcmp__(self, other: object, op: int) -> bool:
>         if op == sys.CMP_EQ:
>             return self.value == other.value
>         ...

I'm using this as a class decorator that fills in "missing" comparisons:

def complete_comparisons(cls):
    class CompleteComparisonsError(Exception): pass

    if hasattr(cls.__lt__, "__objclass__"): # i.e. < inherited from object
        raise CompleteComparisonsError("{0} must define < and "
                "ideally ==".format(cls.__name__))
    if hasattr(cls.__eq__, "__objclass__"): # i.e. == inherited from object
        cls.__eq__ = lambda self, other: not (
                cls.__lt__(self, other) or cls.__lt__(other, self))
    cls.__ne__ = lambda self, other: not cls.__eq__(self, other)
    cls.__gt__ = lambda self, other: cls.__lt__(other, self)
    cls.__le__ = lambda self, other: (cls.__lt__(self, other) or
                                      cls.__eq__(self, other))
    cls.__ge__ = lambda self, other: (cls.__lt__(other, self) or
                                      cls.__eq__(self, other))
    return cls


The reason for the ugly hasattr() calls is that object itself defines
the comparison operators (in Python 3.0a2).


-- 
Mark Summerfield, Qtrac Ltd., www.qtrac.eu



From qrczak at knm.org.pl  Wed Jan  9 18:16:54 2008
From: qrczak at knm.org.pl (Marcin =?UTF-8?Q?=E2=80=98Qrczak=E2=80=99?= Kowalczyk)
Date: Wed, 09 Jan 2008 18:16:54 +0100
Subject: [Python-3000] Need closure on __cmp__ removal
In-Reply-To: <47841A28.9040501@cheimes.de>
References: <37f76d50801052240w44bbf29arb80d7e7b1a451710@mail.gmail.com>
	<ca471dc20801062001m148b343ex450a9093c8c1359a@mail.gmail.com>
	<37f76d50801072048m77f172eei107167647ad37957@mail.gmail.com>
	<ca471dc20801072055g2275dba6na1207902191d3ff8@mail.gmail.com>
	<37f76d50801081434ld99cf1m404f4e21656283a3@mail.gmail.com>
	<ca471dc20801081441u707e9c74tf9fa1ccee030e44f@mail.gmail.com>
	<bbaeab100801081455m69384e82ia481fac83a4d71ae@mail.gmail.com>
	<d11dcfba0801081612s18c3eb06y5da665a0a3291623@mail.gmail.com>
	<37f76d50801081623k66311bb3k759336c87b4f6be5@mail.gmail.com>
	<ca471dc20801081635s48fdd481lc7de78d1d3b18ac@mail.gmail.com>
	<47841A28.9040501@cheimes.de>
Message-ID: <1199899014.23874.14.camel@qrnik>

Dnia 09-01-2008, ?r o godzinie 01:49 +0100, Christian Heimes pisze:

> You could write and implement a PEP about exposing the tp_richcompare
> slot to Python code.

How is it better than separate __eq__, __lt__ etc.? In most cases the
rich comparison starts with dispatching on the operation and treats each
one independently; I suppose only rarely it is forwarded to another
object without looking at the operation. So usually it is less
convenient and slower than separate methods.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/


From guido at python.org  Wed Jan  9 20:08:29 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 9 Jan 2008 11:08:29 -0800
Subject: [Python-3000] Need closure on __cmp__ removal
In-Reply-To: <200801090804.51141.mark@qtrac.eu>
References: <37f76d50801052240w44bbf29arb80d7e7b1a451710@mail.gmail.com>
	<ca471dc20801081635s48fdd481lc7de78d1d3b18ac@mail.gmail.com>
	<47841A28.9040501@cheimes.de> <200801090804.51141.mark@qtrac.eu>
Message-ID: <ca471dc20801091108r7c0a77bdxace227e8d1c2e094@mail.gmail.com>

On Jan 9, 2008 12:04 AM, Mark Summerfield <mark at qtrac.eu> wrote:
> I'm using this as a class decorator that fills in "missing" comparisons:
>
> def complete_comparisons(cls):
>     class CompleteComparisonsError(Exception): pass
>
>     if hasattr(cls.__lt__, "__objclass__"): # i.e. < inherited from object
>         raise CompleteComparisonsError("{0} must define < and "
>                 "ideally ==".format(cls.__name__))
>     if hasattr(cls.__eq__, "__objclass__"): # i.e. == inherited from object
>         cls.__eq__ = lambda self, other: not (
>                 cls.__lt__(self, other) or cls.__lt__(other, self))
>     cls.__ne__ = lambda self, other: not cls.__eq__(self, other)
>     cls.__gt__ = lambda self, other: cls.__lt__(other, self)
>     cls.__le__ = lambda self, other: (cls.__lt__(self, other) or
>                                       cls.__eq__(self, other))
>     cls.__ge__ = lambda self, other: (cls.__lt__(other, self) or
>                                       cls.__eq__(self, other))
>     return cls
>
>
> The reason for the ugly hasattr() calls is that object itself defines
> the comparison operators (in Python 3.0a2).

That's due to object's implementation of __eq__ and __ne__; this is
done by having a tp_richcompare slot and then the wrapper generator
adds wrappers for all six operators to the class dict. This is not
easy to fix.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From janssen at parc.com  Wed Jan  9 20:26:52 2008
From: janssen at parc.com (Bill Janssen)
Date: Wed, 9 Jan 2008 11:26:52 PST
Subject: [Python-3000] Need closure on __cmp__ removal
In-Reply-To: <d11dcfba0801081612s18c3eb06y5da665a0a3291623@mail.gmail.com> 
References: <37f76d50801052240w44bbf29arb80d7e7b1a451710@mail.gmail.com>
	<ca471dc20801062001m148b343ex450a9093c8c1359a@mail.gmail.com>
	<37f76d50801072048m77f172eei107167647ad37957@mail.gmail.com>
	<ca471dc20801072055g2275dba6na1207902191d3ff8@mail.gmail.com>
	<37f76d50801081434ld99cf1m404f4e21656283a3@mail.gmail.com>
	<ca471dc20801081441u707e9c74tf9fa1ccee030e44f@mail.gmail.com>
	<bbaeab100801081455m69384e82ia481fac83a4d71ae@mail.gmail.com>
	<d11dcfba0801081612s18c3eb06y5da665a0a3291623@mail.gmail.com>
Message-ID: <08Jan9.112655pst."58696"@synergy1.parc.xerox.com>

Steve Bethard writes:
> On Jan 8, 2008 3:55 PM, Brett Cannon <brett at python.org> wrote:
> > On Jan 8, 2008 2:41 PM, Guido van Rossum <guido at python.org> wrote:
> > > list.sort() and built-in sorted() are the least of our problems: even
> > > though the API uses cmp, the implementation actually only ever uses
> > > '<'; and the preferred API is to use the 'key' argument instead of
> > > passing a compare function; that's much more efficient.
> > >
> > > Maybe we should retire the compare function completely in 3.0?
> > >
> >
> > +1 from me. I personally have always hated the whole, -1, 0, 1 style
> > of comparison anyway.
> 
> +1 from here too.  I've found it frustrating that the first argument
> to sort() and sorted() is the least useful. ;-)

I'm a bit baffled here; I find cmp() fairly handy in writing sort
routines:

   newlist = oldlist.sort(lambda v1, v2: cmp(v1.attr_x, v2.attr_x))

Is there a better / newer / official way of doing this?  If not, isn't
"cmp()" still useful to have around?

(Bear in mind that I still use the 2.3.5 dialect of Python as much as
possible, due to the continued widespread deployment of Mac OS X 10.4.
So my style may be out-of-date.)

Bill

From phd at phd.pp.ru  Wed Jan  9 20:34:28 2008
From: phd at phd.pp.ru (Oleg Broytmann)
Date: Wed, 9 Jan 2008 22:34:28 +0300
Subject: [Python-3000] Need closure on __cmp__ removal
In-Reply-To: <08Jan9.112655pst."58696"@synergy1.parc.xerox.com>
References: <37f76d50801052240w44bbf29arb80d7e7b1a451710@mail.gmail.com>
	<ca471dc20801062001m148b343ex450a9093c8c1359a@mail.gmail.com>
	<37f76d50801072048m77f172eei107167647ad37957@mail.gmail.com>
	<ca471dc20801072055g2275dba6na1207902191d3ff8@mail.gmail.com>
	<37f76d50801081434ld99cf1m404f4e21656283a3@mail.gmail.com>
	<ca471dc20801081441u707e9c74tf9fa1ccee030e44f@mail.gmail.com>
	<bbaeab100801081455m69384e82ia481fac83a4d71ae@mail.gmail.com>
	<d11dcfba0801081612s18c3eb06y5da665a0a3291623@mail.gmail.com>
	<08Jan9.112655pst."58696"@synergy1.parc.xerox.com>
Message-ID: <20080109193428.GA19182@phd.pp.ru>

On Wed, Jan 09, 2008 at 11:26:52AM -0800, Bill Janssen wrote:
> I'm a bit baffled here; I find cmp() fairly handy in writing sort
> routines:
> 
>    newlist = oldlist.sort(lambda v1, v2: cmp(v1.attr_x, v2.attr_x))
> 
> Is there a better / newer / official way of doing this?

   newlist = oldlist.sort(key=lambda v: v.attr_x)

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

From brett at python.org  Wed Jan  9 20:34:59 2008
From: brett at python.org (Brett Cannon)
Date: Wed, 9 Jan 2008 11:34:59 -0800
Subject: [Python-3000] Need closure on __cmp__ removal
In-Reply-To: <20080109193428.GA19182@phd.pp.ru>
References: <37f76d50801052240w44bbf29arb80d7e7b1a451710@mail.gmail.com>
	<ca471dc20801062001m148b343ex450a9093c8c1359a@mail.gmail.com>
	<37f76d50801072048m77f172eei107167647ad37957@mail.gmail.com>
	<ca471dc20801072055g2275dba6na1207902191d3ff8@mail.gmail.com>
	<37f76d50801081434ld99cf1m404f4e21656283a3@mail.gmail.com>
	<ca471dc20801081441u707e9c74tf9fa1ccee030e44f@mail.gmail.com>
	<bbaeab100801081455m69384e82ia481fac83a4d71ae@mail.gmail.com>
	<d11dcfba0801081612s18c3eb06y5da665a0a3291623@mail.gmail.com>
	<20080109193428.GA19182@phd.pp.ru>
Message-ID: <bbaeab100801091134l2383ddf6pbb2b6584c127c299@mail.gmail.com>

On Jan 9, 2008 11:34 AM, Oleg Broytmann <phd at phd.pp.ru> wrote:
> On Wed, Jan 09, 2008 at 11:26:52AM -0800, Bill Janssen wrote:
> > I'm a bit baffled here; I find cmp() fairly handy in writing sort
> > routines:
> >
> >    newlist = oldlist.sort(lambda v1, v2: cmp(v1.attr_x, v2.attr_x))
> >
> > Is there a better / newer / official way of doing this?
>
>    newlist = oldlist.sort(key=lambda v: v.attr_x)

And don't forget about operator.attrgetter().

-Brett

From phd at phd.pp.ru  Wed Jan  9 20:41:29 2008
From: phd at phd.pp.ru (Oleg Broytmann)
Date: Wed, 9 Jan 2008 22:41:29 +0300
Subject: [Python-3000] Need closure on __cmp__ removal
In-Reply-To: <bbaeab100801091134l2383ddf6pbb2b6584c127c299@mail.gmail.com>
References: <37f76d50801052240w44bbf29arb80d7e7b1a451710@mail.gmail.com>
	<ca471dc20801062001m148b343ex450a9093c8c1359a@mail.gmail.com>
	<37f76d50801072048m77f172eei107167647ad37957@mail.gmail.com>
	<ca471dc20801072055g2275dba6na1207902191d3ff8@mail.gmail.com>
	<37f76d50801081434ld99cf1m404f4e21656283a3@mail.gmail.com>
	<ca471dc20801081441u707e9c74tf9fa1ccee030e44f@mail.gmail.com>
	<bbaeab100801081455m69384e82ia481fac83a4d71ae@mail.gmail.com>
	<d11dcfba0801081612s18c3eb06y5da665a0a3291623@mail.gmail.com>
	<20080109193428.GA19182@phd.pp.ru>
	<bbaeab100801091134l2383ddf6pbb2b6584c127c299@mail.gmail.com>
Message-ID: <20080109194129.GB19182@phd.pp.ru>

On Wed, Jan 09, 2008 at 11:34:59AM -0800, Brett Cannon wrote:
> On Jan 9, 2008 11:34 AM, Oleg Broytmann <phd at phd.pp.ru> wrote:
> >    newlist = oldlist.sort(key=lambda v: v.attr_x)
> 
> And don't forget about operator.attrgetter().

   I don't like it for the task. To use I need to import operator, and
I don't know is it faster or slower than lambda; I suspect it's slower but
I am too lazy to test. Using lambda to get a simple attribute seems much
simpler to me.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

From mike.klaas at gmail.com  Wed Jan  9 21:10:34 2008
From: mike.klaas at gmail.com (Mike Klaas)
Date: Wed, 9 Jan 2008 12:10:34 -0800
Subject: [Python-3000] Need closure on __cmp__ removal
In-Reply-To: <20080109194129.GB19182@phd.pp.ru>
References: <37f76d50801052240w44bbf29arb80d7e7b1a451710@mail.gmail.com>
	<ca471dc20801062001m148b343ex450a9093c8c1359a@mail.gmail.com>
	<37f76d50801072048m77f172eei107167647ad37957@mail.gmail.com>
	<ca471dc20801072055g2275dba6na1207902191d3ff8@mail.gmail.com>
	<37f76d50801081434ld99cf1m404f4e21656283a3@mail.gmail.com>
	<ca471dc20801081441u707e9c74tf9fa1ccee030e44f@mail.gmail.com>
	<bbaeab100801081455m69384e82ia481fac83a4d71ae@mail.gmail.com>
	<d11dcfba0801081612s18c3eb06y5da665a0a3291623@mail.gmail.com>
	<20080109193428.GA19182@phd.pp.ru>
	<bbaeab100801091134l2383ddf6pbb2b6584c127c299@mail.gmail.com>
	<20080109194129.GB19182@phd.pp.ru>
Message-ID: <1DB580AE-244A-4E00-AA20-47402018FD6F@gmail.com>

On 9-Jan-08, at 11:41 AM, Oleg Broytmann wrote:

> On Wed, Jan 09, 2008 at 11:34:59AM -0800, Brett Cannon wrote:
>> On Jan 9, 2008 11:34 AM, Oleg Broytmann <phd at phd.pp.ru> wrote:
>>>    newlist = oldlist.sort(key=lambda v: v.attr_x)
>>
>> And don't forget about operator.attrgetter().
>
>    I don't like it for the task. To use I need to import operator, and
> I don't know is it faster or slower than lambda; I suspect it's  
> slower but
> I am too lazy to test. Using lambda to get a simple attribute seems  
> much
> simpler to me.

lambda's are always slower than the equivalent coded in c:

[worio at domU-12-31-38-00-59-81 frontend]$ python -m 'timeit' 'import  
operator; f=operator.attrgetter("open"); import os' 'f(os)'
100000 loops, best of 3: 5.71 usec per loop
[worio at domU-12-31-38-00-59-81 frontend]$ python -m 'timeit' 'f=lambda  
x: x.open; import os' 'f(os)'

100000 loops, best of 3: 6.06 usec per loop

-Mike

From hashcollision at gmail.com  Thu Jan 10 04:03:47 2008
From: hashcollision at gmail.com (hashcollision)
Date: Wed, 9 Jan 2008 22:03:47 -0500
Subject: [Python-3000] PEP 3116 question
Message-ID: <37f76d50801091903x2b6f848fue68b6ebeea38a2b@mail.gmail.com>

>From PEP 3116: "BufferedRandom implementation is for all random-access
objects, whether they are read-only, write-only, or *read-write*."
(emphasis mine) However, from the pseudo-code for open(),
"if reading + writing + appending > 1:
    raise ValueError("can't have read/write/append mode at once")"
dosn't this contradict each other? Why isn't read + write allowed when
BufferedRandom does allow it? Java's RandomAccessFile allows the mode
"rw". Is there a way to do something like it in Python?

From lists at cheimes.de  Thu Jan 10 04:45:29 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 10 Jan 2008 04:45:29 +0100
Subject: [Python-3000] PEP 3116 question
In-Reply-To: <37f76d50801091903x2b6f848fue68b6ebeea38a2b@mail.gmail.com>
References: <37f76d50801091903x2b6f848fue68b6ebeea38a2b@mail.gmail.com>
Message-ID: <478594D9.7010509@cheimes.de>

hashcollision wrote:
>>From PEP 3116: "BufferedRandom implementation is for all random-access
> objects, whether they are read-only, write-only, or *read-write*."
> (emphasis mine) However, from the pseudo-code for open(),
> "if reading + writing + appending > 1:
>     raise ValueError("can't have read/write/append mode at once")"
> dosn't this contradict each other? Why isn't read + write allowed when
> BufferedRandom does allow it? Java's RandomAccessFile allows the mode
> "rw". Is there a way to do something like it in Python?

In Python we have "r+" or "w+". r+ opens a file for reading but also
allows writing. w+ creates or truncates a file and allows reading and
writing. In the open function it's called "updating".

Christian

From jcea at argo.es  Thu Jan 10 13:52:55 2008
From: jcea at argo.es (Jesus Cea)
Date: Thu, 10 Jan 2008 13:52:55 +0100
Subject: [Python-3000] Is pickle's persistent_id worth keeping?
In-Reply-To: <ca471dc20801080951o3f47fe99yaefbcd6c7557ae0d@mail.gmail.com>
References: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>	<17033E0D-6A78-4D66-ACFB-1A5ED150646E@zope.com>	<52C7B012-8C6A-4530-BE04-ADA9BC54D4E1@acm.org>	<1199796869.6177.25.camel@jcd-desktop>	<5ED6A8B1-241E-4FFB-A512-0FF744A4E964@acm.org>
	<ca471dc20801080951o3f47fe99yaefbcd6c7557ae0d@mail.gmail.com>
Message-ID: <47861527.7020904@argo.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Guido van Rossum wrote:
> pickle should definitely remain part of the core; it is timed in lots
> of ways to core datatypes. It is also something that I expect nobody
> would be thrilled to maintain if it was separate. And there is a lot
> to say for having a "universal" serialization format; e.g. there have
> been RPC systems built on top of pickling.

Notably, the wonderful Pyro :-)

> For things like bsddb I think the argument of release cycles is
> stronger. In particular bsddb support in the core is painful, the
> tests often fail, they take a long time to run, and I don't see that
> many users.

I'm very dependent of bsddb support in python. I'm very sorry also of
the maintainer support of it: he is slow and doesn't implement python
bindings for berkeleydb features deployed five years ago :-(. Could be a
bit rude, but maybe a maintaner change would be in order. I would rather
prefer to talk to current maintainer, but I rather apply for maintaner
position than dropping bsddb from the python stdlib!!.

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
                               _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBR4YVJ5lgi5GaxT1NAQIwqQP+L8lUsU4O2NxykHVLIuONjwqGFfE7+La6
01eKXft06L6sHTJ11qZq2XN9vltrXv39W4DH8Ak+yOD7fJANfTPc2XvYNt2vyiQh
4Hqa5/V8FjErlpebO3/b0ostPNfd422Oijtv5pc8xZqlQX4o9gBL2aNqCKbmLPPI
ht/Ei8MBgfA=
=yQak
-----END PGP SIGNATURE-----

From jcea at argo.es  Thu Jan 10 13:43:12 2008
From: jcea at argo.es (Jesus Cea)
Date: Thu, 10 Jan 2008 13:43:12 +0100
Subject: [Python-3000] Is pickle's persistent_id worth keeping?
In-Reply-To: <17033E0D-6A78-4D66-ACFB-1A5ED150646E@zope.com>
References: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>
	<17033E0D-6A78-4D66-ACFB-1A5ED150646E@zope.com>
Message-ID: <478612E0.10704@argo.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jim Fulton wrote:
> Pickle always memoized objects.  persistent_id is useful for  
> separating data over multiple pickles as is done in a database.  IOW,  
> as its name implies, it is primarily useful for persistence systems.   
> I don't think that ZODB is the only persistence system built on  
> pickle, but perhaps I'm wrong.
> 
> I  suspect ZODB is also the primary user of the pickle module.

Durus, another (excellent) persistence system for Python also uses this
method.

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
                               _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBR4YS4Jlgi5GaxT1NAQInxgQAlzoD5d9srVS5X+h86CXzPtk1S/R9VRLX
r8374kqLLla3wjKKuJXt+dksiKvMbtwpLEYIGJf9EP2NsSm4Xnq4iMtqXxR9r+mZ
4Vr57p2Rqf168r1qMO7frndjxR1YHkVkap0sTE7s0euJOuTjNTtljwko/Fo8TjY6
9ICMujOLaYM=
=uAL6
-----END PGP SIGNATURE-----

From guido at python.org  Thu Jan 10 17:08:55 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 10 Jan 2008 08:08:55 -0800
Subject: [Python-3000] Is pickle's persistent_id worth keeping?
In-Reply-To: <47861527.7020904@argo.es>
References: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>
	<17033E0D-6A78-4D66-ACFB-1A5ED150646E@zope.com>
	<52C7B012-8C6A-4530-BE04-ADA9BC54D4E1@acm.org>
	<1199796869.6177.25.camel@jcd-desktop>
	<5ED6A8B1-241E-4FFB-A512-0FF744A4E964@acm.org>
	<ca471dc20801080951o3f47fe99yaefbcd6c7557ae0d@mail.gmail.com>
	<47861527.7020904@argo.es>
Message-ID: <ca471dc20801100808p419b5481sed2f8075191503da@mail.gmail.com>

On Jan 10, 2008 4:52 AM, Jesus Cea <jcea at argo.es> wrote:
> I'm very dependent of bsddb support in python. I'm very sorry also of
> the maintainer support of it: he is slow and doesn't implement python
> bindings for berkeleydb features deployed five years ago :-(. Could be a
> bit rude, but maybe a maintaner change would be in order. I would rather
> prefer to talk to current maintainer, but I rather apply for maintaner
> position than dropping bsddb from the python stdlib!!.

Hi Jesus,

I don't know if there *is* a current maintainer. There are a few
people who sometimes fix things in the current code base, but I think
development has stopped. If you're serious about wanting to take over
maintenance, (or even just contributing) that would be great!

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From joe.d.angell at gmail.com  Thu Jan 10 17:39:02 2008
From: joe.d.angell at gmail.com (Joe Angell)
Date: Thu, 10 Jan 2008 09:39:02 -0700
Subject: [Python-3000] compiler module
Message-ID: <9fc959f40801100839wfe202ber43a01d551f418eeb@mail.gmail.com>

My apologies if this has been asked before, but are there any plans to
add the compiler module back in to py3k?  If so, any idea on a
timeline?  If help is needed I may be able to put in some time on
this.  I've already back ported some of the py3k grammar (function
parameter annotations) to python 2.5.1 so I can use this with the
compiler module, but I think it would be sweet to just use py3k
directly.

Thanks,

Joe Angell

From guido at python.org  Thu Jan 10 18:34:52 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 10 Jan 2008 09:34:52 -0800
Subject: [Python-3000] compiler module
In-Reply-To: <9fc959f40801100839wfe202ber43a01d551f418eeb@mail.gmail.com>
References: <9fc959f40801100839wfe202ber43a01d551f418eeb@mail.gmail.com>
Message-ID: <ca471dc20801100934g1dd1f247h128ba18c44569f42@mail.gmail.com>

On Jan 10, 2008 8:39 AM, Joe Angell <joe.d.angell at gmail.com> wrote:
> My apologies if this has been asked before, but are there any plans to
> add the compiler module back in to py3k?  If so, any idea on a
> timeline?  If help is needed I may be able to put in some time on
> this.  I've already back ported some of the py3k grammar (function
> parameter annotations) to python 2.5.1 so I can use this with the
> compiler module, but I think it would be sweet to just use py3k
> directly.

AFAIK there are no such plans; maintaining two versions of the
compiler (one in Python and one in C) has turned out to be a
nightmare, with the Python version always running behind and having
bugs because it wasn't used much for real work.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From greg at krypto.org  Thu Jan 10 19:58:27 2008
From: greg at krypto.org (Gregory P. Smith)
Date: Thu, 10 Jan 2008 10:58:27 -0800
Subject: [Python-3000] Is pickle's persistent_id worth keeping?
In-Reply-To: <ca471dc20801100808p419b5481sed2f8075191503da@mail.gmail.com>
References: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>
	<17033E0D-6A78-4D66-ACFB-1A5ED150646E@zope.com>
	<52C7B012-8C6A-4530-BE04-ADA9BC54D4E1@acm.org>
	<1199796869.6177.25.camel@jcd-desktop>
	<5ED6A8B1-241E-4FFB-A512-0FF744A4E964@acm.org>
	<ca471dc20801080951o3f47fe99yaefbcd6c7557ae0d@mail.gmail.com>
	<47861527.7020904@argo.es>
	<ca471dc20801100808p419b5481sed2f8075191503da@mail.gmail.com>
Message-ID: <52dc1c820801101058k43e24a25x6ff9955b294896fb@mail.gmail.com>

On 1/10/08, Guido van Rossum <guido at python.org> wrote:
>
> On Jan 10, 2008 4:52 AM, Jesus Cea <jcea at argo.es> wrote:
> > I'm very dependent of bsddb support in python. I'm very sorry also of
> > the maintainer support of it: he is slow and doesn't implement python
> > bindings for berkeleydb features deployed five years ago :-(. Could be a
> > bit rude, but maybe a maintaner change would be in order. I would rather
> > prefer to talk to current maintainer, but I rather apply for maintaner
> > position than dropping bsddb from the python stdlib!!.
>
> Hi Jesus,
>
> I don't know if there *is* a current maintainer. There are a few
> people who sometimes fix things in the current code base, but I think
> development has stopped. If you're serious about wanting to take over
> maintenance, (or even just contributing) that would be great!


I consider myself the maintainer because I at least make sure it keeps
working with new berkeleydb releases and such and am one of the most
familiar with the _bsddb.c code internals (both the good and the bad).

But theres a caveat to me having that job: I have -zero- use for the bsddb
module myself today. Whenever I update it it really is a donation of my time
since I don't personally need the changes.  A maintainer that has a vested
interest in using the module would be a great thing.  There are a couple
crashing bugs that need fixing and a few more recent API additions that
could be wrapped for sure.

Volunteering Jesus? :)

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080110/82b62041/attachment.htm 

From ndbecker2 at gmail.com  Thu Jan 10 20:20:15 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Thu, 10 Jan 2008 14:20:15 -0500
Subject: [Python-3000] pep 3119 question (ABC)
Message-ID: <fm5r5f$j01$1@ger.gmane.org>

On reading this pep, I was not clear on one issue.

In some interface proposals (zope?), as well as in c++0x concept proposal,
there is a mechanism to specify how to adapt a given class to satisfy given
interface requirements.

For example, suppose container ABC requires a 'size'.  Suppose I have a
container-like class C, but it's size is called 'len'.  The idea is to be
able to specify, _outside of the class C_, that the size requirement is
met, and it's called 'len'.

Does pep 3119 offer that functionality?


From guido at python.org  Thu Jan 10 20:36:38 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 10 Jan 2008 11:36:38 -0800
Subject: [Python-3000] pep 3119 question (ABC)
In-Reply-To: <fm5r5f$j01$1@ger.gmane.org>
References: <fm5r5f$j01$1@ger.gmane.org>
Message-ID: <ca471dc20801101136g371e3488u219300ad44beb9eb@mail.gmail.com>

On Jan 10, 2008 11:20 AM, Neal Becker <ndbecker2 at gmail.com> wrote:
> On reading this pep, I was not clear on one issue.
>
> In some interface proposals (zope?), as well as in c++0x concept proposal,
> there is a mechanism to specify how to adapt a given class to satisfy given
> interface requirements.
>
> For example, suppose container ABC requires a 'size'.  Suppose I have a
> container-like class C, but it's size is called 'len'.  The idea is to be
> able to specify, _outside of the class C_, that the size requirement is
> met, and it's called 'len'.
>
> Does pep 3119 offer that functionality?

No.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From ndbecker2 at gmail.com  Thu Jan 10 20:54:07 2008
From: ndbecker2 at gmail.com (Neal Becker)
Date: Thu, 10 Jan 2008 14:54:07 -0500
Subject: [Python-3000] pep 3119 question (ABC)
References: <fm5r5f$j01$1@ger.gmane.org>
	<ca471dc20801101136g371e3488u219300ad44beb9eb@mail.gmail.com>
Message-ID: <fm5t50$r93$1@ger.gmane.org>

Guido van Rossum wrote:

> On Jan 10, 2008 11:20 AM, Neal Becker <ndbecker2 at gmail.com> wrote:
>> On reading this pep, I was not clear on one issue.
>>
>> In some interface proposals (zope?), as well as in c++0x concept
>> proposal, there is a mechanism to specify how to adapt a given class to
>> satisfy given interface requirements.
>>
>> For example, suppose container ABC requires a 'size'.  Suppose I have a
>> container-like class C, but it's size is called 'len'.  The idea is to be
>> able to specify, _outside of the class C_, that the size requirement is
>> met, and it's called 'len'.
>>
>> Does pep 3119 offer that functionality?
> 
> No.
> 

Isn't that rather limiting then?  It's all well and good to design a
monolithic library with a uniform use of concepts.  But the motivation for
adaptation is that you want to mix libraries from different sources that
might not have coordinated in their design.

Is this because python classes are always open, and so I can always
add/modify their properties to conform to any interface, even without
touching the library source code, and therefore I don't really need any
other mechanism to adapt interfaces?


From guido at python.org  Thu Jan 10 20:59:18 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 10 Jan 2008 11:59:18 -0800
Subject: [Python-3000] pep 3119 question (ABC)
In-Reply-To: <fm5t50$r93$1@ger.gmane.org>
References: <fm5r5f$j01$1@ger.gmane.org>
	<ca471dc20801101136g371e3488u219300ad44beb9eb@mail.gmail.com>
	<fm5t50$r93$1@ger.gmane.org>
Message-ID: <ca471dc20801101159r3a3de279n66ed29c8731dfb76@mail.gmail.com>

On Jan 10, 2008 11:54 AM, Neal Becker <ndbecker2 at gmail.com> wrote:
>
> Guido van Rossum wrote:
>
> > On Jan 10, 2008 11:20 AM, Neal Becker <ndbecker2 at gmail.com> wrote:
> >> On reading this pep, I was not clear on one issue.
> >>
> >> In some interface proposals (zope?), as well as in c++0x concept
> >> proposal, there is a mechanism to specify how to adapt a given class to
> >> satisfy given interface requirements.
> >>
> >> For example, suppose container ABC requires a 'size'.  Suppose I have a
> >> container-like class C, but it's size is called 'len'.  The idea is to be
> >> able to specify, _outside of the class C_, that the size requirement is
> >> met, and it's called 'len'.
> >>
> >> Does pep 3119 offer that functionality?
> >
> > No.
> >
>
> Isn't that rather limiting then?  It's all well and good to design a
> monolithic library with a uniform use of concepts.  But the motivation for
> adaptation is that you want to mix libraries from different sources that
> might not have coordinated in their design.
>
> Is this because python classes are always open, and so I can always
> add/modify their properties to conform to any interface, even without
> touching the library source code, and therefore I don't really need any
> other mechanism to adapt interfaces?

It's because nobody contributed a requirement for this feature to the
PEP discussion when it was being discussed. I wouldn't want to rely on
monkeypatching if it was a valid requirement.

You should be able to subclass the metaclass though to add this
feature if you want it. If you do it cleanly enough it could even be
added to the PEP (or rather a new PEP) and to the standard abc.py
module.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From brett at python.org  Thu Jan 10 21:25:03 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 10 Jan 2008 12:25:03 -0800
Subject: [Python-3000] compiler module
In-Reply-To: <9fc959f40801100839wfe202ber43a01d551f418eeb@mail.gmail.com>
References: <9fc959f40801100839wfe202ber43a01d551f418eeb@mail.gmail.com>
Message-ID: <bbaeab100801101225k35c5676g47d5030e1d5998fa@mail.gmail.com>

On Jan 10, 2008 8:39 AM, Joe Angell <joe.d.angell at gmail.com> wrote:
> My apologies if this has been asked before, but are there any plans to
> add the compiler module back in to py3k?  If so, any idea on a
> timeline?  If help is needed I may be able to put in some time on
> this.  I've already back ported some of the py3k grammar (function
> parameter annotations) to python 2.5.1 so I can use this with the
> compiler module, but I think it would be sweet to just use py3k
> directly.

As Guido said, it is not going back. But we would appreciate help in
writing a function that takes Python's actual AST represesntation (as
returned by compile()) and generated the proper bytecode from it.

-Brett

From joe.d.angell at gmail.com  Thu Jan 10 22:50:19 2008
From: joe.d.angell at gmail.com (Joe Angell)
Date: Thu, 10 Jan 2008 14:50:19 -0700
Subject: [Python-3000] compiler module
In-Reply-To: <ca471dc20801100934g1dd1f247h128ba18c44569f42@mail.gmail.com>
References: <9fc959f40801100839wfe202ber43a01d551f418eeb@mail.gmail.com>
	<ca471dc20801100934g1dd1f247h128ba18c44569f42@mail.gmail.com>
Message-ID: <9fc959f40801101350r4ff4dfcbsed6a40522f2b3d16@mail.gmail.com>

How do you plan on letting third party tools utilize the new grammar?
Will they have to write their own parser then, or is there some kind
of plugin architecture?

Thanks,

joe

On Jan 10, 2008 10:34 AM, Guido van Rossum <guido at python.org> wrote:
>
> On Jan 10, 2008 8:39 AM, Joe Angell <joe.d.angell at gmail.com> wrote:
> > My apologies if this has been asked before, but are there any plans to
> > add the compiler module back in to py3k?  If so, any idea on a
> > timeline?  If help is needed I may be able to put in some time on
> > this.  I've already back ported some of the py3k grammar (function
> > parameter annotations) to python 2.5.1 so I can use this with the
> > compiler module, but I think it would be sweet to just use py3k
> > directly.
>
> AFAIK there are no such plans; maintaining two versions of the
> compiler (one in Python and one in C) has turned out to be a
> nightmare, with the Python version always running behind and having
> bugs because it wasn't used much for real work.
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>

From brett at python.org  Thu Jan 10 22:56:08 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 10 Jan 2008 13:56:08 -0800
Subject: [Python-3000] compiler module
In-Reply-To: <9fc959f40801101350r4ff4dfcbsed6a40522f2b3d16@mail.gmail.com>
References: <9fc959f40801100839wfe202ber43a01d551f418eeb@mail.gmail.com>
	<ca471dc20801100934g1dd1f247h128ba18c44569f42@mail.gmail.com>
	<9fc959f40801101350r4ff4dfcbsed6a40522f2b3d16@mail.gmail.com>
Message-ID: <bbaeab100801101356j1f5d8ae4vf24190778adef20b@mail.gmail.com>

On Jan 10, 2008 1:50 PM, Joe Angell <joe.d.angell at gmail.com> wrote:
> How do you plan on letting third party tools utilize the new grammar?

Don't need to plan anything; people are already using the AST that
Python's compiler uses since 2.5 came out.

> Will they have to write their own parser then, or is there some kind
> of plugin architecture?

No parser is required; Python's parser already handles the parsing.

-Brett



>
> Thanks,
>
> joe
>
>
> On Jan 10, 2008 10:34 AM, Guido van Rossum <guido at python.org> wrote:
> >
> > On Jan 10, 2008 8:39 AM, Joe Angell <joe.d.angell at gmail.com> wrote:
> > > My apologies if this has been asked before, but are there any plans to
> > > add the compiler module back in to py3k?  If so, any idea on a
> > > timeline?  If help is needed I may be able to put in some time on
> > > this.  I've already back ported some of the py3k grammar (function
> > > parameter annotations) to python 2.5.1 so I can use this with the
> > > compiler module, but I think it would be sweet to just use py3k
> > > directly.
> >
> > AFAIK there are no such plans; maintaining two versions of the
> > compiler (one in Python and one in C) has turned out to be a
> > nightmare, with the Python version always running behind and having
> > bugs because it wasn't used much for real work.
> >
> > --
> > --Guido van Rossum (home page: http://www.python.org/~guido/)
> >
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/brett%40python.org
>

From joe.d.angell at gmail.com  Thu Jan 10 23:08:15 2008
From: joe.d.angell at gmail.com (Joe Angell)
Date: Thu, 10 Jan 2008 15:08:15 -0700
Subject: [Python-3000] compiler module
In-Reply-To: <bbaeab100801101356j1f5d8ae4vf24190778adef20b@mail.gmail.com>
References: <9fc959f40801100839wfe202ber43a01d551f418eeb@mail.gmail.com>
	<ca471dc20801100934g1dd1f247h128ba18c44569f42@mail.gmail.com>
	<9fc959f40801101350r4ff4dfcbsed6a40522f2b3d16@mail.gmail.com>
	<bbaeab100801101356j1f5d8ae4vf24190778adef20b@mail.gmail.com>
Message-ID: <9fc959f40801101408o37dbe33ev7a4a0e6424ce239d@mail.gmail.com>

Oh I see... forgive my ignorance but could you point me at some
documentation or a project that uses the c AST as you mentioned?  Is
that done through some part of the C-API?  I cannot find that in the
documentation at the moment.

Thank you,

joe

On Jan 10, 2008 2:56 PM, Brett Cannon <brett at python.org> wrote:
> On Jan 10, 2008 1:50 PM, Joe Angell <joe.d.angell at gmail.com> wrote:
> > How do you plan on letting third party tools utilize the new grammar?
>
> Don't need to plan anything; people are already using the AST that
> Python's compiler uses since 2.5 came out.
>
> > Will they have to write their own parser then, or is there some kind
> > of plugin architecture?
>
> No parser is required; Python's parser already handles the parsing.
>
> -Brett
>
>
>
> >
> > Thanks,
> >
> > joe
> >
> >
> > On Jan 10, 2008 10:34 AM, Guido van Rossum <guido at python.org> wrote:
> > >
> > > On Jan 10, 2008 8:39 AM, Joe Angell <joe.d.angell at gmail.com> wrote:
> > > > My apologies if this has been asked before, but are there any plans to
> > > > add the compiler module back in to py3k?  If so, any idea on a
> > > > timeline?  If help is needed I may be able to put in some time on
> > > > this.  I've already back ported some of the py3k grammar (function
> > > > parameter annotations) to python 2.5.1 so I can use this with the
> > > > compiler module, but I think it would be sweet to just use py3k
> > > > directly.
> > >
> > > AFAIK there are no such plans; maintaining two versions of the
> > > compiler (one in Python and one in C) has turned out to be a
> > > nightmare, with the Python version always running behind and having
> > > bugs because it wasn't used much for real work.
> > >
> > > --
> > > --Guido van Rossum (home page: http://www.python.org/~guido/)
> > >
> > _______________________________________________
> > Python-3000 mailing list
> > Python-3000 at python.org
> > http://mail.python.org/mailman/listinfo/python-3000
> > Unsubscribe: http://mail.python.org/mailman/options/python-3000/brett%40python.org
> >
>

From brett at python.org  Thu Jan 10 23:22:30 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 10 Jan 2008 14:22:30 -0800
Subject: [Python-3000] compiler module
In-Reply-To: <9fc959f40801101408o37dbe33ev7a4a0e6424ce239d@mail.gmail.com>
References: <9fc959f40801100839wfe202ber43a01d551f418eeb@mail.gmail.com>
	<ca471dc20801100934g1dd1f247h128ba18c44569f42@mail.gmail.com>
	<9fc959f40801101350r4ff4dfcbsed6a40522f2b3d16@mail.gmail.com>
	<bbaeab100801101356j1f5d8ae4vf24190778adef20b@mail.gmail.com>
	<9fc959f40801101408o37dbe33ev7a4a0e6424ce239d@mail.gmail.com>
Message-ID: <bbaeab100801101422j5ecefafcy376becc055314e79@mail.gmail.com>

On Jan 10, 2008 2:08 PM, Joe Angell <joe.d.angell at gmail.com> wrote:
> Oh I see... forgive my ignorance but could you point me at some
> documentation or a project that uses the c AST as you mentioned?  Is
> that done through some part of the C-API?  I cannot find that in the
> documentation at the moment.
>

http://docs.python.org/dev/library/_ast.html


> Thank you,
>
> joe
>
>
> On Jan 10, 2008 2:56 PM, Brett Cannon <brett at python.org> wrote:
> > On Jan 10, 2008 1:50 PM, Joe Angell <joe.d.angell at gmail.com> wrote:
> > > How do you plan on letting third party tools utilize the new grammar?
> >
> > Don't need to plan anything; people are already using the AST that
> > Python's compiler uses since 2.5 came out.
> >
> > > Will they have to write their own parser then, or is there some kind
> > > of plugin architecture?
> >
> > No parser is required; Python's parser already handles the parsing.
> >
> > -Brett
> >
> >
> >
> > >
> > > Thanks,
> > >
> > > joe
> > >
> > >
> > > On Jan 10, 2008 10:34 AM, Guido van Rossum <guido at python.org> wrote:
> > > >
> > > > On Jan 10, 2008 8:39 AM, Joe Angell <joe.d.angell at gmail.com> wrote:
> > > > > My apologies if this has been asked before, but are there any plans to
> > > > > add the compiler module back in to py3k?  If so, any idea on a
> > > > > timeline?  If help is needed I may be able to put in some time on
> > > > > this.  I've already back ported some of the py3k grammar (function
> > > > > parameter annotations) to python 2.5.1 so I can use this with the
> > > > > compiler module, but I think it would be sweet to just use py3k
> > > > > directly.
> > > >
> > > > AFAIK there are no such plans; maintaining two versions of the
> > > > compiler (one in Python and one in C) has turned out to be a
> > > > nightmare, with the Python version always running behind and having
> > > > bugs because it wasn't used much for real work.
> > > >
> > > > --
> > > > --Guido van Rossum (home page: http://www.python.org/~guido/)
> > > >
> > > _______________________________________________
> > > Python-3000 mailing list
> > > Python-3000 at python.org
> > > http://mail.python.org/mailman/listinfo/python-3000
> > > Unsubscribe: http://mail.python.org/mailman/options/python-3000/brett%40python.org
> > >
> >
>

From g.brandl at gmx.net  Fri Jan 11 16:02:53 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 11 Jan 2008 16:02:53 +0100
Subject: [Python-3000] parser/compiler interface [was Re: compiler module]
In-Reply-To: <bbaeab100801101422j5ecefafcy376becc055314e79@mail.gmail.com>
References: <9fc959f40801100839wfe202ber43a01d551f418eeb@mail.gmail.com>	<ca471dc20801100934g1dd1f247h128ba18c44569f42@mail.gmail.com>	<9fc959f40801101350r4ff4dfcbsed6a40522f2b3d16@mail.gmail.com>	<bbaeab100801101356j1f5d8ae4vf24190778adef20b@mail.gmail.com>	<9fc959f40801101408o37dbe33ev7a4a0e6424ce239d@mail.gmail.com>
	<bbaeab100801101422j5ecefafcy376becc055314e79@mail.gmail.com>
Message-ID: <fm80fg$1gt$1@ger.gmane.org>

Brett Cannon schrieb:
> On Jan 10, 2008 2:08 PM, Joe Angell <joe.d.angell at gmail.com> wrote:
>> Oh I see... forgive my ignorance but could you point me at some
>> documentation or a project that uses the c AST as you mentioned?  Is
>> that done through some part of the C-API?  I cannot find that in the
>> documentation at the moment.
>>
> 
> http://docs.python.org/dev/library/_ast.html

That's also something I wanted to suggest for a cleanup:

Python's code parsing/compiling interface is currently very cluttered:
* you can parse things with parser.suite(), but not create an AST from
   the parse result
* you can create an AST with an undocumented flag to compile(), but not
   compile the resulting AST
* there are too many modules that have to do with parsing and compiling:
   token, symbol, parser, _ast, symtable

I'd suggest a single package to unify all this functionality and an API
that makes it easy to go from every compiling stage to the next, or to
the final code object.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From martin at v.loewis.de  Fri Jan 11 16:22:28 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 11 Jan 2008 16:22:28 +0100
Subject: [Python-3000] parser/compiler interface [was Re: compiler
	module]
In-Reply-To: <fm80fg$1gt$1@ger.gmane.org>
References: <9fc959f40801100839wfe202ber43a01d551f418eeb@mail.gmail.com>	<ca471dc20801100934g1dd1f247h128ba18c44569f42@mail.gmail.com>	<9fc959f40801101350r4ff4dfcbsed6a40522f2b3d16@mail.gmail.com>	<bbaeab100801101356j1f5d8ae4vf24190778adef20b@mail.gmail.com>	<9fc959f40801101408o37dbe33ev7a4a0e6424ce239d@mail.gmail.com>	<bbaeab100801101422j5ecefafcy376becc055314e79@mail.gmail.com>
	<fm80fg$1gt$1@ger.gmane.org>
Message-ID: <478789B4.4050901@v.loewis.de>

> * you can parse things with parser.suite(), but not create an AST from
>    the parse result
> * you can create an AST with an undocumented flag to compile(), but not
>    compile the resulting AST

The flag is documented, in the document referred to.

There are good reasons for why things are that way. In proceeding, it
is always important to remember these reasons.

> * there are too many modules that have to do with parsing and compiling:
>    token, symbol, parser, _ast, symtable

I fail to see that as a problem. token and symbol are just collections
of symbolic constants - what's wrong with that?

> I'd suggest a single package to unify all this functionality and an API
> that makes it easy to go from every compiling stage to the next, or to
> the final code object.

Unifying might be a good thing, but I don't see how it helps to solve
the problems you report (except for the last one, perhaps - but then,
you might end up with a single package with too many modules). To go
from one step to the next, you first have to implement the code to make
that possible. Only then it becomes relevant whether that code all
should live in a single package.

Regards,
Martin

From fdrake at acm.org  Fri Jan 11 17:06:53 2008
From: fdrake at acm.org (Fred Drake)
Date: Fri, 11 Jan 2008 11:06:53 -0500
Subject: [Python-3000] parser/compiler interface [was Re: compiler
	module]
In-Reply-To: <fm80fg$1gt$1@ger.gmane.org>
References: <9fc959f40801100839wfe202ber43a01d551f418eeb@mail.gmail.com>	<ca471dc20801100934g1dd1f247h128ba18c44569f42@mail.gmail.com>	<9fc959f40801101350r4ff4dfcbsed6a40522f2b3d16@mail.gmail.com>	<bbaeab100801101356j1f5d8ae4vf24190778adef20b@mail.gmail.com>	<9fc959f40801101408o37dbe33ev7a4a0e6424ce239d@mail.gmail.com>
	<bbaeab100801101422j5ecefafcy376becc055314e79@mail.gmail.com>
	<fm80fg$1gt$1@ger.gmane.org>
Message-ID: <29855921-E970-4154-AE05-09AFE5BAB81E@acm.org>

On Jan 11, 2008, at 10:02 AM, Georg Brandl wrote:
> I'd suggest a single package to unify all this functionality and an  
> API
> that makes it easy to go from every compiling stage to the next, or to
> the final code object.


+1


   -Fred

-- 
Fred Drake   <fdrake at acm.org>





From exarkun at divmod.com  Fri Jan 11 17:12:38 2008
From: exarkun at divmod.com (Jean-Paul Calderone)
Date: Fri, 11 Jan 2008 11:12:38 -0500
Subject: [Python-3000] parser/compiler interface [was Re: compiler
 module]
In-Reply-To: <fm80fg$1gt$1@ger.gmane.org>
Message-ID: <20080111161238.31425.873187738.divmod.quotient.3446@ohm>

On Fri, 11 Jan 2008 16:02:53 +0100, Georg Brandl <g.brandl at gmx.net> wrote:
>
>Python's code parsing/compiling interface is currently very cluttered:
>* you can parse things with parser.suite(), but not create an AST from
>   the parse result
>* you can create an AST with an undocumented flag to compile(), but not
>   compile the resulting AST
>* there are too many modules that have to do with parsing and compiling:
>   token, symbol, parser, _ast, symtable
>
>I'd suggest a single package to unify all this functionality and an API
>that makes it easy to go from every compiling stage to the next, or to
>the final code object.

+alot

Jean-Paul

From g.brandl at gmx.net  Fri Jan 11 17:50:57 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Fri, 11 Jan 2008 17:50:57 +0100
Subject: [Python-3000] parser/compiler interface [was Re: compiler
	module]
In-Reply-To: <478789B4.4050901@v.loewis.de>
References: <9fc959f40801100839wfe202ber43a01d551f418eeb@mail.gmail.com>	<ca471dc20801100934g1dd1f247h128ba18c44569f42@mail.gmail.com>	<9fc959f40801101350r4ff4dfcbsed6a40522f2b3d16@mail.gmail.com>	<bbaeab100801101356j1f5d8ae4vf24190778adef20b@mail.gmail.com>	<9fc959f40801101408o37dbe33ev7a4a0e6424ce239d@mail.gmail.com>	<bbaeab100801101422j5ecefafcy376becc055314e79@mail.gmail.com>	<fm80fg$1gt$1@ger.gmane.org>
	<478789B4.4050901@v.loewis.de>
Message-ID: <fm86q3$prl$1@ger.gmane.org>

Martin v. L?wis schrieb:
>> * you can parse things with parser.suite(), but not create an AST from
>>    the parse result
>> * you can create an AST with an undocumented flag to compile(), but not
>>    compile the resulting AST
> 
> The flag is documented, in the document referred to.
> 
> There are good reasons for why things are that way. In proceeding, it
> is always important to remember these reasons.

I think I am aware of the reasons, and I'm not accusing anyone that
things went that way. It's just that a programmer would want a different
situation, especially with the compiler package gone.

>> * there are too many modules that have to do with parsing and compiling:
>>    token, symbol, parser, _ast, symtable
> 
> I fail to see that as a problem. token and symbol are just collections
> of symbolic constants - what's wrong with that?

Nothing per se, but if we are grouping things for Py3k, this is a
strong candidate.

>> I'd suggest a single package to unify all this functionality and an API
>> that makes it easy to go from every compiling stage to the next, or to
>> the final code object.
> 
> Unifying might be a good thing, but I don't see how it helps to solve
> the problems you report (except for the last one, perhaps - but then,
> you might end up with a single package with too many modules). To go
> from one step to the next, you first have to implement the code to make
> that possible.  Only then it becomes relevant whether that code all
> should live in a single package.

Of course, I intend to implement the missing pieces, as well as the
unification.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From python at rcn.com  Fri Jan 11 20:13:21 2008
From: python at rcn.com (Raymond Hettinger)
Date: Fri, 11 Jan 2008 14:13:21 -0500 (EST)
Subject: [Python-3000] Useless methods in Queue module
Message-ID: <20080111141321.AEW71195@ms19.lnh.mail.rcn.net>

I proposed to remove three methods from the queue module, qsize(), empty(), and full().  These are not reliable.  The RightWay (tm) is to trap the Empty and Full exceptions or use the .join() approach.

Raymond


--- From the docs ---

Queue.qsize()?
    Return the approximate size of the queue. Because of multithreading semantics, this number is not reliable.

Queue.empty()?
    Return True if the queue is empty, False otherwise. Because of multithreading semantics, this is not reliable.

Queue.full()?
    Return True if the queue is full, False otherwise. Because of multithreading semantics, this is not reliable.

From aahz at pythoncraft.com  Fri Jan 11 20:16:01 2008
From: aahz at pythoncraft.com (Aahz)
Date: Fri, 11 Jan 2008 11:16:01 -0800
Subject: [Python-3000] Useless methods in Queue module
In-Reply-To: <20080111141321.AEW71195@ms19.lnh.mail.rcn.net>
References: <20080111141321.AEW71195@ms19.lnh.mail.rcn.net>
Message-ID: <20080111191601.GA15354@panix.com>

On Fri, Jan 11, 2008, Raymond Hettinger wrote:
>
> I proposed to remove three methods from the queue module, qsize(),
> empty(), and full().  These are not reliable.  The RightWay (tm) is to
> trap the Empty and Full exceptions or use the .join() approach.

Although I'm not going to advocate for retaining them, I see them as
mildly useful for logging purposes (especially qsize()).
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

Weinberg's Second Law: If builders built buildings the way programmers wrote 
programs, then the first woodpecker that came along would destroy civilization.

From mike.klaas at gmail.com  Fri Jan 11 20:32:03 2008
From: mike.klaas at gmail.com (Mike Klaas)
Date: Fri, 11 Jan 2008 11:32:03 -0800
Subject: [Python-3000] Useless methods in Queue module
In-Reply-To: <20080111141321.AEW71195@ms19.lnh.mail.rcn.net>
References: <20080111141321.AEW71195@ms19.lnh.mail.rcn.net>
Message-ID: <CCB40FC8-52CD-4B5C-918B-8CB607C32CD9@gmail.com>

On 11-Jan-08, at 11:13 AM, Raymond Hettinger wrote:

> I proposed to remove three methods from the queue module, qsize(),  
> empty(), and full().  These are not reliable.  The RightWay (tm) is  
> to trap the Empty and Full exceptions or use the .join() approach.

-1.  There are several "advisory" use cases for these methods where  
the reliability of the answer when .get/.put is not important.

For instance, as Aahz mentioned, being able to log the size of the  
queue is extremely useful (also, for unittesting).  Another, more  
substantive use case is as follows: I have an asyncore.dispatcher  
implementation that reads output from a Queue.Queue to put on the  
wire.  It is necessary here to implement .writable(), which should  
return True if there is a possibility that there is data to be  
written (so asyncore can poll for writability in the select() loop).   
"return not queue.empty()" does the trick.  Of course, when it comes  
time to write to the socket, it is still necessary to catch Empty  
exceptions, and do nothing in that case.

-Mike


From jbarham at gmail.com  Fri Jan 11 20:43:34 2008
From: jbarham at gmail.com (John Barham)
Date: Fri, 11 Jan 2008 11:43:34 -0800
Subject: [Python-3000] Useless methods in Queue module
In-Reply-To: <20080111191601.GA15354@panix.com>
References: <20080111141321.AEW71195@ms19.lnh.mail.rcn.net>
	<20080111191601.GA15354@panix.com>
Message-ID: <4f34febc0801111143i5aef5ebu5b61976055e64c9@mail.gmail.com>

On Jan 11, 2008 11:16 AM, Aahz <aahz at pythoncraft.com> wrote:

> On Fri, Jan 11, 2008, Raymond Hettinger wrote:
> >
> > I proposed to remove three methods from the queue module, qsize(),
> > empty(), and full().  These are not reliable.  The RightWay (tm) is to
> > trap the Empty and Full exceptions or use the .join() approach.
>
> Although I'm not going to advocate for retaining them, I see them as
> mildly useful for logging purposes (especially qsize()).

I've personally found qsize() to be useful, even essential, as if it
was over some threshold it indicated my program was deadlocked. ;)
Knowing when that condition occurred, and logging it, was crucial to
fixing the bug.  I didn't care so much about the exact value as that
it was far too big.  So qsize() IMHO should stay, empty() and full()
can go.

  John

From theller at ctypes.org  Fri Jan 11 21:01:31 2008
From: theller at ctypes.org (Thomas Heller)
Date: Fri, 11 Jan 2008 21:01:31 +0100
Subject: [Python-3000] Useless methods in Queue module
In-Reply-To: <20080111141321.AEW71195@ms19.lnh.mail.rcn.net>
References: <20080111141321.AEW71195@ms19.lnh.mail.rcn.net>
Message-ID: <fm8hun$1nf$1@ger.gmane.org>

Raymond Hettinger schrieb:
> I proposed to remove three methods from the queue module, qsize(),
> empty(), and full().  These are not reliable.  The RightWay (tm) is
> to trap the Empty and Full exceptions or use the .join() approach.

I am actively using empty().  This code example receives and processes requests
into a database, and does a commit when there is nothing to do.  It can
certainly be written in a different way, but I'm happy with it:

            while 1:
                if self.queue.empty():
                    database.commit()
                request = self.queue.get()
                database.process(request)


Please keep them.

Thomas


From tom at vector-seven.com  Sat Jan 12 01:05:40 2008
From: tom at vector-seven.com (Thomas Lee)
Date: Sat, 12 Jan 2008 11:05:40 +1100
Subject: [Python-3000] compiler module
In-Reply-To: <bbaeab100801101225k35c5676g47d5030e1d5998fa@mail.gmail.com>
References: <9fc959f40801100839wfe202ber43a01d551f418eeb@mail.gmail.com>
	<bbaeab100801101225k35c5676g47d5030e1d5998fa@mail.gmail.com>
Message-ID: <47880454.6010501@vector-seven.com>

Brett Cannon wrote:
> On Jan 10, 2008 8:39 AM, Joe Angell <joe.d.angell at gmail.com> wrote:
>   
>> My apologies if this has been asked before, but are there any plans to
>> add the compiler module back in to py3k?  If so, any idea on a
>> timeline?  If help is needed I may be able to put in some time on
>> this.  I've already back ported some of the py3k grammar (function
>> parameter annotations) to python 2.5.1 so I can use this with the
>> compiler module, but I think it would be sweet to just use py3k
>> directly.
>>     
>
> As Guido said, it is not going back. But we would appreciate help in
> writing a function that takes Python's actual AST represesntation (as
> returned by compile()) and generated the proper bytecode from it.
>
>   
I sent an e-mail regarding this earlier under another e-mail address but 
it doesn't seem to have gone through due to security restrictions on the 
Python mailing list:

I've been working on this for a while now at Neal's request and have a 
(mostly working) patch, it's probably long overdue that I ask for some help:

http://bugs.python.org/issue1810

Effectively, it seems to work great for simple statements but it 
segfaults when trying to compile a function. I wasn't able to figure out 
why - the crash seems to occur while the code is being executed.

I also uploaded code to reproduce the crash I'm seeing with the patch 
applied. Can anybody help me out with this?

Cheers,
Tom


From jim at zope.com  Sat Jan 12 18:25:00 2008
From: jim at zope.com (Jim Fulton)
Date: Sat, 12 Jan 2008 12:25:00 -0500
Subject: [Python-3000] inst_persistent_id
Message-ID: <A2A6D220-45A7-4C04-8D4E-CBBB919D55E1@zope.com>


Recently, I reviewed the documentation source for pickle and came  
across the following comment:

    BAW: Both pickle and cPickle support something called  
inst_persistent_id()
    which appears to give unknown types a second shot at producing a  
persistent
    id.  Since Jim Fulton can't remember why it was added or what it's  
for, I'm
    leaving it undocumented.

I couldn't remember this and decided to dig into it and realized that  
this was a very useful experimental feature I added way back when  
cPickle was in its infancy.  This is a fairly useful optimization that  
I never got around to evaluating.  (Yeah, I know.) It is a hook, like  
the persistent_id hook that is called with objects to determine if  
they should be pickled by persistent reference.  Unlike persistent_id,  
it isn't called for built-in types (really types for which pickle has  
specific handlers), like strings, numbers, lists, tuples and so on. It  
is only called for "instances" (types for which pickle doesn't have  
specific handlers).  This vastly reduces the number of calls to the  
hook.  Some tests with ZODB indicated significant improvements in  
pickling speed when a hook is used.

If there are no objections, I'll update the Python 2 documentation to  
describe this and add a test.  The comment above suggests that this  
hook is in pickle and cPickle.  It is in cPickle, but was removed from  
pickle.  I propose to add it back to pickle -- mainly for consistency  
with cPickle.  I'll need to double check how this interacts with the  
type dispatching in pickle protocol 2.

Any objections?

Jim

--
Jim Fulton
Zope Corporation



From alexandre at peadrop.com  Sun Jan 13 01:33:38 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Sat, 12 Jan 2008 19:33:38 -0500
Subject: [Python-3000] inst_persistent_id
In-Reply-To: <A2A6D220-45A7-4C04-8D4E-CBBB919D55E1@zope.com>
References: <A2A6D220-45A7-4C04-8D4E-CBBB919D55E1@zope.com>
Message-ID: <acd65fa20801121633l2ae5202j8a7d75d7933ce91e@mail.gmail.com>

On Jan 12, 2008 12:25 PM, Jim Fulton <jim at zope.com> wrote:
> If there are no objections, I'll update the Python 2 documentation to
> describe this and add a test.  The comment above suggests that this
> hook is in pickle and cPickle.  It is in cPickle, but was removed from
> pickle.  I propose to add it back to pickle -- mainly for consistency
> with cPickle.  I'll need to double check how this interacts with the
> type dispatching in pickle protocol 2.
>
> Any objections?
>

Well, in Python 3K, inst_persistent_id() won't be usable, since
PyInstance_Type was removed. Adding (actually supporting) this feature
in Python 2.x will make it slightly harder to port code. So, I think
it would probably best to leave it as it is right now -- i.e.,
undocumented and unsupported.

By the way, you might be interested to look at my work on pickle [1]
for Python 3K. As part of last year Summer of Code, I removed the
differences between the Python and C implementation of pickle, and
thus allowing the C version to be transparently used, instead of the
Python one, when it is available. Currently, I am polishing the code
for inclusion into the main branch. I also started to work on the next
version of the pickle protocol, that will make it more suitable for
Python 3K. If you are interested to help out, just send me an email
and I will explain you what needs to be done.


-- Alexandre

.. [1] http://peadrop.com/alex-py3k/?file/91639e5487dc/Modules/_picklemodule.c

From jyasskin at gmail.com  Sun Jan 13 02:09:00 2008
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Sat, 12 Jan 2008 17:09:00 -0800
Subject: [Python-3000] [Python-Dev] Rounding Decimals
In-Reply-To: <007601c850ca$7f2ab3e0$6800a8c0@RaymondLaptop1>
References: <5d44f72f0801051857i3b13f1b0q8a9e485831dcd603@mail.gmail.com>
	<003101c85011$e1572530$6800a8c0@RaymondLaptop1>
	<5d44f72f0801060121l39c4d2a0jfdea69f644bc1822@mail.gmail.com>
	<5d44f72f0801061526x788b0a46lbbc17ec5dde44ceb@mail.gmail.com>
	<007601c850ca$7f2ab3e0$6800a8c0@RaymondLaptop1>
Message-ID: <5d44f72f0801121709x7c25efbcvfa13e29864b5b577@mail.gmail.com>

During the discussion about the new Rational implementation
(http://bugs.python.org/issue1682), Guido and Raymond decided that
Decimal should not implement the new Real ABC from PEP 3141. So I've
closed http://bugs.python.org/issue1623 and won't be pursuing any of
the extra rounding methods mentioned on this thread.

-- 
Namast?,
Jeffrey Yasskin

From guido at python.org  Sun Jan 13 05:21:40 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 12 Jan 2008 20:21:40 -0800
Subject: [Python-3000] [Python-Dev] Rounding Decimals
In-Reply-To: <5d44f72f0801121709x7c25efbcvfa13e29864b5b577@mail.gmail.com>
References: <5d44f72f0801051857i3b13f1b0q8a9e485831dcd603@mail.gmail.com>
	<003101c85011$e1572530$6800a8c0@RaymondLaptop1>
	<5d44f72f0801060121l39c4d2a0jfdea69f644bc1822@mail.gmail.com>
	<5d44f72f0801061526x788b0a46lbbc17ec5dde44ceb@mail.gmail.com>
	<007601c850ca$7f2ab3e0$6800a8c0@RaymondLaptop1>
	<5d44f72f0801121709x7c25efbcvfa13e29864b5b577@mail.gmail.com>
Message-ID: <ca471dc20801122021p38570b6s8fecf48e0ca37db6@mail.gmail.com>

On Jan 12, 2008 5:09 PM, Jeffrey Yasskin <jyasskin at gmail.com> wrote:
> During the discussion about the new Rational implementation
> (http://bugs.python.org/issue1682), Guido and Raymond decided that
> Decimal should not implement the new Real ABC from PEP 3141. So I've
> closed http://bugs.python.org/issue1623 and won't be pursuing any of
> the extra rounding methods mentioned on this thread.

Well, I didn't really decide anything. I suggested that if the
developers of Decimal preferred it, it might be better if Decimal did
not implement the Real ABC, and Raymond said he indeed preferred it.

Since this reduces the usefulness of numeric.Real, I'm somewhat
disappointed in this outcome (as I imagine you are). However, Decimal
has very little of my own sweat in it, and a lot of Raymond, Facundo
(and others, including Mark), and the ABC thing is still somewhat
experimental, so it wouldn't make sense for me to impose my ideas onto
Decimal unilaterally, and I'm sure Raymond etc. have their reasons.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From aahz at pythoncraft.com  Sun Jan 13 05:58:02 2008
From: aahz at pythoncraft.com (Aahz)
Date: Sat, 12 Jan 2008 20:58:02 -0800
Subject: [Python-3000] OSCON 2008 Call for Proposals
Message-ID: <20080113045802.GA19791@panix.com>

The O'Reilly Open Source Convention (OSCON) is accepting proposals for
tutorials and presentations.  The submission period ends Feb 4.

OSCON 2008 will be in Portland, Oregon July 21-25.  For more information
and to submit a proposal, see

http://conferences.oreilly.com/oscon/
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

Weinberg's Second Law: If builders built buildings the way programmers wrote 
programs, then the first woodpecker that came along would destroy civilization.

From tom at vector-seven.com  Fri Jan 11 05:38:13 2008
From: tom at vector-seven.com (Thomas Lee)
Date: Fri, 11 Jan 2008 15:38:13 +1100
Subject: [Python-3000] compiler module
In-Reply-To: <bbaeab100801101225k35c5676g47d5030e1d5998fa@mail.gmail.com>
References: <9fc959f40801100839wfe202ber43a01d551f418eeb@mail.gmail.com>
	<bbaeab100801101225k35c5676g47d5030e1d5998fa@mail.gmail.com>
Message-ID: <4786F2B5.2040402@vector-seven.com>

Brett Cannon wrote:
> On Jan 10, 2008 8:39 AM, Joe Angell <joe.d.angell at gmail.com> wrote:
>   
>> My apologies if this has been asked before, but are there any plans to
>> add the compiler module back in to py3k?  If so, any idea on a
>> timeline?  If help is needed I may be able to put in some time on
>> this.  I've already back ported some of the py3k grammar (function
>> parameter annotations) to python 2.5.1 so I can use this with the
>> compiler module, but I think it would be sweet to just use py3k
>> directly.
>>     
>
> As Guido said, it is not going back. But we would appreciate help in
> writing a function that takes Python's actual AST represesntation (as
> returned by compile()) and generated the proper bytecode from it.
>
>   
Sorry, I should have been paying more attention to this thread:

I started on this a few months back at Neal's recommendation. I have a 
patch that is mostly working, but seems to be crashing out for a 
particular case (trying to compile functions, IIRC). I was never quite 
able to work out where it was going wrong. I'll upload my current patch 
to the tracker later tonight - I'd love some help trying to figure out 
why it's crashing out.

Using the patch it's possible to convert between the PyObject AST 
representation and the AST representation used internally by the 
compiler (thus it's possible to compile() an AST down to bytecode).

The patch is against current HEAD, not Py3k, but it should be a good 
starting point.

Cheers,
Tom


From offby1 at blarg.net  Sat Jan 12 18:00:39 2008
From: offby1 at blarg.net (Eric Hanchrow)
Date: Sat, 12 Jan 2008 09:00:39 -0800
Subject: [Python-3000] Failure building docs of py3k r30a2
Message-ID: <87bq7rvv0o.fsf@offby1.atm01.sea.blarg.net>

On Ubuntu 7.10 "Gutsy Gibbon":

Unfortunately I don't really know python, so am unable to debug this.

I checked out by doing

        svn co http://svn.python.org/projects/python/tags/r30a2 py3k

Then I built python itself with no apparent trouble.  But building the docs fails:

    make -k html
    mkdir -p build/html build/doctrees
    python2.5 tools/sphinx-build.py -bhtml -dbuild/doctrees  . build/html
    1mtrying to load pickled env...;49;00m done
    1mbuilding [html]:;49;00m targets for 0 source files that are out of date
    1mreading, updating environment:;49;00m 0 added, 0 changed, 0 removed 1m;49;00m
    1mcreating index...;49;00m
    1mwriting output...;49;00m
    ;01mcontents.rst;49;00m
    1mfinishing...;49;00m
    1mwriting additional files...;49;00m
    Traceback (most recent call last):
      File "tools/sphinx-build.py", line 23, in <module>
        sys.exit(main(sys.argv))
      File "/usr/local/src/py3k/Doc/tools/sphinx/__init__.py", line 145, in main
        builderobj.build_update()
      File "/usr/local/src/py3k/Doc/tools/sphinx/builder.py", line 208, in build_update
        'out of date' % len(to_build))
      File "/usr/local/src/py3k/Doc/tools/sphinx/builder.py", line 244, in build
        self.finish()
      File "/usr/local/src/py3k/Doc/tools/sphinx/builder.py", line 459, in finish
        download_base_url = self.config['html_download_base_url'],
    KeyError: 'html_download_base_url'
    make: *** [build] Error 1
    make: Target `html' not remade because of errors.

    Compilation exited abnormally with code 2 at Sat Jan 12 08:46:15

-- 
When there's not many discoveries being made, there's nothing left to
do all day but witch-hunt the heretics.
        -- Eliezer Yudkowsky

From g.brandl at gmx.net  Sun Jan 13 18:21:00 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Sun, 13 Jan 2008 17:21:00 +0000
Subject: [Python-3000] Failure building docs of py3k r30a2
In-Reply-To: <87bq7rvv0o.fsf@offby1.atm01.sea.blarg.net>
References: <87bq7rvv0o.fsf@offby1.atm01.sea.blarg.net>
Message-ID: <fmdh9s$oup$1@ger.gmane.org>

Eric Hanchrow schrieb:
> On Ubuntu 7.10 "Gutsy Gibbon":
> 
> Unfortunately I don't really know python, so am unable to debug this.
> 
> I checked out by doing
> 
>         svn co http://svn.python.org/projects/python/tags/r30a2 py3k
> 
> Then I built python itself with no apparent trouble.  But building the docs fails:

[traceback]

I worked on the toolchain since 3.0a2 came out -- the specified config value is
not present yet in 3.0a2's config file.

I have a major update to the doctools in my local sandbox, before I check it in
I'll make sure it works with 3.0a2. As a workaround, you can either use the
3.0 branch HEAD docs, or add "html_download_base_url = ''" to Doc/conf.py.

cheers,
Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From charles.merriam at gmail.com  Sun Jan 13 18:37:05 2008
From: charles.merriam at gmail.com (Charles Merriam)
Date: Sun, 13 Jan 2008 09:37:05 -0800
Subject: [Python-3000] PEP 3115: Actual use cases for odd metaclasses?
	Alternate syntax.
In-Reply-To: <20071223050830.DBD933A408B@sparrow.telecommunity.com>
References: <b8c6f6c40712212230r3a7b60bdu6b48cc66a4dec318@mail.gmail.com>
	<20071222140828.C1FFB3A40F7@sparrow.telecommunity.com>
	<b8c6f6c40712222004p6f9f0469p71304664bcba6b71@mail.gmail.com>
	<20071223050830.DBD933A408B@sparrow.telecommunity.com>
Message-ID: <b8c6f6c40801130937o39f0f604rd897215747fa931f@mail.gmail.com>

Well, I'm explicitly dropping this.   So far no one has pointed out
any use cases that are not equivalent to intercepting an array of the
namespace in the __init__() of a  subclass of type, then calling
type's __init__() on the modified namespace.   Still, I do get a level
of snarky insults that leads me to believe this would involve dealing
with people who like the metaclass definition syntax to be hairy.

Good luck!

Charles

From charles.merriam at gmail.com  Sun Jan 13 18:40:56 2008
From: charles.merriam at gmail.com (Charles Merriam)
Date: Sun, 13 Jan 2008 09:40:56 -0800
Subject: [Python-3000] PEP 3115: Actual use cases for odd metaclasses?
	Alternate syntax.
In-Reply-To: <b8c6f6c40801130937o39f0f604rd897215747fa931f@mail.gmail.com>
References: <b8c6f6c40712212230r3a7b60bdu6b48cc66a4dec318@mail.gmail.com>
	<20071222140828.C1FFB3A40F7@sparrow.telecommunity.com>
	<b8c6f6c40712222004p6f9f0469p71304664bcba6b71@mail.gmail.com>
	<20071223050830.DBD933A408B@sparrow.telecommunity.com>
	<b8c6f6c40801130937o39f0f604rd897215747fa931f@mail.gmail.com>
Message-ID: <b8c6f6c40801130940p33c18837g5e86cc3dc769b390@mail.gmail.com>

sorry, I meant __new__() not __init__().  For this crowd, I thought
I'd put in the obvious correction. :)


On Jan 13, 2008 9:37 AM, Charles Merriam <charles.merriam at gmail.com> wrote:
> Well, I'm explicitly dropping this.   So far no one has pointed out
> any use cases that are not equivalent to intercepting an array of the
> namespace in the __init__() of a  subclass of type, then calling
> type's __init__() on the modified namespace.   Still, I do get a level
> of snarky insults that leads me to believe this would involve dealing
> with people who like the metaclass definition syntax to be hairy.
>
> Good luck!
>
> Charles
>

From michele.simionato at gmail.com  Sun Jan 13 18:58:57 2008
From: michele.simionato at gmail.com (Michele Simionato)
Date: Sun, 13 Jan 2008 18:58:57 +0100
Subject: [Python-3000] PEP 3115: Actual use cases for odd metaclasses?
	Alternate syntax.
In-Reply-To: <b8c6f6c40801130940p33c18837g5e86cc3dc769b390@mail.gmail.com>
References: <b8c6f6c40712212230r3a7b60bdu6b48cc66a4dec318@mail.gmail.com>
	<20071222140828.C1FFB3A40F7@sparrow.telecommunity.com>
	<b8c6f6c40712222004p6f9f0469p71304664bcba6b71@mail.gmail.com>
	<20071223050830.DBD933A408B@sparrow.telecommunity.com>
	<b8c6f6c40801130937o39f0f604rd897215747fa931f@mail.gmail.com>
	<b8c6f6c40801130940p33c18837g5e86cc3dc769b390@mail.gmail.com>
Message-ID: <4edc17eb0801130958m4c85c023oab0bf7a07965545b@mail.gmail.com>

> On Jan 13, 2008 9:37 AM, Charles Merriam <charles.merriam at gmail.com> wrote:
> > Well, I'm explicitly dropping this.   So far no one has pointed out
> > any use cases that are not equivalent to intercepting an array of the
> > namespace in the __init__() of a  subclass of type, then calling
> > type's __init__() on the modified namespace.

There are many use cases. For instance in
http://stacktrace.it/articoli/2008/01/metaclassi-python-3000/
I discuss operator overloading on records. The paper is in Italian,
but you can  just look at
the code and at the examples.

    Michele Simionato

From charles.merriam at gmail.com  Sun Jan 13 19:55:00 2008
From: charles.merriam at gmail.com (Charles Merriam)
Date: Sun, 13 Jan 2008 10:55:00 -0800
Subject: [Python-3000] PEP 3115: Actual use cases for odd metaclasses?
	Alternate syntax.
In-Reply-To: <4edc17eb0801130958m4c85c023oab0bf7a07965545b@mail.gmail.com>
References: <b8c6f6c40712212230r3a7b60bdu6b48cc66a4dec318@mail.gmail.com>
	<20071222140828.C1FFB3A40F7@sparrow.telecommunity.com>
	<b8c6f6c40712222004p6f9f0469p71304664bcba6b71@mail.gmail.com>
	<20071223050830.DBD933A408B@sparrow.telecommunity.com>
	<b8c6f6c40801130937o39f0f604rd897215747fa931f@mail.gmail.com>
	<b8c6f6c40801130940p33c18837g5e86cc3dc769b390@mail.gmail.com>
	<4edc17eb0801130958m4c85c023oab0bf7a07965545b@mail.gmail.com>
Message-ID: <b8c6f6c40801131055m5806130dp9eff35d170c0660a@mail.gmail.com>

Sorry, if my Italian is non-existent.  Code is code however.

Could you verify that the article covers:

1.   Complaints that __metaclass__ will be silently ignored in PEP 3115.

My understanding from the last line of the Rational section is that
this is undecided.

2.  Complaints that, without _prepare_, the __new__ operation will not
know which order the items were declared, and that everyone will write
ordered hash implementations.

Though I propose that an array exist for the time analogous to the
current __new__ redirect.  One can look at the array as a hash with
very poor performance characteristics.  This should be acceptable for
the analogue.   After type.__init__() is actually called, only a hash
would survive.

3.  The metaclass can add additional class functions to support class
addition for on the fly creation of mixed in classes.

Though one could simply add these functions into the namespace during
the __new__ analogue.  My understanding is that type.__new__() will
not add new implementations if they exist in the namespace.  I may
well be wrong about type.__new__(), so please verify this yourself.

You have a legitimate counter-argument that grouping the
implementations of __add__ in the metaclass is cleaner than having
them stand alone and be referenced in.   Is this your argument?

Lost,

Charles






On Jan 13, 2008 9:58 AM, Michele Simionato <michele.simionato at gmail.com> wrote:
> > On Jan 13, 2008 9:37 AM, Charles Merriam <charles.merriam at gmail.com> wrote:
> > > Well, I'm explicitly dropping this.   So far no one has pointed out
> > > any use cases that are not equivalent to intercepting an array of the
> > > namespace in the __init__() of a  subclass of type, then calling
> > > type's __init__() on the modified namespace.
>
> There are many use cases. For instance in
> http://stacktrace.it/articoli/2008/01/metaclassi-python-3000/
> I discuss operator overloading on records. The paper is in Italian,
> but you can  just look at
> the code and at the examples.
>
>     Michele Simionato
>

From pje at telecommunity.com  Sun Jan 13 21:15:20 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 13 Jan 2008 15:15:20 -0500
Subject: [Python-3000] PEP 3115: Actual use cases for odd metaclasses?
 Alternate syntax.
In-Reply-To: <b8c6f6c40801130937o39f0f604rd897215747fa931f@mail.gmail.co
 m>
References: <b8c6f6c40712212230r3a7b60bdu6b48cc66a4dec318@mail.gmail.com>
	<20071222140828.C1FFB3A40F7@sparrow.telecommunity.com>
	<b8c6f6c40712222004p6f9f0469p71304664bcba6b71@mail.gmail.com>
	<20071223050830.DBD933A408B@sparrow.telecommunity.com>
	<b8c6f6c40801130937o39f0f604rd897215747fa931f@mail.gmail.com>
Message-ID: <20080113201522.4231C3A4077@sparrow.telecommunity.com>

At 09:37 AM 1/13/2008 -0800, Charles Merriam wrote:
>Well, I'm explicitly dropping this.   So far no one has pointed out
>any use cases that are not equivalent to intercepting an array of the
>namespace in the __init__() of a  subclass of type, then calling
>type's __init__() on the modified namespace.

As I've previously mentioned, see PEP 3115, "Rationale", paragraph 6 
for at least one such use case.

Also, you've still not shown how your proposal can support *any* 
metaclass use case that involves metaclass methods other than 
__init__ or __new__.  Without that, your previous proposal was dead 
in the water, with or without other use cases.


From pje at telecommunity.com  Sun Jan 13 21:27:51 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 13 Jan 2008 15:27:51 -0500
Subject: [Python-3000] PEP 3115: Actual use cases for odd metaclasses?
 Alternate syntax.
In-Reply-To: <b8c6f6c40801131055m5806130dp9eff35d170c0660a@mail.gmail.co
 m>
References: <b8c6f6c40712212230r3a7b60bdu6b48cc66a4dec318@mail.gmail.com>
	<20071222140828.C1FFB3A40F7@sparrow.telecommunity.com>
	<b8c6f6c40712222004p6f9f0469p71304664bcba6b71@mail.gmail.com>
	<20071223050830.DBD933A408B@sparrow.telecommunity.com>
	<b8c6f6c40801130937o39f0f604rd897215747fa931f@mail.gmail.com>
	<b8c6f6c40801130940p33c18837g5e86cc3dc769b390@mail.gmail.com>
	<4edc17eb0801130958m4c85c023oab0bf7a07965545b@mail.gmail.com>
	<b8c6f6c40801131055m5806130dp9eff35d170c0660a@mail.gmail.com>
Message-ID: <20080113202752.EE5923A4077@sparrow.telecommunity.com>

At 10:55 AM 1/13/2008 -0800, Charles Merriam wrote:
>You have a legitimate counter-argument that grouping the
>implementations of __add__ in the metaclass is cleaner than having
>them stand alone and be referenced in.

You've misunderstood Michele's example code.  __add__ in the 
metaclass lets you add two *record classes* together, not two records.

Your proposal didn't support this behavior, nor *any other use case* 
for actually having a metaclass (as opposed to class decoration).

You might find this metaclass tutorial enlightening, especially the 
section I've linked to:

http://www.ibm.com/developerworks/linux/library/l-pymeta2/#h4

Understanding this will show you why your original proposal is 
completely broken for non-decorator use cases.


From charles.merriam at gmail.com  Sun Jan 13 21:35:57 2008
From: charles.merriam at gmail.com (Charles Merriam)
Date: Sun, 13 Jan 2008 12:35:57 -0800
Subject: [Python-3000] PEP 3115: Actual use cases for odd metaclasses?
	Alternate syntax.
In-Reply-To: <20080113202752.EE5923A4077@sparrow.telecommunity.com>
References: <b8c6f6c40712212230r3a7b60bdu6b48cc66a4dec318@mail.gmail.com>
	<20071222140828.C1FFB3A40F7@sparrow.telecommunity.com>
	<b8c6f6c40712222004p6f9f0469p71304664bcba6b71@mail.gmail.com>
	<20071223050830.DBD933A408B@sparrow.telecommunity.com>
	<b8c6f6c40801130937o39f0f604rd897215747fa931f@mail.gmail.com>
	<b8c6f6c40801130940p33c18837g5e86cc3dc769b390@mail.gmail.com>
	<4edc17eb0801130958m4c85c023oab0bf7a07965545b@mail.gmail.com>
	<b8c6f6c40801131055m5806130dp9eff35d170c0660a@mail.gmail.com>
	<20080113202752.EE5923A4077@sparrow.telecommunity.com>
Message-ID: <b8c6f6c40801131235k3baf1413lf910cfe64875d490@mail.gmail.com>

Sigh..  Yes mix-ins are about mixing classes.  No I didn't miss it.
No I'm not explaining it.  You can type 100 words to my one and not
add much.  I'm dropping metaclass changes.

Have a nice day,

Charles
On Jan 13, 2008 12:27 PM, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 10:55 AM 1/13/2008 -0800, Charles Merriam wrote:
> >You have a legitimate counter-argument that grouping the
> >implementations of __add__ in the metaclass is cleaner than having
> >them stand alone and be referenced in.
>
> You've misunderstood Michele's example code.  __add__ in the
> metaclass lets you add two *record classes* together, not two records.
>
> Your proposal didn't support this behavior, nor *any other use case*
> for actually having a metaclass (as opposed to class decoration).
>
> You might find this metaclass tutorial enlightening, especially the
> section I've linked to:
>
> http://www.ibm.com/developerworks/linux/library/l-pymeta2/#h4
>
> Understanding this will show you why your original proposal is
> completely broken for non-decorator use cases.
>
>

From pje at telecommunity.com  Sun Jan 13 22:49:45 2008
From: pje at telecommunity.com (Phillip J. Eby)
Date: Sun, 13 Jan 2008 16:49:45 -0500
Subject: [Python-3000] PEP 3115: Actual use cases for odd metaclasses?
 Alternate syntax.
In-Reply-To: <b8c6f6c40801131235k3baf1413lf910cfe64875d490@mail.gmail.co
 m>
References: <b8c6f6c40712212230r3a7b60bdu6b48cc66a4dec318@mail.gmail.com>
	<20071222140828.C1FFB3A40F7@sparrow.telecommunity.com>
	<b8c6f6c40712222004p6f9f0469p71304664bcba6b71@mail.gmail.com>
	<20071223050830.DBD933A408B@sparrow.telecommunity.com>
	<b8c6f6c40801130937o39f0f604rd897215747fa931f@mail.gmail.com>
	<b8c6f6c40801130940p33c18837g5e86cc3dc769b390@mail.gmail.com>
	<4edc17eb0801130958m4c85c023oab0bf7a07965545b@mail.gmail.com>
	<b8c6f6c40801131055m5806130dp9eff35d170c0660a@mail.gmail.com>
	<20080113202752.EE5923A4077@sparrow.telecommunity.com>
	<b8c6f6c40801131235k3baf1413lf910cfe64875d490@mail.gmail.com>
Message-ID: <20080113215003.886833A4077@sparrow.telecommunity.com>

At 12:35 PM 1/13/2008 -0800, Charles Merriam wrote:
>Sigh..  Yes mix-ins are about mixing classes.  No I didn't miss it.

Yes, you did miss it, and are still missing it.

Otherwise you'd know why your original proposal was never viable in 
the first place, and why mixins have nothing to do with it.


From jyasskin at gmail.com  Mon Jan 14 00:12:56 2008
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Sun, 13 Jan 2008 15:12:56 -0800
Subject: [Python-3000] [Python-Dev] Rounding Decimals
In-Reply-To: <ca471dc20801122021p38570b6s8fecf48e0ca37db6@mail.gmail.com>
References: <5d44f72f0801051857i3b13f1b0q8a9e485831dcd603@mail.gmail.com>
	<003101c85011$e1572530$6800a8c0@RaymondLaptop1>
	<5d44f72f0801060121l39c4d2a0jfdea69f644bc1822@mail.gmail.com>
	<5d44f72f0801061526x788b0a46lbbc17ec5dde44ceb@mail.gmail.com>
	<007601c850ca$7f2ab3e0$6800a8c0@RaymondLaptop1>
	<5d44f72f0801121709x7c25efbcvfa13e29864b5b577@mail.gmail.com>
	<ca471dc20801122021p38570b6s8fecf48e0ca37db6@mail.gmail.com>
Message-ID: <5d44f72f0801131512r7273c014ta4cf2583b8f73f6f@mail.gmail.com>

On Jan 12, 2008 8:21 PM, Guido van Rossum <guido at python.org> wrote:
>
> On Jan 12, 2008 5:09 PM, Jeffrey Yasskin <jyasskin at gmail.com> wrote:
> > During the discussion about the new Rational implementation
> > (http://bugs.python.org/issue1682), Guido and Raymond decided that
> > Decimal should not implement the new Real ABC from PEP 3141. So I've
> > closed http://bugs.python.org/issue1623 and won't be pursuing any of
> > the extra rounding methods mentioned on this thread.
>
> Well, I didn't really decide anything. I suggested that if the
> developers of Decimal preferred it, it might be better if Decimal did
> not implement the Real ABC, and Raymond said he indeed preferred it.
>
> Since this reduces the usefulness of numeric.Real, I'm somewhat
> disappointed in this outcome (as I imagine you are). However, Decimal
> has very little of my own sweat in it, and a lot of Raymond, Facundo
> (and others, including Mark), and the ABC thing is still somewhat
> experimental, so it wouldn't make sense for me to impose my ideas onto
> Decimal unilaterally, and I'm sure Raymond etc. have their reasons.

Sorry for misrepresenting you. I am a little disappointed, but if
we're right that numbers.Real is a good idea, then users will ask for
Decimal to implement it, and the Decimal developers can change their
minds in 3.1. Since I'm not one of those users, I'm not the right
person to argue for this anyway. :)

-- 
Namast?,
Jeffrey Yasskin

From adlaiff6 at gmail.com  Mon Jan 14 00:41:50 2008
From: adlaiff6 at gmail.com (Leif Walsh)
Date: Sun, 13 Jan 2008 18:41:50 -0500
Subject: [Python-3000] [Python-Dev] Rounding Decimals
In-Reply-To: <5d44f72f0801131512r7273c014ta4cf2583b8f73f6f@mail.gmail.com>
References: <5d44f72f0801051857i3b13f1b0q8a9e485831dcd603@mail.gmail.com>
	<003101c85011$e1572530$6800a8c0@RaymondLaptop1>
	<5d44f72f0801060121l39c4d2a0jfdea69f644bc1822@mail.gmail.com>
	<5d44f72f0801061526x788b0a46lbbc17ec5dde44ceb@mail.gmail.com>
	<007601c850ca$7f2ab3e0$6800a8c0@RaymondLaptop1>
	<5d44f72f0801121709x7c25efbcvfa13e29864b5b577@mail.gmail.com>
	<ca471dc20801122021p38570b6s8fecf48e0ca37db6@mail.gmail.com>
	<5d44f72f0801131512r7273c014ta4cf2583b8f73f6f@mail.gmail.com>
Message-ID: <11b6d2f60801131541t5c0853f1l39da084a733c03a@mail.gmail.com>

On Jan 13, 2008 6:12 PM, Jeffrey Yasskin <jyasskin at gmail.com> wrote:
> On Jan 12, 2008 8:21 PM, Guido van Rossum <guido at python.org> wrote:
> >
> > On Jan 12, 2008 5:09 PM, Jeffrey Yasskin <jyasskin at gmail.com> wrote:
> > > During the discussion about the new Rational implementation
> > > (http://bugs.python.org/issue1682), Guido and Raymond decided that
> > > Decimal should not implement the new Real ABC from PEP 3141. So I've
> > > closed http://bugs.python.org/issue1623 and won't be pursuing any of
> > > the extra rounding methods mentioned on this thread.
> >
> > Well, I didn't really decide anything. I suggested that if the
> > developers of Decimal preferred it, it might be better if Decimal did
> > not implement the Real ABC, and Raymond said he indeed preferred it.
> >
> > Since this reduces the usefulness of numeric.Real, I'm somewhat
> > disappointed in this outcome (as I imagine you are). However, Decimal
> > has very little of my own sweat in it, and a lot of Raymond, Facundo
> > (and others, including Mark), and the ABC thing is still somewhat
> > experimental, so it wouldn't make sense for me to impose my ideas onto
> > Decimal unilaterally, and I'm sure Raymond etc. have their reasons.
>
> Sorry for misrepresenting you. I am a little disappointed, but if
> we're right that numbers.Real is a good idea, then users will ask for
> Decimal to implement it, and the Decimal developers can change their
> minds in 3.1. Since I'm not one of those users, I'm not the right
> person to argue for this anyway. :)

I haven't been watching the python-dev list for very long, so maybe
this has already been discussed ad nauseam (in which case, sorry),
but, from the devil's advocate-ish mathematics side of things, unless
numbers.Decimal is planned to be implemented with infinite precision
(which I doubt, but could not confirm with an admittedly small amount
of research), shouldn't it implement numbers.Rational instead?  Was
this ever discussed, or was it just assumed that numbers.Real was the
right decision?

Cheers,
Leif

From jyasskin at gmail.com  Mon Jan 14 01:26:34 2008
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Sun, 13 Jan 2008 16:26:34 -0800
Subject: [Python-3000] [Python-Dev] Rounding Decimals
In-Reply-To: <11b6d2f60801131541t5c0853f1l39da084a733c03a@mail.gmail.com>
References: <5d44f72f0801051857i3b13f1b0q8a9e485831dcd603@mail.gmail.com>
	<003101c85011$e1572530$6800a8c0@RaymondLaptop1>
	<5d44f72f0801060121l39c4d2a0jfdea69f644bc1822@mail.gmail.com>
	<5d44f72f0801061526x788b0a46lbbc17ec5dde44ceb@mail.gmail.com>
	<007601c850ca$7f2ab3e0$6800a8c0@RaymondLaptop1>
	<5d44f72f0801121709x7c25efbcvfa13e29864b5b577@mail.gmail.com>
	<ca471dc20801122021p38570b6s8fecf48e0ca37db6@mail.gmail.com>
	<5d44f72f0801131512r7273c014ta4cf2583b8f73f6f@mail.gmail.com>
	<11b6d2f60801131541t5c0853f1l39da084a733c03a@mail.gmail.com>
Message-ID: <5d44f72f0801131626w780aac5axd505ce1335961377@mail.gmail.com>

On Jan 13, 2008 3:41 PM, Leif Walsh <adlaiff6 at gmail.com> wrote:
> I haven't been watching the python-dev list for very long, so maybe
> this has already been discussed ad nauseam (in which case, sorry),
> but, from the devil's advocate-ish mathematics side of things, unless
> numbers.Decimal is planned to be implemented with infinite precision
> (which I doubt, but could not confirm with an admittedly small amount
> of research), shouldn't it implement numbers.Rational instead?  Was
> this ever discussed, or was it just assumed that numbers.Real was the
> right decision?

Guido mentioned the possibility briefly at
http://mail.python.org/pipermail/python-3000/2007-April/007015.html
("One could argue that float and Decimal are <:Q, but I'm not sure if
that makes things better pragmatically") but never really discussed as
far as I can find (although I did think about it :). I prefer having
float not implement Rational (Decimal's off the table) because
developers usually think of them as approximations to arbitrary,
possibly-irrational, real numbers, rather than as rational numbers
with some odd constraints on their denominators. That is, to me, the
ABCs a type implements are more about how developers should think
about the type than the implementation of the type.

[ A new thread is probably appropriate if anyone wants to discuss the
philosophy, but I probably won't participate... ]

-- 
Namast?,
Jeffrey Yasskin

From adlaiff6 at gmail.com  Mon Jan 14 01:37:46 2008
From: adlaiff6 at gmail.com (Leif Walsh)
Date: Sun, 13 Jan 2008 19:37:46 -0500
Subject: [Python-3000] [Python-Dev] Rounding Decimals
In-Reply-To: <5d44f72f0801131626w780aac5axd505ce1335961377@mail.gmail.com>
References: <5d44f72f0801051857i3b13f1b0q8a9e485831dcd603@mail.gmail.com>
	<003101c85011$e1572530$6800a8c0@RaymondLaptop1>
	<5d44f72f0801060121l39c4d2a0jfdea69f644bc1822@mail.gmail.com>
	<5d44f72f0801061526x788b0a46lbbc17ec5dde44ceb@mail.gmail.com>
	<007601c850ca$7f2ab3e0$6800a8c0@RaymondLaptop1>
	<5d44f72f0801121709x7c25efbcvfa13e29864b5b577@mail.gmail.com>
	<ca471dc20801122021p38570b6s8fecf48e0ca37db6@mail.gmail.com>
	<5d44f72f0801131512r7273c014ta4cf2583b8f73f6f@mail.gmail.com>
	<11b6d2f60801131541t5c0853f1l39da084a733c03a@mail.gmail.com>
	<5d44f72f0801131626w780aac5axd505ce1335961377@mail.gmail.com>
Message-ID: <11b6d2f60801131637n50ed3b31s5fe151c66b5f23b6@mail.gmail.com>

On Jan 13, 2008 7:26 PM, Jeffrey Yasskin <jyasskin at gmail.com> wrote:
> Guido mentioned the possibility briefly at
> http://mail.python.org/pipermail/python-3000/2007-April/007015.html
> ("One could argue that float and Decimal are <:Q, but I'm not sure if
> that makes things better pragmatically") but never really discussed as
> far as I can find (although I did think about it :).

Well, if nothing else, I'm certainly satisfied that my concerns about
accuracy are being addressed.  I will have to go read more of that
discussion.

> I prefer having
> float not implement Rational (Decimal's off the table) because
> developers usually think of them as approximations to arbitrary,
> possibly-irrational, real numbers, rather than as rational numbers
> with some odd constraints on their denominators. That is, to me, the
> ABCs a type implements are more about how developers should think
> about the type than the implementation of the type.

I see where you're coming from.  My personal stance is that developers
_shouldn't_ think that way, but I know that's an unpopular opinion,
and isn't really worth discussion here.

> [ A new thread is probably appropriate if anyone wants to discuss the
> philosophy, but I probably won't participate... ]

I don't feel any pressing need to continue this here and now.

Thanks!

-- 
Cheers,
Leif

From michele.simionato at gmail.com  Mon Jan 14 06:17:21 2008
From: michele.simionato at gmail.com (Michele Simionato)
Date: Mon, 14 Jan 2008 06:17:21 +0100
Subject: [Python-3000] PEP 3115: Actual use cases for odd metaclasses?
	Alternate syntax.
In-Reply-To: <b8c6f6c40801131055m5806130dp9eff35d170c0660a@mail.gmail.com>
References: <b8c6f6c40712212230r3a7b60bdu6b48cc66a4dec318@mail.gmail.com>
	<20071222140828.C1FFB3A40F7@sparrow.telecommunity.com>
	<b8c6f6c40712222004p6f9f0469p71304664bcba6b71@mail.gmail.com>
	<20071223050830.DBD933A408B@sparrow.telecommunity.com>
	<b8c6f6c40801130937o39f0f604rd897215747fa931f@mail.gmail.com>
	<b8c6f6c40801130940p33c18837g5e86cc3dc769b390@mail.gmail.com>
	<4edc17eb0801130958m4c85c023oab0bf7a07965545b@mail.gmail.com>
	<b8c6f6c40801131055m5806130dp9eff35d170c0660a@mail.gmail.com>
Message-ID: <4edc17eb0801132117g485296acn80f04186dc643ecb@mail.gmail.com>

On Jan 13, 2008 7:55 PM, Charles Merriam <charles.merriam at gmail.com> wrote:
> Sorry, if my Italian is non-existent.  Code is code however.
>
> Could you verify that the article covers:
>
> 1.   Complaints that __metaclass__ will be silently ignored in PEP 3115.
>
> My understanding from the last line of the Rational section is that
> this is undecided.

I dunno, in Python 3.0a2 the __metaclass__ hook is silently ignored.
In Python 3.0 final there could be a warning, or the warning  could be
at the level of the 2to3 code convention tool. In any case Python 3.0
is expected to break with the past, I am not complaining much here.

> 2.  Complaints that, without _prepare_, the __new__ operation will not
> know which order the items were declared, and that everyone will write
> ordered hash implementations.

Ordered dictionaries are useful for a variety of purposes, and there are already
lots of implementations out there. The use case for them in __prepare__
is very *very* minor. My complaint about the lack of an ordered dictionary
in the standard library stands on its own, independently of metaclasses.

> You have a legitimate counter-argument that grouping the
> implementations of __add__ in the metaclass is cleaner than having
> them stand alone and be referenced in.   Is this your argument?

I am not sure if I understand you correctly.
In the paper I have a metaclass definining the methods
__new__, __eq__, __call__, __add__ and __repr__ in the class body.
In Python, the ability to define methods in the class body is purely
syntactic sugar. One
could just define the methods externally and attach them to the class
dictionary later on.
Or one could just have a single __new__ method taking a dictionary as argument
(even for ordinary classes) and setting all the methods, possibly with
a memoization mechanism,
since you don't want to reset all the methods at each instantiation.
However, everybody basically agrees that it is nicer to define the
methods in the class body
for ordinary classes, so why it should be different in metaclasses?
Special cases are not
special enough.

 Michele Simionato

From miguel.branco at cern.ch  Mon Jan 14 14:24:44 2008
From: miguel.branco at cern.ch (Miguel Branco)
Date: Mon, 14 Jan 2008 14:24:44 +0100
Subject: [Python-3000] Useless methods in Queue module
In-Reply-To: <20080111141321.AEW71195@ms19.lnh.mail.rcn.net>
References: <20080111141321.AEW71195@ms19.lnh.mail.rcn.net>
Message-ID: <6297740F-C0FE-4380-BD83-2F8A94355F92@cern.ch>

-1 if I may.

I use qsize() to sustain an average queue size (unreliably) but not  
allowing the queue to be full. Certainly, this could be done in some  
other way, but the existence of the method remains very useful.

cheers


On Jan 11, 2008, at 8:13 PM, Raymond Hettinger wrote:

> I proposed to remove three methods from the queue module, qsize(),  
> empty(), and full().  These are not reliable.  The RightWay (tm) is  
> to trap the Empty and Full exceptions or use the .join() approach.
>
> Raymond
>
>
> --- From the docs ---
>
> Queue.qsize()?
>    Return the approximate size of the queue. Because of  
> multithreading semantics, this number is not reliable.
>
> Queue.empty()?
>    Return True if the queue is empty, False otherwise. Because of  
> multithreading semantics, this is not reliable.
>
> Queue.full()?
>    Return True if the queue is full, False otherwise. Because of  
> multithreading semantics, this is not reliable.
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/miguel.branco%40cern.ch

--
Miguel Branco, CERN - ATLAS Computing Group
MSN: msbranco at hotmail.com
   +41 22 76 71268 - http://cern.ch/mbranco/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080114/9fc18c03/attachment.htm 

From jimjjewett at gmail.com  Mon Jan 14 14:48:06 2008
From: jimjjewett at gmail.com (Jim Jewett)
Date: Mon, 14 Jan 2008 08:48:06 -0500
Subject: [Python-3000] [Python-Dev] Rounding Decimals
In-Reply-To: <ca471dc20801122021p38570b6s8fecf48e0ca37db6@mail.gmail.com>
References: <5d44f72f0801051857i3b13f1b0q8a9e485831dcd603@mail.gmail.com>
	<003101c85011$e1572530$6800a8c0@RaymondLaptop1>
	<5d44f72f0801060121l39c4d2a0jfdea69f644bc1822@mail.gmail.com>
	<5d44f72f0801061526x788b0a46lbbc17ec5dde44ceb@mail.gmail.com>
	<007601c850ca$7f2ab3e0$6800a8c0@RaymondLaptop1>
	<5d44f72f0801121709x7c25efbcvfa13e29864b5b577@mail.gmail.com>
	<ca471dc20801122021p38570b6s8fecf48e0ca37db6@mail.gmail.com>
Message-ID: <fb6fbf560801140548v2faa4f78l41eb3de9cc4dd0d8@mail.gmail.com>

On 1/12/08, Guido van Rossum <guido at python.org> wrote:
> On Jan 12, 2008 5:09 PM, Jeffrey Yasskin <jyasskin at gmail.com> wrote:
> > During the discussion about the new Rational implementation
> > (http://bugs.python.org/issue1682), Guido and Raymond decided that
> > Decimal should not implement the new Real ABC from PEP 3141. So I've
> > closed http://bugs.python.org/issue1623 and won't be pursuing any of
> > the extra rounding methods mentioned on this thread.

> Well, I didn't really decide anything. I suggested that if the
> developers of Decimal preferred it, it might be better if Decimal did
> not implement the Real ABC, and Raymond said he indeed preferred it.

I read his objections slightly differently.

He is very clear that Decimal itself should be restricted to the
standard, and therefore should not natively implement the extensions.
But he also said that it might be reasonable for another package to
subset or superset it in a friendlier way.

numbers.py is a different module, which must be explicitly imported.

If the objection is that

    >>> decimal.Decimal("43.2").imag

would work (instead of throwing an exception) only when numbers.py has
already been imported, then ... well, that confusion is inherent in
the abstract classes.

Or is the problem that it *still* wouldn't work, without help from the
decimal module itself?  In that case, 3rd party registration is fairly
limited, and this might be a good candidate for trying to figure out
ABCs and adapters *should* work together.

-jJ

From guido at python.org  Mon Jan 14 19:21:37 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 14 Jan 2008 10:21:37 -0800
Subject: [Python-3000] Useless methods in Queue module
In-Reply-To: <6297740F-C0FE-4380-BD83-2F8A94355F92@cern.ch>
References: <20080111141321.AEW71195@ms19.lnh.mail.rcn.net>
	<6297740F-C0FE-4380-BD83-2F8A94355F92@cern.ch>
Message-ID: <ca471dc20801141021n139ad3d0meb150ad7acf8291d@mail.gmail.com>

How about dropping empty() and full(), but keeping qsize()? empty() is
trivially rephrased as qsize()==0; I haven't heard any use cases for
full().


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From guido at python.org  Mon Jan 14 19:39:00 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 14 Jan 2008 10:39:00 -0800
Subject: [Python-3000] [Python-Dev] Rounding Decimals
In-Reply-To: <fb6fbf560801140548v2faa4f78l41eb3de9cc4dd0d8@mail.gmail.com>
References: <5d44f72f0801051857i3b13f1b0q8a9e485831dcd603@mail.gmail.com>
	<003101c85011$e1572530$6800a8c0@RaymondLaptop1>
	<5d44f72f0801060121l39c4d2a0jfdea69f644bc1822@mail.gmail.com>
	<5d44f72f0801061526x788b0a46lbbc17ec5dde44ceb@mail.gmail.com>
	<007601c850ca$7f2ab3e0$6800a8c0@RaymondLaptop1>
	<5d44f72f0801121709x7c25efbcvfa13e29864b5b577@mail.gmail.com>
	<ca471dc20801122021p38570b6s8fecf48e0ca37db6@mail.gmail.com>
	<fb6fbf560801140548v2faa4f78l41eb3de9cc4dd0d8@mail.gmail.com>
Message-ID: <ca471dc20801141039j43c59407l306c014fd1106965@mail.gmail.com>

On Jan 14, 2008 5:48 AM, Jim Jewett <jimjjewett at gmail.com> wrote:
> On 1/12/08, Guido van Rossum <guido at python.org> wrote:
> > On Jan 12, 2008 5:09 PM, Jeffrey Yasskin <jyasskin at gmail.com> wrote:
> > > During the discussion about the new Rational implementation
> > > (http://bugs.python.org/issue1682), Guido and Raymond decided that
> > > Decimal should not implement the new Real ABC from PEP 3141. So I've
> > > closed http://bugs.python.org/issue1623 and won't be pursuing any of
> > > the extra rounding methods mentioned on this thread.
>
> > Well, I didn't really decide anything. I suggested that if the
> > developers of Decimal preferred it, it might be better if Decimal did
> > not implement the Real ABC, and Raymond said he indeed preferred it.
>
> I read his objections slightly differently.
>
> He is very clear that Decimal itself should be restricted to the
> standard, and therefore should not natively implement the extensions.

Well, to me that sounds like idolizing the standard. The standard
exists so as to ensure that decimal numbers have well-understood
semantics that are implemented correctly. I don't think the standard
was ever meant to exclude optimal interaction with the rest of a
language. I'd like to see if ReXX implements numeric features over and
above the standard.

> But he also said that it might be reasonable for another package to
> subset or superset it in a friendlier way.

>From a user's perspective, it might make more sense to move the
strictly standard-conforming code into a module "decimal_standard" and
make the friendlier-named "decimal" module be that friendly superset.

> numbers.py is a different module, which must be explicitly imported.
>
> If the objection is that
>
>     >>> decimal.Decimal("43.2").imag
>
> would work (instead of throwing an exception) only when numbers.py has
> already been imported, then ... well, that confusion is inherent in
> the abstract classes.

Fortunately, the confusion is in your mind only, because that's not
how ABCs work according to PEP 3119. While as a side effect of
importing the numbers module, the Decimal class might become a virtual
subclass of numbers.Real, that doesn't mean that implementation
features are automatically added. The registration that might take
place inside numbers.py *only* affects the outcome of isinstance() and
issubclass() checks -- it doesn't magically add missing attributes or
methods to the class.

> Or is the problem that it *still* wouldn't work, without help from the
> decimal module itself?

Right.

> In that case, 3rd party registration is fairly
> limited, and this might be a good candidate for trying to figure out
> ABCs and adapters *should* work together.

Of course 3rd party registration is limited -- there's no way that you
could automatically define the right semantics, since the ABCs don't
have a way to express semantics.

PEP 3119 is meant as a *first step* towards adopting ABCs as a core
feature. The changes added to collections.py and numbers.py are best
considered as minimal examples. The main achievement of the PEP is
probably the hooks that allow you to override isinstance() and
issubclass(), plus the decision (which was discussed at length) to use
ABCs (with virtual inheritance), not interfaces, to model similarities
between class APIs.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From adlaiff6 at gmail.com  Mon Jan 14 20:15:08 2008
From: adlaiff6 at gmail.com (Leif Walsh)
Date: Mon, 14 Jan 2008 14:15:08 -0500
Subject: [Python-3000] Useless methods in Queue module
In-Reply-To: <ca471dc20801141021n139ad3d0meb150ad7acf8291d@mail.gmail.com>
References: <20080111141321.AEW71195@ms19.lnh.mail.rcn.net>
	<6297740F-C0FE-4380-BD83-2F8A94355F92@cern.ch>
	<ca471dc20801141021n139ad3d0meb150ad7acf8291d@mail.gmail.com>
Message-ID: <11b6d2f60801141115p46afb166v9768e41cfd5f13bd@mail.gmail.com>

On Jan 14, 2008 1:21 PM, Guido van Rossum <guido at python.org> wrote:
> How about dropping empty() and full(), but keeping qsize()? empty() is
> trivially rephrased as qsize()==0; I haven't heard any use cases for
> full().

I think the point is that, with multiple threads, those methods are
not guaranteed to be correct, whereas trapping the exceptions
apparently are, and therefore, leaving those methods in is confusing
to new programmers who might assume they work and use them without a
second thought.

-- 
Cheers,
Leif

From adlaiff6 at gmail.com  Mon Jan 14 20:16:20 2008
From: adlaiff6 at gmail.com (Leif Walsh)
Date: Mon, 14 Jan 2008 14:16:20 -0500
Subject: [Python-3000] Useless methods in Queue module
In-Reply-To: <11b6d2f60801141115p46afb166v9768e41cfd5f13bd@mail.gmail.com>
References: <20080111141321.AEW71195@ms19.lnh.mail.rcn.net>
	<6297740F-C0FE-4380-BD83-2F8A94355F92@cern.ch>
	<ca471dc20801141021n139ad3d0meb150ad7acf8291d@mail.gmail.com>
	<11b6d2f60801141115p46afb166v9768e41cfd5f13bd@mail.gmail.com>
Message-ID: <11b6d2f60801141116v4cdb6d8bid8a28e0e0326b2f9@mail.gmail.com>

On Jan 14, 2008 2:15 PM, Leif Walsh <adlaiff6 at gmail.com> wrote:
> On Jan 14, 2008 1:21 PM, Guido van Rossum <guido at python.org> wrote:
> > How about dropping empty() and full(), but keeping qsize()? empty() is
> > trivially rephrased as qsize()==0; I haven't heard any use cases for
> > full().
>
> I think the point is that, with multiple threads, those methods are
> not guaranteed to be correct, whereas trapping the exceptions
> apparently are, and therefore, leaving those methods in is confusing
> to new programmers who might assume they work and use them without a
> second thought.

Err, what I mean is, qsize()==0 really isn't a satisfactory replacement.

From collinw at gmail.com  Mon Jan 14 20:33:12 2008
From: collinw at gmail.com (Collin Winter)
Date: Mon, 14 Jan 2008 11:33:12 -0800
Subject: [Python-3000] Useless methods in Queue module
In-Reply-To: <11b6d2f60801141115p46afb166v9768e41cfd5f13bd@mail.gmail.com>
References: <20080111141321.AEW71195@ms19.lnh.mail.rcn.net>
	<6297740F-C0FE-4380-BD83-2F8A94355F92@cern.ch>
	<ca471dc20801141021n139ad3d0meb150ad7acf8291d@mail.gmail.com>
	<11b6d2f60801141115p46afb166v9768e41cfd5f13bd@mail.gmail.com>
Message-ID: <43aa6ff70801141133x5065152an993fa5f35b88b6a7@mail.gmail.com>

On Jan 14, 2008 11:15 AM, Leif Walsh <adlaiff6 at gmail.com> wrote:
> On Jan 14, 2008 1:21 PM, Guido van Rossum <guido at python.org> wrote:
> > How about dropping empty() and full(), but keeping qsize()? empty() is
> > trivially rephrased as qsize()==0; I haven't heard any use cases for
> > full().
>
> I think the point is that, with multiple threads, those methods are
> not guaranteed to be correct, whereas trapping the exceptions
> apparently are, and therefore, leaving those methods in is confusing
> to new programmers who might assume they work and use them without a
> second thought.

I'm not sure people who ignore the big "Because of multithreading
semantics, this is not reliable" warnings should be catered to. Since
others have contributed use-cases for qsize()'s advisory information,
it should probably stay around.

Collin Winter

From python at rcn.com  Mon Jan 14 20:55:35 2008
From: python at rcn.com (Raymond Hettinger)
Date: Mon, 14 Jan 2008 14:55:35 -0500 (EST)
Subject: [Python-3000] Useless methods in Queue module
Message-ID: <20080114145535.AEZ95753@ms19.lnh.mail.rcn.net>

> I'm not sure people who ignore the big "Because of 
> multithreading semantics, this is not reliable" warnings 
> should be catered to. Since others have contributed use-cases
> for qsize()'s advisory information, it should probably stay around.

I concur.

I do recommend we dump q.empty() and q.full().  The right way is to trap the Empty and Full exceptions.  If needed qsize() is available to make your own less reliable checks.

More than just simplifying the API, the improvement makes it easier to roll your own Queue (like a priority queue style).  Currently, we require that six methods get overridden (_init, _empty, _full, _qsize, _put, and _get).  It would be nice to lower the burden to just the basic four.


Raymond

From guido at python.org  Mon Jan 14 20:59:15 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 14 Jan 2008 11:59:15 -0800
Subject: [Python-3000] Useless methods in Queue module
In-Reply-To: <20080114145535.AEZ95753@ms19.lnh.mail.rcn.net>
References: <20080114145535.AEZ95753@ms19.lnh.mail.rcn.net>
Message-ID: <ca471dc20801141159y13bbca80i2f648d98d51092a8@mail.gmail.com>

Sounds like we have all-round agreement. Go for it.

On Jan 14, 2008 11:55 AM, Raymond Hettinger <python at rcn.com> wrote:
> > I'm not sure people who ignore the big "Because of
> > multithreading semantics, this is not reliable" warnings
> > should be catered to. Since others have contributed use-cases
> > for qsize()'s advisory information, it should probably stay around.
>
> I concur.
>
> I do recommend we dump q.empty() and q.full().  The right way is to trap the Empty and Full exceptions.  If needed qsize() is available to make your own less reliable checks.
>
> More than just simplifying the API, the improvement makes it easier to roll your own Queue (like a priority queue style).  Currently, we require that six methods get overridden (_init, _empty, _full, _qsize, _put, and _get).  It would be nice to lower the burden to just the basic four.
>
>
> Raymond
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From charles.merriam at gmail.com  Mon Jan 14 22:32:13 2008
From: charles.merriam at gmail.com (Charles Merriam)
Date: Mon, 14 Jan 2008 13:32:13 -0800
Subject: [Python-3000] Useless methods in Queue module
In-Reply-To: <ca471dc20801141159y13bbca80i2f648d98d51092a8@mail.gmail.com>
References: <20080114145535.AEZ95753@ms19.lnh.mail.rcn.net>
	<ca471dc20801141159y13bbca80i2f648d98d51092a8@mail.gmail.com>
Message-ID: <b8c6f6c40801141332k113ce80ck4fc1ab242ce251e@mail.gmail.com>

Not to be pedantic, but the major concern others are voicing is that
is that queue size is not reliable and is therefore a potential source
of hard to find threading bugs by naive users.   Why not just rename
q.size() to the unweildy name of q.est_size()?


On Jan 14, 2008 11:59 AM, Guido van Rossum <guido at python.org> wrote:
> Sounds like we have all-round agreement. Go for it.
>
> On Jan 14, 2008 11:55 AM, Raymond Hettinger <python at rcn.com> wrote:
> > > I'm not sure people who ignore the big "Because of
> > > multithreading semantics, this is not reliable" warnings
> > > should be catered to. Since others have contributed use-cases
> > > for qsize()'s advisory information, it should probably stay around.
> >
> > I concur.
> >
> > I do recommend we dump q.empty() and q.full().  The right way is to trap the Empty and Full exceptions.  If needed qsize() is available to make your own less reliable checks.
> >
> > More than just simplifying the API, the improvement makes it easier to roll your own Queue (like a priority queue style).  Currently, we require that six methods get overridden (_init, _empty, _full, _qsize, _put, and _get).  It would be nice to lower the burden to just the basic four.
> >
> >
> > Raymond
> >
>
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> _______________________________________________
>
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/charles.merriam%40gmail.com
>

From skip at pobox.com  Mon Jan 14 22:54:42 2008
From: skip at pobox.com (skip at pobox.com)
Date: Mon, 14 Jan 2008 15:54:42 -0600
Subject: [Python-3000] Useless methods in Queue module
In-Reply-To: <11b6d2f60801141115p46afb166v9768e41cfd5f13bd@mail.gmail.com>
References: <20080111141321.AEW71195@ms19.lnh.mail.rcn.net>
	<6297740F-C0FE-4380-BD83-2F8A94355F92@cern.ch>
	<ca471dc20801141021n139ad3d0meb150ad7acf8291d@mail.gmail.com>
	<11b6d2f60801141115p46afb166v9768e41cfd5f13bd@mail.gmail.com>
Message-ID: <18315.55842.877143.320957@montanaro.dyndns.org>


    Leif> I think the point is that, with multiple threads, those methods
    Leif> are not guaranteed to be correct, whereas trapping the exceptions
    Leif> apparently are, and therefore, leaving those methods in is
    Leif> confusing to new programmers who might assume they work and use
    Leif> them without a second thought.

For the guy who said he wanted to maintain an average qsize (not too small,
not too big), empty() and full() don't help.  He'll have to implement a
qsize() function or monkey patch (or subclass) the Queue class.  I agree
with Guido that empty() and full() can go with no great consequence.
qsize() should stay though.  In my old threading code (stuff I no longer
use) qsize() was the only one of the three I ever used.

That said, I don't understand why things can't just be left as-is.  I can't
see that they are hurting anything.  All three have long been documented as
not reliable.  It's not like it should be a surprise to anyone that

    if not q.qsize():
        print q.qsize()

might print something besides 0.  And if it is a surprise, they should
probably not be programming with threads. <0.5-even-rounded wink>

Skip

From adlaiff6 at gmail.com  Mon Jan 14 23:04:29 2008
From: adlaiff6 at gmail.com (Leif Walsh)
Date: Mon, 14 Jan 2008 17:04:29 -0500
Subject: [Python-3000] Useless methods in Queue module
In-Reply-To: <18315.55842.877143.320957@montanaro.dyndns.org>
References: <20080111141321.AEW71195@ms19.lnh.mail.rcn.net>
	<6297740F-C0FE-4380-BD83-2F8A94355F92@cern.ch>
	<ca471dc20801141021n139ad3d0meb150ad7acf8291d@mail.gmail.com>
	<11b6d2f60801141115p46afb166v9768e41cfd5f13bd@mail.gmail.com>
	<18315.55842.877143.320957@montanaro.dyndns.org>
Message-ID: <11b6d2f60801141404r7d8a18f2xdaa2992803b29c9d@mail.gmail.com>

On Jan 14, 2008 4:54 PM,  <skip at pobox.com> wrote:
> For the guy who said he wanted to maintain an average qsize (not too small,
> not too big), empty() and full() don't help.  He'll have to implement a
> qsize() function or monkey patch (or subclass) the Queue class.  I agree
> with Guido that empty() and full() can go with no great consequence.
> qsize() should stay though.  In my old threading code (stuff I no longer
> use) qsize() was the only one of the three I ever used.

Yes, qsize() is useful (and I think Charles' suggestion to change the
name is a good one), yes empty() and full() should go.  I was saying
qsize()==0 should probably not be suggested as a replacement.

-- 
Cheers,
Leif

From brett at python.org  Mon Jan 14 23:10:30 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 14 Jan 2008 14:10:30 -0800
Subject: [Python-3000] Useless methods in Queue module
In-Reply-To: <18315.55842.877143.320957@montanaro.dyndns.org>
References: <20080111141321.AEW71195@ms19.lnh.mail.rcn.net>
	<6297740F-C0FE-4380-BD83-2F8A94355F92@cern.ch>
	<ca471dc20801141021n139ad3d0meb150ad7acf8291d@mail.gmail.com>
	<11b6d2f60801141115p46afb166v9768e41cfd5f13bd@mail.gmail.com>
	<18315.55842.877143.320957@montanaro.dyndns.org>
Message-ID: <bbaeab100801141410p8cc1d5dle171d9337b71285f@mail.gmail.com>

On Jan 14, 2008 1:54 PM,  <skip at pobox.com> wrote:
>
>     Leif> I think the point is that, with multiple threads, those methods
>     Leif> are not guaranteed to be correct, whereas trapping the exceptions
>     Leif> apparently are, and therefore, leaving those methods in is
>     Leif> confusing to new programmers who might assume they work and use
>     Leif> them without a second thought.
>
> For the guy who said he wanted to maintain an average qsize (not too small,
> not too big), empty() and full() don't help.  He'll have to implement a
> qsize() function or monkey patch (or subclass) the Queue class.  I agree
> with Guido that empty() and full() can go with no great consequence.
> qsize() should stay though.  In my old threading code (stuff I no longer
> use) qsize() was the only one of the three I ever used.
>
> That said, I don't understand why things can't just be left as-is.  I can't
> see that they are hurting anything.  All three have long been documented as
> not reliable.  It's not like it should be a surprise to anyone that
>
>     if not q.qsize():
>         print q.qsize()
>
> might print something besides 0.  And if it is a surprise, they should
> probably not be programming with threads. <0.5-even-rounded wink>

As Raymond pointed out, if you subclass you then have to make sure
full() and empty() are properly supported.

It is also just more code and more documentation to maintain, keep
modernized, etc. That means there is that much more of a chance of
having an issue get reported that has to deal with it, etc. If Raymond
is willing to put the time and effort in to remove it I say let him
and save all of us the possible trouble of having bug reports on the
code in the future.

-Brett

From python at rcn.com  Mon Jan 14 23:19:59 2008
From: python at rcn.com (Raymond Hettinger)
Date: Mon, 14 Jan 2008 17:19:59 -0500 (EST)
Subject: [Python-3000] Useless methods in Queue module
Message-ID: <20080114171959.AFA19932@ms19.lnh.mail.rcn.net>

[Skip]
>     if not q.qsize():
>        print q.qsize()
> might print something besides 0.  And if it is a surprise,
> they should probably not be programming with threads. 
> 0.5-even-rounded wink>

I concur. Let's leave qsize() alone.  Even renaming it would cause unnecessary breakage.

FWIW, the removal of empty() and full() are checked-in.  Looks nice and clean now.


Raymond

From mike.klaas at gmail.com  Mon Jan 14 23:55:56 2008
From: mike.klaas at gmail.com (Mike Klaas)
Date: Mon, 14 Jan 2008 14:55:56 -0800
Subject: [Python-3000] Useless methods in Queue module
In-Reply-To: <b8c6f6c40801141332k113ce80ck4fc1ab242ce251e@mail.gmail.com>
References: <20080114145535.AEZ95753@ms19.lnh.mail.rcn.net>
	<ca471dc20801141159y13bbca80i2f648d98d51092a8@mail.gmail.com>
	<b8c6f6c40801141332k113ce80ck4fc1ab242ce251e@mail.gmail.com>
Message-ID: <9D02E804-3B7B-47CC-89A3-3922A4A168D0@gmail.com>

On 14-Jan-08, at 1:32 PM, Charles Merriam wrote:

> Not to be pedantic, but the major concern others are voicing is that
> is that queue size is not reliable and is therefore a potential source
> of hard to find threading bugs by naive users.   Why not just rename
> q.size() to the unweildy name of q.est_size()?

This is a misleading name.  The number returned from qsize() [not size 
()] is perfectly reliable, in the sense that it is the exact size of  
the queue at some instant in time.  The real concern is that qsize()  
 > 0 doesn't guarantee that a subsequent .get() will not block, nor  
that qsize() < maxsize guarantee that .put() will not block.   
Incidentally, I find this warning much less confusion than the vague  
"Because of multithreading semantics, this number is not reliable."  
in the docs.

-Mike

From alexandre at peadrop.com  Tue Jan 15 00:04:06 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Mon, 14 Jan 2008 18:04:06 -0500
Subject: [Python-3000] [Python-Dev]  inst_persistent_id
In-Reply-To: <20080114175943.GA26431@code0.codespeak.net>
References: <A2A6D220-45A7-4C04-8D4E-CBBB919D55E1@zope.com>
	<acd65fa20801121633l2ae5202j8a7d75d7933ce91e@mail.gmail.com>
	<20080114175943.GA26431@code0.codespeak.net>
Message-ID: <acd65fa20801141504j5f496a06t133fab8f727609d@mail.gmail.com>

Oh, you are right. I thought that save_inst() used inst_persistent_id,
but that isn't the case. Now, I have checked more thoroughly and found
the relevant piece of code:

	if (!pers_save && self->inst_pers_func) {
		if ((tmp = save_pers(self, args, self->inst_pers_func)) != 0) {
			res = tmp;
			goto finally;
		}
	}

which is indeed called only when the object is not "supported" by pickle.

I guess my original argument doesn't hold anymore, thus I don't have
anything against supporting this feature officially.

Thanks for correcting me!
-- Alexandre


On Jan 14, 2008 12:59 PM, Armin Rigo <arigo at tunes.org> wrote:
> Hi,
>
> On Sat, Jan 12, 2008 at 07:33:38PM -0500, Alexandre Vassalotti wrote:
> > Well, in Python 3K, inst_persistent_id() won't be usable, since
> > PyInstance_Type was removed.
>
> Looking at the code, inst_persistent_id() is just a confusing name.  It
> has got nothing to do with PyInstance_Type; it's called for any object
> type that cPickle.c doesn't know how to handle.  In fact, it seems that
> cPickle.c never calls inst_persistent_id() for objects of type
> PyInstance_Type...
>
>
> A bientot,
>
> Armin.
>

From jyasskin at gmail.com  Tue Jan 15 02:49:26 2008
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Mon, 14 Jan 2008 17:49:26 -0800
Subject: [Python-3000] Useless methods in Queue module
In-Reply-To: <9D02E804-3B7B-47CC-89A3-3922A4A168D0@gmail.com>
References: <20080114145535.AEZ95753@ms19.lnh.mail.rcn.net>
	<ca471dc20801141159y13bbca80i2f648d98d51092a8@mail.gmail.com>
	<b8c6f6c40801141332k113ce80ck4fc1ab242ce251e@mail.gmail.com>
	<9D02E804-3B7B-47CC-89A3-3922A4A168D0@gmail.com>
Message-ID: <5d44f72f0801141749r7aea9e0cj181272ee17c94a6e@mail.gmail.com>

On Jan 14, 2008 2:55 PM, Mike Klaas <mike.klaas at gmail.com> wrote:
> On 14-Jan-08, at 1:32 PM, Charles Merriam wrote:
>
> > Not to be pedantic, but the major concern others are voicing is that
> > is that queue size is not reliable and is therefore a potential source
> > of hard to find threading bugs by naive users.   Why not just rename
> > q.size() to the unweildy name of q.est_size()?
>
> This is a misleading name.  The number returned from qsize() [not size
> ()] is perfectly reliable, in the sense that it is the exact size of
> the queue at some instant in time.

No, you're wrong. In CPython's implementation, it's likely that qsize
is implemented by locking the structure and reading a size field, but
there are other, more highly concurrent implementations, like Java's
ConcurrentLinkedQueue
(http://java.sun.com/javase/6/docs/api/java/util/concurrent/ConcurrentLinkedQueue.html)
[1], that have to traverse the structure to read its size.  Then the
returned value can be higher than the number ever "simultaneously"
contained in the queue, if some were added and some were removed
during the traversal.

Furthermore, it's misleading to think of even a locked
implementation's result as reliable. Ignoring problems with
simultaneity in the presence of threads, the "true" value could easily
have changed by the time qsize returns. And if it returns a value
that's not accurate, that can hardly be described as reliable. It
really is returning an estimate of the size, suitable only for use in
performance optimizations where you're prepared to handle it sometimes
being wildly wrong.

That said, I'm +1 on the current decision to keep it around, with its
current name. Users already have to look it up (since it's not spelled
len(q)), so they'll hit the warning.


[1]: ConcurrentLinkedQueue can't actually implement Queue in its
current form because it can't block. Something more like the data
structures described at
http://www.cs.rochester.edu/research/synchronization/pseudocode/duals.html
looks like it could, but I haven't examined the implementation well
enough to be sure. Nevertheless, it would be a bad idea to assume such
data structures will never be designed.

-- 
Namast?,
Jeffrey Yasskin

From mike.klaas at gmail.com  Tue Jan 15 03:31:08 2008
From: mike.klaas at gmail.com (Mike Klaas)
Date: Mon, 14 Jan 2008 18:31:08 -0800
Subject: [Python-3000] Useless methods in Queue module
In-Reply-To: <5d44f72f0801141749r7aea9e0cj181272ee17c94a6e@mail.gmail.com>
References: <20080114145535.AEZ95753@ms19.lnh.mail.rcn.net>
	<ca471dc20801141159y13bbca80i2f648d98d51092a8@mail.gmail.com>
	<b8c6f6c40801141332k113ce80ck4fc1ab242ce251e@mail.gmail.com>
	<9D02E804-3B7B-47CC-89A3-3922A4A168D0@gmail.com>
	<5d44f72f0801141749r7aea9e0cj181272ee17c94a6e@mail.gmail.com>
Message-ID: <A8D828D1-B673-4ED8-9DCF-2467AA28E679@gmail.com>

On 14-Jan-08, at 5:49 PM, Jeffrey Yasskin wrote:

> On Jan 14, 2008 2:55 PM, Mike Klaas <mike.klaas at gmail.com> wrote:

>> This is a misleading name.  The number returned from qsize() [not  
>> size
>> ()] is perfectly reliable, in the sense that it is the exact size of
>> the queue at some instant in time.
>
> No, you're wrong. In CPython's implementation, it's likely that qsize
> is implemented by locking the structure and reading a size field,

It isn't likely, it is.  It is also implemented as such in all  
mainstream python interpreters (ironpython, jython), since they use  
CPython's pure-python implementation.

I grant that it is theoretically possible to implement Queue.Queue's  
full interface with a data structure in which qsize() is never a  
consistent length of the index at a given time, even if such a  
structure may not yet exist.

> Furthermore, it's misleading to think of even a locked
> implementation's result as reliable. Ignoring problems with
> simultaneity in the presence of threads, the "true" value could easily
> have changed by the time qsize returns. And if it returns a value
> that's not accurate, that can hardly be described as reliable. It
> really is returning an estimate of the size, suitable only for use in
> performance optimizations where you're prepared to handle it sometimes
> being wildly wrong.

In some usage patterns it is thread-unsafe.  Whether this means that  
the method itself is "unreliable" is a battle likely not worth  
getting in to.

Thanks for the interesting reference,
-Mike

From skip at pobox.com  Tue Jan 15 04:42:27 2008
From: skip at pobox.com (skip at pobox.com)
Date: Mon, 14 Jan 2008 21:42:27 -0600
Subject: [Python-3000] Useless methods in Queue module
In-Reply-To: <9D02E804-3B7B-47CC-89A3-3922A4A168D0@gmail.com>
References: <20080114145535.AEZ95753@ms19.lnh.mail.rcn.net>
	<ca471dc20801141159y13bbca80i2f648d98d51092a8@mail.gmail.com>
	<b8c6f6c40801141332k113ce80ck4fc1ab242ce251e@mail.gmail.com>
	<9D02E804-3B7B-47CC-89A3-3922A4A168D0@gmail.com>
Message-ID: <18316.11171.59886.209223@montanaro.dyndns.org>


    Mike> The real concern is that qsize() > 0 doesn't guarantee that a
    Mike> subsequent .get() will not block, nor that qsize() < maxsize
    Mike> guarantee that .put() will not block.  Incidentally, I find this
    Mike> warning much less confusion than the vague "Because of
    Mike> multithreading semantics, this number is not reliable."  in the
    Mike> docs.

I checked in similar change to the trunk version of queue.rst for all three
methods.  The qsize() description almost completely matches your text above.
The other two are a bit more cumbersome, but I didn't worry too much about
that since a future merge to the 3.0 branch will delete them anyway.

Thanks for the suggestion.

Skip


From martin at v.loewis.de  Tue Jan 15 06:54:20 2008
From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=)
Date: Tue, 15 Jan 2008 06:54:20 +0100
Subject: [Python-3000] Useless methods in Queue module
In-Reply-To: <5d44f72f0801141749r7aea9e0cj181272ee17c94a6e@mail.gmail.com>
References: <20080114145535.AEZ95753@ms19.lnh.mail.rcn.net>	<ca471dc20801141159y13bbca80i2f648d98d51092a8@mail.gmail.com>	<b8c6f6c40801141332k113ce80ck4fc1ab242ce251e@mail.gmail.com>	<9D02E804-3B7B-47CC-89A3-3922A4A168D0@gmail.com>
	<5d44f72f0801141749r7aea9e0cj181272ee17c94a6e@mail.gmail.com>
Message-ID: <478C4A8C.5010400@v.loewis.de>

>> This is a misleading name.  The number returned from qsize() [not size
>> ()] is perfectly reliable, in the sense that it is the exact size of
>> the queue at some instant in time.
> 
> No, you're wrong.

As Mike explains: he is right, you are wrong.

> In CPython's implementation, it's likely that qsize
> is implemented by locking the structure and reading a size field

    def qsize(self):
        """Return the approximate size of the queue (not reliable!)."""
        self.mutex.acquire()
        n = self._qsize()
        self.mutex.release()
        return n
    def _qsize(self):
        return len(self.queue)


> but there are other, more highly concurrent implementations, like Java's
> ConcurrentLinkedQueue
> (http://java.sun.com/javase/6/docs/api/java/util/concurrent/ConcurrentLinkedQueue.html)
> [1], that have to traverse the structure to read its size.

Still, with the Queue.Queue API, such an implementation would hold the
queue lock while computing the size.

For the base class, Mike's statement would be true even without explicit
acquisition of the queue lock: the len() operation is atomic in the
sense that it yields some historical value of the deque object that is
being used:

static Py_ssize_t
deque_len(dequeobject *deque)
{
	return deque->len;
}

Most processors guarantee that a read operation of a Py_ssize_t
field is atomic, plus that read operation is protected by the GIL.

> Furthermore, it's misleading to think of even a locked
> implementation's result as reliable. Ignoring problems with
> simultaneity in the presence of threads, the "true" value could easily
> have changed by the time qsize returns. And if it returns a value
> that's not accurate, that can hardly be described as reliable. It
> really is returning an estimate of the size, suitable only for use in
> performance optimizations where you're prepared to handle it sometimes
> being wildly wrong.

Nonsense. In typical Queue applications, you either have multiple
readers and one writer, or multiple writers and one reader (*). For
the end of the queue that doesn't have contention, empty() resp.
full() are completely reliable (i.e. if you are the only reader,
and you see that empty() is False, you know for sure that it won't
suddenly become True).

(*) in many cases, you have exactly one reader and exactly one writer.

> Nevertheless, it would be a bad idea to assume such
> data structures will never be designed.

It also is a bad idea to make project assumptions into interfaces
which aren't actually part of the interface. That often leads to
bad code which elaborately deals with cases that can never occur.

Regards,
Martin


From jyasskin at gmail.com  Tue Jan 15 07:30:35 2008
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Mon, 14 Jan 2008 22:30:35 -0800
Subject: [Python-3000] Useless methods in Queue module
In-Reply-To: <A8D828D1-B673-4ED8-9DCF-2467AA28E679@gmail.com>
References: <20080114145535.AEZ95753@ms19.lnh.mail.rcn.net>
	<ca471dc20801141159y13bbca80i2f648d98d51092a8@mail.gmail.com>
	<b8c6f6c40801141332k113ce80ck4fc1ab242ce251e@mail.gmail.com>
	<9D02E804-3B7B-47CC-89A3-3922A4A168D0@gmail.com>
	<5d44f72f0801141749r7aea9e0cj181272ee17c94a6e@mail.gmail.com>
	<A8D828D1-B673-4ED8-9DCF-2467AA28E679@gmail.com>
Message-ID: <5d44f72f0801142230k3b16d202x3c3dbbbed8a71a8@mail.gmail.com>

On Jan 14, 2008 6:31 PM, Mike Klaas <mike.klaas at gmail.com> wrote:
> On 14-Jan-08, at 5:49 PM, Jeffrey Yasskin wrote:
>
> > On Jan 14, 2008 2:55 PM, Mike Klaas <mike.klaas at gmail.com> wrote:
>
> >> This is a misleading name.  The number returned from qsize() [not
> >> size
> >> ()] is perfectly reliable, in the sense that it is the exact size of
> >> the queue at some instant in time.
> >
> > No, you're wrong. In CPython's implementation, it's likely that qsize
> > is implemented by locking the structure and reading a size field,
>
> It isn't likely, it is.  It is also implemented as such in all
> mainstream python interpreters (ironpython, jython), since they use
> CPython's pure-python implementation.

Yes, I was thinking solely about the API, while everyone else is
thinking (correctly) about the implementations we actually have. Sorry
for being needlessly confrontational.

> I grant that it is theoretically possible to implement Queue.Queue's
> full interface with a data structure in which qsize() is never a
> consistent length of the index at a given time, even if such a
> structure may not yet exist.
>
> > Furthermore, it's misleading to think of even a locked
> > implementation's result as reliable. Ignoring problems with
> > simultaneity in the presence of threads, the "true" value could easily
> > have changed by the time qsize returns. And if it returns a value
> > that's not accurate, that can hardly be described as reliable. It
> > really is returning an estimate of the size, suitable only for use in
> > performance optimizations where you're prepared to handle it sometimes
> > being wildly wrong.
>
> In some usage patterns it is thread-unsafe.  Whether this means that
> the method itself is "unreliable" is a battle likely not worth
> getting in to.
>
> Thanks for the interesting reference,
> -Mike
>



-- 
Namast?,
Jeffrey Yasskin
http://jeffrey.yasskin.info/

"Religion is an improper response to the Divine." ? "Skinny Legs and
All", by Tom Robbins

From facundobatista at gmail.com  Tue Jan 15 12:24:44 2008
From: facundobatista at gmail.com (Facundo Batista)
Date: Tue, 15 Jan 2008 09:24:44 -0200
Subject: [Python-3000] Useless methods in Queue module
In-Reply-To: <20080114145535.AEZ95753@ms19.lnh.mail.rcn.net>
References: <20080114145535.AEZ95753@ms19.lnh.mail.rcn.net>
Message-ID: <e04bdf310801150324k5f49d7a6yf61098c080f989d4@mail.gmail.com>

2008/1/14, Raymond Hettinger <python at rcn.com>:

> I do recommend we dump q.empty() and q.full().  The right way is to trap the Empty and Full exceptions.  If needed qsize() is available to make your own less reliable checks.

+1

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

From guido at python.org  Tue Jan 15 18:39:08 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 15 Jan 2008 09:39:08 -0800
Subject: [Python-3000] Useless methods in Queue module
In-Reply-To: <478C4A8C.5010400@v.loewis.de>
References: <20080114145535.AEZ95753@ms19.lnh.mail.rcn.net>
	<ca471dc20801141159y13bbca80i2f648d98d51092a8@mail.gmail.com>
	<b8c6f6c40801141332k113ce80ck4fc1ab242ce251e@mail.gmail.com>
	<9D02E804-3B7B-47CC-89A3-3922A4A168D0@gmail.com>
	<5d44f72f0801141749r7aea9e0cj181272ee17c94a6e@mail.gmail.com>
	<478C4A8C.5010400@v.loewis.de>
Message-ID: <ca471dc20801150939i3d82a8c0u37a5f59d08e27941@mail.gmail.com>

> > No, you're wrong.
>
> As Mike explains: he is right, you are wrong.

Folks, can we please maintain a minimal level of decency? It would
make reading the thread easier not to have to deal with the mental
image of heads butting.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From jcea at argo.es  Tue Jan 15 19:13:10 2008
From: jcea at argo.es (Jesus Cea)
Date: Tue, 15 Jan 2008 19:13:10 +0100
Subject: [Python-3000] Is pickle's persistent_id worth keeping?
In-Reply-To: <ca471dc20801100808p419b5481sed2f8075191503da@mail.gmail.com>
References: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>	
	<17033E0D-6A78-4D66-ACFB-1A5ED150646E@zope.com>	
	<52C7B012-8C6A-4530-BE04-ADA9BC54D4E1@acm.org>	
	<1199796869.6177.25.camel@jcd-desktop>	
	<5ED6A8B1-241E-4FFB-A512-0FF744A4E964@acm.org>	
	<ca471dc20801080951o3f47fe99yaefbcd6c7557ae0d@mail.gmail.com>	
	<47861527.7020904@argo.es>
	<ca471dc20801100808p419b5481sed2f8075191503da@mail.gmail.com>
Message-ID: <478CF7B6.8020001@argo.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Guido van Rossum wrote:
| On Jan 10, 2008 4:52 AM, Jesus Cea <jcea at argo.es> wrote:
|> I'm very dependent of bsddb support in python. I'm very sorry also of
|> the maintainer support of it: he is slow and doesn't implement python
|> bindings for berkeleydb features deployed five years ago :-(. Could be a
|> bit rude, but maybe a maintaner change would be in order. I would rather
|> prefer to talk to current maintainer, but I rather apply for maintaner
|> position than dropping bsddb from the python stdlib!!.
|
| Hi Jesus,
|
| I don't know if there *is* a current maintainer. There are a few
| people who sometimes fix things in the current code base, but I think
| development has stopped. If you're serious about wanting to take over
| maintenance, (or even just contributing) that would be great!

I would do, *if* Greg agrees. Or if he is Missing In Action.

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
~                               _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBR4z3tZlgi5GaxT1NAQLpZwP/fjkMH9n8+CTmZr6hLiCxuVd9MS/KVP+8
kCltZgIA0SA7g3lyYakg46rasfrvX4BfCHwIL+UmxxJ18uKO5NTV7NafrycBm5Yd
k77dlx7ShWq6RKCh9KKLjiKN/WOVSnOLOjWpI1LFHX7rsRCegW2vUlr+VEI69K0z
Hewv+F39KOg=
=6H06
-----END PGP SIGNATURE-----

From guido at python.org  Tue Jan 15 19:15:33 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 15 Jan 2008 10:15:33 -0800
Subject: [Python-3000] Is pickle's persistent_id worth keeping?
In-Reply-To: <478CF7B6.8020001@argo.es>
References: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>
	<17033E0D-6A78-4D66-ACFB-1A5ED150646E@zope.com>
	<52C7B012-8C6A-4530-BE04-ADA9BC54D4E1@acm.org>
	<1199796869.6177.25.camel@jcd-desktop>
	<5ED6A8B1-241E-4FFB-A512-0FF744A4E964@acm.org>
	<ca471dc20801080951o3f47fe99yaefbcd6c7557ae0d@mail.gmail.com>
	<47861527.7020904@argo.es>
	<ca471dc20801100808p419b5481sed2f8075191503da@mail.gmail.com>
	<478CF7B6.8020001@argo.es>
Message-ID: <ca471dc20801151015q47c1805cm55087ae155b99da1@mail.gmail.com>

On Jan 15, 2008 10:13 AM, Jesus Cea <jcea at argo.es> wrote:
> | On Jan 10, 2008 4:52 AM, Jesus Cea <jcea at argo.es> wrote:
> |> I'm very dependent of bsddb support in python. I'm very sorry also of
> |> the maintainer support of it: he is slow and doesn't implement python
> |> bindings for berkeleydb features deployed five years ago :-(. Could be a
> |> bit rude, but maybe a maintaner change would be in order. I would rather
> |> prefer to talk to current maintainer, but I rather apply for maintaner
> |> position than dropping bsddb from the python stdlib!!.
> |
> | Hi Jesus,
> |
> | I don't know if there *is* a current maintainer. There are a few
> | people who sometimes fix things in the current code base, but I think
> | development has stopped. If you're serious about wanting to take over
> | maintenance, (or even just contributing) that would be great!
>
> I would do, *if* Greg agrees. Or if he is Missing In Action.

"""
Looks like you missed Greg's response a few days ago:

I consider myself the maintainer because I at least make sure it keeps
working with new berkeleydb releases and such and am one of the most
familiar with the _bsddb.c code internals (both the good and the bad).

But theres a caveat to me having that job: I have -zero- use for the
bsddb module myself today. Whenever I update it it really is a
donation of my time since I don't personally need the changes.  A
maintainer that has a vested interest in using the module would be a
great thing.  There are a couple crashing bugs that need fixing and a
few more recent API additions that could be wrapped for sure.

Volunteering Jesus? :)
"""

Sounds like he's all for you taking over!

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From jcea at argo.es  Tue Jan 15 19:31:08 2008
From: jcea at argo.es (Jesus Cea)
Date: Tue, 15 Jan 2008 19:31:08 +0100
Subject: [Python-3000] Is pickle's persistent_id worth keeping?
In-Reply-To: <ca471dc20801151015q47c1805cm55087ae155b99da1@mail.gmail.com>
References: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>	
	<17033E0D-6A78-4D66-ACFB-1A5ED150646E@zope.com>	
	<52C7B012-8C6A-4530-BE04-ADA9BC54D4E1@acm.org>	
	<1199796869.6177.25.camel@jcd-desktop>	
	<5ED6A8B1-241E-4FFB-A512-0FF744A4E964@acm.org>	
	<ca471dc20801080951o3f47fe99yaefbcd6c7557ae0d@mail.gmail.com>	
	<47861527.7020904@argo.es>	
	<ca471dc20801100808p419b5481sed2f8075191503da@mail.gmail.com>	
	<478CF7B6.8020001@argo.es>
	<ca471dc20801151015q47c1805cm55087ae155b99da1@mail.gmail.com>
Message-ID: <478CFBEC.2000806@argo.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Guido van Rossum wrote:
| Looks like you missed Greg's response a few days ago:
[...]
| Sounds like he's all for you taking over!

Yes, catching old email after Christmas :-). 6119 emails to go :-(

I would like to take over bsddb maintenance. Yes. But I need to know
about python commit procedures, roadmaps, etc. That is, knowing the
implications aside keeping bssdb code updated. Mailing list traffic is
overhelming to me, currently, for example. I'm a fairly busy guy these days.

And I'm unable to compile code for MS Windows or MacOS platforms.

But I need bsddb and I would really like to see "old" BerkeleyDB
features accesible from Python, like replication. So would volunteer if
there is nobody else to take the gauntlet and "somebody" could tell me
what *exactly* would be my demanded responsabilities and communication
level.

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
~                               _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBR4z77Jlgi5GaxT1NAQKyxQP/QWUkqLv2CNhs26wfOltJs78oe0tmsv/t
ddUSkvzidWUJmXT/XLv+cZeHCCzXmPO6hHGUX00xaqrX0YL09KZiGBHADeN6OX1c
UBimr4km5kJqx4SFdLpe3s4Sc4tLhsFFLwcRLvoNv0WTqcMksXsWV5w/7sTh2FQb
SGMs2RocUFk=
=FTGJ
-----END PGP SIGNATURE-----

From guido at python.org  Tue Jan 15 19:36:47 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 15 Jan 2008 10:36:47 -0800
Subject: [Python-3000] Is pickle's persistent_id worth keeping?
In-Reply-To: <478CFBEC.2000806@argo.es>
References: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>
	<52C7B012-8C6A-4530-BE04-ADA9BC54D4E1@acm.org>
	<1199796869.6177.25.camel@jcd-desktop>
	<5ED6A8B1-241E-4FFB-A512-0FF744A4E964@acm.org>
	<ca471dc20801080951o3f47fe99yaefbcd6c7557ae0d@mail.gmail.com>
	<47861527.7020904@argo.es>
	<ca471dc20801100808p419b5481sed2f8075191503da@mail.gmail.com>
	<478CF7B6.8020001@argo.es>
	<ca471dc20801151015q47c1805cm55087ae155b99da1@mail.gmail.com>
	<478CFBEC.2000806@argo.es>
Message-ID: <ca471dc20801151036r2fe18698yebde58eef754f876@mail.gmail.com>

On Jan 15, 2008 10:31 AM, Jesus Cea <jcea at argo.es> wrote:
> I would like to take over bsddb maintenance. Yes. But I need to know
> about python commit procedures, roadmaps, etc. That is, knowing the
> implications aside keeping bssdb code updated. Mailing list traffic is
> overhelming to me, currently, for example. I'm a fairly busy guy these days.
>
> And I'm unable to compile code for MS Windows or MacOS platforms.
>
> But I need bsddb and I would really like to see "old" BerkeleyDB
> features accesible from Python, like replication. So would volunteer if
> there is nobody else to take the gauntlet and "somebody" could tell me
> what *exactly* would be my demanded responsabilities and communication
> level.

Hopefully Greg can mentor you some. You'll have to start by submitting
patches and getting someone to review and apply them -- Greg should be
able to help out there. When Greg is tired of approving first-time
perfect patches he'll recommend you apply for developer status. :-)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From jcea at argo.es  Tue Jan 15 19:50:10 2008
From: jcea at argo.es (Jesus Cea)
Date: Tue, 15 Jan 2008 19:50:10 +0100
Subject: [Python-3000] Is pickle's persistent_id worth keeping?
In-Reply-To: <ca471dc20801151036r2fe18698yebde58eef754f876@mail.gmail.com>
References: <acd65fa20801051550h5b5765acjf7d4b271e6a977a4@mail.gmail.com>	
	<52C7B012-8C6A-4530-BE04-ADA9BC54D4E1@acm.org>	
	<1199796869.6177.25.camel@jcd-desktop>	
	<5ED6A8B1-241E-4FFB-A512-0FF744A4E964@acm.org>	
	<ca471dc20801080951o3f47fe99yaefbcd6c7557ae0d@mail.gmail.com>	
	<47861527.7020904@argo.es>	
	<ca471dc20801100808p419b5481sed2f8075191503da@mail.gmail.com>	
	<478CF7B6.8020001@argo.es>	
	<ca471dc20801151015q47c1805cm55087ae155b99da1@mail.gmail.com>	
	<478CFBEC.2000806@argo.es>
	<ca471dc20801151036r2fe18698yebde58eef754f876@mail.gmail.com>
Message-ID: <478D0062.8090806@argo.es>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Guido van Rossum wrote:
| Hopefully Greg can mentor you some. You'll have to start by submitting
| patches and getting someone to review and apply them -- Greg should be
| able to help out there. When Greg is tired of approving first-time
| perfect patches he'll recommend you apply for developer status. :-)

So, first step would be to take over bsddb library development, as a
separate project, and *THEN* fight to update the version distributed by
python itself.

Seems doable.

Greg, how can we manage the transition?. I would need current source
code, a brief status report and a "public" maintenance transfer ack in
the pybsddb mailing list. We could keep co-maintenance status both of
us. I would like to benefice from your experience. If you rather prefer
to forget about pybsddb, then we need to talk about sourceforge access
and such.

- --
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea at argo.es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
~                               _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBR40AYplgi5GaxT1NAQIS5AP/TBpRVWsG8PdNb2TlJwnDNO6QudlXS792
en8ZqtxKvaw1vJZU4+6+nZo3BPDhNLqZwAOYeRWxdBxQ5SRZgQ6nJ/fF0RdpF7p8
UsfSluZqzMh38Xh5ul3d+oSn9hDYEgiESNvEppU8WI3QMnLRV9ro6LmjNfTbiqFy
Ke9Z7an0/Ss=
=fEmH
-----END PGP SIGNATURE-----

From dwheeler at dwheeler.com  Wed Jan 16 00:07:07 2008
From: dwheeler at dwheeler.com (David A. Wheeler)
Date: Tue, 15 Jan 2008 18:07:07 -0500 (EST)
Subject: [Python-3000] Need closure on __cmp__ removal
In-Reply-To: <ca471dc20801062001m148b343ex450a9093c8c1359a@mail.gmail.com>
References: <37f76d50801052240w44bbf29arb80d7e7b1a451710@mail.gmail.com>
	<ca471dc20801062001m148b343ex450a9093c8c1359a@mail.gmail.com>
Message-ID: <E1JEus7-0004OT-66@fenris.runbox.com>

Bill Janssen:
>I'm a bit baffled here; I find cmp() fairly handy in writing sort routines...
>Is there a better / newer / official way of doing this? If not, isn't
>"cmp()" still useful to have around?

I agree with you - I find cmp() useful, and I notice that some others do too.
E.G., Adam Olson said "It's clear to me that the opposition to
removing __cmp__ comes down to "make the common things easy and
the rare things possible".  Removing __cmp__ means one of the
common things (total ordering) becomes hard."

hashcollision:
> On Jan 5, 2008 10:40 PM, hashcollision <hashcollision at gmail.com> wrote:
> > David A. Wheeler has already written a draft PEP, which can be found here:
> > http://www.dwheeler.com/misc/pep-cmp.txt.

You can blame me for that :-).


Guido van Rossum:
> Thanks, I'd missed that.
> 
> But alas, it's a bit short on the motivation for rich comparisons. For
> example it fails to notice that quite a few object types need to be
> comparable for equality but need not be orderable. Comparison for
> equality only is often much faster than a full three-way-compare,
> since there is likely some quick test that decides two instances
> cannot possibly be equal (e.g. lists of different lengths).

A fair comment.  But if you really only want to know 'equal/not-equal',
I think it's reasonable to presume that the user will just use == or !=,
instead of __cmp__ directly.  I don't propose removing == or !=, because
they're still needed for the asymmetric cases.  In those cases, I'd expect
that the user would write == or !=, which would then invoke __eq__ or
__ne__, which would make the decision.  If there's a performance difference,
for the basic types I'd expect Python to just implement == or != in the "faster"
way directly - so __cmp__ wouldn't matter in such cases.

I'll try to modify the draft PEP to cover that.

> It also misses the use case of overloading < and <= as set inclusion
> operators.

Okay.  Well, I can add this:
    Note that < and <= will continue to be overloaded as 
    set inclusion operators.

But I think there's more behind this comment that I don't understand.
Can you help me understand why that's a serious problem for __cmp__?

> But the biggest thing missing is precise semantics. Saying "exactly
> the same semantics as with Python 2.5" doesn't cut it (those semantics
> are incredibly hairy and sometimes surprising, and their
> implementation was a nightmare -- I've rarely been as relieved as when
> I was able to cut those out of the implementation).

Okay.  I made a stab, it's almost certainly wrong, suggestions welcome.
It should be _simple_, returning +1,0, or -1.

> A PEP should specify exactly what happens when both __cmp__ and one or
> more of the __xx__ operators are defined on the same class;

I think the goal should be "not surprising". IE: When you use a specific relationship like "<",
it calls __lt__(); the implementation of __lt__ may call __cmp__.

> it should
> specify what it means to override one or the other in a subclass;

Fair enough.  Hopefully that follows from the above.

> and
> it should define Python and C APIs for invoking __cmp__

I suggest using the 2.5 interfaces - is there a reason that must change?

> (and what it
> should do if __cmp__ isn't defined).

I'd expect it to do the same thing as calling __foo__ if __foo__ isn't defined.
Indeed, anything else would be surprising.

> I also notice that, because not-equal can often be decided more
> quickly than a full ordering, the argument (which I brought up
> myself!) that not having __cmp__ would slow down list comparisons may
> be wrong or at least weak. E.g., for the sake of argument, let's
> assume that __eq__ is just 10% faster than __cmp__, and __lt__ is as
> fast as __eq__. Then comparing two lists using __cmp__ on successive
> element pairs would be slower than using __eq__ plus one final __lt__
> if the deciding element is beyond the 9th index. If __eq__ is twice as
> fast as __cmp__ and __lt__ is the same speed as __cmp__, using __cmp__
> would be slower beyond the 2nd index.

True, but if that's true for a particular comparison, then the
implementation of __cmp__ could ITSELF implement the comparison that way.
Besides, if I understand you correctly, that presumes that the
user is keeping track of all the subelements through the comparison.
That's a pain; I'd rather say "compare these items", let the structures
do all the tracking, and get just the final answer.

Anyway, I hope this helps.

--- David A. Wheeler

From arigo at tunes.org  Mon Jan 14 18:59:43 2008
From: arigo at tunes.org (Armin Rigo)
Date: Mon, 14 Jan 2008 18:59:43 +0100
Subject: [Python-3000] [Python-Dev]  inst_persistent_id
In-Reply-To: <acd65fa20801121633l2ae5202j8a7d75d7933ce91e@mail.gmail.com>
References: <A2A6D220-45A7-4C04-8D4E-CBBB919D55E1@zope.com>
	<acd65fa20801121633l2ae5202j8a7d75d7933ce91e@mail.gmail.com>
Message-ID: <20080114175943.GA26431@code0.codespeak.net>

Hi,

On Sat, Jan 12, 2008 at 07:33:38PM -0500, Alexandre Vassalotti wrote:
> Well, in Python 3K, inst_persistent_id() won't be usable, since
> PyInstance_Type was removed.

Looking at the code, inst_persistent_id() is just a confusing name.  It
has got nothing to do with PyInstance_Type; it's called for any object
type that cPickle.c doesn't know how to handle.  In fact, it seems that
cPickle.c never calls inst_persistent_id() for objects of type
PyInstance_Type...


A bientot,

Armin.

From lars at ibp.de  Fri Jan 18 22:37:25 2008
From: lars at ibp.de (Lars Immisch)
Date: Fri, 18 Jan 2008 22:37:25 +0100
Subject: [Python-3000] Need closure on __cmp__ removal
In-Reply-To: <E1JEus7-0004OT-66@fenris.runbox.com>
References: <37f76d50801052240w44bbf29arb80d7e7b1a451710@mail.gmail.com>	<ca471dc20801062001m148b343ex450a9093c8c1359a@mail.gmail.com>
	<E1JEus7-0004OT-66@fenris.runbox.com>
Message-ID: <47911C15.6040000@ibp.de>

David A. Wheeler wrote:
> Bill Janssen:
>> I'm a bit baffled here; I find cmp() fairly handy in writing sort routines...
>> Is there a better / newer / official way of doing this? If not, isn't
>> "cmp()" still useful to have around?
> 
> I agree with you - I find cmp() useful, and I notice that some others do too.
> E.G., Adam Olson said "It's clear to me that the opposition to
> removing __cmp__ comes down to "make the common things easy and
> the rare things possible".  Removing __cmp__ means one of the
> common things (total ordering) becomes hard."

I like cmp, too. I've looked through my code, and I've only used it in 
script-ish circumstances, but here is an example that sorts a list of 
files by modification date:

def cmp_mtime(f, g):
     """Too much for a lambda for my tastes."""
     return cmp(os.stat(f).st_mtime, os.stat(g).st_mtime)

files = os.listdir('.')
files.sort(cmp_mtime)

- Lars

From mike.klaas at gmail.com  Fri Jan 18 23:24:01 2008
From: mike.klaas at gmail.com (Mike Klaas)
Date: Fri, 18 Jan 2008 14:24:01 -0800
Subject: [Python-3000] Need closure on __cmp__ removal
In-Reply-To: <47911C15.6040000@ibp.de>
References: <37f76d50801052240w44bbf29arb80d7e7b1a451710@mail.gmail.com>	<ca471dc20801062001m148b343ex450a9093c8c1359a@mail.gmail.com>
	<E1JEus7-0004OT-66@fenris.runbox.com> <47911C15.6040000@ibp.de>
Message-ID: <393B5AFD-B064-4B2B-9B4C-F9C5D7096893@gmail.com>

On 18-Jan-08, at 1:37 PM, Lars Immisch wrote:
>
> I like cmp, too. I've looked through my code, and I've only used it in
> script-ish circumstances, but here is an example that sorts a list of
> files by modification date:
>
> def cmp_mtime(f, g):
>      """Too much for a lambda for my tastes."""
>      return cmp(os.stat(f).st_mtime, os.stat(g).st_mtime)
>
> files = os.listdir('.')
> files.sort(cmp_mtime)

The use case of sort-function delegating to cmp() of part of an  
object is covered by the key= parameter, which is faster and more  
succinct:

files = os.listdir('.')
files.sort(key=lambda f: os.stat(f).st_mtime)

Grepping though my team's codebase, I see some uses similar to yours  
above, but all can be replaced with key=.  Personally, I don't see  
the attraction of writing sort functions this way: I fell in love  
with key= the moment I discovered it.

The relative frequency is 84 key-based sorts to 9 cmp()-based sorts  
(admittedly that is more due to my influence than to a natural  
distribution).

-Mike

From lars at ibp.de  Fri Jan 18 23:54:32 2008
From: lars at ibp.de (Lars Immisch)
Date: Fri, 18 Jan 2008 23:54:32 +0100
Subject: [Python-3000] Need closure on __cmp__ removal
In-Reply-To: <393B5AFD-B064-4B2B-9B4C-F9C5D7096893@gmail.com>
References: <37f76d50801052240w44bbf29arb80d7e7b1a451710@mail.gmail.com>	<ca471dc20801062001m148b343ex450a9093c8c1359a@mail.gmail.com>
	<E1JEus7-0004OT-66@fenris.runbox.com> <47911C15.6040000@ibp.de>
	<393B5AFD-B064-4B2B-9B4C-F9C5D7096893@gmail.com>
Message-ID: <47912E28.8010208@ibp.de>

Mike Klaas wrote:
> On 18-Jan-08, at 1:37 PM, Lars Immisch wrote:
>>
>> I like cmp, too. I've looked through my code, and I've only used it in
>> script-ish circumstances, but here is an example that sorts a list of
>> files by modification date:
>>
>> def cmp_mtime(f, g):
>>      """Too much for a lambda for my tastes."""
>>      return cmp(os.stat(f).st_mtime, os.stat(g).st_mtime)
>>
>> files = os.listdir('.')
>> files.sort(cmp_mtime)
> 
> The use case of sort-function delegating to cmp() of part of an object 
> is covered by the key= parameter, which is faster and more succinct:
> 
> files = os.listdir('.')
> files.sort(key=lambda f: os.stat(f).st_mtime)

You are right.

> Grepping though my team's codebase, I see some uses similar to yours 
> above, but all can be replaced with key=.  Personally, I don't see the 
> attraction of writing sort functions this way: I fell in love with key= 
> the moment I discovered it.
> 
> The relative frequency is 84 key-based sorts to 9 cmp()-based sorts 
> (admittedly that is more due to my influence than to a natural 
> distribution).

I know off hand how cmp should look like, but with 'key' I think 
'attribute access', even if it isn't. My head is stuck with 2.3, it seems.

- Lars

From jim at zope.com  Sun Jan 20 22:14:11 2008
From: jim at zope.com (Jim Fulton)
Date: Sun, 20 Jan 2008 16:14:11 -0500
Subject: [Python-3000] [Python-Dev]  inst_persistent_id
In-Reply-To: <acd65fa20801121633l2ae5202j8a7d75d7933ce91e@mail.gmail.com>
References: <A2A6D220-45A7-4C04-8D4E-CBBB919D55E1@zope.com>
	<acd65fa20801121633l2ae5202j8a7d75d7933ce91e@mail.gmail.com>
Message-ID: <EFB69A57-3547-4F53-AFA0-871ED571764F@zope.com>


On Jan 12, 2008, at 7:33 PM, Alexandre Vassalotti wrote:
> By the way, you might be interested to look at my work on pickle [1]
> for Python 3K. As part of last year Summer of Code, I removed the
> differences between the Python and C implementation of pickle, and
> thus allowing the C version to be transparently used, instead of the
> Python one, when it is available.

Interesting. Does that mean that cPickle can be extended through  
inheritance?

> Currently, I am polishing the code
> for inclusion into the main branch.

Are you doing any benchmarking?

(I'm worried by the performance impact of allowing extending through  
inheritance. :)

> I also started to work on the next
> version of the pickle protocol, that will make it more suitable for
> Python 3K. If you are interested to help out, just send me an email
> and I will explain you what needs to be done.


I'm interested, but I don't think I have time. :(

Jim

--
Jim Fulton
Zope Corporation



From alexandre at peadrop.com  Mon Jan 21 04:39:15 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Sun, 20 Jan 2008 22:39:15 -0500
Subject: [Python-3000] [Python-Dev]  inst_persistent_id
In-Reply-To: <EFB69A57-3547-4F53-AFA0-871ED571764F@zope.com>
References: <A2A6D220-45A7-4C04-8D4E-CBBB919D55E1@zope.com>
	<acd65fa20801121633l2ae5202j8a7d75d7933ce91e@mail.gmail.com>
	<EFB69A57-3547-4F53-AFA0-871ED571764F@zope.com>
Message-ID: <acd65fa20801201939m191b7d95s7b4ae7dae617ada4@mail.gmail.com>

On Jan 20, 2008 4:14 PM, Jim Fulton <jim at zope.com> wrote:
>
> On Jan 12, 2008, at 7:33 PM, Alexandre Vassalotti wrote:
> > By the way, you might be interested to look at my work on pickle [1]
> > for Python 3K. As part of last year Summer of Code, I removed the
> > differences between the Python and C implementation of pickle, and
> > thus allowing the C version to be transparently used, instead of the
> > Python one, when it is available.
>
> Interesting. Does that mean that cPickle can be extended through
> inheritance?
>

Well, Pickler and Unpickler can be subclassed. I am not sure they can
be really "extended," since, unlike the Python version, the C version
of Pickler and Unpickler only exposes a minimal API.

> > Currently, I am polishing the code
> > for inclusion into the main branch.
>
> Are you doing any benchmarking?
>

Yes.

> (I'm worried by the performance impact of allowing extending through
> inheritance. :)

Well, I haven't changed cPickle much to make it subclassable. So, the
impact is minimal. Currently, the only performance change is due the
removal of the special-cases for PyFile and cStringIO "buffers."

> > I also started to work on the next
> > version of the pickle protocol, that will make it more suitable for
> > Python 3K. If you are interested to help out, just send me an email
> > and I will explain you what needs to be done.
>
>
> I'm interested, but I don't think I have time. :(
>

I am short of time, too. :-)

-- Alexandre

From dlitz at dlitz.net  Tue Jan 22 07:47:03 2008
From: dlitz at dlitz.net (Dwayne C. Litzenberger)
Date: Tue, 22 Jan 2008 00:47:03 -0600
Subject: [Python-3000] exception-swallowing behaviour of hasattr
Message-ID: <20080122064703.GA24619@rivest.dlitz.net>

This issue has been raised before, but Guido thought that changing things 
in 2.x would break too much code.  See:

     http://mail.python.org/pipermail/python-dev/2005-February/051770.html
     http://mail.python.org/pipermail/python-dev/2005-December/058498.html
     http://bugs.python.org/issue504714

I'm bringing this up again because the arguments I've seen in favour of 
fixing hasattr have been fairly weak, and I'd like to raise some stronger 
ones.  Also, I haven't seen this issue considered specifically in the 
context of Python 3000.

The problem is that hasattr behaves just like the following code:

     def hasattr(obj, name):
         try:
             getattr(obj, name)
             return True
         except:
             return False

In Python 3000, all exceptions inherit from BaseException, so this is 
equivalent to:

     def hasattr(obj, name):
         try:
             getattr(obj, name)
             return True
         except BaseException:
             return False

There are three major things that are broken by this behaviour, which I 
don't think have been explicitly mentioned:

     1. If the Python interpreter receives SIGINT (usually triggered by 
        Ctrl-C) while executing obj.__getattr__ (or anything it calls), 
        hasattr silently returns False and the program continues running.

        Cause: KeyboardInterrupt is swallowed.

     2. If sys.exit is called within obj.__getattr__, hasattr silently 
        returns False and the program continues running.

        Cause: SystemExit is swallowed.

     3. If an assert statement fails within obj.__getattr__, hasattr 
        silently returns False and the program continues running.

        Cause: AssertionError is swallowed.

Also, because getattr(x,y,z) swallows only AttributeError, users naturally 
expect hasattr to behave the same way.  (This argument has been raised 
before.)

I propose a few alternate behaviours for hasattr (and their consequences):

     1. Swallow only AttributeError.

         - KeyboardInterrupt, SystemExit, and AssertionError are all passed 
           through, solving all three of the above problems.

         - The behaviour of hasattr is made consistent with getattr(x,y,z).

     2. Swallow only Exception.

         - KeyboardInterrupt and SystemExit are passed through, but 
           AssertionError is still swallowed.

         - Breaks less code than the previous option.

     3. Swallow Exception unless it's an AssertionError.

         - KeyboardInterrupt, SystemExit, and AssertionError are all passed 
           through, solving all three of the above problems.

         - Kind of ugly.

     4. Swallow everything except KeyboardInterrupt and SystemExit.

         - AssertionError is still swallowed, but the other problems are 
           fixed and this probably won't break any existing code.

I looked at bltinmodule.c, and any of these would be trivial to implement.

Ideally, I would like to see the first option implemented in Python 3000 
and one of the other options implemented in 2.x.

-- 
Dwayne C. Litzenberger <dlitz at dlitz.net>

From lists at cheimes.de  Tue Jan 22 08:14:20 2008
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 22 Jan 2008 08:14:20 +0100
Subject: [Python-3000] exception-swallowing behaviour of hasattr
In-Reply-To: <20080122064703.GA24619@rivest.dlitz.net>
References: <20080122064703.GA24619@rivest.dlitz.net>
Message-ID: <479597CC.4050903@cheimes.de>

Dwayne C. Litzenberger wrote:
> I'm bringing this up again because the arguments I've seen in favour of 
> fixing hasattr have been fairly weak, and I'd like to raise some stronger 
> ones.  Also, I haven't seen this issue considered specifically in the 
> context of Python 3000.

The behavior of hasattr and (IIRC) isinstance and issubclass has been a
problem for several applications. For instance Zope requires code to
re-raise ConflictErrors. ZODB conflict errors must bubble through the
program flow until it hits the ZODB transaction system so it can re-roll
the transaction.

> I propose a few alternate behaviours for hasattr (and their consequences):
> 
>      1. Swallow only AttributeError.
> 
>          - KeyboardInterrupt, SystemExit, and AssertionError are all passed 
>            through, solving all three of the above problems.
> 
>          - The behaviour of hasattr is made consistent with getattr(x,y,z).

I prefer 1) for Python 3.0

>      2. Swallow only Exception.
> 
>          - KeyboardInterrupt and SystemExit are passed through, but 
>            AssertionError is still swallowed.
> 
>          - Breaks less code than the previous option.

I think it's a sensible solution for Python 2.6.

Christian

From lists at cheimes.de  Tue Jan 22 08:14:20 2008
From: lists at cheimes.de (Christian Heimes)
Date: Tue, 22 Jan 2008 08:14:20 +0100
Subject: [Python-3000] exception-swallowing behaviour of hasattr
In-Reply-To: <20080122064703.GA24619@rivest.dlitz.net>
References: <20080122064703.GA24619@rivest.dlitz.net>
Message-ID: <479597CC.4050903@cheimes.de>

Dwayne C. Litzenberger wrote:
> I'm bringing this up again because the arguments I've seen in favour of 
> fixing hasattr have been fairly weak, and I'd like to raise some stronger 
> ones.  Also, I haven't seen this issue considered specifically in the 
> context of Python 3000.

The behavior of hasattr and (IIRC) isinstance and issubclass has been a
problem for several applications. For instance Zope requires code to
re-raise ConflictErrors. ZODB conflict errors must bubble through the
program flow until it hits the ZODB transaction system so it can re-roll
the transaction.

> I propose a few alternate behaviours for hasattr (and their consequences):
> 
>      1. Swallow only AttributeError.
> 
>          - KeyboardInterrupt, SystemExit, and AssertionError are all passed 
>            through, solving all three of the above problems.
> 
>          - The behaviour of hasattr is made consistent with getattr(x,y,z).

I prefer 1) for Python 3.0

>      2. Swallow only Exception.
> 
>          - KeyboardInterrupt and SystemExit are passed through, but 
>            AssertionError is still swallowed.
> 
>          - Breaks less code than the previous option.

I think it's a sensible solution for Python 2.6.

Christian


From jim at zope.com  Tue Jan 22 16:30:27 2008
From: jim at zope.com (Jim Fulton)
Date: Tue, 22 Jan 2008 10:30:27 -0500
Subject: [Python-3000] [Python-Dev]  inst_persistent_id
In-Reply-To: <acd65fa20801201939m191b7d95s7b4ae7dae617ada4@mail.gmail.com>
References: <A2A6D220-45A7-4C04-8D4E-CBBB919D55E1@zope.com>
	<acd65fa20801121633l2ae5202j8a7d75d7933ce91e@mail.gmail.com>
	<EFB69A57-3547-4F53-AFA0-871ED571764F@zope.com>
	<acd65fa20801201939m191b7d95s7b4ae7dae617ada4@mail.gmail.com>
Message-ID: <A862A59F-7C37-4E09-A9FF-D5B8C32965B3@zope.com>


On Jan 20, 2008, at 10:39 PM, Alexandre Vassalotti wrote:

> On Jan 20, 2008 4:14 PM, Jim Fulton <jim at zope.com> wrote:
>>
>> On Jan 12, 2008, at 7:33 PM, Alexandre Vassalotti wrote:
>>> By the way, you might be interested to look at my work on pickle [1]
>>> for Python 3K. As part of last year Summer of Code, I removed the
>>> differences between the Python and C implementation of pickle, and
>>> thus allowing the C version to be transparently used, instead of the
>>> Python one, when it is available.
>>
>> Interesting. Does that mean that cPickle can be extended through
>> inheritance?
>>
>
> Well, Pickler and Unpickler can be subclassed. I am not sure they can
> be really "extended," since, unlike the Python version, the C version
> of Pickler and Unpickler only exposes a minimal API.

Then I don't understand what you mean by:

"I removed the differences between the Python and C implementation of  
pickle, and thus allowing the C version to be transparently used,  
instead of the Python one, when it is available."

People *do* routinely subclass pickle.Pickler and pickle.Unpickler and  
if this isn't possible with cPickle, then it can't be substituted for  
pickle.  If making cPickle.Pickler and cPickle.Unpickler subclassible  
in the same way as the pickle classes makes cPickle much slower, then  
I don't think the "transparency" is worth the tradeoff.

...

> Well, I haven't changed cPickle much to make it subclassable. So, the
> impact is minimal. Currently, the only performance change is due the
> removal of the special-cases for PyFile and cStringIO "buffers."

What is the benefit of removing this special casing? What is the cost?

Jim

--
Jim Fulton
Zope Corporation



From guido at python.org  Tue Jan 22 16:36:12 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 22 Jan 2008 07:36:12 -0800
Subject: [Python-3000] exception-swallowing behaviour of hasattr
In-Reply-To: <20080122064703.GA24619@rivest.dlitz.net>
References: <20080122064703.GA24619@rivest.dlitz.net>
Message-ID: <ca471dc20801220736j54f31197wfd7ba28150a40278@mail.gmail.com>

IMO (1) or (2) are both acceptable, but I'd prefer (2): swallow
'Exception'. There's a reason why hasattr() is different from
getattr() with a default value; it's too early for me to explain it
clearly, but I know it was discussed and argued at length when
hasattr() was introduced.

I don't see why AssertionError ought to be treated differently than
TypeError or any other "regular" error. The key goal here is to avoid
swallowing KeyboardInterrupt, and to a lesser extend SystemExit.

--Guido

On Jan 21, 2008 10:47 PM, Dwayne C. Litzenberger <dlitz at dlitz.net> wrote:
> This issue has been raised before, but Guido thought that changing things
> in 2.x would break too much code.  See:
>
>      http://mail.python.org/pipermail/python-dev/2005-February/051770.html
>      http://mail.python.org/pipermail/python-dev/2005-December/058498.html
>      http://bugs.python.org/issue504714
>
> I'm bringing this up again because the arguments I've seen in favour of
> fixing hasattr have been fairly weak, and I'd like to raise some stronger
> ones.  Also, I haven't seen this issue considered specifically in the
> context of Python 3000.
>
> The problem is that hasattr behaves just like the following code:
>
>      def hasattr(obj, name):
>          try:
>              getattr(obj, name)
>              return True
>          except:
>              return False
>
> In Python 3000, all exceptions inherit from BaseException, so this is
> equivalent to:
>
>      def hasattr(obj, name):
>          try:
>              getattr(obj, name)
>              return True
>          except BaseException:
>              return False
>
> There are three major things that are broken by this behaviour, which I
> don't think have been explicitly mentioned:
>
>      1. If the Python interpreter receives SIGINT (usually triggered by
>         Ctrl-C) while executing obj.__getattr__ (or anything it calls),
>         hasattr silently returns False and the program continues running.
>
>         Cause: KeyboardInterrupt is swallowed.
>
>      2. If sys.exit is called within obj.__getattr__, hasattr silently
>         returns False and the program continues running.
>
>         Cause: SystemExit is swallowed.
>
>      3. If an assert statement fails within obj.__getattr__, hasattr
>         silently returns False and the program continues running.
>
>         Cause: AssertionError is swallowed.
>
> Also, because getattr(x,y,z) swallows only AttributeError, users naturally
> expect hasattr to behave the same way.  (This argument has been raised
> before.)
>
> I propose a few alternate behaviours for hasattr (and their consequences):
>
>      1. Swallow only AttributeError.
>
>          - KeyboardInterrupt, SystemExit, and AssertionError are all passed
>            through, solving all three of the above problems.
>
>          - The behaviour of hasattr is made consistent with getattr(x,y,z).
>
>      2. Swallow only Exception.
>
>          - KeyboardInterrupt and SystemExit are passed through, but
>            AssertionError is still swallowed.
>
>          - Breaks less code than the previous option.
>
>      3. Swallow Exception unless it's an AssertionError.
>
>          - KeyboardInterrupt, SystemExit, and AssertionError are all passed
>            through, solving all three of the above problems.
>
>          - Kind of ugly.
>
>      4. Swallow everything except KeyboardInterrupt and SystemExit.
>
>          - AssertionError is still swallowed, but the other problems are
>            fixed and this probably won't break any existing code.
>
> I looked at bltinmodule.c, and any of these would be trivial to implement.
>
> Ideally, I would like to see the first option implemented in Python 3000
> and one of the other options implemented in 2.x.
>
> --
> Dwayne C. Litzenberger <dlitz at dlitz.net>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From arkanes at gmail.com  Tue Jan 22 18:31:03 2008
From: arkanes at gmail.com (Chris Mellon)
Date: Tue, 22 Jan 2008 11:31:03 -0600
Subject: [Python-3000] exception-swallowing behaviour of hasattr
In-Reply-To: <ca471dc20801220736j54f31197wfd7ba28150a40278@mail.gmail.com>
References: <20080122064703.GA24619@rivest.dlitz.net>
	<ca471dc20801220736j54f31197wfd7ba28150a40278@mail.gmail.com>
Message-ID: <4866bea60801220931s687b18eh91a9ec7a508e851d@mail.gmail.com>

On Jan 22, 2008 9:36 AM, Guido van Rossum <guido at python.org> wrote:
> IMO (1) or (2) are both acceptable, but I'd prefer (2): swallow
> 'Exception'. There's a reason why hasattr() is different from
> getattr() with a default value; it's too early for me to explain it
> clearly, but I know it was discussed and argued at length when
> hasattr() was introduced.
>
> I don't see why AssertionError ought to be treated differently than
> TypeError or any other "regular" error. The key goal here is to avoid
> swallowing KeyboardInterrupt, and to a lesser extend SystemExit.
>
> --Guido
>

A particularly nasty case is that it swallows RecursionLimitExceededError.

From guido at python.org  Tue Jan 22 18:36:39 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 22 Jan 2008 09:36:39 -0800
Subject: [Python-3000] exception-swallowing behaviour of hasattr
In-Reply-To: <4866bea60801220931s687b18eh91a9ec7a508e851d@mail.gmail.com>
References: <20080122064703.GA24619@rivest.dlitz.net>
	<ca471dc20801220736j54f31197wfd7ba28150a40278@mail.gmail.com>
	<4866bea60801220931s687b18eh91a9ec7a508e851d@mail.gmail.com>
Message-ID: <ca471dc20801220936n6e70695dhcfbdf550203ea61e@mail.gmail.com>

On Jan 22, 2008 9:31 AM, Chris Mellon <arkanes at gmail.com> wrote:
> On Jan 22, 2008 9:36 AM, Guido van Rossum <guido at python.org> wrote:
> > IMO (1) or (2) are both acceptable, but I'd prefer (2): swallow
> > 'Exception'. There's a reason why hasattr() is different from
> > getattr() with a default value; it's too early for me to explain it
> > clearly, but I know it was discussed and argued at length when
> > hasattr() was introduced.
> >
> > I don't see why AssertionError ought to be treated differently than
> > TypeError or any other "regular" error. The key goal here is to avoid
> > swallowing KeyboardInterrupt, and to a lesser extend SystemExit.
> >
> > --Guido
> >
>
> A particularly nasty case is that it swallows RecursionLimitExceededError.

Why is that nastier than other bugs?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From arkanes at gmail.com  Tue Jan 22 18:39:25 2008
From: arkanes at gmail.com (Chris Mellon)
Date: Tue, 22 Jan 2008 11:39:25 -0600
Subject: [Python-3000] exception-swallowing behaviour of hasattr
In-Reply-To: <ca471dc20801220936n6e70695dhcfbdf550203ea61e@mail.gmail.com>
References: <20080122064703.GA24619@rivest.dlitz.net>
	<ca471dc20801220736j54f31197wfd7ba28150a40278@mail.gmail.com>
	<4866bea60801220931s687b18eh91a9ec7a508e851d@mail.gmail.com>
	<ca471dc20801220936n6e70695dhcfbdf550203ea61e@mail.gmail.com>
Message-ID: <4866bea60801220939y438cfe7bh8f13cb18e506de2c@mail.gmail.com>

On Jan 22, 2008 11:36 AM, Guido van Rossum <guido at python.org> wrote:
>
> On Jan 22, 2008 9:31 AM, Chris Mellon <arkanes at gmail.com> wrote:
> > On Jan 22, 2008 9:36 AM, Guido van Rossum <guido at python.org> wrote:
> > > IMO (1) or (2) are both acceptable, but I'd prefer (2): swallow
> > > 'Exception'. There's a reason why hasattr() is different from
> > > getattr() with a default value; it's too early for me to explain it
> > > clearly, but I know it was discussed and argued at length when
> > > hasattr() was introduced.
> > >
> > > I don't see why AssertionError ought to be treated differently than
> > > TypeError or any other "regular" error. The key goal here is to avoid
> > > swallowing KeyboardInterrupt, and to a lesser extend SystemExit.
> > >
> > > --Guido
> > >
> >
> > A particularly nasty case is that it swallows RecursionLimitExceededError.
>
> Why is that nastier than other bugs?
>
>

Because when you mess up your hooks and end up with recursion through
hasattr, you get a hang followed by a segfault instead of an
exception. MemoryError might have similar effects.

(And of course I meant RuntimeError, not whatever thing I said)

From guido at python.org  Tue Jan 22 18:59:18 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 22 Jan 2008 09:59:18 -0800
Subject: [Python-3000] exception-swallowing behaviour of hasattr
In-Reply-To: <4866bea60801220939y438cfe7bh8f13cb18e506de2c@mail.gmail.com>
References: <20080122064703.GA24619@rivest.dlitz.net>
	<ca471dc20801220736j54f31197wfd7ba28150a40278@mail.gmail.com>
	<4866bea60801220931s687b18eh91a9ec7a508e851d@mail.gmail.com>
	<ca471dc20801220936n6e70695dhcfbdf550203ea61e@mail.gmail.com>
	<4866bea60801220939y438cfe7bh8f13cb18e506de2c@mail.gmail.com>
Message-ID: <ca471dc20801220959n517c99acnc75eb32faa830d9d@mail.gmail.com>

On Jan 22, 2008 9:39 AM, Chris Mellon <arkanes at gmail.com> wrote:
>
> On Jan 22, 2008 11:36 AM, Guido van Rossum <guido at python.org> wrote:
> >
> > On Jan 22, 2008 9:31 AM, Chris Mellon <arkanes at gmail.com> wrote:
> > > On Jan 22, 2008 9:36 AM, Guido van Rossum <guido at python.org> wrote:
> > > > IMO (1) or (2) are both acceptable, but I'd prefer (2): swallow
> > > > 'Exception'. There's a reason why hasattr() is different from
> > > > getattr() with a default value; it's too early for me to explain it
> > > > clearly, but I know it was discussed and argued at length when
> > > > hasattr() was introduced.
> > > >
> > > > I don't see why AssertionError ought to be treated differently than
> > > > TypeError or any other "regular" error. The key goal here is to avoid
> > > > swallowing KeyboardInterrupt, and to a lesser extend SystemExit.
> > > >
> > > > --Guido
> > > >
> > >
> > > A particularly nasty case is that it swallows RecursionLimitExceededError.
> >
> > Why is that nastier than other bugs?
> >
> >
>
> Because when you mess up your hooks and end up with recursion through
> hasattr, you get a hang followed by a segfault instead of an
> exception. MemoryError might have similar effects.
>
> (And of course I meant RuntimeError, not whatever thing I said)

Sorry, you are talking a language I don't understand.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From tomerfiliba at gmail.com  Tue Jan 22 21:36:11 2008
From: tomerfiliba at gmail.com (tomer filiba)
Date: Tue, 22 Jan 2008 22:36:11 +0200
Subject: [Python-3000] Fwd: [Python-Dev] misbehaving __contains__
In-Reply-To: <ca471dc20801221155y72f4f438qaab06d3c509a6c90@mail.gmail.com>
References: <9834f887-7e99-4c3f-9ec1-b28f798b36b4@s13g2000prd.googlegroups.com>
	<ca471dc20801221155y72f4f438qaab06d3c509a6c90@mail.gmail.com>
Message-ID: <1d85506f0801221236m13fb50a0x39800c4eb508ed31@mail.gmail.com>

i can work on a patch, but before i start, i want to make sure it's
accepted. the change will require sq_contains to return a PyObject,
as well as some minor tweaks to cmp_outcome().


-tomer

---------- Forwarded message ----------
From: Guido van Rossum <guido at python.org>
Date: Jan 22, 2008 9:55 PM
Subject: Re: [Python-Dev] misbehaving __contains__
To: tomer filiba <tomerfiliba at gmail.com>
Cc: python-dev at python.org


The issue is that the sq_contains slot is defined as returning an int,
while the tp_richcompare slot is defined as returning a PyObject *.

Your first opportunity for changing this will be Py3k. Please submit a patch!



On Jan 22, 2008 11:26 AM, tomer filiba <tomerfiliba at gmail.com> wrote:
> i'm using python to create expression objects, for more intuitive
> usage as
> predicates, for instance:
>     x = (Arg(0) > 17) & (Arg(1).foo == "bar")
> instead of
>     x = And(Gt(Arg(0), 17), Eq(GetAttr(Arg(1), "foo"), "bar"))
>
> so now i can use x.eval(18, "spam") and get the result of the
> expression.
>
> i'm doing it by overriding all the operators to return expression
> objects, instead of evaluating the result immediately. it works
> fine, but i encountered a problem with making
> __contains__ behave so.
>
> it turns out __contains__ coerces the return value into a bool.
> this might seem logical at first, but is not consistent with
> the rest of the language.
>
> consider the following code:
>
> >>> class Foo(object):
> ...     def __contains__(self, key):
> ...             return 17
> ...     def __eq__(self, other):
> ...             return 19
> ...
> >>>
> >>> f=Foo()
> >>> f == 8
> 19
> >>> 8 in f
> True
>
> as you can see, __eq__ does not coerces the result to bool, so why
> should __contains__ do that?
>
> i've looked at PySequence_Contains in objects/abstract.c, but i can't
> quite understand where the coercion is made. is because the
> function is typed as int? if so, i believe it should either be
> changed to PyObject, or have cmp_outcome (in ceval.c) not use this
> API directly, and rather return the result, as it is returned
> from __contains__.
>
> i see no reason it should behave differently than __eq__ and the rest
> of comparison operators.
>
>
> -tomer

--
--Guido van Rossum (home page: http://www.python.org/~guido/)

From tomerfiliba at gmail.com  Tue Jan 22 21:55:14 2008
From: tomerfiliba at gmail.com (tomer filiba)
Date: Tue, 22 Jan 2008 22:55:14 +0200
Subject: [Python-3000] Fwd: [Python-Dev] misbehaving __contains__
In-Reply-To: <478D8E02-DF65-40C0-AA55-8A8382742228@nicko.org>
References: <9834f887-7e99-4c3f-9ec1-b28f798b36b4@s13g2000prd.googlegroups.com>
	<ca471dc20801221155y72f4f438qaab06d3c509a6c90@mail.gmail.com>
	<1d85506f0801221236m13fb50a0x39800c4eb508ed31@mail.gmail.com>
	<478D8E02-DF65-40C0-AA55-8A8382742228@nicko.org>
Message-ID: <1d85506f0801221255i1390b7cfw934cbc74637ff845@mail.gmail.com>

On Jan 22, 2008 10:48 PM, Nicko van Someren <nicko at nicko.org> wrote:
> I don't know if your patch will be accepted but two salient questions
> you should address are:
>         a) Will the change break much existing code?
>         b) Will the change substantially impact performance?

well, i will take care of all the places in the core that define a
sq_contains method (not many), and i don't believe many extension
types implement it themselves, so the impact is expected to
be marginal.

as for the tweak in cmp_outcome, it's outside the eval-loop, so
there's no reason for a performance penalty.

-tomer

From guido at python.org  Tue Jan 22 22:36:33 2008
From: guido at python.org (Guido van Rossum)
Date: Tue, 22 Jan 2008 13:36:33 -0800
Subject: [Python-3000] [Python-Dev] misbehaving __contains__
In-Reply-To: <1d85506f0801221236m13fb50a0x39800c4eb508ed31@mail.gmail.com>
References: <9834f887-7e99-4c3f-9ec1-b28f798b36b4@s13g2000prd.googlegroups.com>
	<ca471dc20801221155y72f4f438qaab06d3c509a6c90@mail.gmail.com>
	<1d85506f0801221236m13fb50a0x39800c4eb508ed31@mail.gmail.com>
Message-ID: <ca471dc20801221336u7c0994f3o3e99d745737d09b2@mail.gmail.com>

I can't promise a patch is accepted before I see it. :-)

But the idea is sound, so don't worry about it being rejected on the
basis of being an undesirable feature.

--Guido

On Jan 22, 2008 12:36 PM, tomer filiba <tomerfiliba at gmail.com> wrote:
> i can work on a patch, but before i start, i want to make sure it's
> accepted. the change will require sq_contains to return a PyObject,
> as well as some minor tweaks to cmp_outcome().
>
>
> -tomer
>
> ---------- Forwarded message ----------
> From: Guido van Rossum <guido at python.org>
> Date: Jan 22, 2008 9:55 PM
> Subject: Re: [Python-Dev] misbehaving __contains__
> To: tomer filiba <tomerfiliba at gmail.com>
> Cc: python-dev at python.org
>
>
> The issue is that the sq_contains slot is defined as returning an int,
> while the tp_richcompare slot is defined as returning a PyObject *.
>
> Your first opportunity for changing this will be Py3k. Please submit a patch!
>
>
>
> On Jan 22, 2008 11:26 AM, tomer filiba <tomerfiliba at gmail.com> wrote:
> > i'm using python to create expression objects, for more intuitive
> > usage as
> > predicates, for instance:
> >     x = (Arg(0) > 17) & (Arg(1).foo == "bar")
> > instead of
> >     x = And(Gt(Arg(0), 17), Eq(GetAttr(Arg(1), "foo"), "bar"))
> >
> > so now i can use x.eval(18, "spam") and get the result of the
> > expression.
> >
> > i'm doing it by overriding all the operators to return expression
> > objects, instead of evaluating the result immediately. it works
> > fine, but i encountered a problem with making
> > __contains__ behave so.
> >
> > it turns out __contains__ coerces the return value into a bool.
> > this might seem logical at first, but is not consistent with
> > the rest of the language.
> >
> > consider the following code:
> >
> > >>> class Foo(object):
> > ...     def __contains__(self, key):
> > ...             return 17
> > ...     def __eq__(self, other):
> > ...             return 19
> > ...
> > >>>
> > >>> f=Foo()
> > >>> f == 8
> > 19
> > >>> 8 in f
> > True
> >
> > as you can see, __eq__ does not coerces the result to bool, so why
> > should __contains__ do that?
> >
> > i've looked at PySequence_Contains in objects/abstract.c, but i can't
> > quite understand where the coercion is made. is because the
> > function is typed as int? if so, i believe it should either be
> > changed to PyObject, or have cmp_outcome (in ceval.c) not use this
> > API directly, and rather return the result, as it is returned
> > from __contains__.
> >
> > i see no reason it should behave differently than __eq__ and the rest
> > of comparison operators.
> >
> >
> > -tomer
>
> --
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From nicko at nicko.org  Tue Jan 22 21:48:25 2008
From: nicko at nicko.org (Nicko van Someren)
Date: Tue, 22 Jan 2008 20:48:25 +0000
Subject: [Python-3000] Fwd: [Python-Dev] misbehaving __contains__
In-Reply-To: <1d85506f0801221236m13fb50a0x39800c4eb508ed31@mail.gmail.com>
References: <9834f887-7e99-4c3f-9ec1-b28f798b36b4@s13g2000prd.googlegroups.com>
	<ca471dc20801221155y72f4f438qaab06d3c509a6c90@mail.gmail.com>
	<1d85506f0801221236m13fb50a0x39800c4eb508ed31@mail.gmail.com>
Message-ID: <478D8E02-DF65-40C0-AA55-8A8382742228@nicko.org>

On 22 Jan 2008, at 20:36, tomer filiba wrote:

> i can work on a patch, but before i start, i want to make sure it's
> accepted. the change will require sq_contains to return a PyObject,
> as well as some minor tweaks to cmp_outcome().

I don't know if your patch will be accepted but two salient questions  
you should address are:
	a) Will the change break much existing code?
	b) Will the change substantially impact performance?

It seems to me that the answer should be 'no' to both questions, which  
is a good start!

	Nicko


> ---------- Forwarded message ----------
> From: Guido van Rossum <guido at python.org>
> Date: Jan 22, 2008 9:55 PM
> Subject: Re: [Python-Dev] misbehaving __contains__
> To: tomer filiba <tomerfiliba at gmail.com>
> Cc: python-dev at python.org
>
>
> The issue is that the sq_contains slot is defined as returning an int,
> while the tp_richcompare slot is defined as returning a PyObject *.
>
> Your first opportunity for changing this will be Py3k. Please submit  
> a patch!


From rhettinger at fattoc.com  Wed Jan 23 01:47:50 2008
From: rhettinger at fattoc.com (Raymond Hettinger)
Date: Tue, 22 Jan 2008 16:47:50 -0800
Subject: [Python-3000] Ellipsis Literal
Message-ID: <47968EB6.9010503@fattoc.com>

I missed the conversation on this one.
Was there a use case or a reason to add this?
I ask because the spelling has an unfortunate
overlap with the sys.ps2 prompt:

>>> def f(x):
...     return x+1

I don't know if this is a problem.  Just thought I would bring it up.


Raymond

From robert.kern at gmail.com  Wed Jan 23 08:37:40 2008
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 23 Jan 2008 01:37:40 -0600
Subject: [Python-3000] Ellipsis Literal
In-Reply-To: <47968EB6.9010503@fattoc.com>
References: <47968EB6.9010503@fattoc.com>
Message-ID: <fn6qs4$qf6$1@ger.gmane.org>

Raymond Hettinger wrote:
> I missed the conversation on this one.
> Was there a use case or a reason to add this?

It was added for Numeric a long time ago. We use it in multidimensional indices 
to specify slice(None, None, None) for all of the omitted dimensions. For example:


In [25]: from numpy import *

In [26]: a = arange(2*3*4).reshape([2,3,4])

In [27]: a
Out[27]:
array([[[ 0,  1,  2,  3],
         [ 4,  5,  6,  7],
         [ 8,  9, 10, 11]],

        [[12, 13, 14, 15],
         [16, 17, 18, 19],
         [20, 21, 22, 23]]])

In [28]: a[...,0]
Out[28]:
array([[ 0,  4,  8],
        [12, 16, 20]])

In [29]: a[:,:,0]
Out[29]:
array([[ 0,  4,  8],
        [12, 16, 20]])

In [30]: a[1,...]
Out[30]:
array([[12, 13, 14, 15],
        [16, 17, 18, 19],
        [20, 21, 22, 23]])

In [31]: a[1,:,:]
Out[31]:
array([[12, 13, 14, 15],
        [16, 17, 18, 19],
        [20, 21, 22, 23]])

In [32]: a[1,...,0]
Out[32]: array([12, 16, 20])

In [33]: a[1,:,0]
Out[33]: array([12, 16, 20])


 > I ask because the spelling has an unfortunate
 > overlap with the sys.ps2 prompt:
 >
 >>>> def f(x):
 > ...     return x+1
 >
 > I don't know if this is a problem.  Just thought I would bring it up.

I've never encountered a problem with this ambiguity. At least, not in software. 
I don't know if affects newbie-comprehension of code snippets.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco


From lists at cheimes.de  Wed Jan 23 14:29:47 2008
From: lists at cheimes.de (Christian Heimes)
Date: Wed, 23 Jan 2008 14:29:47 +0100
Subject: [Python-3000] Fwd: [Python-Dev] misbehaving __contains__
In-Reply-To: <478D8E02-DF65-40C0-AA55-8A8382742228@nicko.org>
References: <9834f887-7e99-4c3f-9ec1-b28f798b36b4@s13g2000prd.googlegroups.com>	<ca471dc20801221155y72f4f438qaab06d3c509a6c90@mail.gmail.com>	<1d85506f0801221236m13fb50a0x39800c4eb508ed31@mail.gmail.com>
	<478D8E02-DF65-40C0-AA55-8A8382742228@nicko.org>
Message-ID: <fn7fgb$ujr$1@ger.gmane.org>

Nicko van Someren wrote:
> I don't know if your patch will be accepted but two salient questions  
> you should address are:
> 	a) Will the change break much existing code?
> 	b) Will the change substantially impact performance?
> 
> It seems to me that the answer should be 'no' to both questions, which  
> is a good start!

I don't agree with you. I believe the answer to both questions is yes.
It will break every C code and it may slow down existing C code unless
you implement and optimize a fast path for Py_True and Py_False.

Christian


From jimjjewett at gmail.com  Wed Jan 23 16:54:36 2008
From: jimjjewett at gmail.com (Jim Jewett)
Date: Wed, 23 Jan 2008 10:54:36 -0500
Subject: [Python-3000] Ellipsis Literal
In-Reply-To: <fn6qs4$qf6$1@ger.gmane.org>
References: <47968EB6.9010503@fattoc.com> <fn6qs4$qf6$1@ger.gmane.org>
Message-ID: <fb6fbf560801230754h797b357gc6b3ddb860599a7a@mail.gmail.com>

On 1/23/08, Robert Kern <robert.kern at gmail.com> wrote:
> Raymond Hettinger wrote:
>  > I ask because the spelling has an unfortunate
>  > overlap with the sys.ps2 prompt:

>  >>>> def f(x):
>  > ...     return x+1
>  >
>  > I don't know if this is a problem.  Just thought I would bring it up.

> I've never encountered a problem with this ambiguity. At least, not in software.
> I don't know if affects newbie-comprehension of code snippets.

It did cause me some grief at one time, because I would try to
cut-and-paste examples (including docstrings).  Obviously, a block cut
(or copy) would have been better, at least in IDLE.  There might also
be room to improve the error messages, but I'm not entirely sure how.

-jJ

From alexandre at peadrop.com  Wed Jan 23 22:30:00 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Wed, 23 Jan 2008 16:30:00 -0500
Subject: [Python-3000] [Python-Dev]  inst_persistent_id
In-Reply-To: <A862A59F-7C37-4E09-A9FF-D5B8C32965B3@zope.com>
References: <A2A6D220-45A7-4C04-8D4E-CBBB919D55E1@zope.com>
	<acd65fa20801121633l2ae5202j8a7d75d7933ce91e@mail.gmail.com>
	<EFB69A57-3547-4F53-AFA0-871ED571764F@zope.com>
	<acd65fa20801201939m191b7d95s7b4ae7dae617ada4@mail.gmail.com>
	<A862A59F-7C37-4E09-A9FF-D5B8C32965B3@zope.com>
Message-ID: <acd65fa20801231330r3fc24b24sbad1c62579a42a29@mail.gmail.com>

On Jan 22, 2008 10:30 AM, Jim Fulton <jim at zope.com> wrote:
>
> On Jan 20, 2008, at 10:39 PM, Alexandre Vassalotti wrote:
>
> > On Jan 20, 2008 4:14 PM, Jim Fulton <jim at zope.com> wrote:
> >>
> >> Interesting. Does that mean that cPickle can be extended through
> >> inheritance?
> >>
> >
> > Well, Pickler and Unpickler can be subclassed. I am not sure they can
> > be really "extended," since, unlike the Python version, the C version
> > of Pickler and Unpickler only exposes a minimal API.
>
> Then I don't understand what you mean by:
>
> "I removed the differences between the Python and C implementation of
> pickle, and thus allowing the C version to be transparently used,
> instead of the Python one, when it is available."
>
> People *do* routinely subclass pickle.Pickler and pickle.Unpickler and
> if this isn't possible with cPickle, then it can't be substituted for
> pickle.  If making cPickle.Pickler and cPickle.Unpickler subclassible
> in the same way as the pickle classes makes cPickle much slower, then
> I don't think the "transparency" is worth the tradeoff.
>

I am not sure what you mean by "cPickle.Pickler and cPickle.Unpickler
subclassible in the same way as the pickle classes." It is possible to
subclass the C implementation. However, the C implementation does not
expose pickle "private" methods, such as Pickler.save_int and
Unpickler.load_tuple. This is fine because these were never documented
as part of the interface of pickle. Only Pickler.dump,
Pickler.clear_memo and Unpickler.load are supported by the Python
implementation. All these are supported by the C implementation as
well.

So, what kind of "extensibility" are you looking for the C
implementation of pickle?

Quick note, one of the original motives for making the C
implementation of pickle transparent was to make it more "friendly"
for alternate implementations of Python (e.g., Jython, IronPython,
etc).

>
> > Well, I haven't changed cPickle much to make it subclassable. So, the
> > impact is minimal. Currently, the only performance change is due the
> > removal of the special-cases for PyFile and cStringIO "buffers."
>
> What is the benefit of removing this special casing? What is the cost?
>

As far as know, most of PyFile is gone in Py3k -- i.e., it been
castrated beyond recognition [1]. Therefore, the special case for
PyFile didn't improve the performance (in fact, it probably made
things go slower). I removed the special case for cStringIO for
similiar reason -- i.e., cStringIO will be replaced by the respective
C implementations of io.BytesIO and io.StringIO. I also did it because
it allowed me to keep the part of pickle that aren't speed critical
written in Python, thus cleaning out almost 1000 lines of code. The
performance cost of this is minimal and constant.

-- Alexandre

.. [1] http://svn.python.org/view/python/branches/py3k/Objects/fileobject.c?rev=59311&view=markup

From aahz at pythoncraft.com  Thu Jan 24 01:49:39 2008
From: aahz at pythoncraft.com (Aahz)
Date: Wed, 23 Jan 2008 16:49:39 -0800
Subject: [Python-3000] REMINDER: OSCON 2008 Call for Proposals
Message-ID: <20080124004939.GA6387@panix.com>

The O'Reilly Open Source Convention (OSCON) is accepting proposals for
tutorials and presentations.  The submission period ends Feb 4.

OSCON 2008 will be in Portland, Oregon July 21-25.  For more information
and to submit a proposal, see

http://conferences.oreilly.com/oscon/
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"All problems in computer science can be solved by another level of     
indirection."  --Butler Lampson

From jim at zope.com  Thu Jan 24 15:47:58 2008
From: jim at zope.com (Jim Fulton)
Date: Thu, 24 Jan 2008 09:47:58 -0500
Subject: [Python-3000] [Python-Dev]  inst_persistent_id
In-Reply-To: <acd65fa20801231330r3fc24b24sbad1c62579a42a29@mail.gmail.com>
References: <A2A6D220-45A7-4C04-8D4E-CBBB919D55E1@zope.com>
	<acd65fa20801121633l2ae5202j8a7d75d7933ce91e@mail.gmail.com>
	<EFB69A57-3547-4F53-AFA0-871ED571764F@zope.com>
	<acd65fa20801201939m191b7d95s7b4ae7dae617ada4@mail.gmail.com>
	<A862A59F-7C37-4E09-A9FF-D5B8C32965B3@zope.com>
	<acd65fa20801231330r3fc24b24sbad1c62579a42a29@mail.gmail.com>
Message-ID: <19ECF92A-31C8-48EE-AFEB-62055157EF96@zope.com>


On Jan 23, 2008, at 4:30 PM, Alexandre Vassalotti wrote:

> On Jan 22, 2008 10:30 AM, Jim Fulton <jim at zope.com> wrote:
>>
>> On Jan 20, 2008, at 10:39 PM, Alexandre Vassalotti wrote:
>>
>>> On Jan 20, 2008 4:14 PM, Jim Fulton <jim at zope.com> wrote:
>>>>
>>>> Interesting. Does that mean that cPickle can be extended through
>>>> inheritance?
>>>>
>>>
>>> Well, Pickler and Unpickler can be subclassed. I am not sure they  
>>> can
>>> be really "extended," since, unlike the Python version, the C  
>>> version
>>> of Pickler and Unpickler only exposes a minimal API.
>>
>> Then I don't understand what you mean by:
>>
>> "I removed the differences between the Python and C implementation of
>> pickle, and thus allowing the C version to be transparently used,
>> instead of the Python one, when it is available."
>>
>> People *do* routinely subclass pickle.Pickler and pickle.Unpickler  
>> and
>> if this isn't possible with cPickle, then it can't be substituted for
>> pickle.  If making cPickle.Pickler and cPickle.Unpickler subclassible
>> in the same way as the pickle classes makes cPickle much slower, then
>> I don't think the "transparency" is worth the tradeoff.
>>
>
> I am not sure what you mean by "cPickle.Pickler and cPickle.Unpickler
> subclassible in the same way as the pickle classes." It is possible to
> subclass the C implementation. However, the C implementation does not
> expose pickle "private" methods, such as Pickler.save_int and
> Unpickler.load_tuple. This is fine because these were never documented
> as part of the interface of pickle.

That doesn't mean that they aren't overridden.  I've overridden them  
in specialized applications.  I suspect that others have as well.


> Only Pickler.dump,
> Pickler.clear_memo and Unpickler.load are supported by the Python
> implementation. All these are supported by the C implementation as
> well.

How about find_class?  I actually prefer cPickle's way of handling this.

> So, what kind of "extensibility" are you looking for the C
> implementation of pickle?

I'm not really looking for anything that isn't there already.  The  
python pickle version is more extensible that cPickle and I find that  
valuable.  I don't want to make cPickle more flexible.  I'd willing to  
trade off speed and flexibility depending on the application.  I don't  
want to lose either in the interest of unification.

> Quick note, one of the original motives for making the C
> implementation of pickle transparent was to make it more "friendly"
> for alternate implementations of Python (e.g., Jython, IronPython,
> etc).

I don't know what that means.  I don't know that Jython or IronPython  
need to support cPickle. Honestly, I'd be happy to see a *much*  
smaller standard library and, IMO, the standard library doesn't need  
to include pickle or cPickle.

Having said that, I would agree that there are certain aspects of  
their external APIs that ought to be unified.  A good example is  
handling of globals.


>>> Well, I haven't changed cPickle much to make it subclassable. So,  
>>> the
>>> impact is minimal. Currently, the only performance change is due the
>>> removal of the special-cases for PyFile and cStringIO "buffers."
>>
>> What is the benefit of removing this special casing? What is the  
>> cost?
>>
>
> As far as know, most of PyFile is gone in Py3k -- i.e., it been
> castrated beyond recognition [1]. Therefore, the special case for
> PyFile didn't improve the performance (in fact, it probably made
> things go slower).

I'll have to skeptically take your work for it.  I take this to mean  
that there is no C API to write to file objects or their underlying  
files.  If there is a C API, then I'd be surprised if it wasn't faster  
than going though a Python API.  My initial skepticism of this change  
was along the lines of "if it aint broke, don't fix it".  It sounds  
like it was broke, so it makes sense to rip it out and only re- 
implement it if it makes sense later.

> I removed the special case for cStringIO for
> similiar reason -- i.e., cStringIO will be replaced by the respective
> C implementations of io.BytesIO and io.StringIO. I also did it because
> it allowed me to keep the part of pickle that aren't speed critical
> written in Python, thus cleaning out almost 1000 lines of code. The
> performance cost of this is minimal and constant.


OK, for the same reasons.

Jim

--
Jim Fulton
Zope Corporation



From lists at cheimes.de  Thu Jan 24 17:04:11 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 24 Jan 2008 17:04:11 +0100
Subject: [Python-3000] [Python-Dev]  inst_persistent_id
In-Reply-To: <19ECF92A-31C8-48EE-AFEB-62055157EF96@zope.com>
References: <A2A6D220-45A7-4C04-8D4E-CBBB919D55E1@zope.com>	<acd65fa20801121633l2ae5202j8a7d75d7933ce91e@mail.gmail.com>	<EFB69A57-3547-4F53-AFA0-871ED571764F@zope.com>	<acd65fa20801201939m191b7d95s7b4ae7dae617ada4@mail.gmail.com>	<A862A59F-7C37-4E09-A9FF-D5B8C32965B3@zope.com>	<acd65fa20801231330r3fc24b24sbad1c62579a42a29@mail.gmail.com>
	<19ECF92A-31C8-48EE-AFEB-62055157EF96@zope.com>
Message-ID: <fnactr$era$1@ger.gmane.org>

Jim Fulton wrote:
> I'll have to skeptically take your work for it.  I take this to mean  
> that there is no C API to write to file objects or their underlying  
> files.  If there is a C API, then I'd be surprised if it wasn't faster  
> than going though a Python API.  My initial skepticism of this change  
> was along the lines of "if it aint broke, don't fix it".  It sounds  
> like it was broke, so it makes sense to rip it out and only re- 
> implement it if it makes sense later.

Most parts of the C API for file object was rewritten in Python. Only
small parts are written in C (_fileio module). The C API still has some
convenient methods to write to a file object.

Alex is working on an optimized C implementation.


http://svn.python.org/view/python/branches/py3k/Modules/_fileio.c?rev=59565&view=auto
http://svn.python.org/view/python/branches/py3k/Include/fileobject.h?rev=59311&view=auto


From python at rcn.com  Thu Jan 24 20:16:33 2008
From: python at rcn.com (Raymond Hettinger)
Date: Thu, 24 Jan 2008 14:16:33 -0500 (EST)
Subject: [Python-3000] Ellipsis Literal
Message-ID: <20080124141633.AFQ57054@ms19.lnh.mail.rcn.net>

[Raymond Hettinger]
>> I missed the conversation on this one.
>> Was there a use case or a reason to add this?

[Robert Kern]
> It was added for Numeric a long time ago.

The ellipsis syntax has been around for a while.
What is new is the Ellipsis literal in Py3.0.
See snippets below.

Raymond


------------------------------------
Python 2.6a0 (trunk:59985:59987, Jan 15 2008, 12:54:09) [GCC 4.1.1 (Gentoo 4.1.1)] on linux2
>>> ...
 File "<stdin>", line 1
   ...
   ^
SyntaxError: invalid syntax

------------------------------------
Python 3.0a2+ (py3k:60204M, Jan 22 2008, 14:50:12) [GCC 4.1.1 (Gentoo 4.1.1)] on linux2
>>> ...
Ellipsis 

From guido at python.org  Thu Jan 24 20:32:24 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 24 Jan 2008 11:32:24 -0800
Subject: [Python-3000] Ellipsis Literal
In-Reply-To: <20080124141633.AFQ57054@ms19.lnh.mail.rcn.net>
References: <20080124141633.AFQ57054@ms19.lnh.mail.rcn.net>
Message-ID: <ca471dc20801241132q6d6df78ej845f4b637d1d5ea3@mail.gmail.com>

On Jan 24, 2008 11:16 AM, Raymond Hettinger <python at rcn.com> wrote:
> [Raymond Hettinger]
> >> I missed the conversation on this one.
> >> Was there a use case or a reason to add this?
>
> [Robert Kern]
> > It was added for Numeric a long time ago.
>
> The ellipsis syntax has been around for a while.
> What is new is the Ellipsis literal in Py3.0.
> See snippets below.
>
> Raymond
>
>
> ------------------------------------
> Python 2.6a0 (trunk:59985:59987, Jan 15 2008, 12:54:09) [GCC 4.1.1 (Gentoo 4.1.1)] on linux2
> >>> ...
>  File "<stdin>", line 1
>    ...
>    ^
> SyntaxError: invalid syntax
>
> ------------------------------------
> Python 3.0a2+ (py3k:60204M, Jan 22 2008, 14:50:12) [GCC 4.1.1 (Gentoo 4.1.1)] on linux2
> >>> ...
> Ellipsis

Some folks thought it would be cute to be able to write incomplete
code like this:

class C:
  def meth(self): ...
  ...

and have it be syntactically correct.

PEP 3100 has the reference:
* ``...`` to become a general expression element [16]_ [done]
.. [16] python-3000 email
   http://mail.python.org/pipermail/python-3000/2006-April/000996.html


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From python at rcn.com  Thu Jan 24 21:04:00 2008
From: python at rcn.com (Raymond Hettinger)
Date: Thu, 24 Jan 2008 15:04:00 -0500 (EST)
Subject: [Python-3000] Ellipsis
Message-ID: <20080124150400.AFQ66279@ms19.lnh.mail.rcn.net>

> Some folks thought it would be cute to be able to 
> write incomplete code like this:
>
> class C:
>   def meth(self): ...
>   ...
>
> and have it be syntactically correct.

Hmm, that *is* cute :-)

Raymond

From charles.merriam at gmail.com  Thu Jan 24 21:12:34 2008
From: charles.merriam at gmail.com (Charles Merriam)
Date: Thu, 24 Jan 2008 12:12:34 -0800
Subject: [Python-3000] Ellipsis
In-Reply-To: <20080124150400.AFQ66279@ms19.lnh.mail.rcn.net>
References: <20080124150400.AFQ66279@ms19.lnh.mail.rcn.net>
Message-ID: <b8c6f6c40801241212m4167c43fmbd9c940f0d8402e7@mail.gmail.com>

OK, I'll admit this is confusing to me.

Is "..." == pass?

So, does a line with tokens after the "..." get an error like
"characters after an elipses (...).  Did you cut and paste from IDLE?"


On Jan 24, 2008 12:04 PM, Raymond Hettinger <python at rcn.com> wrote:
> > Some folks thought it would be cute to be able to
> > write incomplete code like this:
> >
> > class C:
> >   def meth(self): ...
> >   ...
> >
> > and have it be syntactically correct.
>
> Hmm, that *is* cute :-)
>
> Raymond
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/charles.merriam%40gmail.com
>

From thomas at python.org  Thu Jan 24 21:16:45 2008
From: thomas at python.org (Thomas Wouters)
Date: Thu, 24 Jan 2008 12:16:45 -0800
Subject: [Python-3000] Ellipsis
In-Reply-To: <b8c6f6c40801241212m4167c43fmbd9c940f0d8402e7@mail.gmail.com>
References: <20080124150400.AFQ66279@ms19.lnh.mail.rcn.net>
	<b8c6f6c40801241212m4167c43fmbd9c940f0d8402e7@mail.gmail.com>
Message-ID: <9e804ac0801241216m339d4e69ia20ff7cf3633ab4d@mail.gmail.com>

On Jan 24, 2008 12:12 PM, Charles Merriam <charles.merriam at gmail.com> wrote:

> OK, I'll admit this is confusing to me.
>
> Is "..." == pass?


No, ... == Ellipsis.


> So, does a line with tokens after the "..." get an error like
> "characters after an elipses (...).  Did you cut and paste from IDLE?"
>

No, it'll get an error like "IndentationError: expected an indented block".
In other words, the exact same thing as before :)

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080124/10502bd8/attachment.htm 

From lists at cheimes.de  Thu Jan 24 22:14:09 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 24 Jan 2008 22:14:09 +0100
Subject: [Python-3000] Ellipsis
In-Reply-To: <20080124150400.AFQ66279@ms19.lnh.mail.rcn.net>
References: <20080124150400.AFQ66279@ms19.lnh.mail.rcn.net>
Message-ID: <fnav31$krr$1@ger.gmane.org>

Raymond Hettinger wrote:
>> Some folks thought it would be cute to be able to 
>> write incomplete code like this:
>>
>> class C:
>>   def meth(self): ...
>>   ...
>>
>> and have it be syntactically correct.
> 
> Hmm, that *is* cute :-)

Indeed! It's one character shorter than "pass", it requires much less
finger movement and it even looks cool. I like it

However ... can lead to strange looking code, too:

>>> ....__class__.__name__
'ellipsis'

Christian


From python at rcn.com  Thu Jan 24 23:32:02 2008
From: python at rcn.com (Raymond Hettinger)
Date: Thu, 24 Jan 2008 17:32:02 -0500 (EST)
Subject: [Python-3000] Set literal
Message-ID: <20080124173202.AFQ93921@ms19.lnh.mail.rcn.net>

I think it would be more useful for the {e1, e2, e3} literal to be a frozenset instead of a set.

In expressions like "x in {'html', 'xml', 'php'}" the compiler could optimize away the set construction and treat it as a constant.

In cases where we want to build-up mutable sets, we need to start with set() anyway:

    s = set()
    for elem in source:
        s.add(elem)

I don't think it would be typical to start with a partially filled-out set and then build-t up further:

   s = {'a', 'b', 'c'}   # rare use-case
   for elem in source:
       s.add(elem)

One of the primary use cases for frozensets is to be members of other sets or to be keys in a dict (esp. for graph representations).  The repr's of those nested structures are annoying to read because the word "frozenset" gets spelled-out over and over again.  Here's a few lines from the pprint() output for a graph of a cube:

  {frozenset([0, 1]): frozenset([frozenset([0]),
                                 frozenset([1]),
                                 frozenset([0, 1, 2])]),
   frozenset([0, 1, 2]): frozenset([frozenset([1, 2]),
                                    frozenset([0, 2]),
                                    frozenset([0, 1])])}


This would read *much* better with the new notation:

  {{0, 1}: {{0},
            {1},
            {0, 1, 2}},
  {0, 1, 2}: {{1, 2},
              {0, 2},
              {0, 1}}}

If you want to see how extremely bad the current repr's can get, see the repr for David Eppstein's cuboctahedron in the tests for pprint:  http://mail.python.org/pipermail/python-checkins/2008-January/065099.html

In short, I think we would be much better served by using the {} literal notation for frozensets.

Raymond


P.S.  A small side-benefit is it may put an end for interminable requests for a {:} or {/} notation for empty sets.  There's not much need for a literal for a empty frozenset (use "not s" instead).


From guido at python.org  Fri Jan 25 00:22:55 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 24 Jan 2008 15:22:55 -0800
Subject: [Python-3000] Set literal
In-Reply-To: <20080124173202.AFQ93921@ms19.lnh.mail.rcn.net>
References: <20080124173202.AFQ93921@ms19.lnh.mail.rcn.net>
Message-ID: <ca471dc20801241522l517afdet69539df2af565@mail.gmail.com>

Looking over the code base, frozensets are used rarely. So I don't
think this is warranted.

On Jan 24, 2008 2:32 PM, Raymond Hettinger <python at rcn.com> wrote:
> I think it would be more useful for the {e1, e2, e3} literal to be a frozenset instead of a set.
>
> In expressions like "x in {'html', 'xml', 'php'}" the compiler could optimize away the set construction and treat it as a constant.
>
> In cases where we want to build-up mutable sets, we need to start with set() anyway:
>
>     s = set()
>     for elem in source:
>         s.add(elem)
>
> I don't think it would be typical to start with a partially filled-out set and then build-t up further:
>
>    s = {'a', 'b', 'c'}   # rare use-case
>    for elem in source:
>        s.add(elem)
>
> One of the primary use cases for frozensets is to be members of other sets or to be keys in a dict (esp. for graph representations).  The repr's of those nested structures are annoying to read because the word "frozenset" gets spelled-out over and over again.  Here's a few lines from the pprint() output for a graph of a cube:
>
>   {frozenset([0, 1]): frozenset([frozenset([0]),
>                                  frozenset([1]),
>                                  frozenset([0, 1, 2])]),
>    frozenset([0, 1, 2]): frozenset([frozenset([1, 2]),
>                                     frozenset([0, 2]),
>                                     frozenset([0, 1])])}
>
>
> This would read *much* better with the new notation:
>
>   {{0, 1}: {{0},
>             {1},
>             {0, 1, 2}},
>   {0, 1, 2}: {{1, 2},
>               {0, 2},
>               {0, 1}}}
>
> If you want to see how extremely bad the current repr's can get, see the repr for David Eppstein's cuboctahedron in the tests for pprint:  http://mail.python.org/pipermail/python-checkins/2008-January/065099.html
>
> In short, I think we would be much better served by using the {} literal notation for frozensets.
>
> Raymond
>
>
> P.S.  A small side-benefit is it may put an end for interminable requests for a {:} or {/} notation for empty sets.  There's not much need for a literal for a empty frozenset (use "not s" instead).
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From python3now at gmail.com  Fri Jan 25 00:25:39 2008
From: python3now at gmail.com (James Thiele)
Date: Thu, 24 Jan 2008 15:25:39 -0800
Subject: [Python-3000] Ellipsis
In-Reply-To: <fnav31$krr$1@ger.gmane.org>
References: <20080124150400.AFQ66279@ms19.lnh.mail.rcn.net>
	<fnav31$krr$1@ger.gmane.org>
Message-ID: <8f01efd00801241525x4208a36aq17d6f3fe4e211e1a@mail.gmail.com>

On Jan 24, 2008 1:14 PM, Christian Heimes <lists at cheimes.de> wrote:


> Indeed! It's one character shorter than "pass", it requires much less
> finger movement and it even looks cool. I like it
>
> However ... can lead to strange looking code, too:
>
> >>> ....__class__.__name__
> 'ellipsis'

So ellipsis is a class?

Can it be subclassed as in:

class myclass(...):
    pass

From thomas at python.org  Fri Jan 25 00:38:29 2008
From: thomas at python.org (Thomas Wouters)
Date: Thu, 24 Jan 2008 15:38:29 -0800
Subject: [Python-3000] Ellipsis
In-Reply-To: <8f01efd00801241525x4208a36aq17d6f3fe4e211e1a@mail.gmail.com>
References: <20080124150400.AFQ66279@ms19.lnh.mail.rcn.net>
	<fnav31$krr$1@ger.gmane.org>
	<8f01efd00801241525x4208a36aq17d6f3fe4e211e1a@mail.gmail.com>
Message-ID: <9e804ac0801241538p52345714p77c8a19021a5ea22@mail.gmail.com>

On Jan 24, 2008 3:25 PM, James Thiele <python3now at gmail.com> wrote:

> On Jan 24, 2008 1:14 PM, Christian Heimes <lists at cheimes.de> wrote:
>
>
> > Indeed! It's one character shorter than "pass", it requires much less
> > finger movement and it even looks cool. I like it
> >
> > However ... can lead to strange looking code, too:
> >
> > >>> ....__class__.__name__
> > 'ellipsis'
>
> So ellipsis is a class?
>
> Can it be subclassed as in:
>
> class myclass(...):
>    pass


No, Ellipsis is a singleton, like None. ellipsis is Ellipsis's type, and you
can't subclass it:

>>> ...
Ellipsis

>>> Ellipsis
Ellipsis

>>> type(...)
<type 'ellipsis'>

>>> class Spam(...): pass
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot create 'ellipsis' instances

>>> class Spam(type(...)): pass
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: type 'ellipsis' is not an acceptable base type

 Compare with None:

>>> type(None)
<type 'NoneType'>

>>> class Spam(None): pass
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot create 'NoneType' instances

>>> class Spam(type(None)): pass
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: type 'NoneType' is not an acceptable base type

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080124/285518a0/attachment.htm 

From python at rcn.com  Fri Jan 25 01:12:47 2008
From: python at rcn.com (Raymond Hettinger)
Date: Thu, 24 Jan 2008 19:12:47 -0500 (EST)
Subject: [Python-3000] Set literal
Message-ID: <20080124191247.AFR08858@ms19.lnh.mail.rcn.net>

> Looking over the code base, frozensets are used rarely. 
> So I don't think this is warranted.

There is no shortage for perfect use cases in the form:

   if urlext in {'html', 'xml', 'php'}:
         . . .


If the curly braces are taken to mean a frozenset,
then the peepholer can code the whole thing as a 
compile time constant.  It is fast and clean.
You need not even be aware that you're using a
frozenset.

The use cases for set literals lean *heavily* toward
situtations where the set doesn't get mutated. It
would be nice if all that code got optimized down
to a compile time constant.

The cases for literals differ quite a bit from
general, dynamically formed sets.  I see little
advantage for {'html', 'xml', 'php'} being mutable.


Raymond

From skip at pobox.com  Fri Jan 25 01:13:42 2008
From: skip at pobox.com (skip at pobox.com)
Date: Thu, 24 Jan 2008 18:13:42 -0600
Subject: [Python-3000] Set literal
In-Reply-To: <ca471dc20801241522l517afdet69539df2af565@mail.gmail.com>
References: <20080124173202.AFQ93921@ms19.lnh.mail.rcn.net>
	<ca471dc20801241522l517afdet69539df2af565@mail.gmail.com>
Message-ID: <18329.10678.273241.241537@montanaro.dyndns.org>


    Guido> Looking over the code base, frozensets are used rarely. So I
    Guido> don't think this is warranted.

I kind of like the idea.  Raymond's arguments make sense to me.  Most of the
time if I bother to create a set literal it would be to use it as a
constant.

Skip

From barry at python.org  Fri Jan 25 01:23:57 2008
From: barry at python.org (Barry Warsaw)
Date: Thu, 24 Jan 2008 19:23:57 -0500
Subject: [Python-3000] Set literal
In-Reply-To: <20080124191247.AFR08858@ms19.lnh.mail.rcn.net>
References: <20080124191247.AFR08858@ms19.lnh.mail.rcn.net>
Message-ID: <6E7362E6-CECC-4F6A-8F99-07E0665CDAC4@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jan 24, 2008, at 7:12 PM, Raymond Hettinger wrote:

>> Looking over the code base, frozensets are used rarely.
>> So I don't think this is warranted.
>
> There is no shortage for perfect use cases in the form:
>
>   if urlext in {'html', 'xml', 'php'}:

It's interesting that you point this out because I've had debates with  
people about the difference between:

     if urlext in ['html', 'xml', 'php']:

and

     if urlext in ('html', 'xml', 'php'):

I generally prefer the latter but I know folks who prefer the former.   
What's interesting is that in both cases we're trying to ask if the  
key is a member of a literal set, and to me, it makes no sense for  
that literal to be mutable.  So I also think Raymond's idea has merit.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBR5ksHnEjvBPtnXfVAQJkCAP9Fe/3gp9Ar6bKmCEq9f6uwUdxjwvfpRdI
7hOhwU7u2/bCTfVv/bxYi6SYIs54xzBPruHxiQ5qNwduRPMTeDHcKfSw1XrByVip
uNvjzF4ul+hplYeetKYylDDJbBxUqHXRT27psHRluNRorr9dkcqjI73zxj4FdM9M
BCwXJfW/9hI=
=dYZQ
-----END PGP SIGNATURE-----

From jbarham at gmail.com  Fri Jan 25 01:32:48 2008
From: jbarham at gmail.com (John Barham)
Date: Thu, 24 Jan 2008 16:32:48 -0800
Subject: [Python-3000] Set literal
In-Reply-To: <6E7362E6-CECC-4F6A-8F99-07E0665CDAC4@python.org>
References: <20080124191247.AFR08858@ms19.lnh.mail.rcn.net>
	<6E7362E6-CECC-4F6A-8F99-07E0665CDAC4@python.org>
Message-ID: <4f34febc0801241632h3a7c9693tf6c8c8bd77ca4e9b@mail.gmail.com>

On Jan 24, 2008 4:23 PM, Barry Warsaw wrote:

> On Jan 24, 2008, at 7:12 PM, Raymond Hettinger wrote:
>
> >> Looking over the code base, frozensets are used rarely.
> >> So I don't think this is warranted.
> >
> > There is no shortage for perfect use cases in the form:
> >
> >   if urlext in {'html', 'xml', 'php'}:
>
> It's interesting that you point this out because I've had debates with
> people about the difference between:
>
>      if urlext in ['html', 'xml', 'php']:
>
> and
>
>      if urlext in ('html', 'xml', 'php'):
>
> I generally prefer the latter but I know folks who prefer the former.
> What's interesting is that in both cases we're trying to ask if the
> key is a member of a literal set, and to me, it makes no sense for
> that literal to be mutable.  So I also think Raymond's idea has merit.

Well I've measured the time difference and, at least in CPython on my
machine, constructing small tuples is quicker than constructing small
lists, although not enough to make any significant runtime difference.

But getting back to the original issue, what does using frozensets
gain you over using a tuple:

if urlext in ('html', 'xml', 'php'):

Given that tuples are also immutable, couldn't the peepholer also
optimize the tuple as a compile time constant?  Since this idiom is
usually used as a shortcut for:

if urlext == 'html' or urlext == 'xml' or urlext == 'php':

the semantics of using a frozenset are subtly different since with the
equivalent tuple you know the search is linear and short circuits on
success, but using a frozenset the search order is undefined.  Of
course if you had a largish search set, frozenset would probably be
quicker than using a tuple, but I think it's safe to say the search
set is small for the typical case.

  John

From python at rcn.com  Fri Jan 25 01:46:37 2008
From: python at rcn.com (Raymond Hettinger)
Date: Thu, 24 Jan 2008 19:46:37 -0500 (EST)
Subject: [Python-3000] Set literal
Message-ID: <20080124194637.AFR12976@ms19.lnh.mail.rcn.net>

[John Barham]
> But getting back to the original issue, what does using
> frozensets gain you over using a tuple:
>
> if urlext in ('html', 'xml', 'php'):

With sets, the search is O(1).
With tuples, it is O(n).
Sets win on inputs longer than 1.


Raymond

From steven.bethard at gmail.com  Fri Jan 25 01:52:18 2008
From: steven.bethard at gmail.com (Steven Bethard)
Date: Thu, 24 Jan 2008 17:52:18 -0700
Subject: [Python-3000] Set literal
In-Reply-To: <18329.10678.273241.241537@montanaro.dyndns.org>
References: <20080124173202.AFQ93921@ms19.lnh.mail.rcn.net>
	<ca471dc20801241522l517afdet69539df2af565@mail.gmail.com>
	<18329.10678.273241.241537@montanaro.dyndns.org>
Message-ID: <d11dcfba0801241652l6095bc61i1fa8df2b970b008b@mail.gmail.com>

On Jan 24, 2008 5:13 PM,  <skip at pobox.com> wrote:
>
>     Guido> Looking over the code base, frozensets are used rarely. So I
>     Guido> don't think this is warranted.
>
> I kind of like the idea.  Raymond's arguments make sense to me.  Most of the
> time if I bother to create a set literal it would be to use it as a
> constant.

Likewise.  I just took a look at my own code, and over 95% of the time
when I've written something like ``set([...])``, the set was never
modified.  (I found only one instance where it was, out of 47
instances.)

STeVe
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
        --- Bucky Katt, Get Fuzzy

From jyasskin at gmail.com  Fri Jan 25 02:38:49 2008
From: jyasskin at gmail.com (Jeffrey Yasskin)
Date: Thu, 24 Jan 2008 17:38:49 -0800
Subject: [Python-3000] Set literal
In-Reply-To: <18329.10678.273241.241537@montanaro.dyndns.org>
References: <20080124173202.AFQ93921@ms19.lnh.mail.rcn.net>
	<ca471dc20801241522l517afdet69539df2af565@mail.gmail.com>
	<18329.10678.273241.241537@montanaro.dyndns.org>
Message-ID: <5d44f72f0801241738j16bc0e5av93d683a5fd079f1a@mail.gmail.com>

On Jan 24, 2008 4:13 PM,  <skip at pobox.com> wrote:
>
>     Guido> Looking over the code base, frozensets are used rarely. So I
>     Guido> don't think this is warranted.
>
> I kind of like the idea.  Raymond's arguments make sense to me.  Most of the
> time if I bother to create a set literal it would be to use it as a
> constant.

Agreed. I suspect that "frozenset" is just too long to type often,
even if people are usually creating sets they don't intend to modify.

-- 
Namast?,
Jeffrey Yasskin

From alexandre at peadrop.com  Fri Jan 25 03:25:08 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Thu, 24 Jan 2008 21:25:08 -0500
Subject: [Python-3000] [Python-Dev]  inst_persistent_id
In-Reply-To: <19ECF92A-31C8-48EE-AFEB-62055157EF96@zope.com>
References: <A2A6D220-45A7-4C04-8D4E-CBBB919D55E1@zope.com>
	<acd65fa20801121633l2ae5202j8a7d75d7933ce91e@mail.gmail.com>
	<EFB69A57-3547-4F53-AFA0-871ED571764F@zope.com>
	<acd65fa20801201939m191b7d95s7b4ae7dae617ada4@mail.gmail.com>
	<A862A59F-7C37-4E09-A9FF-D5B8C32965B3@zope.com>
	<acd65fa20801231330r3fc24b24sbad1c62579a42a29@mail.gmail.com>
	<19ECF92A-31C8-48EE-AFEB-62055157EF96@zope.com>
Message-ID: <acd65fa20801241825g54dc8232h5bc4721426a7bb4d@mail.gmail.com>

On Jan 24, 2008 9:47 AM, Jim Fulton <jim at zope.com> wrote:
>
> On Jan 23, 2008, at 4:30 PM, Alexandre Vassalotti wrote:
> > I am not sure what you mean by "cPickle.Pickler and cPickle.Unpickler
> > subclassible in the same way as the pickle classes." It is possible to
> > subclass the C implementation. However, the C implementation does not
> > expose pickle "private" methods, such as Pickler.save_int and
> > Unpickler.load_tuple. This is fine because these were never documented
> > as part of the interface of pickle.
>
> That doesn't mean that they aren't overridden.  I've overridden them
> in specialized applications.  I suspect that others have as well.
>

Well even in pickle.py, you can't override the save_* and load_*
methods (at least, directly), since they are called via a dispatch
dictionary.

> > Only Pickler.dump,
> > Pickler.clear_memo and Unpickler.load are supported by the Python
> > implementation. All these are supported by the C implementation as
> > well.
>
> How about find_class?  I actually prefer cPickle's way of handling this.
>

I haven't thought much about these -- i.e., methods overrided via
__setattr__ -- yet. But, you are right -- they should be supported
too.

> > So, what kind of "extensibility" are you looking for the C
> > implementation of pickle?
>
> I'm not really looking for anything that isn't there already.  The
> python pickle version is more extensible that cPickle and I find that
> valuable.  I don't want to make cPickle more flexible.  I'd willing to
> trade off speed and flexibility depending on the application.  I don't
> want to lose either in the interest of unification.

How much of cPickle is really speed critical? Personally, I think
built-in types pickling should be optimized as much as possible and
other things, such as user-defined classes and extension types
pickling, could be done in Python.

> > Quick note, one of the original motives for making the C
> > implementation of pickle transparent was to make it more "friendly"
> > for alternate implementations of Python (e.g., Jython, IronPython,
> > etc).
>
> I don't know what that means.  I don't know that Jython or IronPython
> need to support cPickle.

Maybe, but it make it slightly harder for people to write code accross
these implementations. Interestingly, IronPython's team actually
reimplemented cPickle in C#:

http://www.codeplex.com/IronPython/SourceControl/FileView.aspx?itemId=296271&changeSetId=29832

> Having said that, I would agree that there are certain aspects of
> their external APIs that ought to be unified.  A good example is
> handling of globals.

Could you elaborate about this, please; how the handling of globals by
cPickle is different from pickle?

-- Alexandre

From alexandre at peadrop.com  Fri Jan 25 03:33:33 2008
From: alexandre at peadrop.com (Alexandre Vassalotti)
Date: Thu, 24 Jan 2008 21:33:33 -0500
Subject: [Python-3000] [Python-Dev]  inst_persistent_id
In-Reply-To: <acd65fa20801241825g54dc8232h5bc4721426a7bb4d@mail.gmail.com>
References: <A2A6D220-45A7-4C04-8D4E-CBBB919D55E1@zope.com>
	<acd65fa20801121633l2ae5202j8a7d75d7933ce91e@mail.gmail.com>
	<EFB69A57-3547-4F53-AFA0-871ED571764F@zope.com>
	<acd65fa20801201939m191b7d95s7b4ae7dae617ada4@mail.gmail.com>
	<A862A59F-7C37-4E09-A9FF-D5B8C32965B3@zope.com>
	<acd65fa20801231330r3fc24b24sbad1c62579a42a29@mail.gmail.com>
	<19ECF92A-31C8-48EE-AFEB-62055157EF96@zope.com>
	<acd65fa20801241825g54dc8232h5bc4721426a7bb4d@mail.gmail.com>
Message-ID: <acd65fa20801241833keb53bd7vdfef2e45227bba71@mail.gmail.com>

On Jan 24, 2008 9:25 PM, Alexandre Vassalotti <alexandre at peadrop.com> wrote:
> Maybe, but it make it slightly harder for people to write code accross
> these implementations. Interestingly, IronPython's team actually
> reimplemented cPickle in C#:
>
> http://www.codeplex.com/IronPython/SourceControl/FileView.aspx?itemId=296271&changeSetId=29832
>

Oh, Jython also got their implementation too.

https://jython.svn.sourceforge.net/svnroot/jython/trunk/jython/src/org/python/modules/cPickle.java

-- Alexandre

From brett at python.org  Fri Jan 25 04:15:44 2008
From: brett at python.org (Brett Cannon)
Date: Thu, 24 Jan 2008 19:15:44 -0800
Subject: [Python-3000] Set literal
In-Reply-To: <5d44f72f0801241738j16bc0e5av93d683a5fd079f1a@mail.gmail.com>
References: <20080124173202.AFQ93921@ms19.lnh.mail.rcn.net>
	<ca471dc20801241522l517afdet69539df2af565@mail.gmail.com>
	<18329.10678.273241.241537@montanaro.dyndns.org>
	<5d44f72f0801241738j16bc0e5av93d683a5fd079f1a@mail.gmail.com>
Message-ID: <bbaeab100801241915w315363cfhb667550f8968a3f4@mail.gmail.com>

On Jan 24, 2008 5:38 PM, Jeffrey Yasskin <jyasskin at gmail.com> wrote:
> On Jan 24, 2008 4:13 PM,  <skip at pobox.com> wrote:
> >
> >     Guido> Looking over the code base, frozensets are used rarely. So I
> >     Guido> don't think this is warranted.
> >
> > I kind of like the idea.  Raymond's arguments make sense to me.  Most of the
> > time if I bother to create a set literal it would be to use it as a
> > constant.
>
> Agreed. I suspect that "frozenset" is just too long to type often,
> even if people are usually creating sets they don't intend to modify.

I never thought of that, but that is a good point. There is also a
greater chance people will look for 'set' at the interpreter, find it,
and just not come across frozenset. Luckily the docs mention both
side-by-side, so reading the docs makes this explanation a little less
plausible.

-Brett

From jimjjewett at gmail.com  Fri Jan 25 04:20:12 2008
From: jimjjewett at gmail.com (Jim Jewett)
Date: Thu, 24 Jan 2008 22:20:12 -0500
Subject: [Python-3000] Set literal
In-Reply-To: <20080124194637.AFR12976@ms19.lnh.mail.rcn.net>
References: <20080124194637.AFR12976@ms19.lnh.mail.rcn.net>
Message-ID: <fb6fbf560801241920x53e5f9e0h3df54176406d99b3@mail.gmail.com>

On 1/24/08, Raymond Hettinger <python at rcn.com> wrote:
> [John Barham]
> > But getting back to the original issue, what does using
> > frozensets gain you over using a tuple:
> >
> > if urlext in ('html', 'xml', 'php'):
>
> With sets, the search is O(1).
> With tuples, it is O(n).
> Sets win on inputs longer than 1.

I thought you tried changing those tuples to frozensets (because it
was semantically better), and found that it didn't actually win for
tuples of length 2 or 3.

-jJ

From python at rcn.com  Fri Jan 25 04:56:36 2008
From: python at rcn.com (Raymond Hettinger)
Date: Thu, 24 Jan 2008 22:56:36 -0500 (EST)
Subject: [Python-3000] Set literal
Message-ID: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>

[Jim Jewett]
> I thought you tried changing those tuples to frozensets
>(because it was semantically better), and found that it 
> didn't actually win for tuples of length 2 or 3.

The sets were faster.  The automatic transformation didn't
go in because it changed semantics -- the searched for item
would need to be hashable -- the tuple search only requires
an equality test.


Raymond

From guido at python.org  Fri Jan 25 05:12:05 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 24 Jan 2008 20:12:05 -0800
Subject: [Python-3000] Set literal
In-Reply-To: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
Message-ID: <ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>

For the record, I'm thinking Raymond has won this argument fair and
square, and I'm withdrawing my opposition.

I hope it isn't too confusing that {1: 1} creates a *mutable* dict
while {1} creates an *immutable* frozenset. I still find this slightly
inelegant. But the practicality of being able to treat set literals as
compile-time constants wins me over.

(I suspect for a 2-element set of ints or strings, translating "x in
{C1, C2}" into "x in (C1, C2)" might actually be a slight win since
probing a tuple must be much faster than probing a set; but that's a
detail.)

--Guido

On Jan 24, 2008 7:56 PM, Raymond Hettinger <python at rcn.com> wrote:
> [Jim Jewett]
> > I thought you tried changing those tuples to frozensets
> >(because it was semantically better), and found that it
> > didn't actually win for tuples of length 2 or 3.
>
> The sets were faster.  The automatic transformation didn't
> go in because it changed semantics -- the searched for item
> would need to be hashable -- the tuple search only requires
> an equality test.
>
>
> Raymond
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From aahz at pythoncraft.com  Fri Jan 25 05:59:06 2008
From: aahz at pythoncraft.com (Aahz)
Date: Thu, 24 Jan 2008 20:59:06 -0800
Subject: [Python-3000] [Python-Dev]  inst_persistent_id
In-Reply-To: <19ECF92A-31C8-48EE-AFEB-62055157EF96@zope.com>
References: <A2A6D220-45A7-4C04-8D4E-CBBB919D55E1@zope.com>
	<acd65fa20801121633l2ae5202j8a7d75d7933ce91e@mail.gmail.com>
	<EFB69A57-3547-4F53-AFA0-871ED571764F@zope.com>
	<acd65fa20801201939m191b7d95s7b4ae7dae617ada4@mail.gmail.com>
	<A862A59F-7C37-4E09-A9FF-D5B8C32965B3@zope.com>
	<acd65fa20801231330r3fc24b24sbad1c62579a42a29@mail.gmail.com>
	<19ECF92A-31C8-48EE-AFEB-62055157EF96@zope.com>
Message-ID: <20080125045906.GA21722@panix.com>

On Thu, Jan 24, 2008, Jim Fulton wrote:
>
> I don't know what that means.  I don't know that Jython or IronPython  
> need to support cPickle. Honestly, I'd be happy to see a *much*  
> smaller standard library and, IMO, the standard library doesn't need  
> to include pickle or cPickle.

While it's easy enough to work around, my company would be unhappy if
pickle were removed, and so would my previous company.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"All problems in computer science can be solved by another level of     
indirection."  --Butler Lampson

From guido at python.org  Fri Jan 25 06:07:42 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 24 Jan 2008 21:07:42 -0800
Subject: [Python-3000] [Python-Dev] inst_persistent_id
In-Reply-To: <20080125045906.GA21722@panix.com>
References: <A2A6D220-45A7-4C04-8D4E-CBBB919D55E1@zope.com>
	<acd65fa20801121633l2ae5202j8a7d75d7933ce91e@mail.gmail.com>
	<EFB69A57-3547-4F53-AFA0-871ED571764F@zope.com>
	<acd65fa20801201939m191b7d95s7b4ae7dae617ada4@mail.gmail.com>
	<A862A59F-7C37-4E09-A9FF-D5B8C32965B3@zope.com>
	<acd65fa20801231330r3fc24b24sbad1c62579a42a29@mail.gmail.com>
	<19ECF92A-31C8-48EE-AFEB-62055157EF96@zope.com>
	<20080125045906.GA21722@panix.com>
Message-ID: <ca471dc20801242107x262bdcb0y9990df77a61a7a39@mail.gmail.com>

On Jan 24, 2008 8:59 PM, Aahz <aahz at pythoncraft.com> wrote:
> On Thu, Jan 24, 2008, Jim Fulton wrote:
> >
> > I don't know what that means.  I don't know that Jython or IronPython
> > need to support cPickle. Honestly, I'd be happy to see a *much*
> > smaller standard library and, IMO, the standard library doesn't need
> > to include pickle or cPickle.
>
> While it's easy enough to work around, my company would be unhappy if
> pickle were removed, and so would my previous company.

I don't know why Jim is saying this (*), but it's not going to happen.
pickle is here to stay. cPickle is a different story; 99% of programs
shouldn't be bothered with the choice between the two.

(*) I can only speculate that it's because Jim, whose ZODB is probably
pickle's most intensive user, would like to "own" it and would like to
evolve it much faster than the nearly frozen version in the standard
library. I would like to suggest that Jim can evolve pickle without
removing it from the standard library -- he could just include a fork
in the Zope package. As long as the Zope version were to use a
different magic number this would be a fine approach.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From jbarham at gmail.com  Fri Jan 25 06:09:03 2008
From: jbarham at gmail.com (John Barham)
Date: Thu, 24 Jan 2008 21:09:03 -0800
Subject: [Python-3000] Set literal
In-Reply-To: <ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
Message-ID: <4f34febc0801242109m302b6b06t5f9ef24f9f3ccfb7@mail.gmail.com>

Guido wrote:

> (I suspect for a 2-element set of ints or strings, translating "x in
> {C1, C2}" into "x in (C1, C2)" might actually be a slight win since
> probing a tuple must be much faster than probing a set; but that's a
> detail.)

A trivial but hopefully fairly representative benchmark:

ActivePython 2.5.1.1 (ActiveState Software Inc.) based on
Python 2.5.1 (r251:54863, May  1 2007, 17:47:05) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import timeit
>>> timeit.Timer("3 in (1,2,3)").timeit()
0.20900340099335493
>>> timeit.Timer("3 in frozenset((1,2,3))").timeit()
0.72151788129635008
>>> timeit.Timer("3 in choices", setup="choices = (1,2,3)").timeit()
0.21716441294536537
>>> timeit.Timer("3 in choices", setup="choices = frozenset((1,2,3))").timeit()
0.16064769736693307

This demonstrates that constructing a frozen set obviously takes
longer, but suggests that searching even within a 3-element set (the
construction time for which could presumably be amortized away by the
compiler) is quicker than in a tuple, which is heartening.  So the
only overhead for using frozen sets is slightly more memory...

  John

From guido at python.org  Fri Jan 25 06:17:38 2008
From: guido at python.org (Guido van Rossum)
Date: Thu, 24 Jan 2008 21:17:38 -0800
Subject: [Python-3000] Set literal
In-Reply-To: <4f34febc0801242109m302b6b06t5f9ef24f9f3ccfb7@mail.gmail.com>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<4f34febc0801242109m302b6b06t5f9ef24f9f3ccfb7@mail.gmail.com>
Message-ID: <ca471dc20801242117j39f6d1e4ob6ea2286ad9591d3@mail.gmail.com>

Thanks! I tried it again with a 2-element tuple and frozenset, and
with hits on the first and second item, and with a miss. I am
convinced. Even for a 2-element set, the frozenset comes out ahead
except compared to a hit on the first tuple item. So let's leave this
alone -- if the user writes a tuple, we use a tuple (because the
semantics are different), if the user writes a frozenset literal, we
use that.

--Guido

On Jan 24, 2008 9:09 PM, John Barham <jbarham at gmail.com> wrote:
> Guido wrote:
>
> > (I suspect for a 2-element set of ints or strings, translating "x in
> > {C1, C2}" into "x in (C1, C2)" might actually be a slight win since
> > probing a tuple must be much faster than probing a set; but that's a
> > detail.)
>
> A trivial but hopefully fairly representative benchmark:
>
> ActivePython 2.5.1.1 (ActiveState Software Inc.) based on
> Python 2.5.1 (r251:54863, May  1 2007, 17:47:05) [MSC v.1310 32 bit (Intel)] on
> win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import timeit
> >>> timeit.Timer("3 in (1,2,3)").timeit()
> 0.20900340099335493
> >>> timeit.Timer("3 in frozenset((1,2,3))").timeit()
> 0.72151788129635008
> >>> timeit.Timer("3 in choices", setup="choices = (1,2,3)").timeit()
> 0.21716441294536537
> >>> timeit.Timer("3 in choices", setup="choices = frozenset((1,2,3))").timeit()
> 0.16064769736693307
>
> This demonstrates that constructing a frozen set obviously takes
> longer, but suggests that searching even within a 3-element set (the
> construction time for which could presumably be amortized away by the
> compiler) is quicker than in a tuple, which is heartening.  So the
> only overhead for using frozen sets is slightly more memory...
>
>   John
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From martin at v.loewis.de  Fri Jan 25 07:25:36 2008
From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=)
Date: Fri, 25 Jan 2008 07:25:36 +0100
Subject: [Python-3000] Set literal
In-Reply-To: <4f34febc0801241632h3a7c9693tf6c8c8bd77ca4e9b@mail.gmail.com>
References: <20080124191247.AFR08858@ms19.lnh.mail.rcn.net>	<6E7362E6-CECC-4F6A-8F99-07E0665CDAC4@python.org>
	<4f34febc0801241632h3a7c9693tf6c8c8bd77ca4e9b@mail.gmail.com>
Message-ID: <479980E0.8040803@v.loewis.de>

> But getting back to the original issue, what does using frozensets
> gain you over using a tuple:
> 
> if urlext in ('html', 'xml', 'php'):
> 
> Given that tuples are also immutable, couldn't the peepholer also
> optimize the tuple as a compile time constant?

py> def f():
...   if urlext in ('html','xml','php'):return 3
...
py> dis.dis(f)
  2           0 LOAD_GLOBAL              0 (urlext)
              3 LOAD_CONST               5 (('html', 'xml', 'php'))
              6 COMPARE_OP               6 (in)
              9 JUMP_IF_FALSE            8 (to 20)
             12 POP_TOP
             13 LOAD_CONST               4 (3)
             16 RETURN_VALUE
             17 JUMP_FORWARD             1 (to 21)
        >>   20 POP_TOP
        >>   21 LOAD_CONST               0 (None)
             24 RETURN_VALUE


> Since this idiom is
> usually used as a shortcut for:
> 
> if urlext == 'html' or urlext == 'xml' or urlext == 'php':
> 
> the semantics of using a frozenset are subtly different since with the
> equivalent tuple you know the search is linear and short circuits on
> success, but using a frozenset the search order is undefined.  Of
> course if you had a largish search set, frozenset would probably be
> quicker than using a tuple, but I think it's safe to say the search
> set is small for the typical case.

Are you implying that the search is faster for a tuple if the set is
small?

Regards,
Martin

From rhamph at gmail.com  Fri Jan 25 07:40:12 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Thu, 24 Jan 2008 23:40:12 -0700
Subject: [Python-3000] Set literal
In-Reply-To: <20080124191247.AFR08858@ms19.lnh.mail.rcn.net>
References: <20080124191247.AFR08858@ms19.lnh.mail.rcn.net>
Message-ID: <aac2c7cb0801242240n3540d895i290d05b624954656@mail.gmail.com>

On Jan 24, 2008 5:12 PM, Raymond Hettinger <python at rcn.com> wrote:
> > Looking over the code base, frozensets are used rarely.
> > So I don't think this is warranted.
>
> There is no shortage for perfect use cases in the form:
>
>    if urlext in {'html', 'xml', 'php'}:
>          . . .
>
>
> If the curly braces are taken to mean a frozenset,
> then the peepholer can code the whole thing as a
> compile time constant.  It is fast and clean.
> You need not even be aware that you're using a
> frozenset.

Is there any reason preventing it from being optimized even with a
mutable set?  urlext only interacts with the items in the set, and
doesn't get to see the set itself, so I don't see why the "in"
operator couldn't trigger transforming it into a constant.

The same argument applies to list literals.  The only limitation I see
is whether or not calling hash() on urlext is considered an essential
part of the semantics - and I'm inclined to say "no".


-- 
Adam Olsen, aka Rhamphoryncus

From jbarham at gmail.com  Fri Jan 25 07:55:05 2008
From: jbarham at gmail.com (John Barham)
Date: Thu, 24 Jan 2008 22:55:05 -0800
Subject: [Python-3000] Set literal
In-Reply-To: <479980E0.8040803@v.loewis.de>
References: <20080124191247.AFR08858@ms19.lnh.mail.rcn.net>
	<6E7362E6-CECC-4F6A-8F99-07E0665CDAC4@python.org>
	<4f34febc0801241632h3a7c9693tf6c8c8bd77ca4e9b@mail.gmail.com>
	<479980E0.8040803@v.loewis.de>
Message-ID: <4f34febc0801242255v2e068e57i75abfff3a59fbc9f@mail.gmail.com>

Martin v. L?wis" wrote:

> Are you implying that the search is faster for a tuple if the set is
> small?

That was my intuition but the measurements say otherwise. ;)  Even for
sets as small as two or three elements, searches in frozensets are
faster than within tuples.  See my tuple vs. frozenset timeit results
and Guido's confirmation in a parallel thread.

  John

From mark at qtrac.eu  Fri Jan 25 08:18:23 2008
From: mark at qtrac.eu (Mark Summerfield)
Date: Fri, 25 Jan 2008 07:18:23 +0000
Subject: [Python-3000] Set literal
In-Reply-To: <ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
Message-ID: <200801250718.23840.mark@qtrac.eu>

On 2008-01-25, Guido van Rossum wrote:
> For the record, I'm thinking Raymond has won this argument fair and
> square, and I'm withdrawing my opposition.
>
> I hope it isn't too confusing that {1: 1} creates a *mutable* dict
> while {1} creates an *immutable* frozenset. I still find this slightly
> inelegant. But the practicality of being able to treat set literals as
> compile-time constants wins me over.

So this will produce:

    frozenset()	# empty frozen set
    {1}	    	# 1 item frozen set
    {1, 2}  	# 2 item frozen set
    {}	    	# empty dict
    {1:1}   	# 1 item dict
    {1:1, 2:2}	# 2 item dict

I think this is confusing and messy, especially for new Python programmers.

If you're going to make the change, why not make things consistent:

    {}		# empty frozen set
    {1}	    	# 1 item frozen set
    {1, 2}  	# 2 item frozen set
    {:}	    	# empty dict
    {1:1}   	# 1 item dict
    {1:1, 2:2}  # 2 item dict

-- 
Mark Summerfield, Qtrac Ltd., www.qtrac.eu


From steven.bethard at gmail.com  Fri Jan 25 08:33:44 2008
From: steven.bethard at gmail.com (Steven Bethard)
Date: Fri, 25 Jan 2008 00:33:44 -0700
Subject: [Python-3000] Set literal
In-Reply-To: <200801250718.23840.mark@qtrac.eu>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<200801250718.23840.mark@qtrac.eu>
Message-ID: <d11dcfba0801242333o33a93f54h607fb7cd738fd9e8@mail.gmail.com>

On Jan 25, 2008 12:18 AM, Mark Summerfield <mark at qtrac.eu> wrote:
> On 2008-01-25, Guido van Rossum wrote:
> > For the record, I'm thinking Raymond has won this argument fair and
> > square, and I'm withdrawing my opposition.
> >
> > I hope it isn't too confusing that {1: 1} creates a *mutable* dict
> > while {1} creates an *immutable* frozenset. I still find this slightly
> > inelegant. But the practicality of being able to treat set literals as
> > compile-time constants wins me over.
>
> So this will produce:
>
>     frozenset() # empty frozen set
>     {1}         # 1 item frozen set
>     {1, 2}      # 2 item frozen set
>     {}          # empty dict
>     {1:1}       # 1 item dict
>     {1:1, 2:2}  # 2 item dict
>
> I think this is confusing and messy, especially for new Python programmers.
>
> If you're going to make the change, why not make things consistent:
>
>     {}          # empty frozen set
>     {1}         # 1 item frozen set
>     {1, 2}      # 2 item frozen set
>     {:}         # empty dict
>     {1:1}       # 1 item dict
>     {1:1, 2:2}  # 2 item dict

This has been discussed and rejected as it would break too much code.
Check the archives during the set literals discussions.

STeVe
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
        --- Bucky Katt, Get Fuzzy

From mark at qtrac.eu  Fri Jan 25 10:29:49 2008
From: mark at qtrac.eu (Mark Summerfield)
Date: Fri, 25 Jan 2008 09:29:49 +0000
Subject: [Python-3000] Set literal
In-Reply-To: <d11dcfba0801242333o33a93f54h607fb7cd738fd9e8@mail.gmail.com>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<200801250718.23840.mark@qtrac.eu>
	<d11dcfba0801242333o33a93f54h607fb7cd738fd9e8@mail.gmail.com>
Message-ID: <200801250929.49286.mark@qtrac.eu>

On 2008-01-25, Steven Bethard wrote:
> On Jan 25, 2008 12:18 AM, Mark Summerfield <mark at qtrac.eu> wrote:
> > On 2008-01-25, Guido van Rossum wrote:
> > > For the record, I'm thinking Raymond has won this argument fair and
> > > square, and I'm withdrawing my opposition.
> > >
> > > I hope it isn't too confusing that {1: 1} creates a *mutable* dict
> > > while {1} creates an *immutable* frozenset. I still find this slightly
> > > inelegant. But the practicality of being able to treat set literals as
> > > compile-time constants wins me over.
> >
> > So this will produce:
> >
> >     frozenset() # empty frozen set
> >     {1}         # 1 item frozen set
> >     {1, 2}      # 2 item frozen set
> >     {}          # empty dict
> >     {1:1}       # 1 item dict
> >     {1:1, 2:2}  # 2 item dict
> >
> > I think this is confusing and messy, especially for new Python
> > programmers.
> >
> > If you're going to make the change, why not make things consistent:
> >
> >     {}          # empty frozen set
> >     {1}         # 1 item frozen set
> >     {1, 2}      # 2 item frozen set
> >     {:}         # empty dict
> >     {1:1}       # 1 item dict
> >     {1:1, 2:2}  # 2 item dict
>
> This has been discussed and rejected as it would break too much code.
> Check the archives during the set literals discussions.
>
> STeVe

Python 3 is going to break compatibility anyway. I thought one of the
purposes of having a new major release was to allow for such changes.

In 2 or 3 years from now Python 3 will be "Python" for most people, and
confusing inconsistencies won't be seen to have any rationale.

-- 
Mark Summerfield, Qtrac Ltd., www.qtrac.eu


From phd at phd.pp.ru  Fri Jan 25 10:42:48 2008
From: phd at phd.pp.ru (Oleg Broytmann)
Date: Fri, 25 Jan 2008 12:42:48 +0300
Subject: [Python-3000] Set literal
In-Reply-To: <200801250929.49286.mark@qtrac.eu>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<200801250718.23840.mark@qtrac.eu>
	<d11dcfba0801242333o33a93f54h607fb7cd738fd9e8@mail.gmail.com>
	<200801250929.49286.mark@qtrac.eu>
Message-ID: <20080125094248.GC1246@phd.pp.ru>

On Fri, Jan 25, 2008 at 09:29:49AM +0000, Mark Summerfield wrote:
> In 2 or 3 years from now Python 3 will be "Python" for most people

   It depends on how much it breaks. If Python 3 breaks too much people may
find it is a completely new language and decide to switch to another
language instead of new Python.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd at phd.pp.ru
           Programmers don't die, they just GOSUB without RETURN.

From qrczak at knm.org.pl  Fri Jan 25 10:52:45 2008
From: qrczak at knm.org.pl (Marcin =?UTF-8?Q?=E2=80=98Qrczak=E2=80=99?= Kowalczyk)
Date: Fri, 25 Jan 2008 10:52:45 +0100
Subject: [Python-3000] Set literal
In-Reply-To: <200801250718.23840.mark@qtrac.eu>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<200801250718.23840.mark@qtrac.eu>
Message-ID: <1201254765.15568.3.camel@qrnik>

Dnia 25-01-2008, Pt o godzinie 07:18 +0000, Mark Summerfield pisze:

> If you're going to make the change, why not make things consistent:

How often do you need the empty frozenset (which will stay as such),
compared to an empty dict (which will probably get filled later)?

The real inconsistency is that there is no frozendict.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak at knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/


From lists at cheimes.de  Fri Jan 25 11:02:19 2008
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 25 Jan 2008 11:02:19 +0100
Subject: [Python-3000] Set literal
In-Reply-To: <200801250929.49286.mark@qtrac.eu>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>	<200801250718.23840.mark@qtrac.eu>	<d11dcfba0801242333o33a93f54h607fb7cd738fd9e8@mail.gmail.com>
	<200801250929.49286.mark@qtrac.eu>
Message-ID: <fncc3d$m10$1@ger.gmane.org>

Mark Summerfield wrote:
> Python 3 is going to break compatibility anyway. I thought one of the
> purposes of having a new major release was to allow for such changes.

Please stop the discussion! Guido already voted against it. I assume
most of the remaining core developers agree with me that three character
literals suck.

Guido seems to be under lots of tension lately. Please don't make him
more cranky and peevish. Orlijn needs his father and we need him as our
beloved and benevolent dictator.

Christian

PS: {:} is hard to type on a German keyboard, too. It's press [alt gr],
press 7, release [alt gr], press [shift], press ., release [shift],
press [alt gr], press 0, release [alt gr].


From gustavo at niemeyer.net  Fri Jan 25 14:41:31 2008
From: gustavo at niemeyer.net (Gustavo Niemeyer)
Date: Fri, 25 Jan 2008 11:41:31 -0200
Subject: [Python-3000] Set literal
In-Reply-To: <ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
Message-ID: <4799E70B.4090406@niemeyer.net>


> I hope it isn't too confusing that {1: 1} creates a *mutable* dict
> while {1} creates an *immutable* frozenset. I still find this slightly
> inelegant. But the practicality of being able to treat set literals as
> compile-time constants wins me over.

Another point in favor of Raymond's suggestion is that problems created
by getting it wrong in the first try are more easily solved when going
frozenset => set than the opposite way.

-- 
Gustavo Niemeyer
http://niemeyer.net

From aahz at pythoncraft.com  Fri Jan 25 16:18:48 2008
From: aahz at pythoncraft.com (Aahz)
Date: Fri, 25 Jan 2008 07:18:48 -0800
Subject: [Python-3000] Set literal
In-Reply-To: <200801250929.49286.mark@qtrac.eu>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<200801250718.23840.mark@qtrac.eu>
	<d11dcfba0801242333o33a93f54h607fb7cd738fd9e8@mail.gmail.com>
	<200801250929.49286.mark@qtrac.eu>
Message-ID: <20080125151848.GA22087@panix.com>

On Fri, Jan 25, 2008, Mark Summerfield wrote:
>
> Python 3 is going to break compatibility anyway. I thought one of the
> purposes of having a new major release was to allow for such changes.
> 
> In 2 or 3 years from now Python 3 will be "Python" for most people, and
> confusing inconsistencies won't be seen to have any rationale.

You are exceedingly optimistic.  My company was using Python 2.2 until a
few months ago, and getting rid of 2.3 is many months away.  Some people
still support Python 1.5.2 (ever hear of Fredrik Lundh?).  As other
people pointed out, there are trade-offs with every breakage, and some
changes are deemed just too radical.

More to the point: the focus on breakage is removing old idioms that are
considered language cruft even in Python 2.x.  {} as a dict literal is
not cruft.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"All problems in computer science can be solved by another level of     
indirection."  --Butler Lampson

From gisle at activestate.com  Fri Jan 25 16:47:13 2008
From: gisle at activestate.com (Gisle Aas)
Date: Fri, 25 Jan 2008 16:47:13 +0100
Subject: [Python-3000] Ellipsis Literal
In-Reply-To: <ca471dc20801241132q6d6df78ej845f4b637d1d5ea3@mail.gmail.com>
References: <20080124141633.AFQ57054@ms19.lnh.mail.rcn.net>
	<ca471dc20801241132q6d6df78ej845f4b637d1d5ea3@mail.gmail.com>
Message-ID: <261F2224-7CBA-4E68-A2DE-8FCB64B2D794@activestate.com>

On Jan 24, 2008, at 20:32, Guido van Rossum wrote:

> Some folks thought it would be cute to be able to write incomplete
> code like this:
>
> class C:
>   def meth(self): ...
>   ...
>
> and have it be syntactically correct.

I think it would be been nice if "..." raised an NotYetImplemented  
exception if executed as a lone statement.  Is that desirable and  
doable?

BTW, Perl 6 also introduce the same feature and Larry calls it the  
"yadayadayada operator"[1].

Regards,
Gisle

>
> PEP 3100 has the reference:
> * ``...`` to become a general expression element [16]_ [done]
> .. [16] python-3000 email
>    http://mail.python.org/pipermail/python-3000/2006-April/000996.html

[1] http://dev.perl.org/perl6/doc/design/syn/S06.html

From ncoghlan at gmail.com  Fri Jan 25 17:05:15 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 26 Jan 2008 02:05:15 +1000
Subject: [Python-3000] Set literal
In-Reply-To: <200801250718.23840.mark@qtrac.eu>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<200801250718.23840.mark@qtrac.eu>
Message-ID: <479A08BB.6010101@gmail.com>

Mark Summerfield wrote:
> On 2008-01-25, Guido van Rossum wrote:
>> For the record, I'm thinking Raymond has won this argument fair and
>> square, and I'm withdrawing my opposition.
>>
>> I hope it isn't too confusing that {1: 1} creates a *mutable* dict
>> while {1} creates an *immutable* frozenset. I still find this slightly
>> inelegant. But the practicality of being able to treat set literals as
>> compile-time constants wins me over.
> 
> So this will produce:
> 
>     frozenset()	# empty frozen set
>     {1}	    	# 1 item frozen set
>     {1, 2}  	# 2 item frozen set
>     {}	    	# empty dict
>     {1:1}   	# 1 item dict
>     {1:1, 2:2}	# 2 item dict

More completely:

      ()           # empty tuple
      (1,)         # 1 item tuple
      (1, 2)       # 2 item tuple
      []           # empty list
      [1]          # 1 item list
      [1, 2]       # 2 item list
      {}           # empty dict
      {1:1}        # 1 item dict
      {1:1, 2:2}	  # 2 item dict
      frozenset()  # empty frozen set
      {1}          # 1 item frozen set
      {1, 2}       # 2 item frozen set
      set()        # empty mutable set
      set({1})     # 1 item mutable set
      set({1, 2})  # 2 item mutable set

So with Raymond's proposal we will have syntax for two immutable 
literals (tuples, frozensets) and two mutable container displays (lists, 
dicts).

Yes, there will be a few anomalies to learn in this list:
   - 1-tuples require a trailing comma
   - {} is a dict rather than a frozen set
   - frozen sets are immutable while dicts are mutable

Do these anomalies make this area of the language syntax harder to 
learn? Almost certainly - the 1-tuple anomaly has been tripping people 
up for years. Despite any reservation, are there valid reasons for 
having these anomalies in Py3k? As far as I am concerned, yes there 
are*, and I believe that is Guido's view as well.

Cheers,
Nick.

*Taking them from the top:
- 1-tuples require a trailing comma to differentiate them from the use 
of parentheses for mere expression grouping. Expression grouping is kind 
of important, and this anomaly in the syntax is a small price to pay for 
making that work intuitively.
- {} is used extensively in existing code (both operational code and 
code in documentation and other examples). Py3k may lower the bar for 
'acceptable breakage' in the realm of backwards compatibility, but it 
doesn't get rid of it altogether - and changing the meaning of {} fails 
to clear even that lowered hurdle. Also, as Marcin pointed out, an empty 
frozenset() is pretty useless, while an empty dict() is common.
- making set literals immutable provides excellent optimisation 
opportunities, which is important because it is a concern for speed 
which is likely to lead to the use of a set in the first place. It is 
also convenient in that set() is a lot easier to type than frozenset(), 
so going from an immutable literal to a mutable container is easier than 
going the other way would have been.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From lists at cheimes.de  Fri Jan 25 17:25:30 2008
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 25 Jan 2008 17:25:30 +0100
Subject: [Python-3000] Set literal
In-Reply-To: <20080124173202.AFQ93921@ms19.lnh.mail.rcn.net>
References: <20080124173202.AFQ93921@ms19.lnh.mail.rcn.net>
Message-ID: <fnd2hq$8ja$1@ger.gmane.org>

Raymond Hettinger wrote:
> I think it would be more useful for the {e1, e2, e3} literal to be a frozenset instead of a set.

+1 from me

Christian


From digitalxero at gmail.com  Fri Jan 25 18:06:53 2008
From: digitalxero at gmail.com (Dj Gilcrease)
Date: Fri, 25 Jan 2008 10:06:53 -0700
Subject: [Python-3000] Set literal
In-Reply-To: <ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
Message-ID: <e9764b730801250906i219b24e7tfa3f15e64399a7fe@mail.gmail.com>

On Jan 24, 2008 8:12 PM, Guido van Rossum <guido at python.org> wrote:
> I hope it isn't too confusing that {1: 1} creates a *mutable* dict
> while {1} creates an *immutable* frozenset. I still find this slightly
> inelegant. But the practicality of being able to treat set literals as
> compile-time constants wins me over.

This probably will not go over well, but why not use the pipe
character to define a frozenset?

if urltxt in |'html', 'xml', 'php'|:

No way to confuse it with a dict, and as far as I know the pipe isnt
used for anything else that would conflict or confuse the issue.

Also on Raymonds point about repr being hard to read

 {frozenset([0, 1]): frozenset([frozenset([0]),
                               frozenset([1]),
                               frozenset([0, 1, 2])]),
 frozenset([0, 1, 2]): frozenset([frozenset([1, 2]),
                                  frozenset([0, 2]),
                                  frozenset([0, 1])])}


would become:

 {|0, 1|: ||0|,
          |1|,
          |0, 1, 2||,
 |0, 1, 2|: ||1, 2|,
            |0, 2|,
            |0, 1||}

From lists at cheimes.de  Fri Jan 25 18:37:05 2008
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 25 Jan 2008 18:37:05 +0100
Subject: [Python-3000] Set literal
In-Reply-To: <e9764b730801250906i219b24e7tfa3f15e64399a7fe@mail.gmail.com>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<e9764b730801250906i219b24e7tfa3f15e64399a7fe@mail.gmail.com>
Message-ID: <fnd6o1$p2a$1@ger.gmane.org>

Dj Gilcrease wrote:
> This probably will not go over well, but why not use the pipe
> character to define a frozenset?
> 
> if urltxt in |'html', 'xml', 'php'|:

The pipe char is ambiguous because is no direction. It was suggested and
rejected last year.

Christian


From guido at python.org  Fri Jan 25 18:56:13 2008
From: guido at python.org (Guido van Rossum)
Date: Fri, 25 Jan 2008 09:56:13 -0800
Subject: [Python-3000] Ellipsis Literal
In-Reply-To: <261F2224-7CBA-4E68-A2DE-8FCB64B2D794@activestate.com>
References: <20080124141633.AFQ57054@ms19.lnh.mail.rcn.net>
	<ca471dc20801241132q6d6df78ej845f4b637d1d5ea3@mail.gmail.com>
	<261F2224-7CBA-4E68-A2DE-8FCB64B2D794@activestate.com>
Message-ID: <ca471dc20801250956w26cc5598lceaf9e0b0cba0c80@mail.gmail.com>

On Jan 25, 2008 7:47 AM, Gisle Aas <gisle at activestate.com> wrote:
> On Jan 24, 2008, at 20:32, Guido van Rossum wrote:
>
> > Some folks thought it would be cute to be able to write incomplete
> > code like this:
> >
> > class C:
> >   def meth(self): ...
> >   ...
> >
> > and have it be syntactically correct.
>
> I think it would be been nice if "..." raised an NotYetImplemented
> exception if executed as a lone statement.  Is that desirable and
> doable?

That wouldn't work, because in slice syntax it's always been allowed
and meant to return the Ellipsis object. Changing this in some
contexts but not others would be confusing.

> BTW, Perl 6 also introduce the same feature and Larry calls it the
> "yadayadayada operator"[1].

Blah, bah. :-)

> Regards,
> Gisle
>
> >
> > PEP 3100 has the reference:
> > * ``...`` to become a general expression element [16]_ [done]
> > .. [16] python-3000 email
> >    http://mail.python.org/pipermail/python-3000/2006-April/000996.html
>
> [1] http://dev.perl.org/perl6/doc/design/syn/S06.html

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From adlaiff6 at gmail.com  Fri Jan 25 19:01:11 2008
From: adlaiff6 at gmail.com (Leif Walsh)
Date: Fri, 25 Jan 2008 13:01:11 -0500
Subject: [Python-3000] Set literal
In-Reply-To: <fnd6o1$p2a$1@ger.gmane.org>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<e9764b730801250906i219b24e7tfa3f15e64399a7fe@mail.gmail.com>
	<fnd6o1$p2a$1@ger.gmane.org>
Message-ID: <cc7430500801251001h112998fejb3e320f40da42e4b@mail.gmail.com>

On Jan 25, 2008 12:37 PM, Christian Heimes <lists at cheimes.de> wrote:
> The pipe char is ambiguous because is no direction. It was suggested and
> rejected last year.

Out of almost-pure devil's advocacy, has <> been considered?  My first
instinct is that it would be ambiguous with less-than/greater-than,
but if someone can convince me otherwise, might it work?  After all,
it's the only other balanced pair of punctuation I see on my keyboard.

--
Cheers,
Leif

From guido at python.org  Fri Jan 25 19:08:29 2008
From: guido at python.org (Guido van Rossum)
Date: Fri, 25 Jan 2008 10:08:29 -0800
Subject: [Python-3000] Set literal
In-Reply-To: <cc7430500801251001h112998fejb3e320f40da42e4b@mail.gmail.com>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<e9764b730801250906i219b24e7tfa3f15e64399a7fe@mail.gmail.com>
	<fnd6o1$p2a$1@ger.gmane.org>
	<cc7430500801251001h112998fejb3e320f40da42e4b@mail.gmail.com>
Message-ID: <ca471dc20801251008g70327756r66df690a3edd9e9f@mail.gmail.com>

On Jan 25, 2008 10:01 AM, Leif Walsh <adlaiff6 at gmail.com> wrote:
> On Jan 25, 2008 12:37 PM, Christian Heimes <lists at cheimes.de> wrote:
> > The pipe char is ambiguous because is no direction. It was suggested and
> > rejected last year.
>
> Out of almost-pure devil's advocacy, has <> been considered?  My first
> instinct is that it would be ambiguous with less-than/greater-than,
> but if someone can convince me otherwise, might it work?  After all,
> it's the only other balanced pair of punctuation I see on my keyboard.

No, there are too many syntactic situations where this would make the
grammar ambiguous or tortuous. We don't want to move beyond LL(1).
(Apart from parsing indentation and nested parentheses, of course --
which actually reminds me or another issue with using <> as brackets:
the lexer can't know whether a particular < or > is used as a bracket
or not, so it can't keep track of nesting like it does for (), [] and
{}. So <> would always remain a second-class citizen.)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From guido at python.org  Fri Jan 25 19:23:20 2008
From: guido at python.org (Guido van Rossum)
Date: Fri, 25 Jan 2008 10:23:20 -0800
Subject: [Python-3000] Set literal
In-Reply-To: <217accd40801251015i14be5156y65e8990c23f047a9@mail.gmail.com>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<e9764b730801250906i219b24e7tfa3f15e64399a7fe@mail.gmail.com>
	<fnd6o1$p2a$1@ger.gmane.org>
	<cc7430500801251001h112998fejb3e320f40da42e4b@mail.gmail.com>
	<ca471dc20801251008g70327756r66df690a3edd9e9f@mail.gmail.com>
	<217accd40801251015i14be5156y65e8990c23f047a9@mail.gmail.com>
Message-ID: <ca471dc20801251023p10004288tb72ea9a35da4a00d@mail.gmail.com>

On Jan 25, 2008 10:15 AM, nathan binkert <nate at binkert.org> wrote:
> > No, there are too many syntactic situations where this would make the
> > grammar ambiguous or tortuous. We don't want to move beyond LL(1).
> > (Apart from parsing indentation and nested parentheses, of course --
> > which actually reminds me or another issue with using <> as brackets:
> > the lexer can't know whether a particular < or > is used as a bracket
> > or not, so it can't keep track of nesting like it does for (), [] and
> > {}. So <> would always remain a second-class citizen.)
>
> What about a single character prefix like we have with r'' and u''?
> We could have f{} and s{}.
> I'm not particularly enamored by the idea, but the parser should be
> able to handle it, no?

It's not the same -- r"..." is a single token to the lexer, but r{...}
is multiple tokens. It would also rule out a possible future syntactic
extension (present in some other languages) where, in analogy of
foo(...) and foo[...] you can also write foo{...}.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From lists at cheimes.de  Fri Jan 25 19:32:32 2008
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 25 Jan 2008 19:32:32 +0100
Subject: [Python-3000] Set literal
In-Reply-To: <cc7430500801251001h112998fejb3e320f40da42e4b@mail.gmail.com>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>	<e9764b730801250906i219b24e7tfa3f15e64399a7fe@mail.gmail.com>	<fnd6o1$p2a$1@ger.gmane.org>
	<cc7430500801251001h112998fejb3e320f40da42e4b@mail.gmail.com>
Message-ID: <fnda00$68l$1@ger.gmane.org>

Leif Walsh wrote:
> Out of almost-pure devil's advocacy, has <> been considered?  My first
> instinct is that it would be ambiguous with less-than/greater-than,
> but if someone can convince me otherwise, might it work?  After all,
> it's the only other balanced pair of punctuation I see on my keyboard.

There are also ? and ?, << and >> for those w/o UTF-8 support in their
mail client. On my keyboard the characters are available under [alt gr]
+ y and x.

Christian


From thomas at python.org  Fri Jan 25 19:39:44 2008
From: thomas at python.org (Thomas Wouters)
Date: Fri, 25 Jan 2008 10:39:44 -0800
Subject: [Python-3000] Set literal
In-Reply-To: <cc7430500801251001h112998fejb3e320f40da42e4b@mail.gmail.com>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<e9764b730801250906i219b24e7tfa3f15e64399a7fe@mail.gmail.com>
	<fnd6o1$p2a$1@ger.gmane.org>
	<cc7430500801251001h112998fejb3e320f40da42e4b@mail.gmail.com>
Message-ID: <9e804ac0801251039y46eced3eofc4f6d62231866ee@mail.gmail.com>

On Jan 25, 2008 10:01 AM, Leif Walsh <adlaiff6 at gmail.com> wrote:

> On Jan 25, 2008 12:37 PM, Christian Heimes <lists at cheimes.de> wrote:
> > The pipe char is ambiguous because is no direction. It was suggested and
> > rejected last year.
>
> Out of almost-pure devil's advocacy, has <> been considered?  My first
> instinct is that it would be ambiguous with less-than/greater-than,
> but if someone can convince me otherwise, might it work?  After all,
> it's the only other balanced pair of punctuation I see on my keyboard.
>

Yes. And yes, even if the idea wasn't rejected, the parser wouldn't be able
to handle it. The same goes for |, too. The syntax would be ambiguous, and
Python's parser would not be able to ever 'close' a set, because the closing
character would be eaten by the expression inside the set.

 set([1, 2, 1|2]) -> |1, 2, 1|2|
 set([1>0, 2, 3]) -> <1>0, 2, 3>

For some situations, a more clever parser would be able to figure it out,
but there would still be purely ambiguous cases. And Guido has repeatedly
stated he wants Python to remain parseable by a simple parser, even if we
were to make CPython's parser more powerful. Weirder balanced-pairs have
also been suggested, and rejected (both because they don't improve the
readability and parsing situation, and because they just look absurd :)

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080125/02e62bcb/attachment.htm 

From thomas at python.org  Fri Jan 25 19:43:04 2008
From: thomas at python.org (Thomas Wouters)
Date: Fri, 25 Jan 2008 10:43:04 -0800
Subject: [Python-3000] Set literal
In-Reply-To: <fnda00$68l$1@ger.gmane.org>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<e9764b730801250906i219b24e7tfa3f15e64399a7fe@mail.gmail.com>
	<fnd6o1$p2a$1@ger.gmane.org>
	<cc7430500801251001h112998fejb3e320f40da42e4b@mail.gmail.com>
	<fnda00$68l$1@ger.gmane.org>
Message-ID: <9e804ac0801251043r2f16029ai2b7c81330eadd5a3@mail.gmail.com>

On Jan 25, 2008 10:32 AM, Christian Heimes <lists at cheimes.de> wrote:

> Leif Walsh wrote:
> > Out of almost-pure devil's advocacy, has <> been considered?  My first
> > instinct is that it would be ambiguous with less-than/greater-than,
> > but if someone can convince me otherwise, might it work?  After all,
> > it's the only other balanced pair of punctuation I see on my keyboard.
>
> There are also ? and ?, << and >> for those w/o UTF-8 support in their
> mail client. On my keyboard the characters are available under [alt gr]
> + y and x.
>

They aren't available on my keyboard, nor on most US keyboards I would
reckon. You can still type them if you know how (and I happen to know how in
any of my environments) but it would limit the set literals to a particular
set of source encodings (most notably, not ASCII.) I find this an extremely
disturbing idea.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080125/f67a6967/attachment.htm 

From charles.merriam at gmail.com  Fri Jan 25 19:47:23 2008
From: charles.merriam at gmail.com (Charles Merriam)
Date: Fri, 25 Jan 2008 10:47:23 -0800
Subject: [Python-3000] Set literal
In-Reply-To: <fnda00$68l$1@ger.gmane.org>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<e9764b730801250906i219b24e7tfa3f15e64399a7fe@mail.gmail.com>
	<fnd6o1$p2a$1@ger.gmane.org>
	<cc7430500801251001h112998fejb3e320f40da42e4b@mail.gmail.com>
	<fnda00$68l$1@ger.gmane.org>
Message-ID: <b8c6f6c40801251047v6d769453nce3ab7a42bb86f9e@mail.gmail.com>

> There are also ? and ?, << and >> for those w/o UTF-8 support in their
> mail client. On my keyboard the characters are available under [alt gr]
> + y and x.

Not elegant.  It should look pretty.  Code should look the same in all
character encodings unless alternate codings for used for identifiers.

Seriously, people just want to code in Python without odd little nooks of lore.
Over 99.9% of programmers will not care about a minor performance hit
for no compile-time frozen sets.

Cheers,

Charles

From collinw at gmail.com  Fri Jan 25 20:52:49 2008
From: collinw at gmail.com (Collin Winter)
Date: Fri, 25 Jan 2008 11:52:49 -0800
Subject: [Python-3000] Set literal
In-Reply-To: <aac2c7cb0801242240n3540d895i290d05b624954656@mail.gmail.com>
References: <20080124191247.AFR08858@ms19.lnh.mail.rcn.net>
	<aac2c7cb0801242240n3540d895i290d05b624954656@mail.gmail.com>
Message-ID: <43aa6ff70801251152rd47fd0dr8957675ab75c6c5c@mail.gmail.com>

On Jan 24, 2008 10:40 PM, Adam Olsen <rhamph at gmail.com> wrote:
> On Jan 24, 2008 5:12 PM, Raymond Hettinger <python at rcn.com> wrote:
> > > Looking over the code base, frozensets are used rarely.
> > > So I don't think this is warranted.
> >
> > There is no shortage for perfect use cases in the form:
> >
> >    if urlext in {'html', 'xml', 'php'}:
> >          . . .
> >
> >
> > If the curly braces are taken to mean a frozenset,
> > then the peepholer can code the whole thing as a
> > compile time constant.  It is fast and clean.
> > You need not even be aware that you're using a
> > frozenset.
>
> Is there any reason preventing it from being optimized even with a
> mutable set?  urlext only interacts with the items in the set, and
> doesn't get to see the set itself, so I don't see why the "in"
> operator couldn't trigger transforming it into a constant.
>
> The same argument applies to list literals.  The only limitation I see
> is whether or not calling hash() on urlext is considered an essential
> part of the semantics - and I'm inclined to say "no".

You're asking if it would be possible to automatically turn "x in [a,
b, c]" into "x in {a, b, c}"? If so, the answer is no: x may be
unhashable.

Collin Winter

From jcd at sdf.lonestar.org  Fri Jan 25 21:31:03 2008
From: jcd at sdf.lonestar.org (J. Cliff Dyer)
Date: Fri, 25 Jan 2008 15:31:03 -0500
Subject: [Python-3000] Set literal
In-Reply-To: <479A08BB.6010101@gmail.com>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>	<200801250718.23840.mark@qtrac.eu>
	<479A08BB.6010101@gmail.com>
Message-ID: <479A4707.5030408@sdf.lonestar.org>

I'm a -0.9 on this one. I really like that Python is powerful, but also
a great pedagogical language.

I don't like that whereas before you could teach someone {} creates a
dict, but now you have to say {} creates a dict, if there are colons
inside, or it's empty, but otherwise creates a frozenset. I also don't
like that it will be easy (especially coming from Certain Other
Languages) to make the following error:

my_dict = {
'a', 'b',
'c', 'd',
'e', 'f'
}

Moreover, I don't like that once you've done that, you'll be able to do

if 'c' in my_dict:
...

and have it evaluate as true even though you aren't dealing with a dict.
Those are ugly gotchas for something so basic to the language. Newcomers
will run into it a lot.

As a half-baked alternative thought, what about using {{ 'a', 'b', 'c'
}} for the syntax. It's visually clearer, and still syntactically
unambiguous, because a dict can't have another dict as a key, and a
(frozen)set can't have a dict inside it. Thinking about possible
issues--what if you come across a construct with three opening braces at
the start? ({{{)

* It can't be a dict within a dict within a dict, because a dict is not
hashable, so can't be a key.
* It can't be a dict within a frozenset, because a dict is not hashable.
* It can (and must) be a frozenset within a dict, because a frozenset is
hashable, and hence a valid dict key.

Four braces? ({{{{)
* I think this has to be a frozen set within a frozen set.

More?
* The outer one is a dict if an odd number of braces, everything else is
a frozen set.

Obviously, the more complex cases get less visually clear, but (1) they
are not common cases, and (2) they are still unambigous, and will often
be made clearer by (a) the placement of closing brackets, and (b) decent
syntax highlighting.

Any major holes in this idea?

Cheers,
Cliff





Nick Coghlan wrote:
> Mark Summerfield wrote:
>   
>> On 2008-01-25, Guido van Rossum wrote:
>>     
>>> For the record, I'm thinking Raymond has won this argument fair and
>>> square, and I'm withdrawing my opposition.
>>>
>>> I hope it isn't too confusing that {1: 1} creates a *mutable* dict
>>> while {1} creates an *immutable* frozenset. I still find this slightly
>>> inelegant. But the practicality of being able to treat set literals as
>>> compile-time constants wins me over.
>>>       
>> So this will produce:
>>
>>     frozenset()	# empty frozen set
>>     {1}	    	# 1 item frozen set
>>     {1, 2}  	# 2 item frozen set
>>     {}	    	# empty dict
>>     {1:1}   	# 1 item dict
>>     {1:1, 2:2}	# 2 item dict
>>     
>
> More completely:
>
>       ()           # empty tuple
>       (1,)         # 1 item tuple
>       (1, 2)       # 2 item tuple
>       []           # empty list
>       [1]          # 1 item list
>       [1, 2]       # 2 item list
>       {}           # empty dict
>       {1:1}        # 1 item dict
>       {1:1, 2:2}	  # 2 item dict
>       frozenset()  # empty frozen set
>       {1}          # 1 item frozen set
>       {1, 2}       # 2 item frozen set
>       set()        # empty mutable set
>       set({1})     # 1 item mutable set
>       set({1, 2})  # 2 item mutable set
>
> So with Raymond's proposal we will have syntax for two immutable 
> literals (tuples, frozensets) and two mutable container displays (lists, 
> dicts).
>
> Yes, there will be a few anomalies to learn in this list:
>    - 1-tuples require a trailing comma
>    - {} is a dict rather than a frozen set
>    - frozen sets are immutable while dicts are mutable
>
> Do these anomalies make this area of the language syntax harder to 
> learn? Almost certainly - the 1-tuple anomaly has been tripping people 
> up for years. Despite any reservation, are there valid reasons for 
> having these anomalies in Py3k? As far as I am concerned, yes there 
> are*, and I believe that is Guido's view as well.
>
> Cheers,
> Nick.
>
> *Taking them from the top:
> - 1-tuples require a trailing comma to differentiate them from the use 
> of parentheses for mere expression grouping. Expression grouping is kind 
> of important, and this anomaly in the syntax is a small price to pay for 
> making that work intuitively.
> - {} is used extensively in existing code (both operational code and 
> code in documentation and other examples). Py3k may lower the bar for 
> 'acceptable breakage' in the realm of backwards compatibility, but it 
> doesn't get rid of it altogether - and changing the meaning of {} fails 
> to clear even that lowered hurdle. Also, as Marcin pointed out, an empty 
> frozenset() is pretty useless, while an empty dict() is common.
> - making set literals immutable provides excellent optimisation 
> opportunities, which is important because it is a concern for speed 
> which is likely to lead to the use of a set in the first place. It is 
> also convenient in that set() is a lot easier to type than frozenset(), 
> so going from an immutable literal to a mutable container is easier than 
> going the other way would have been.
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080125/af956f86/attachment-0001.htm 

From steven.bethard at gmail.com  Fri Jan 25 21:41:36 2008
From: steven.bethard at gmail.com (Steven Bethard)
Date: Fri, 25 Jan 2008 13:41:36 -0700
Subject: [Python-3000] Set literal
In-Reply-To: <479A4707.5030408@sdf.lonestar.org>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<200801250718.23840.mark@qtrac.eu> <479A08BB.6010101@gmail.com>
	<479A4707.5030408@sdf.lonestar.org>
Message-ID: <d11dcfba0801251241u3be7f2cbl65a59e17ffd54e6e@mail.gmail.com>

On Jan 25, 2008 1:31 PM, J. Cliff Dyer <jcd at sdf.lonestar.org> wrote:
>
>  I'm a -0.9 on this one.  I really like that Python is powerful, but also a
> great pedagogical language.
>
>  I don't like that whereas before you could teach someone {} creates a dict,
> but now you have to say {} creates a dict, if there are colons inside, or
> it's empty, but otherwise creates a frozenset.  I also don't like that it
> will be easy (especially coming from Certain Other Languages) to make the
> following error:
>
>  my_dict = {
>      'a', 'b',
>      'c', 'd',
>      'e', 'f'
>  }
>
>  Moreover, I don't like that once you've done that, you'll be able to do
>
>  if 'c' in my_dict:
>      ...
>
>  and have it evaluate as true even though you aren't dealing with a dict.

You're a little late for this discussion.  Python 3.0 already has this
behavior::

    Python 3.0a2+ (py3k:60260, Jan 25 2008, 13:40:11)
    [MSC v.1500 32 bit (Intel)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> my_dict = {
    ...     'a', 'b',
    ...     'c', 'd',
    ...     'e', 'f',
    ... }
    >>> 'c' in my_dict
    True

This discussion is about whether the set literal should be a set() or
a frozenset().

STeVe
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
        --- Bucky Katt, Get Fuzzy

From rhamph at gmail.com  Fri Jan 25 21:54:55 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Fri, 25 Jan 2008 13:54:55 -0700
Subject: [Python-3000] Set literal
In-Reply-To: <43aa6ff70801251152rd47fd0dr8957675ab75c6c5c@mail.gmail.com>
References: <20080124191247.AFR08858@ms19.lnh.mail.rcn.net>
	<aac2c7cb0801242240n3540d895i290d05b624954656@mail.gmail.com>
	<43aa6ff70801251152rd47fd0dr8957675ab75c6c5c@mail.gmail.com>
Message-ID: <aac2c7cb0801251254t5ca1b437ka950816f04c6a949@mail.gmail.com>

On Jan 25, 2008 12:52 PM, Collin Winter <collinw at gmail.com> wrote:
>
> On Jan 24, 2008 10:40 PM, Adam Olsen <rhamph at gmail.com> wrote:
> > On Jan 24, 2008 5:12 PM, Raymond Hettinger <python at rcn.com> wrote:
> > > > Looking over the code base, frozensets are used rarely.
> > > > So I don't think this is warranted.
> > >
> > > There is no shortage for perfect use cases in the form:
> > >
> > >    if urlext in {'html', 'xml', 'php'}:
> > >          . . .
> > >
> > >
> > > If the curly braces are taken to mean a frozenset,
> > > then the peepholer can code the whole thing as a
> > > compile time constant.  It is fast and clean.
> > > You need not even be aware that you're using a
> > > frozenset.
> >
> > Is there any reason preventing it from being optimized even with a
> > mutable set?  urlext only interacts with the items in the set, and
> > doesn't get to see the set itself, so I don't see why the "in"
> > operator couldn't trigger transforming it into a constant.
> >
> > The same argument applies to list literals.  The only limitation I see
> > is whether or not calling hash() on urlext is considered an essential
> > part of the semantics - and I'm inclined to say "no".
>
> You're asking if it would be possible to automatically turn "x in [a,
> b, c]" into "x in {a, b, c}"? If so, the answer is no: x may be
> unhashable.

That's not what I'm asking.  I'm asking about changing "x in set([a,
b, c])" into "x into frozenset([a, b, c])".

The second part about changing "x in set([a, b, c])" into "x in (a, b,
c)".  This removes the hashability requirement, rather than adding it.
 However, it seems moot given the benchmarks others have provided.


-- 
Adam Olsen, aka Rhamphoryncus

From rrr at ronadam.com  Sat Jan 26 01:58:33 2008
From: rrr at ronadam.com (Ron Adam)
Date: Fri, 25 Jan 2008 18:58:33 -0600
Subject: [Python-3000] Set literal
In-Reply-To: <20080124173202.AFQ93921@ms19.lnh.mail.rcn.net>
References: <20080124173202.AFQ93921@ms19.lnh.mail.rcn.net>
Message-ID: <479A85B9.4080906@ronadam.com>



Raymond Hettinger wrote:

> P.S.  A small side-benefit is it may put an end for interminable requests for a {:} or {/} notation for empty sets.  There's not much need for a literal for a empty frozenset (use "not s" instead).


How about also removing the {} as an empty dictionary?  Then both
dictionary and set literals will require at least one item to be valid.  No 
  confusion, and {} is not allowed because it's ambiguous (to users) as to 
weather it's a set or dictionary.



Would set({a, b, c}) be valid?

If so, should the repr for a set be set({a, b, c}) instead of
set([a, b, c])?


Ron





From guido at python.org  Sat Jan 26 03:23:55 2008
From: guido at python.org (Guido van Rossum)
Date: Fri, 25 Jan 2008 18:23:55 -0800
Subject: [Python-3000] Set literal
In-Reply-To: <479A85B9.4080906@ronadam.com>
References: <20080124173202.AFQ93921@ms19.lnh.mail.rcn.net>
	<479A85B9.4080906@ronadam.com>
Message-ID: <ca471dc20801251823h20f19da7tdde2400431471d7@mail.gmail.com>

On Jan 25, 2008 4:58 PM, Ron Adam <rrr at ronadam.com> wrote:
> How about also removing the {} as an empty dictionary?  Then both
> dictionary and set literals will require at least one item to be valid.No
>   confusion, and {} is not allowed because it's ambiguous (to users) as to
> weather it's a set or dictionary.

That sounds like punishing the dict type for something it didn't do.

> Would set({a, b, c}) be valid?

Can't see how it couldn't be. :-)

> If so, should the repr for a set be set({a, b, c}) instead of
> set([a, b, c])?

Of course. In current 3.0 the frozenset() repr() already does this:

>>> frozenset([1,2,3])
frozenset({1, 2, 3})
>>>

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From python at rcn.com  Sat Jan 26 04:03:58 2008
From: python at rcn.com (Raymond Hettinger)
Date: Fri, 25 Jan 2008 22:03:58 -0500 (EST)
Subject: [Python-3000] Set literal
Message-ID: <20080125220358.AFT02821@ms19.lnh.mail.rcn.net>

> should the repr for a set be set({a, b, c}) 
> instead of set([a, b, c])?

FWIW, running eval() on the repr is slower and less memory efficient with curly braces than with the square brackets.

Also, it may be easily misread as meaning: set([frozenset([a, b, c])]).  If the latter is intended, then that would become set({{a, b, c}}) which I find hard to parse correctly.  Maybe the set([a, b, c]) form should live on.

Raymond

From ncoghlan at gmail.com  Sat Jan 26 06:03:42 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 26 Jan 2008 15:03:42 +1000
Subject: [Python-3000] Set literal
In-Reply-To: <ca471dc20801251008g70327756r66df690a3edd9e9f@mail.gmail.com>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>	<e9764b730801250906i219b24e7tfa3f15e64399a7fe@mail.gmail.com>	<fnd6o1$p2a$1@ger.gmane.org>	<cc7430500801251001h112998fejb3e320f40da42e4b@mail.gmail.com>
	<ca471dc20801251008g70327756r66df690a3edd9e9f@mail.gmail.com>
Message-ID: <479ABF2E.9070007@gmail.com>

Guido van Rossum wrote:
> On Jan 25, 2008 10:01 AM, Leif Walsh <adlaiff6 at gmail.com> wrote:
>> On Jan 25, 2008 12:37 PM, Christian Heimes <lists at cheimes.de> wrote:
>>> The pipe char is ambiguous because is no direction. It was suggested and
>>> rejected last year.
>> Out of almost-pure devil's advocacy, has <> been considered?  My first
>> instinct is that it would be ambiguous with less-than/greater-than,
>> but if someone can convince me otherwise, might it work?  After all,
>> it's the only other balanced pair of punctuation I see on my keyboard.
> 
> No, there are too many syntactic situations where this would make the
> grammar ambiguous or tortuous. We don't want to move beyond LL(1).
> (Apart from parsing indentation and nested parentheses, of course --
> which actually reminds me or another issue with using <> as brackets:
> the lexer can't know whether a particular < or > is used as a bracket
> or not, so it can't keep track of nesting like it does for (), [] and
> {}. So <> would always remain a second-class citizen.)
> 

Hmm, I guess both of those objections apply to using | as the delimiter 
as well. Ah well.

If anyone has a bit of free time to play with, it will probably be worth 
creating a retrospective PEP for the set literal syntax to capture the 
rationale for the various design decisions like:
   - why not || or <> as the delimeters?
   - why {} continues as the empty dict
   - why {1, 2, 3} is immutable, while {1:2} is not

Cheers,
Nick.


-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From tjreedy at udel.edu  Sat Jan 26 09:21:53 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 26 Jan 2008 03:21:53 -0500
Subject: [Python-3000] Set literal
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com><200801250718.23840.mark@qtrac.eu>
	<479A08BB.6010101@gmail.com>
Message-ID: <fneqis$70a$1@ger.gmane.org>


"Nick Coghlan" <ncoghlan at gmail.com> wrote in message 
news:479A08BB.6010101 at gmail.com...
| More completely:
|
|      ()           # empty tuple
|      (1,)        # 1 item tuple
|      (1,2)      # 2 item tuple

1,    # 1 item tuple, no parens needed, trailing comma mandatory
1,2  # 2 item tuple, no parens needed
1,2, # 2 item tuple with optional trailing comma

The anomaly is the need for parens to denote an empty tuple since
it is otherwise hard to tell a tuple nothing from a nothing nothing.  The 
alternative would have been to use a bare trailing , ... but I guess Guido 
thought 'a = ,' and 'a == ,' would look odder than the current form, 
although it would have avoided the implication that parens rather than 
commas make tuples (other than the empty one).

| - 1-tuples require a trailing comma to differentiate them from the use
| of parentheses for mere expression grouping.

1-tuples require the trailing comma in order to have at least one around to 
differentiate them from bare expressions.  Except for empty tuples, parens 
only need be added if they are indeed needed for expression grouping (which 
they often are because of precedence).

tjr




From ncoghlan at gmail.com  Sat Jan 26 16:26:23 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 27 Jan 2008 01:26:23 +1000
Subject: [Python-3000] Set literal
In-Reply-To: <fneqis$70a$1@ger.gmane.org>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com><200801250718.23840.mark@qtrac.eu>	<479A08BB.6010101@gmail.com>
	<fneqis$70a$1@ger.gmane.org>
Message-ID: <479B511F.9040605@gmail.com>

Terry Reedy wrote:
> "Nick Coghlan" <ncoghlan at gmail.com> wrote in message 
> news:479A08BB.6010101 at gmail.com...
> | More completely:
> |
> |      ()           # empty tuple
> |      (1,)        # 1 item tuple
> |      (1,2)      # 2 item tuple
> 
> 1,    # 1 item tuple, no parens needed, trailing comma mandatory
> 1,2  # 2 item tuple, no parens needed
> 1,2, # 2 item tuple with optional trailing comma

No parens needed, unless the comma would be interpreted as meaning 
something else if the parens were left out (function argument separator, 
name separator in a 2.x series except clause, item separator in a 
surrounding tuple/list/dict definition, etc), or if the first expression 
would be overinclusive without them (e.g. string formatting with %). A 
lot of the time I find it easier to just include the parentheses instead 
of worrying about it (they're kind of like yield expressions that way...).

Anyway, for the kind of stylistic comparison I was talking about in the 
previous post, I think it is useful to think of the parentheses as part 
of the tuple syntax (because that's the way they are often written), 
even though that isn't completely correct in terms of the language's 
grammar.

We've veered pretty far from the original topic now though, so it would 
probably be best to drop the mailing list from any further discussion :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From rrr at ronadam.com  Sat Jan 26 21:48:04 2008
From: rrr at ronadam.com (Ron Adam)
Date: Sat, 26 Jan 2008 14:48:04 -0600
Subject: [Python-3000] Set literal
In-Reply-To: <20080125220358.AFT02821@ms19.lnh.mail.rcn.net>
References: <20080125220358.AFT02821@ms19.lnh.mail.rcn.net>
Message-ID: <479B9C84.1050605@ronadam.com>



Raymond Hettinger wrote:
>> should the repr for a set be set({a, b, c}) 
>> instead of set([a, b, c])?
> 
> FWIW, running eval() on the repr is slower and less memory efficient with curly braces than with the square brackets.


This is what I get.


 >>> timeit.timeit("eval('frozenset({1,2,3})')")
48.011682987213135
 >>> timeit.timeit("eval('frozenset([1,2,3])')")
48.155133962631226
 >>> timeit.timeit("eval('frozenset((1,2,3))')")
48.062387943267822
 >>> timeit.timeit("eval('set({1,2,3})')")
46.738940000534058
 >>> timeit.timeit("eval('set([1,2,3])')")
47.597666025161743
 >>> timeit.timeit("eval('set((1,2,3))')")
47.087898969650269


It's all very close.  I think the frozenset({1,2,3}) example will get 
faster if {..} notation becomes a frozen set, and set({...}) example will 
slow down a bit.


> Also, it may be easily misread as meaning: set([frozenset([a, b, c])]).  If the latter is intended, then that would become set({{a, b, c}}) which I find hard to parse correctly.  Maybe the set([a, b, c]) form should live on.
> 
> Raymond

You added an extra level of nesting.  set(frozenset([a, b, c])) isn't any 
harder to parse (to me) than the equivalent tuple or list versions of the 
same forms: list(tuple([a, b, c]) and tuple(list([a, b, c]).


Ron


From python at rcn.com  Sat Jan 26 22:45:45 2008
From: python at rcn.com (Raymond Hettinger)
Date: Sat, 26 Jan 2008 13:45:45 -0800
Subject: [Python-3000] Set literal
References: <20080125220358.AFT02821@ms19.lnh.mail.rcn.net>
	<479B9C84.1050605@ronadam.com>
Message-ID: <003301c86064$cf68d810$6800a8c0@RaymondLaptop1>

>>> should the repr for a set be set({a, b, c}) instead of set([a, b, c])?

[Raymond]
>> FWIW, running eval() on the repr is slower and less memory efficient with curly braces than with the square brackets.

[Ron]
> It's all very close.  I think the frozenset({1,2,3}) example will get faster if {..} notation becomes a frozen set, and set({...}) 
> example will slow down a bit.

Am strongly -1 on changing the repr for set to set({a, b, c}) .   Creating an innermost frozenset doubles the memory consumption. 
Also, it invisibly pushes the hashing inward one step which will lead to weird tracebacks with set subclasses (it should be the 
outermost that raises an exception, not the innermost).  I find the notation to be confusing.  I am strongly against this change and 
would like to see it reverted right away. As the caretaker of this code, hopefully my recommendation will carry some weight.  I'm 
not happy with this change.


Raymond 

From lists at cheimes.de  Sat Jan 26 22:50:14 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 26 Jan 2008 22:50:14 +0100
Subject: [Python-3000] Set literal
In-Reply-To: <479B9C84.1050605@ronadam.com>
References: <20080125220358.AFT02821@ms19.lnh.mail.rcn.net>
	<479B9C84.1050605@ronadam.com>
Message-ID: <fng9un$8td$1@ger.gmane.org>

Ron Adam wrote:
> It's all very close.  I think the frozenset({1,2,3}) example will get 
> faster if {..} notation becomes a frozen set, and set({...}) example will 
> slow down a bit.

frozenset({1,2,3}) can be optimized and reduced to a simple return in
frozenset_new() just like str("abc") returns the same string object. I
assume set({...}) is going to be as fast or maybe faster than set([...]).

Christian


From guido at python.org  Sat Jan 26 22:50:37 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 26 Jan 2008 13:50:37 -0800
Subject: [Python-3000] Set literal
In-Reply-To: <003301c86064$cf68d810$6800a8c0@RaymondLaptop1>
References: <20080125220358.AFT02821@ms19.lnh.mail.rcn.net>
	<479B9C84.1050605@ronadam.com>
	<003301c86064$cf68d810$6800a8c0@RaymondLaptop1>
Message-ID: <ca471dc20801261350v21d84038g597030fcd9f8e6e6@mail.gmail.com>

On Jan 26, 2008 1:45 PM, Raymond Hettinger <python at rcn.com> wrote:
> Am strongly -1 on changing the repr for set to set({a, b, c}) .   Creating an innermost frozenset doubles the memory consumption.

Raymond, I think you're overestimating how often the repr() of a set
actually gets eval()'ed. I expect this happens approximately never. I
certainly haven't used it myself, and most certainly not in a
performance-critical context.

The reason that repr() returns an eval()'able expression isn't that
the expression is likely to be eval()'ed -- it is that the programmer
is already familiar with the notation and can thus immediately
understand what it means.

>From an understandability POV, set({...}) is simpler than set([...])
because the list is just a distraction.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From nnorwitz at gmail.com  Sat Jan 26 22:57:53 2008
From: nnorwitz at gmail.com (Neal Norwitz)
Date: Sat, 26 Jan 2008 13:57:53 -0800
Subject: [Python-3000] plistlib module and test
Message-ID: <ee2a432c0801261357i2f5fa475k4606d943bf28fb24@mail.gmail.com>

I remember seeing a change which moved the plistlib module from
Lib/plat-mac to Lib so all platforms can use it.  This change causes
*all* the builds fail because the test has several problems.  For
example, the test references functions/methods that don't exist (see
below).  Can someone fix this?

  File "/home/pybot/buildarea/3.0.klose-debian-ia64/build/Lib/test/test_plistlib.py",
line 140, in test_appleformatting
    pl = plistlib.readPlistFromBytes(TESTDATA)
AttributeError: 'module' object has no attribute 'readPlistFromBytes'

  File "/home/pybot/buildarea/3.0.klose-debian-ia64/build/Lib/test/test_plistlib.py",
line 133, in test_bytes
    data = plistlib.writePlistToBytes(pl)
AttributeError: 'module' object has no attribute 'writePlistToBytes'

There are 2 more errors I noticed.  Here's an example:
http://www.python.org/dev/buildbot/all/ia64%20Ubuntu%203.0/builds/471/step-test/0

n

From python at rcn.com  Sat Jan 26 23:01:06 2008
From: python at rcn.com (Raymond Hettinger)
Date: Sat, 26 Jan 2008 14:01:06 -0800
Subject: [Python-3000] Set literal
References: <20080125220358.AFT02821@ms19.lnh.mail.rcn.net>
	<479B9C84.1050605@ronadam.com>
	<003301c86064$cf68d810$6800a8c0@RaymondLaptop1>
	<ca471dc20801261350v21d84038g597030fcd9f8e6e6@mail.gmail.com>
Message-ID: <004401c86066$f3f305a0$6800a8c0@RaymondLaptop1>

[GvR]
> Raymond, I think you're overestimating how often the repr() of a set
> actually gets eval()'ed. 

The repr is the model for how we enter things by hand.
If the repr is set([1,2,3]), the that's how we will learn
to type them into our programs.  It's not the eval(repr(s))
round trip that's at issue, it is a question of the preferred
way to write code.


> From an understandability POV, set({...}) is simpler than set([...])

I'm at a loss for words to explain the reasons for my strong
aversion to the syntax.  All I can say is that I think it's a mistake
and hope you let me switch back to the Py2.6 way.


Raymond

From g.brandl at gmx.net  Sat Jan 26 23:02:25 2008
From: g.brandl at gmx.net (Georg Brandl)
Date: Sat, 26 Jan 2008 23:02:25 +0100
Subject: [Python-3000] Set literal
In-Reply-To: <ca471dc20801261350v21d84038g597030fcd9f8e6e6@mail.gmail.com>
References: <20080125220358.AFT02821@ms19.lnh.mail.rcn.net>	<479B9C84.1050605@ronadam.com>	<003301c86064$cf68d810$6800a8c0@RaymondLaptop1>
	<ca471dc20801261350v21d84038g597030fcd9f8e6e6@mail.gmail.com>
Message-ID: <fngalj$a73$1@ger.gmane.org>

Guido van Rossum schrieb:
> On Jan 26, 2008 1:45 PM, Raymond Hettinger <python at rcn.com> wrote:
>> Am strongly -1 on changing the repr for set to set({a, b, c}) .   Creating an innermost frozenset doubles the memory consumption.
> 
> Raymond, I think you're overestimating how often the repr() of a set
> actually gets eval()'ed. I expect this happens approximately never. I
> certainly haven't used it myself, and most certainly not in a
> performance-critical context.
> 
> The reason that repr() returns an eval()'able expression isn't that
> the expression is likely to be eval()'ed -- it is that the programmer
> is already familiar with the notation and can thus immediately
> understand what it means.

Which means of course that users will pick up that idiom when they're
creating nonempty sets in their own code, thus causing the issues
Raymond mentioned.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.


From guido at python.org  Sat Jan 26 23:11:43 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 26 Jan 2008 14:11:43 -0800
Subject: [Python-3000] Set literal
In-Reply-To: <fngalj$a73$1@ger.gmane.org>
References: <20080125220358.AFT02821@ms19.lnh.mail.rcn.net>
	<479B9C84.1050605@ronadam.com>
	<003301c86064$cf68d810$6800a8c0@RaymondLaptop1>
	<ca471dc20801261350v21d84038g597030fcd9f8e6e6@mail.gmail.com>
	<fngalj$a73$1@ger.gmane.org>
Message-ID: <ca471dc20801261411w6d942981hb247ca4ad6220c17@mail.gmail.com>

On Jan 26, 2008 2:02 PM, Georg Brandl <g.brandl at gmx.net> wrote:
> Guido van Rossum schrieb:
> > On Jan 26, 2008 1:45 PM, Raymond Hettinger <python at rcn.com> wrote:
> >> Am strongly -1 on changing the repr for set to set({a, b, c}) .   Creating an innermost frozenset doubles the memory consumption.
> >
> > Raymond, I think you're overestimating how often the repr() of a set
> > actually gets eval()'ed. I expect this happens approximately never. I
> > certainly haven't used it myself, and most certainly not in a
> > performance-critical context.
> >
> > The reason that repr() returns an eval()'able expression isn't that
> > the expression is likely to be eval()'ed -- it is that the programmer
> > is already familiar with the notation and can thus immediately
> > understand what it means.
>
> Which means of course that users will pick up that idiom when they're
> creating nonempty sets in their own code, thus causing the issues
> Raymond mentioned.

But didn't we start by establishing that users are rarely going to
create non-empty non-frozen sets anyway, because most algorithms
involving mutable sets start with an empty one? Even if users
occasionally write initialized sets, I find it hard to believe that
this would occur in a performance-critical position.

I think Raymond has been focusing on performance for so long that he
sees performance issues *everywhere*. It reminds me of the ugly idioms
that were common in Zope (long ago, it's probably changed) because
they boosted performance -- unfortunately they were used everywhere,
not just in performance-critical code, making the code harder to read
and maintain.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From lists at cheimes.de  Sat Jan 26 23:13:10 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 26 Jan 2008 23:13:10 +0100
Subject: [Python-3000] plistlib module and test
In-Reply-To: <ee2a432c0801261357i2f5fa475k4606d943bf28fb24@mail.gmail.com>
References: <ee2a432c0801261357i2f5fa475k4606d943bf28fb24@mail.gmail.com>
Message-ID: <fngb9n$c1k$1@ger.gmane.org>

Neal Norwitz wrote:
> I remember seeing a change which moved the plistlib module from
> Lib/plat-mac to Lib so all platforms can use it.  This change causes
> *all* the builds fail because the test has several problems.  For
> example, the test references functions/methods that don't exist (see
> below).  Can someone fix this?

I fixed it by copying plistlib.py from the py3k directory Lib/plat-mac/
to Lib/.

svn rm Lib/plistlib.py
svn cp -r 60150
svn+ssh://pythondev at svn.python.org/python/branches/py3k/Lib/plat-mac/plistlib.py
Lib/

svnmerge.py doesn't automatically do relative copies. It always copies
the absolute path. In the case of a rename, move or copy one has to copy
the right file manually.

Christian


From guido at python.org  Sat Jan 26 23:13:44 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 26 Jan 2008 14:13:44 -0800
Subject: [Python-3000] plistlib module and test
In-Reply-To: <ee2a432c0801261357i2f5fa475k4606d943bf28fb24@mail.gmail.com>
References: <ee2a432c0801261357i2f5fa475k4606d943bf28fb24@mail.gmail.com>
Message-ID: <ca471dc20801261413r6d71115w73283f0a3ffe1257@mail.gmail.com>

I filed http://bugs.python.org/issue1942 about this.

On Jan 26, 2008 1:57 PM, Neal Norwitz <nnorwitz at gmail.com> wrote:
> I remember seeing a change which moved the plistlib module from
> Lib/plat-mac to Lib so all platforms can use it.  This change causes
> *all* the builds fail because the test has several problems.  For
> example, the test references functions/methods that don't exist (see
> below).  Can someone fix this?
>
>   File "/home/pybot/buildarea/3.0.klose-debian-ia64/build/Lib/test/test_plistlib.py",
> line 140, in test_appleformatting
>     pl = plistlib.readPlistFromBytes(TESTDATA)
> AttributeError: 'module' object has no attribute 'readPlistFromBytes'
>
>   File "/home/pybot/buildarea/3.0.klose-debian-ia64/build/Lib/test/test_plistlib.py",
> line 133, in test_bytes
>     data = plistlib.writePlistToBytes(pl)
> AttributeError: 'module' object has no attribute 'writePlistToBytes'
>
> There are 2 more errors I noticed.  Here's an example:
> http://www.python.org/dev/buildbot/all/ia64%20Ubuntu%203.0/builds/471/step-test/0
>
> n
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From guido at python.org  Sat Jan 26 23:16:11 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 26 Jan 2008 14:16:11 -0800
Subject: [Python-3000] plistlib module and test
In-Reply-To: <fngb9n$c1k$1@ger.gmane.org>
References: <ee2a432c0801261357i2f5fa475k4606d943bf28fb24@mail.gmail.com>
	<fngb9n$c1k$1@ger.gmane.org>
Message-ID: <ca471dc20801261416o6a8414c4gd93df0a55c31534f@mail.gmail.com>

On Jan 26, 2008 2:13 PM, Christian Heimes <lists at cheimes.de> wrote:
> Neal Norwitz wrote:
> > I remember seeing a change which moved the plistlib module from
> > Lib/plat-mac to Lib so all platforms can use it.  This change causes
> > *all* the builds fail because the test has several problems.  For
> > example, the test references functions/methods that don't exist (see
> > below).  Can someone fix this?
>
> I fixed it by copying plistlib.py from the py3k directory Lib/plat-mac/
> to Lib/.
>
> svn rm Lib/plistlib.py
> svn cp -r 60150
> svn+ssh://pythondev at svn.python.org/python/branches/py3k/Lib/plat-mac/plistlib.py
> Lib/
>
> svnmerge.py doesn't automatically do relative copies. It always copies
> the absolute path. In the case of a rename, move or copy one has to copy
> the right file manually.

Well that sucks. Can't it be fixed in svnmerge?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From adlaiff6 at gmail.com  Sat Jan 26 23:25:54 2008
From: adlaiff6 at gmail.com (Leif Walsh)
Date: Sat, 26 Jan 2008 17:25:54 -0500
Subject: [Python-3000] Set literal
In-Reply-To: <ca471dc20801261411w6d942981hb247ca4ad6220c17@mail.gmail.com>
References: <20080125220358.AFT02821@ms19.lnh.mail.rcn.net>
	<479B9C84.1050605@ronadam.com>
	<003301c86064$cf68d810$6800a8c0@RaymondLaptop1>
	<ca471dc20801261350v21d84038g597030fcd9f8e6e6@mail.gmail.com>
	<fngalj$a73$1@ger.gmane.org>
	<ca471dc20801261411w6d942981hb247ca4ad6220c17@mail.gmail.com>
Message-ID: <cc7430500801261425l2c73c0f8sbbef761ce7503380@mail.gmail.com>

On Jan 26, 2008 5:11 PM, Guido van Rossum <guido at python.org> wrote:
> But didn't we start by establishing that users are rarely going to
> create non-empty non-frozen sets anyway, because most algorithms
> involving mutable sets start with an empty one? Even if users
> occasionally write initialized sets, I find it hard to believe that
> this would occur in a performance-critical position.

+1

I can't imagine ever being annoyed that a non-empty mutable set that I
type in myself runs a little slower than it could.

--
Cheers,
Leif

From lists at cheimes.de  Sat Jan 26 23:34:47 2008
From: lists at cheimes.de (Christian Heimes)
Date: Sat, 26 Jan 2008 23:34:47 +0100
Subject: [Python-3000] plistlib module and test
In-Reply-To: <ca471dc20801261416o6a8414c4gd93df0a55c31534f@mail.gmail.com>
References: <ee2a432c0801261357i2f5fa475k4606d943bf28fb24@mail.gmail.com>	<fngb9n$c1k$1@ger.gmane.org>
	<ca471dc20801261416o6a8414c4gd93df0a55c31534f@mail.gmail.com>
Message-ID: <fngci7$g20$1@ger.gmane.org>

Guido van Rossum wrote:
> Well that sucks. Can't it be fixed in svnmerge?

I don't know. We could probably ask the author about it. His name is
Giovanni Bajo.


From rhamph at gmail.com  Sun Jan 27 04:50:36 2008
From: rhamph at gmail.com (Adam Olsen)
Date: Sat, 26 Jan 2008 20:50:36 -0700
Subject: [Python-3000] Set literal
In-Reply-To: <ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
Message-ID: <aac2c7cb0801261950j31f804feg28fd523e0bafcaa2@mail.gmail.com>

On Jan 24, 2008 9:12 PM, Guido van Rossum <guido at python.org> wrote:
> For the record, I'm thinking Raymond has won this argument fair and
> square, and I'm withdrawing my opposition.
>
> I hope it isn't too confusing that {1: 1} creates a *mutable* dict
> while {1} creates an *immutable* frozenset. I still find this slightly
> inelegant. But the practicality of being able to treat set literals as
> compile-time constants wins me over.
>
> (I suspect for a 2-element set of ints or strings, translating "x in
> {C1, C2}" into "x in (C1, C2)" might actually be a slight win since
> probing a tuple must be much faster than probing a set; but that's a
> detail.)

Given that "x in {1,2,3}" can be optimized just as well with mutable
sets (can somebody think of an example that can't?), do you still
support immutable using the literal notation?


-- 
Adam Olsen, aka Rhamphoryncus

From python at rcn.com  Sun Jan 27 05:39:36 2008
From: python at rcn.com (Raymond Hettinger)
Date: Sat, 26 Jan 2008 20:39:36 -0800
Subject: [Python-3000] Set literal
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<aac2c7cb0801261950j31f804feg28fd523e0bafcaa2@mail.gmail.com>
Message-ID: <00b501c8609e$9f5f95c0$6800a8c0@RaymondLaptop1>

[Adam]
> Given that "x in {1,2,3}" can be optimized just as well with mutable
> sets (can somebody think of an example that can't?), do you still
> support immutable using the literal notation?

>From an optimization point of view, it is still best to have {...} as a frozenset.

However, my support for it has waned anyway.  The notation is also
used for set comprehension and those should be mutable.


Raymond

From guido at python.org  Sun Jan 27 06:20:23 2008
From: guido at python.org (Guido van Rossum)
Date: Sat, 26 Jan 2008 21:20:23 -0800
Subject: [Python-3000] Set literal
In-Reply-To: <00b501c8609e$9f5f95c0$6800a8c0@RaymondLaptop1>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<aac2c7cb0801261950j31f804feg28fd523e0bafcaa2@mail.gmail.com>
	<00b501c8609e$9f5f95c0$6800a8c0@RaymondLaptop1>
Message-ID: <ca471dc20801262120h342069e6ye29cc7d7a2f7e8e@mail.gmail.com>

On Jan 26, 2008 8:39 PM, Raymond Hettinger <python at rcn.com> wrote:
> [Adam]
> > Given that "x in {1,2,3}" can be optimized just as well with mutable
> > sets (can somebody think of an example that can't?), do you still
> > support immutable using the literal notation?
>
> From an optimization point of view, it is still best to have {...} as a frozenset.
>
> However, my support for it has waned anyway.  The notation is also
> used for set comprehension and those should be mutable.

Cool. That saves us a PEP. Vive le status quo.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From python at rcn.com  Sun Jan 27 06:57:24 2008
From: python at rcn.com (Raymond Hettinger)
Date: Sat, 26 Jan 2008 21:57:24 -0800
Subject: [Python-3000] Set literal
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<aac2c7cb0801261950j31f804feg28fd523e0bafcaa2@mail.gmail.com>
	<00b501c8609e$9f5f95c0$6800a8c0@RaymondLaptop1>
	<ca471dc20801262120h342069e6ye29cc7d7a2f7e8e@mail.gmail.com>
Message-ID: <010101c860a9$7db56ac0$6800a8c0@RaymondLaptop1>

>> However, my support for it has waned anyway.  The notation is also
>> used for set comprehension and those should be mutable.
> 
> Cool. That saves us a PEP. Vive le status quo.

It just wasn't me to be.


Raymond

From ncoghlan at gmail.com  Mon Jan 28 05:16:54 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 28 Jan 2008 14:16:54 +1000
Subject: [Python-3000] [Python-3000-checkins] r60376 - in
 python/branches/py3k:	Lib/test/test_float.py
 Lib/test/test_long.py	Objects/stringlib/formatter.h
In-Reply-To: <20080127210759.A620F1E4014@bag.python.org>
References: <20080127210759.A620F1E4014@bag.python.org>
Message-ID: <479D5736.2030403@gmail.com>

eric.smith wrote:
> Author: eric.smith
> Date: Sun Jan 27 22:07:59 2008
> New Revision: 60376
> 
> Modified:
>    python/branches/py3k/Lib/test/test_float.py
>    python/branches/py3k/Lib/test/test_long.py
>    python/branches/py3k/Objects/stringlib/formatter.h
> Log:
> Restrict format presentation types to those specified in the 'Standard Format Specifiers' section of PEP 3101.

I think this checkin goes too far in removing support for the floating 
point formatting codes from integers. Guido objected to %d working on 
floats last year, but expected %f and friends to continue to work on 
integers [1]. This makes sense when you consider that there is no data 
loss in displaying an integer as a floating point number, while there is 
a definite potential for data loss when going the other way.

Perhaps the PEP needs a tweak (referencing Guido's email) to state 
explicitly that the builtin integers understand the floating point 
formatting codes, but the builtin and standard library floating point 
types don't understand the integer codes? That area of the PEP is 
slightly problematic anyway where it suggests that integers could handle 
the floating point codes by delegating to float() - that isn't quite 
true, since the maximum precision on floats is less than the maximum 
precision on integers.

Cheers,
Nick.

[1]
http://mail.python.org/pipermail/python-3000/2007-August/009066.html


-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From guido at python.org  Mon Jan 28 05:23:29 2008
From: guido at python.org (Guido van Rossum)
Date: Sun, 27 Jan 2008 20:23:29 -0800
Subject: [Python-3000] [Python-3000-checkins] r60376 - in
	python/branches/py3k: Lib/test/test_float.py
	Lib/test/test_long.py Objects/stringlib/formatter.h
In-Reply-To: <479D5736.2030403@gmail.com>
References: <20080127210759.A620F1E4014@bag.python.org>
	<479D5736.2030403@gmail.com>
Message-ID: <ca471dc20801272023r1fe39d96o8c98fe2c2ec073dc@mail.gmail.com>

On Jan 27, 2008 8:16 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> eric.smith wrote:
> > Author: eric.smith
> > Date: Sun Jan 27 22:07:59 2008
> > New Revision: 60376
> >
> > Modified:
> >    python/branches/py3k/Lib/test/test_float.py
> >    python/branches/py3k/Lib/test/test_long.py
> >    python/branches/py3k/Objects/stringlib/formatter.h
> > Log:
> > Restrict format presentation types to those specified in the 'Standard Format Specifiers' section of PEP 3101.
>
> I think this checkin goes too far in removing support for the floating
> point formatting codes from integers. Guido objected to %d working on
> floats last year, but expected %f and friends to continue to work on
> integers [1]. This makes sense when you consider that there is no data
> loss in displaying an integer as a floating point number, while there is
> a definite potential for data loss when going the other way.
>
> Perhaps the PEP needs a tweak (referencing Guido's email) to state
> explicitly that the builtin integers understand the floating point
> formatting codes, but the builtin and standard library floating point
> types don't understand the integer codes? That area of the PEP is
> slightly problematic anyway where it suggests that integers could handle
> the floating point codes by delegating to float() - that isn't quite
> true, since the maximum precision on floats is less than the maximum
> precision on integers.
>
> Cheers,
> Nick.
>
> [1]
> http://mail.python.org/pipermail/python-3000/2007-August/009066.html

Agreed with Nick -- in general, the idea is that ints should be
allowed whenever floats are expected -- just not the other way around!
Python 2.x broke this in one important place, division -- 2/3 and
2.0/3.0 had different meanings there. We are fixing this in 3.0.
Please maintain this rule for formatting!

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From aahz at pythoncraft.com  Mon Jan 28 05:50:18 2008
From: aahz at pythoncraft.com (Aahz)
Date: Sun, 27 Jan 2008 20:50:18 -0800
Subject: [Python-3000] [Python-3000-checkins] r60376 - in
	python/branches/py3k:	Lib/test/test_float.py
	Lib/test/test_long.py	Objects/stringlib/formatter.h
In-Reply-To: <479D5736.2030403@gmail.com>
References: <20080127210759.A620F1E4014@bag.python.org>
	<479D5736.2030403@gmail.com>
Message-ID: <20080128045018.GA23131@panix.com>

On Mon, Jan 28, 2008, Nick Coghlan wrote:
>
> I think this checkin goes too far in removing support for the floating 
> point formatting codes from integers. Guido objected to %d working on 
> floats last year, but expected %f and friends to continue to work on 
> integers [1]. This makes sense when you consider that there is no data 
> loss in displaying an integer as a floating point number, while there is 
> a definite potential for data loss when going the other way.

Not true:

>>> repr(float(1234567890123456789012345678901234567890123456789012345678901234567890))
'1.2345678901234567e+69'

Overall, I could care less what decision gets made, but I think it's
unfair to make the decision on an incorrect argument.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"All problems in computer science can be solved by another level of     
indirection."  --Butler Lampson

From ncoghlan at gmail.com  Mon Jan 28 07:06:33 2008
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Mon, 28 Jan 2008 16:06:33 +1000
Subject: [Python-3000] r60376 -
 in	python/branches/py3k:	Lib/test/test_float.py
 Lib/test/test_long.py	Objects/stringlib/formatter.h
In-Reply-To: <20080128045018.GA23131@panix.com>
References: <20080127210759.A620F1E4014@bag.python.org>	<479D5736.2030403@gmail.com>
	<20080128045018.GA23131@panix.com>
Message-ID: <479D70E9.8000601@gmail.com>

Aahz wrote:
> On Mon, Jan 28, 2008, Nick Coghlan wrote:
>> I think this checkin goes too far in removing support for the floating 
>> point formatting codes from integers. Guido objected to %d working on 
>> floats last year, but expected %f and friends to continue to work on 
>> integers [1]. This makes sense when you consider that there is no data 
>> loss in displaying an integer as a floating point number, while there is 
>> a definite potential for data loss when going the other way.
> 
> Not true:
> 
>>>> repr(float(1234567890123456789012345678901234567890123456789012345678901234567890))
> '1.2345678901234567e+69'

I remarked on that problem in the paragraph you cut out - the data loss 
in your example is caused by the conversion to the builtin float type, 
not by the act of displaying an integer as a floating point number. To 
get lossless display of integers in scientific notation, all you need to 
do is use the whole of the integer value as the mantissa (probably with 
any trailing zeroes stripped, as we're talking about display here rather 
than values intended for further processing).

That is, I think it should be possible to write something like the 
following:

 >>>format(1234567890123456789012345678901234567890123456789012345678900000000000, 
'f')
'1.23456789012345678901234567890123456789012345678901234567890e+69'

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org

From greg.ewing at canterbury.ac.nz  Mon Jan 28 07:13:25 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 28 Jan 2008 19:13:25 +1300
Subject: [Python-3000] Ellipsis Literal
In-Reply-To: <261F2224-7CBA-4E68-A2DE-8FCB64B2D794@activestate.com>
References: <20080124141633.AFQ57054@ms19.lnh.mail.rcn.net>
	<ca471dc20801241132q6d6df78ej845f4b637d1d5ea3@mail.gmail.com>
	<261F2224-7CBA-4E68-A2DE-8FCB64B2D794@activestate.com>
Message-ID: <479D7285.7090000@canterbury.ac.nz>

Gisle Aas wrote:
> I think it would be been nice if "..." raised an NotYetImplemented  
> exception if executed as a lone statement.

That's quite a clever idea! Not sure if it's actually desirable,
but it makes a Monty Pythonish sort of sense.

> BTW, Perl 6 also introduce the same feature and Larry calls it the  
> "yadayadayada operator"[1].

We should call the exception YaddaYaddaError, then. :-)

--
Greg


From hashcollision at gmail.com  Mon Jan 28 08:08:20 2008
From: hashcollision at gmail.com (hashcollision)
Date: Mon, 28 Jan 2008 02:08:20 -0500
Subject: [Python-3000] Rename re.sub and re.subn
Message-ID: <37f76d50801272308p5349e51an8fca9c607dd463d@mail.gmail.com>

I have always thought that re's sub and subn are misnamed. I always
mis-remember them as 'replace'. Can they either be renamed to
"replace" and "replacen" or at least the new functions added?

From greg.ewing at canterbury.ac.nz  Mon Jan 28 06:38:13 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 28 Jan 2008 18:38:13 +1300
Subject: [Python-3000] Set literal
In-Reply-To: <ca471dc20801262120h342069e6ye29cc7d7a2f7e8e@mail.gmail.com>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<aac2c7cb0801261950j31f804feg28fd523e0bafcaa2@mail.gmail.com>
	<00b501c8609e$9f5f95c0$6800a8c0@RaymondLaptop1>
	<ca471dc20801262120h342069e6ye29cc7d7a2f7e8e@mail.gmail.com>
Message-ID: <479D6A45.6090607@canterbury.ac.nz>

Guido van Rossum wrote:
> On Jan 26, 2008 8:39 PM, Raymond Hettinger <python at rcn.com> wrote:
> 
>>However, my support for it has waned anyway.  The notation is also
>>used for set comprehension and those should be mutable.
> 
> Cool. That saves us a PEP. Vive le status quo.

You're changing your mind back again just like that? That's
disappointing -- I was fairly convinced there as well.

Another possibility would be to drop set comprehension
syntax and just require people to use set(genexp).

Or have set comprehensions produce frozensets and require
set(genexp) to get a mutable set.

On the face of it, it's not clear to me that the result of
a set comprehension should necessarily be mutable.

When I think about how I have used list comprehensions,
mutability of the resulting list isn't usually a requirement.
I don't expect this would be different with sets.

--
Greg

From greg.ewing at canterbury.ac.nz  Mon Jan 28 09:35:40 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 28 Jan 2008 21:35:40 +1300
Subject: [Python-3000] Ellipsis Literal
In-Reply-To: <ca471dc20801241132q6d6df78ej845f4b637d1d5ea3@mail.gmail.com>
References: <20080124141633.AFQ57054@ms19.lnh.mail.rcn.net>
	<ca471dc20801241132q6d6df78ej845f4b637d1d5ea3@mail.gmail.com>
Message-ID: <479D93DC.2030500@canterbury.ac.nz>

Guido van Rossum wrote:
> Some folks thought it would be cute to be able to write incomplete
> code like this:
> 
> class C:
>   def meth(self): ...
>   ...

I thought there were better reasons than that.
For example, the new print() function could be
arranged so that

   print(a, b, c, ...)

prints a line without a newline.

--
Greg

From eric at trueblade.com  Mon Jan 28 11:30:14 2008
From: eric at trueblade.com (Eric Smith)
Date: Mon, 28 Jan 2008 05:30:14 -0500
Subject: [Python-3000] [Python-3000-checkins] r60376 - in
 python/branches/py3k:	Lib/test/test_float.py
 Lib/test/test_long.py	Objects/stringlib/formatter.h
In-Reply-To: <ca471dc20801272023r1fe39d96o8c98fe2c2ec073dc@mail.gmail.com>
References: <20080127210759.A620F1E4014@bag.python.org>	<479D5736.2030403@gmail.com>
	<ca471dc20801272023r1fe39d96o8c98fe2c2ec073dc@mail.gmail.com>
Message-ID: <479DAEB6.1040404@trueblade.com>

Guido van Rossum wrote:
> On Jan 27, 2008 8:16 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> eric.smith wrote:
>>> Author: eric.smith
>>> Date: Sun Jan 27 22:07:59 2008
>>> New Revision: 60376
>>>
>>> Modified:
>>>    python/branches/py3k/Lib/test/test_float.py
>>>    python/branches/py3k/Lib/test/test_long.py
>>>    python/branches/py3k/Objects/stringlib/formatter.h
>>> Log:
>>> Restrict format presentation types to those specified in the 'Standard Format Specifiers' section of PEP 3101.
>> I think this checkin goes too far in removing support for the floating
>> point formatting codes from integers. Guido objected to %d working on
>> floats last year, but expected %f and friends to continue to work on
>> integers [1]. This makes sense when you consider that there is no data
>> loss in displaying an integer as a floating point number, while there is
>> a definite potential for data loss when going the other way.
>>
>> Perhaps the PEP needs a tweak (referencing Guido's email) to state
>> explicitly that the builtin integers understand the floating point
>> formatting codes, but the builtin and standard library floating point
>> types don't understand the integer codes? That area of the PEP is
>> slightly problematic anyway where it suggests that integers could handle
>> the floating point codes by delegating to float() - that isn't quite
>> true, since the maximum precision on floats is less than the maximum
>> precision on integers.
>>
>> Cheers,
>> Nick.
>>
>> [1]
>> http://mail.python.org/pipermail/python-3000/2007-August/009066.html
> 
> Agreed with Nick -- in general, the idea is that ints should be
> allowed whenever floats are expected -- just not the other way around!
> Python 2.x broke this in one important place, division -- 2/3 and
> 2.0/3.0 had different meanings there. We are fixing this in 3.0.
> Please maintain this rule for formatting!
> 

Okay, I'll restore ints understanding float formatting codes.


From jimjjewett at gmail.com  Mon Jan 28 15:42:04 2008
From: jimjjewett at gmail.com (Jim Jewett)
Date: Mon, 28 Jan 2008 09:42:04 -0500
Subject: [Python-3000] Set literal
In-Reply-To: <479D6A45.6090607@canterbury.ac.nz>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<aac2c7cb0801261950j31f804feg28fd523e0bafcaa2@mail.gmail.com>
	<00b501c8609e$9f5f95c0$6800a8c0@RaymondLaptop1>
	<ca471dc20801262120h342069e6ye29cc7d7a2f7e8e@mail.gmail.com>
	<479D6A45.6090607@canterbury.ac.nz>
Message-ID: <fb6fbf560801280642w8dc60e0je9310fab7a3be87f@mail.gmail.com>

On 1/28/08, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Guido van Rossum wrote:
> > On Jan 26, 2008 8:39 PM, Raymond Hettinger <python at rcn.com> wrote:

> >>However, my support for it has waned anyway.  The
> >> notation is also used for set comprehension
> >> and those should be mutable.

Set comprehensions don't appear yet in 2.5, so they aren't yet an
immovable constraint.

How often are set comprehensions needed, and how often must they be mutable?

In my own code, I already tend to treat even the results of a list
comprehension as immutable.  Normally, the result is already a
complete set, and when it isn't, the code is already awkward as I
digress to get the other members.

    res = tupleA + tupleB

wouldn't really be any worse than

    res.extend(listB)

and I would actually prefer

    res = setA.union(setB)

> Another possibility would be to drop set comprehension
> syntax and just require people to use set(genexp).

This looks fine to me, but again, I usually just iterate through it
once, so I typically use list even when a set would be more
semantically correct.

> Or have set comprehensions produce frozensets and require
> set(genexp) to get a mutable set.

Absolutely ... why are the default sets mutable?  When I want a
mutable set, I almost always start with an empty set.  Even when I
have initial members, they usually come from another container, and
turning them into a set is (mentally) more of a casting than a
comprehension.

-jJ

From guido at python.org  Mon Jan 28 17:02:24 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 28 Jan 2008 08:02:24 -0800
Subject: [Python-3000] Set literal
In-Reply-To: <479D6A45.6090607@canterbury.ac.nz>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<aac2c7cb0801261950j31f804feg28fd523e0bafcaa2@mail.gmail.com>
	<00b501c8609e$9f5f95c0$6800a8c0@RaymondLaptop1>
	<ca471dc20801262120h342069e6ye29cc7d7a2f7e8e@mail.gmail.com>
	<479D6A45.6090607@canterbury.ac.nz>
Message-ID: <ca471dc20801280802s68875edck907008f797a4ccc5@mail.gmail.com>

Please don't reopen this. There are good reasons for 'set' to be the
default set type and 'frozenset' to appear like a poor cousin. For
one, their naming. This was all reasoned out long, long ago, in Python
2.3 with the sets module. If you insist I will try to write it up all
again, but I'd rather you believe that we weren't crazy back then.
Raymond's about-face suggests that there are plenty of dead alleys
that lead the traveler astray by appearing to be a shortcut to their
destination.

--Guido

On Jan 27, 2008 9:38 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Guido van Rossum wrote:
> > On Jan 26, 2008 8:39 PM, Raymond Hettinger <python at rcn.com> wrote:
> >
> >>However, my support for it has waned anyway.  The notation is also
> >>used for set comprehension and those should be mutable.
> >
> > Cool. That saves us a PEP. Vive le status quo.
>
> You're changing your mind back again just like that? That's
> disappointing -- I was fairly convinced there as well.
>
> Another possibility would be to drop set comprehension
> syntax and just require people to use set(genexp).
>
> Or have set comprehensions produce frozensets and require
> set(genexp) to get a mutable set.
>
> On the face of it, it's not clear to me that the result of
> a set comprehension should necessarily be mutable.
>
> When I think about how I have used list comprehensions,
> mutability of the resulting list isn't usually a requirement.
> I don't expect this would be different with sets.
>
> --
> Greg
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From greg.ewing at canterbury.ac.nz  Mon Jan 28 23:46:26 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 29 Jan 2008 11:46:26 +1300
Subject: [Python-3000] Set literal
In-Reply-To: <ca471dc20801280802s68875edck907008f797a4ccc5@mail.gmail.com>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<aac2c7cb0801261950j31f804feg28fd523e0bafcaa2@mail.gmail.com>
	<00b501c8609e$9f5f95c0$6800a8c0@RaymondLaptop1>
	<ca471dc20801262120h342069e6ye29cc7d7a2f7e8e@mail.gmail.com>
	<479D6A45.6090607@canterbury.ac.nz>
	<ca471dc20801280802s68875edck907008f797a4ccc5@mail.gmail.com>
Message-ID: <479E5B42.1010908@canterbury.ac.nz>

Guido van Rossum wrote:
> This was all reasoned out long, long ago, in Python
> 2.3 with the sets module. If you insist I will try to write it up all
> again, but I'd rather you believe that we weren't crazy back then.

Is there a PEP we can refer to for confirmation of
said non-craziness?

--
Greg

From guido at python.org  Tue Jan 29 00:03:58 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 28 Jan 2008 15:03:58 -0800
Subject: [Python-3000] Set literal
In-Reply-To: <479E5B42.1010908@canterbury.ac.nz>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<aac2c7cb0801261950j31f804feg28fd523e0bafcaa2@mail.gmail.com>
	<00b501c8609e$9f5f95c0$6800a8c0@RaymondLaptop1>
	<ca471dc20801262120h342069e6ye29cc7d7a2f7e8e@mail.gmail.com>
	<479D6A45.6090607@canterbury.ac.nz>
	<ca471dc20801280802s68875edck907008f797a4ccc5@mail.gmail.com>
	<479E5B42.1010908@canterbury.ac.nz>
Message-ID: <ca471dc20801281503n3f02344bx156502fb2ceaecde@mail.gmail.com>

On Jan 28, 2008 2:46 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Guido van Rossum wrote:
> > This was all reasoned out long, long ago, in Python
> > 2.3 with the sets module. If you insist I will try to write it up all
> > again, but I'd rather you believe that we weren't crazy back then.
>
> Is there a PEP we can refer to for confirmation of
> said non-craziness?

Have a look at PEP 218.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From greg.ewing at canterbury.ac.nz  Tue Jan 29 00:45:26 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 29 Jan 2008 12:45:26 +1300
Subject: [Python-3000] Set literal
In-Reply-To: <ca471dc20801281503n3f02344bx156502fb2ceaecde@mail.gmail.com>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<aac2c7cb0801261950j31f804feg28fd523e0bafcaa2@mail.gmail.com>
	<00b501c8609e$9f5f95c0$6800a8c0@RaymondLaptop1>
	<ca471dc20801262120h342069e6ye29cc7d7a2f7e8e@mail.gmail.com>
	<479D6A45.6090607@canterbury.ac.nz>
	<ca471dc20801280802s68875edck907008f797a4ccc5@mail.gmail.com>
	<479E5B42.1010908@canterbury.ac.nz>
	<ca471dc20801281503n3f02344bx156502fb2ceaecde@mail.gmail.com>
Message-ID: <479E6916.3050208@canterbury.ac.nz>

Guido van Rossum wrote:
> On Jan 28, 2008 2:46 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> 
>>Is there a PEP we can refer to for confirmation of
>>said non-craziness?
> 
> Have a look at PEP 218.

That PEP proposes that there be no set literal or comprehension
syntax, and doesn't contain any discussion on whether such
syntax should produce sets or frozensets if it were to exist.

Maybe there was discussion about that at the time, but it would
be good to have it summarised in a PEP somewhere.

--
Greg



From guido at python.org  Tue Jan 29 00:58:52 2008
From: guido at python.org (Guido van Rossum)
Date: Mon, 28 Jan 2008 15:58:52 -0800
Subject: [Python-3000] Set literal
In-Reply-To: <479E6916.3050208@canterbury.ac.nz>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<aac2c7cb0801261950j31f804feg28fd523e0bafcaa2@mail.gmail.com>
	<00b501c8609e$9f5f95c0$6800a8c0@RaymondLaptop1>
	<ca471dc20801262120h342069e6ye29cc7d7a2f7e8e@mail.gmail.com>
	<479D6A45.6090607@canterbury.ac.nz>
	<ca471dc20801280802s68875edck907008f797a4ccc5@mail.gmail.com>
	<479E5B42.1010908@canterbury.ac.nz>
	<ca471dc20801281503n3f02344bx156502fb2ceaecde@mail.gmail.com>
	<479E6916.3050208@canterbury.ac.nz>
Message-ID: <ca471dc20801281558i7c0ffa30mb847c68eaf2b32d8@mail.gmail.com>

On Jan 28, 2008 3:45 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Guido van Rossum wrote:
> > On Jan 28, 2008 2:46 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> >
> >>Is there a PEP we can refer to for confirmation of
> >>said non-craziness?
> >
> > Have a look at PEP 218.
>
> That PEP proposes that there be no set literal or comprehension
> syntax, and doesn't contain any discussion on whether such
> syntax should produce sets or frozensets if it were to exist.
>
> Maybe there was discussion about that at the time, but it would
> be good to have it summarised in a PEP somewhere.

No, but it *does* make 'set' the "default" type, making you work
harder to get a frozenset. From this it follows that frozenset was
considered the lesser-useful type at the time. And I still feel that
way.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From greg.ewing at canterbury.ac.nz  Tue Jan 29 03:24:24 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 29 Jan 2008 15:24:24 +1300
Subject: [Python-3000] Set literal
In-Reply-To: <ca471dc20801281558i7c0ffa30mb847c68eaf2b32d8@mail.gmail.com>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<aac2c7cb0801261950j31f804feg28fd523e0bafcaa2@mail.gmail.com>
	<00b501c8609e$9f5f95c0$6800a8c0@RaymondLaptop1>
	<ca471dc20801262120h342069e6ye29cc7d7a2f7e8e@mail.gmail.com>
	<479D6A45.6090607@canterbury.ac.nz>
	<ca471dc20801280802s68875edck907008f797a4ccc5@mail.gmail.com>
	<479E5B42.1010908@canterbury.ac.nz>
	<ca471dc20801281503n3f02344bx156502fb2ceaecde@mail.gmail.com>
	<479E6916.3050208@canterbury.ac.nz>
	<ca471dc20801281558i7c0ffa30mb847c68eaf2b32d8@mail.gmail.com>
Message-ID: <479E8E58.4040802@canterbury.ac.nz>

Guido van Rossum wrote:

> No, but it *does* make 'set' the "default" type, making you work
> harder to get a frozenset. From this it follows that frozenset was
> considered the lesser-useful type at the time.

That logic assumes that one of them necessarily has to be
harder to get than the other, therefore we have to pick
one to be the "default".

With no literal syntax there might be some truth in that,
but with a literal syntax it no longer holds. We can have
the literal syntax produce one and set() produce the
other.

What's more, the recent discussion has put forward what
seems like an excellent use for frozensets, i.e. making
'if x in {1, 2, 3}' highly optimisable.

The original PEP doesn't explicity address any of these
arguments. Even if they're rejected, they deserve to be
set out in a PEP along with the reasons for rejection,
I think, to stop them from recurring.

--
Greg

From jimjjewett at gmail.com  Tue Jan 29 13:58:35 2008
From: jimjjewett at gmail.com (Jim Jewett)
Date: Tue, 29 Jan 2008 07:58:35 -0500
Subject: [Python-3000] Set literal
In-Reply-To: <ca471dc20801280802s68875edck907008f797a4ccc5@mail.gmail.com>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<aac2c7cb0801261950j31f804feg28fd523e0bafcaa2@mail.gmail.com>
	<00b501c8609e$9f5f95c0$6800a8c0@RaymondLaptop1>
	<ca471dc20801262120h342069e6ye29cc7d7a2f7e8e@mail.gmail.com>
	<479D6A45.6090607@canterbury.ac.nz>
	<ca471dc20801280802s68875edck907008f797a4ccc5@mail.gmail.com>
Message-ID: <fb6fbf560801290458q6c453ff7h2ced4916f4cfd0ca@mail.gmail.com>

On 1/28/08, Guido van Rossum <guido at python.org> wrote:
> Please don't reopen this. There are good reasons for 'set' to be the
> default set type and 'frozenset' to appear like a poor cousin. For
> one, their naming. This was all reasoned out long, long ago, in Python
> 2.3 with the sets module.

In general, mutable sets are more useful.

I don't think that applies to the more specific use case of already
having members available when you create the set.

To rephrase:

The majority of uses need a mutable set that starts empty.
The majority of uses that start non-empty do not require mutability.

In fairness, most of the non-empty cases don't require hashability
either, so a mutable set remains an acceptable substitute.  The
question is whether an explicit set( ) around it to indicate
mutability (and the loss of hashability) is desirable.  (Today, we
need the longer frozenset to indicate the opposite, but I'll agree
that we don't need it often.)

-jJ

From greg.ewing at canterbury.ac.nz  Tue Jan 29 23:29:24 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 30 Jan 2008 11:29:24 +1300
Subject: [Python-3000] Set literal
In-Reply-To: <fb6fbf560801290458q6c453ff7h2ced4916f4cfd0ca@mail.gmail.com>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<aac2c7cb0801261950j31f804feg28fd523e0bafcaa2@mail.gmail.com>
	<00b501c8609e$9f5f95c0$6800a8c0@RaymondLaptop1>
	<ca471dc20801262120h342069e6ye29cc7d7a2f7e8e@mail.gmail.com>
	<479D6A45.6090607@canterbury.ac.nz>
	<ca471dc20801280802s68875edck907008f797a4ccc5@mail.gmail.com>
	<fb6fbf560801290458q6c453ff7h2ced4916f4cfd0ca@mail.gmail.com>
Message-ID: <479FA8C4.2040204@canterbury.ac.nz>

Jim Jewett wrote:

> The majority of uses need a mutable set that starts empty.

Does anyone have evidence to support that assertion?

Thinking about my own code, I probably do membership
tests on constant sets (represented as tuples) about as
often as I build up mutable sets (or some equivalent data
structure).

--
Greg

From mike.klaas at gmail.com  Wed Jan 30 01:18:39 2008
From: mike.klaas at gmail.com (Mike Klaas)
Date: Tue, 29 Jan 2008 16:18:39 -0800
Subject: [Python-3000] Set literal
In-Reply-To: <479FA8C4.2040204@canterbury.ac.nz>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<aac2c7cb0801261950j31f804feg28fd523e0bafcaa2@mail.gmail.com>
	<00b501c8609e$9f5f95c0$6800a8c0@RaymondLaptop1>
	<ca471dc20801262120h342069e6ye29cc7d7a2f7e8e@mail.gmail.com>
	<479D6A45.6090607@canterbury.ac.nz>
	<ca471dc20801280802s68875edck907008f797a4ccc5@mail.gmail.com>
	<fb6fbf560801290458q6c453ff7h2ced4916f4cfd0ca@mail.gmail.com>
	<479FA8C4.2040204@canterbury.ac.nz>
Message-ID: <AB2447EA-B1D1-463D-B947-4DBEF40091E0@gmail.com>


On 29-Jan-08, at 2:29 PM, Greg Ewing wrote:

> Jim Jewett wrote:
>
>> The majority of uses need a mutable set that starts empty.
>
> Does anyone have evidence to support that assertion?
>
> Thinking about my own code, I probably do membership
> tests on constant sets (represented as tuples) about as
> often as I build up mutable sets (or some equivalent data
> structure).

over 120k loc:

All uses of set():

$ pygrep '[^.a-z]set[(]' | grep -v unittest | wc
     320    1583   24774

Empty set():

$ pygrep '[^.a-z]set[(][)]' | grep -v unittest | wc
     114     478    7406

Some of the uses in the first group could be replaced with frozenset,  
of course.  Looking at the examples, though, I would say that most of  
the uses of sets start out using a set constructed using  
comprehension or set(<iterable>).

I think that 'set()' is a perfectly fine and readable empty set  
"literal".

-Mike

From jimjjewett at gmail.com  Wed Jan 30 04:14:26 2008
From: jimjjewett at gmail.com (Jim Jewett)
Date: Tue, 29 Jan 2008 22:14:26 -0500
Subject: [Python-3000] Set literal
In-Reply-To: <AB2447EA-B1D1-463D-B947-4DBEF40091E0@gmail.com>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<aac2c7cb0801261950j31f804feg28fd523e0bafcaa2@mail.gmail.com>
	<00b501c8609e$9f5f95c0$6800a8c0@RaymondLaptop1>
	<ca471dc20801262120h342069e6ye29cc7d7a2f7e8e@mail.gmail.com>
	<479D6A45.6090607@canterbury.ac.nz>
	<ca471dc20801280802s68875edck907008f797a4ccc5@mail.gmail.com>
	<fb6fbf560801290458q6c453ff7h2ced4916f4cfd0ca@mail.gmail.com>
	<479FA8C4.2040204@canterbury.ac.nz>
	<AB2447EA-B1D1-463D-B947-4DBEF40091E0@gmail.com>
Message-ID: <fb6fbf560801291914w44809feyf1caf8170a75d0f2@mail.gmail.com>

On 1/29/08, Mike Klaas <mike.klaas at gmail.com> wrote:

> On 29-Jan-08, at 2:29 PM, Greg Ewing wrote:

> > Jim Jewett wrote:

> >> The majority of uses need a mutable set that starts empty.

> > Does anyone have evidence to support that assertion?

> $ pygrep '[^.a-z]set[(]' | grep -v unittest | wc
>      320    1583   24774

> Empty set():

> $ pygrep '[^.a-z]set[(][)]' | grep -v unittest | wc
>      114     478    7406

> Some of the uses in the first group could be replaced with frozenset,
> of course.  Looking at the examples, though, I would say that most of
> the uses of sets start out using a set constructed using
> comprehension or set(<iterable>).

Apparently you abstract your code better than I do.  Many of my
mutable sets could be done that way if the iterable were described
better; in practice, I just create the set as empty and add to it.

How often is that iterable a literal?  (For me, almost always, because
otherwise I usually either don't make the iterable explicit, or don't
bother turning it into a set.)

How often do you change the set again after the initial iterable is
exhausted?  (I don't, but I suspect that might be a style quirk.)

-jJ

From nicko at nicko.org  Wed Jan 30 06:28:58 2008
From: nicko at nicko.org (Nicko van Someren)
Date: Wed, 30 Jan 2008 05:28:58 +0000
Subject: [Python-3000] Set literal
In-Reply-To: <479E6916.3050208@canterbury.ac.nz>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<aac2c7cb0801261950j31f804feg28fd523e0bafcaa2@mail.gmail.com>
	<00b501c8609e$9f5f95c0$6800a8c0@RaymondLaptop1>
	<ca471dc20801262120h342069e6ye29cc7d7a2f7e8e@mail.gmail.com>
	<479D6A45.6090607@canterbury.ac.nz>
	<ca471dc20801280802s68875edck907008f797a4ccc5@mail.gmail.com>
	<479E5B42.1010908@canterbury.ac.nz>
	<ca471dc20801281503n3f02344bx156502fb2ceaecde@mail.gmail.com>
	<479E6916.3050208@canterbury.ac.nz>
Message-ID: <53C77886-694D-409A-B3F9-713B5EF6CAAA@nicko.org>

On 28 Jan 2008, at 23:45, Greg Ewing wrote:
> Guido van Rossum wrote:
>>
...
>> Have a look at PEP 218.
>
> That PEP proposes that there be no set literal or comprehension
> syntax, and doesn't contain any discussion on whether such
> syntax should produce sets or frozensets if it were to exist.

It seems to me that this raises a critical question; would one want a  
set comprehension to produce frozen sets?  If the comprehension form  
{i for i in range(4)} should produce something mutable then I think it  
would be way too confusing for the form {0,1,2,3} to produce something  
different.  Personally I'd like set comprehensions to give me mutable  
sets, and so I feel set literals should do the same.

	Nicko


From greg.ewing at canterbury.ac.nz  Thu Jan 31 00:11:28 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 31 Jan 2008 12:11:28 +1300
Subject: [Python-3000] Set literal
In-Reply-To: <AB2447EA-B1D1-463D-B947-4DBEF40091E0@gmail.com>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<aac2c7cb0801261950j31f804feg28fd523e0bafcaa2@mail.gmail.com>
	<00b501c8609e$9f5f95c0$6800a8c0@RaymondLaptop1>
	<ca471dc20801262120h342069e6ye29cc7d7a2f7e8e@mail.gmail.com>
	<479D6A45.6090607@canterbury.ac.nz>
	<ca471dc20801280802s68875edck907008f797a4ccc5@mail.gmail.com>
	<fb6fbf560801290458q6c453ff7h2ced4916f4cfd0ca@mail.gmail.com>
	<479FA8C4.2040204@canterbury.ac.nz>
	<AB2447EA-B1D1-463D-B947-4DBEF40091E0@gmail.com>
Message-ID: <47A10420.5080600@canterbury.ac.nz>

Mike Klaas wrote:

> over 120k loc:
> 
> All uses of set():
> 
> $ pygrep '[^.a-z]set[(]' | grep -v unittest | wc
>      320    1583   24774
> 
> Empty set():
> 
> $ pygrep '[^.a-z]set[(][)]' | grep -v unittest | wc
>      114     478    7406

But that doesn't count uses of tuples that could be
turned into frozenset literals if such a thing existed.

> I think that 'set()' is a perfectly fine and readable empty set  
> "literal".

Are you talking only about empty sets? If so, then I
agree. I thought you were talking about all potential
uses of set literals.

--
Greg

From greg.ewing at canterbury.ac.nz  Thu Jan 31 00:17:39 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 31 Jan 2008 12:17:39 +1300
Subject: [Python-3000] Set literal
In-Reply-To: <53C77886-694D-409A-B3F9-713B5EF6CAAA@nicko.org>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>
	<aac2c7cb0801261950j31f804feg28fd523e0bafcaa2@mail.gmail.com>
	<00b501c8609e$9f5f95c0$6800a8c0@RaymondLaptop1>
	<ca471dc20801262120h342069e6ye29cc7d7a2f7e8e@mail.gmail.com>
	<479D6A45.6090607@canterbury.ac.nz>
	<ca471dc20801280802s68875edck907008f797a4ccc5@mail.gmail.com>
	<479E5B42.1010908@canterbury.ac.nz>
	<ca471dc20801281503n3f02344bx156502fb2ceaecde@mail.gmail.com>
	<479E6916.3050208@canterbury.ac.nz>
	<53C77886-694D-409A-B3F9-713B5EF6CAAA@nicko.org>
Message-ID: <47A10593.7080805@canterbury.ac.nz>

Nicko van Someren wrote:
> Personally I'd like set comprehensions to give me mutable  
> sets, and so I feel set literals should do the same.

Do you really want set comprehensions at all, given that
set(genexp) exists?

--
Greg

From thomas at python.org  Thu Jan 31 00:40:42 2008
From: thomas at python.org (Thomas Wouters)
Date: Wed, 30 Jan 2008 15:40:42 -0800
Subject: [Python-3000] Set literal
In-Reply-To: <47A10593.7080805@canterbury.ac.nz>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<00b501c8609e$9f5f95c0$6800a8c0@RaymondLaptop1>
	<ca471dc20801262120h342069e6ye29cc7d7a2f7e8e@mail.gmail.com>
	<479D6A45.6090607@canterbury.ac.nz>
	<ca471dc20801280802s68875edck907008f797a4ccc5@mail.gmail.com>
	<479E5B42.1010908@canterbury.ac.nz>
	<ca471dc20801281503n3f02344bx156502fb2ceaecde@mail.gmail.com>
	<479E6916.3050208@canterbury.ac.nz>
	<53C77886-694D-409A-B3F9-713B5EF6CAAA@nicko.org>
	<47A10593.7080805@canterbury.ac.nz>
Message-ID: <9e804ac0801301540r46c92accgdafdb9ff260dba0b@mail.gmail.com>

On Jan 30, 2008 3:17 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:

> Nicko van Someren wrote:
> > Personally I'd like set comprehensions to give me mutable
> > sets, and so I feel set literals should do the same.
>
> Do you really want set comprehensions at all, given that
> set(genexp) exists?
>

Too late.

>>> {i for i in range(5) }
{0, 1, 2, 3, 4}
>>> {i: "foo" for i in range(5) }
{0: 'foo', 1: 'foo', 2: 'foo', 3: 'foo', 4: 'foo'}

Welcome-to-py3k-ly y'rs,

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20080130/d9d37e6b/attachment.htm 

From lists at cheimes.de  Thu Jan 31 00:42:40 2008
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 31 Jan 2008 00:42:40 +0100
Subject: [Python-3000] Set literal
In-Reply-To: <47A10593.7080805@canterbury.ac.nz>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>	<aac2c7cb0801261950j31f804feg28fd523e0bafcaa2@mail.gmail.com>	<00b501c8609e$9f5f95c0$6800a8c0@RaymondLaptop1>	<ca471dc20801262120h342069e6ye29cc7d7a2f7e8e@mail.gmail.com>	<479D6A45.6090607@canterbury.ac.nz>	<ca471dc20801280802s68875edck907008f797a4ccc5@mail.gmail.com>	<479E5B42.1010908@canterbury.ac.nz>	<ca471dc20801281503n3f02344bx156502fb2ceaecde@mail.gmail.com>	<479E6916.3050208@canterbury.ac.nz>	<53C77886-694D-409A-B3F9-713B5EF6CAAA@nicko.org>
	<47A10593.7080805@canterbury.ac.nz>
Message-ID: <fnr21h$6h5$1@ger.gmane.org>

Greg Ewing wrote:
> Do you really want set comprehensions at all, given that
> set(genexp) exists?

For me comprehension are a means to optimize common patterns in the
sense of faster to execute, faster to read and faster to write. Do set
comprehensions occur so often that {item for item in sequence} makes
code both faster and more readable? Or is the speed benefit of a frozen
set literal larger?

Personally I'm more than happy to trade set comprehensions for optimized
frozen set literals. My code has more 'item in fixed_set' than sets. I
can't remember a project where I've used frozenset() instead of a tuple.
 The name is too long.

Christian


From greg.ewing at canterbury.ac.nz  Thu Jan 31 01:01:58 2008
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 31 Jan 2008 13:01:58 +1300
Subject: [Python-3000] Set literal
In-Reply-To: <9e804ac0801301540r46c92accgdafdb9ff260dba0b@mail.gmail.com>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<00b501c8609e$9f5f95c0$6800a8c0@RaymondLaptop1>
	<ca471dc20801262120h342069e6ye29cc7d7a2f7e8e@mail.gmail.com>
	<479D6A45.6090607@canterbury.ac.nz>
	<ca471dc20801280802s68875edck907008f797a4ccc5@mail.gmail.com>
	<479E5B42.1010908@canterbury.ac.nz>
	<ca471dc20801281503n3f02344bx156502fb2ceaecde@mail.gmail.com>
	<479E6916.3050208@canterbury.ac.nz>
	<53C77886-694D-409A-B3F9-713B5EF6CAAA@nicko.org>
	<47A10593.7080805@canterbury.ac.nz>
	<9e804ac0801301540r46c92accgdafdb9ff260dba0b@mail.gmail.com>
Message-ID: <47A10FF6.3000609@canterbury.ac.nz>

Thomas Wouters wrote:
> 
> On Jan 30, 2008 3:17 PM, Greg Ewing <greg.ewing at canterbury.ac.nz 
> <mailto:greg.ewing at canterbury.ac.nz>> wrote:
> 
>     Do you really want set comprehensions at all, given that
>     set(genexp) exists?
> 
> Too late.

I thought Guido said it wasn't too late to change this?

--
Greg


From guido at python.org  Thu Jan 31 01:09:37 2008
From: guido at python.org (Guido van Rossum)
Date: Wed, 30 Jan 2008 16:09:37 -0800
Subject: [Python-3000] Set literal
In-Reply-To: <47A10FF6.3000609@canterbury.ac.nz>
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>
	<479D6A45.6090607@canterbury.ac.nz>
	<ca471dc20801280802s68875edck907008f797a4ccc5@mail.gmail.com>
	<479E5B42.1010908@canterbury.ac.nz>
	<ca471dc20801281503n3f02344bx156502fb2ceaecde@mail.gmail.com>
	<479E6916.3050208@canterbury.ac.nz>
	<53C77886-694D-409A-B3F9-713B5EF6CAAA@nicko.org>
	<47A10593.7080805@canterbury.ac.nz>
	<9e804ac0801301540r46c92accgdafdb9ff260dba0b@mail.gmail.com>
	<47A10FF6.3000609@canterbury.ac.nz>
Message-ID: <ca471dc20801301609x45344380sd65ebe7a1d919218@mail.gmail.com>

On Jan 30, 2008 4:01 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Thomas Wouters wrote:
> >
> > On Jan 30, 2008 3:17 PM, Greg Ewing <greg.ewing at canterbury.ac.nz
> > <mailto:greg.ewing at canterbury.ac.nz>> wrote:
> >
> >     Do you really want set comprehensions at all, given that
> >     set(genexp) exists?
> >
> > Too late.
>
> I thought Guido said it wasn't too late to change this?

I don't recall saying this. The only aspect that I was almost okay
with changing was whether set displays (and by implication set
comprehensions; "literals" is really the wrong term given the example
{a, b}) could be changed to frozenset.

The more I think about it the less I like that alternative though. So
I think you're wasting your time (and mine :).

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From tjreedy at udel.edu  Thu Jan 31 04:04:54 2008
From: tjreedy at udel.edu (Terry Reedy)
Date: Wed, 30 Jan 2008 22:04:54 -0500
Subject: [Python-3000] Set literal
References: <20080124225636.AFR34133@ms19.lnh.mail.rcn.net>	<ca471dc20801242012t3abffa0fy27bba39bc980e982@mail.gmail.com>	<aac2c7cb0801261950j31f804feg28fd523e0bafcaa2@mail.gmail.com>	<00b501c8609e$9f5f95c0$6800a8c0@RaymondLaptop1>	<ca471dc20801262120h342069e6ye29cc7d7a2f7e8e@mail.gmail.com>	<479D6A45.6090607@canterbury.ac.nz>	<ca471dc20801280802s68875edck907008f797a4ccc5@mail.gmail.com>	<479E5B42.1010908@canterbury.ac.nz>	<ca471dc20801281503n3f02344bx156502fb2ceaecde@mail.gmail.com>	<479E6916.3050208@canterbury.ac.nz>	<53C77886-694D-409A-B3F9-713B5EF6CAAA@nicko.org><47A10593.7080805@canterbury.ac.nz>
	<fnr21h$6h5$1@ger.gmane.org>
Message-ID: <fnrdsm$3g3$1@ger.gmane.org>


"Christian Heimes" <lists at cheimes.de> wrote in message 
news:fnr21h$6h5$1 at ger.gmane.org...
| Greg Ewing wrote:
| | Personally I'm more than happy to trade set comprehensions for 
optimized
| frozen set literals. My code has more 'item in fixed_set' than sets. I
| can't remember a project where I've used frozenset() instead of a tuple.
| The name is too long.

I might have preferred 'fset' to 'frozenset'.  But I presume the name is 
frozen.
So I might put 'fset=frozenset' at the top of a file where is gets used 
alot. 




From aahz at pythoncraft.com  Thu Jan 31 17:19:00 2008
From: aahz at pythoncraft.com (Aahz)
Date: Thu, 31 Jan 2008 08:19:00 -0800
Subject: [Python-3000] DEADLINE Feb 4: OSCON 2008 Call for Proposals
Message-ID: <20080131161900.GA2002@panix.com>

The O'Reilly Open Source Convention (OSCON) is accepting proposals for
tutorials and presentations.  The submission period ends Feb 4.

OSCON 2008 will be in Portland, Oregon July 21-25.  For more information
and to submit a proposal, see

http://conferences.oreilly.com/oscon/
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"All problems in computer science can be solved by another level of     
indirection."  --Butler Lampson

From brett at python.org  Tue Jan 29 02:20:09 2008
From: brett at python.org (Brett Cannon)
Date: Mon, 28 Jan 2008 17:20:09 -0800
Subject: [Python-3000] Announcing the Python core sprint at PyCon 2008
Message-ID: <bbaeab100801281720k7d121e38tab01227b8f0fb791@mail.gmail.com>

As has occurred since the inception of PyCon, there will be a sprint
on the Python core at this year's conference!

If you will be attending PyCon (or will be in Chicago during the dates
of the sprints), attending the sprint is a great way to give back to
Python. Working on Python itself tends to deepens one knowledge of the
language and the standard library. Plus it is just plain fun getting
to sit around some tables with fellow Python programmers for several
days (the sprint will last four days, but you do not need to attend
all four days to participate).

The sprint is open to everyone of all skill levels. We can always use
help with things from updating documentation to preparing for the next
release of Python 3.0.

On Sunday evening of the conference there will not only be a sprint
intro session, but also a tutorial on how to develop for Python.
Details will be covered from where to look in the code base for things
to some best practices tips.

If you are interested enough to want to sign up to attend, please go
to http://wiki.python.org/moin/PyCon2008/SprintSignups/Python and add
your name and email address. If you have questions you may email me.

Please sign up for the sprint by the end of February as an email on
what you need to do beforehand will be sent at that time based on the
sprint sign-up page.

And if you are not attending PyCon, we will most likely have several
people in attendance on IRC, thus allowing even people not at PyCon to
participate!

-Brett Cannon
Python core sprint coach, PyCon 2008