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 :-).
--Guido On 7/17/06, Michael Chermside <[EMAIL PROTECTED]> 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 [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
