Raymond Hettinger wrote:
It is not quite correct to say that this is what all immutables do:

.>>>x = 500
.>>>y = 600 - 100
.>>>x is y
False

That is an implementation detail, not guaranteed by the language (i.e. not necessarily true in future versions, in Jython, or other implementations). It is just an optimization that made sense for tuples but not necessarily for other immutables.

Jp had another good example with long(). I take your point, not relying on it is a safer bet.



That solution is reasonable and portable:

emptyset = frozenset()
f('abc', emptyset)
g('def', emtpyset)
h(1, 2, emtpyset, True)
 . . .

I also find it be more readable than:

f('abc', frozenset())
g('def', frozenset())
h(1, 2, emtpyset, frozenset())

I also find it more readable (it's the idiom I currently use) and normally the places where this is used are quite local in the code, usually at class level. I don't think, though, that your argument about faster local variable access holds for that level also.



Also, I don't know what else needs to be changed and what a difference that
makes. But if the added code is reasonably limited, I'd vote for it.

Will think about it for a while. I'm not terribly opposed to the idea. I just find the case for it to be somewhat weak. Also, I'm not sure it warrants the effort, the code clutter, or introducing issues like having a semantic difference between the result of frozenset() and the result of frozenset([]).

.>>> tuple(i for i in [False] if i) is () False .>>> tuple(i for i in []) is () False .>>> tuple([]) is () True

I see the difference. And I guess it's the same argument you (?) recently had on c.l.py about propagating __len__ in builtin iterators. But still, it's not really about semantic differences but about implementation details that are there to make a difference in certain cases. So I was somewhat wrong about extrapolating features of immutable types.

Ok, I admit that the priority of this change is not very high. Admittedly, the set types are too recent in Python to claim 'major common use cases' that demand optimization. But I generally believe that many programmers will silently expect frozenset() to be (and become) more efficient than set() - in whatever regard: processing, memory, etc. - and use it when they think appropriate. We'll see.

Stefan
--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to