On Jan 25, 2008 12:52 PM, Collin Winter <[EMAIL PROTECTED]> wrote:
>
> On Jan 24, 2008 10:40 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > 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 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
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
