Nick Coghlan wrote: > Another point in favour of set literals is that they let an optimising > compiler play games because the compiler knows that the contents of > that literal are supposed to be hashable, even if it can't resolve > them right now, and it knows that the result is going to be an actual > builtin set object. So the constant-folding part of the optimiser > could create the actual set and tuck it away in co_consts if the > literal was only used for an "in" test. > > Those kinds of tricks can't even be contemplated with 'set' because > the compiler can't trust that the name is going to resolve to the > actual builtin.
I wouldn't go in that direction. There ahead lies the usage of punctuation for everything, just because punctuation can't be rebound while builtin names can. What needs to be done in Py3K is to change the language so that it's possible to know whether a builtin was rebound and not, thus allowing to optimize their lookup away. I believe there were already proposals for this, but I'm not sure there is a PEP already. We shouldn't recur to using literals/punctuation just because we can't optimize builtins. -- Giovanni Bajo _______________________________________________ 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
