Nicko van Someren wrote:
Do we really want set literals at all, given that set(...) exists?
If we are going to have one then, it seems to make sense to have
both. If we are going to have both, I would rather that they generate
the same type of set.
Maybe the postings crossed in the ether, but Guido said as much on the
30th; either they'd both change or neither would change.
Personally I like the idea of changing them to frozensets; a) it's easy
to cast to set() if you want mutability, b) it makes the
if x in { 1, 2, 5 }: # three, sir!
idiom faster. Yeah, it's a bit ticklish wrt dict
literals/comprehensions returning mutable types, but at least tuple()
would have company in the immutable constants department. So +1 from
me... for what little that is worth.
When compiling a mutable type with an immutable equivalent, does Python
generate create-empty-object/insert-each-item bytecodes, or does it
create an immutable constant then cast it to the appropriate type? My
intuition is that the latter would be faster; given the professionalism
of the Python development community, I assume both approaches have been
tried, and the faster one was switched to long ago? A coworker of mine
got a tiny--but measurable--speedup by applying that style of
optimization to PHP arrays.
/larry/
p.s. or maybe the create-empty-object takes an optional parameter of
"and reserve this much space inside"? That would probably even the
playing field.
_______________________________________________
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
