[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