[Python-3000] set literals

[Jack Diederich]

On Mon, Jul 17, 2006 at 02:54:14PM -0700, Guido van Rossum wrote:
> Hm. Your objections seem to be purely from a performance tuning POV. I
> think that if we agree that API-wise this is an improvement (fewer
> things to learn, set literals problem solved, and dicts grow some
> useful new methods) we should make a decision to do it and damn the
> tuning (I trust Raymond will find a way :-).

Sets are dicts like lists are tuples.  Similar but different.  Heck no one
has proposed ditching tuples just because lists are a superset (err, not
recently).  Back in the bad old days of 2.2 when I used a dict as a set I
would defensively initialize it as
  uniques = dict(zip(somelist, somelist))
so the values could never be abused a a side effect ten lines down.
Python has a great tradition of supporting a few basic operations across
different kinds of containers - the 'in' and 'iter(x)' and sometimes 'foo[x]'
Commonalities accross types exist right up until the uses are different.

Let's not mess it up by going towards the PHP route of unifying more than
we need to (I'm thinking of the unification of hashes and vectors).

Not even Raymond can make dicts as cheap as sets.  He did after all scoop
out portions of the dict machinery to make sets as fast as they could be.
He was kind enough to write Object/dictnotes.txt to record the different
ways dictionaires are used and again to break out sets as a distinct type.

For what it is worth I'm biased towards the specialization of basic types
as long as there is a conceptual split.  I spent a week before the Need
For Speed sprint and a day during separating dictionaries used for symbol
lookup from general hash tables.  The result worked but was unusable a 
week before 2.5-beta1 as it was far too invasive.  I still like the idea of
namespaces being dict work-alikes but not necessarily dict()s proper.

-jack

nb, the suggestion in this thread that 'dictA |= dictB' have the opposite 
meaning of 'dictA.update(dictB)' with respect to values has a code smell 
all its own.

> On 7/17/06, Michael Chermside <mcherm at mcherm.com> wrote:
> > Guido writes:
> > > I've also sometimes thought of unifying dicts and sets by implementing
> > > set operations on the keys of dicts only.
> >     [... much discussion ...]
> > > I'm still very much undecided but I don't want to rule this out for
> > > py3k. Perhaps I'll write up a PEP and see how it flies.
> >
> > Playing with it, and PEPing it both sound fine, but I think DOING it
> > seems like a bad idea.
> >
> > I see two advantages. One is public: it solves the issue of a set
> > literal. The other is private: it allows us to reuse the implementation.
> >
> > Fixing the set literal just isn't sufficient justification, IMHO. And
> > as for the implementation, we care VERY much about perfectly tuning
> > the performance of the dict type, because its performance is so key to
> > the implementation of namespaces throughout Python. So I would not want
> > to accept any unnecessary restrictions on the implementation that might
> > constrain future optimizations of dict performance.
> >
> > Besides, how difficult is it to maintain the existing C implementation
> > of set and frozenset (now that they're written and have been through
> > the wringer of being in a production release). It's not zero cost, but
> > it's also probably not THAT big.
> >
> > Of course, that's the idea behind trying it out and even writing a PEP
> > -- then we'll see whether my guess (or yours!) is correct.
> >
> > -- Michael Chermside
> >
> 
> 
> -- 
> --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/jack%40performancedrivers.com
>