[PATCH] Re: frozenset() without arguments should return a singleton
Stefan Behnel
stefan.behnel-n05pAM at web.de
Sun Feb 13 06:47:10 EST 2005
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
More information about the Python-list
mailing list