[Python-3000] Set literal

[Adam Olsen]

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