"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| 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 nee
Terry Reedy wrote:
> "Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> | More completely:
> |
> | () # empty tuple
> | (1,)# 1 item tuple
> | (1,2) # 2 item tuple
>
> 1,# 1 item tuple, no parens needed, trailing comma mandator
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})
>>> 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
>
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") return
On Jan 26, 2008 1:45 PM, Raymond Hettinger <[EMAIL PROTECTED]> 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 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?
Guido van Rossum schrieb:
> On Jan 26, 2008 1:45 PM, Raymond Hettinger <[EMAIL PROTECTED]> 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()
On Jan 26, 2008 2:02 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum schrieb:
> > On Jan 26, 2008 1:45 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> >> Am strongly -1 on changing the repr for set to set({a, b, c}) . Creating
> >> an innermost frozenset doubles the memory cons
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
> b
I filed http://bugs.python.org/issue1942 about this.
On Jan 26, 2008 1:57 PM, Neal Norwitz <[EMAIL PROTECTED]> 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 ha
On Jan 26, 2008 2:13 PM, Christian Heimes <[EMAIL PROTECTED]> 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. F
On Jan 26, 2008 5:11 PM, Guido van Rossum <[EMAIL PROTECTED]> 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 initializ
[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
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.
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/pyt
On Jan 24, 2008 9:12 PM, Guido van Rossum <[EMAIL PROTECTED]> 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
[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 suppo
On Jan 26, 2008 8:39 PM, Raymond Hettinger <[EMAIL PROTECTED]> 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 po
>> 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
___
Python-3000 mailing list
Python-30
19 matches
Mail list logo
