On Jan 23, 2008, at 4:30 PM, Alexandre Vassalotti wrote:
> On Jan 22, 2008 10:30 AM, Jim Fulton <[EMAIL PROTECTED]> wrote:
>>
>> On Jan 20, 2008, at 10:39 PM, Alexandre Vassalotti wrote:
>>
>>> On Jan 20, 2008 4:14 PM, Jim Fulton <[EMAIL PROTECTED]> wrote:
Interesting. Does that mean th
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 t
[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
--
On Jan 24, 2008 11:16 AM, Raymond Hettinger <[EMAIL PROTECTED]> 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 w
> 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@pytho
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 <[EMAIL PROTECTED]> wrote:
> > Some folks thought it would b
On Jan 24, 2008 12:12 PM, Charles Merriam <[EMAIL PROTECTED]> 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?"
>
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 m
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
On Jan 24, 2008 1:14 PM, Christian Heimes <[EMAIL PROTECTED]> 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 e
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 <[EMAIL PROTECTED]> 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 {'ht
On Jan 24, 2008 3:25 PM, James Thiele <[EMAIL PROTECTED]> wrote:
> On Jan 24, 2008 1:14 PM, Christian Heimes <[EMAIL PROTECTED]> 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 t
-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
> 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 whol
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
__
On Jan 24, 2008 5:13 PM, <[EMAIL PROTECTED]> 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
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
[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
___
On Jan 24, 2008 4:13 PM, <[EMAIL PROTECTED]> 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
On Jan 24, 2008 9:47 AM, Jim Fulton <[EMAIL PROTECTED]> 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 impleme
On Jan 24, 2008 9:25 PM, Alexandre Vassalotti <[EMAIL PROTECTED]> 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/Fi
On Jan 24, 2008 5:38 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> On Jan 24, 2008 4:13 PM, <[EMAIL PROTECTED]> 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 argume
On 1/24/08, Raymond Hettinger <[EMAIL PROTECTED]> 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 i
[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
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
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'
On Jan 24, 2008 8:59 PM, Aahz <[EMAIL PROTECTED]> 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 li
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:
Act
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 tup
> 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 ('ht
On Jan 24, 2008 5:12 PM, Raymond Hettinger <[EMAIL PROTECTED]> 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
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
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
>
On Jan 25, 2008 12:18 AM, Mark Summerfield <[EMAIL PROTECTED]> 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*
34 matches
Mail list logo
