A bit weird dictionary behavior

[Tino Wildenhain]

Hi,

bearophileHUGS at lycos.com wrote:
> Tino Wildenhain:
> 
>> Wouldn't
>> len([x for x in iterable if x==y])
>> or even shorter:
>> iterable.count(y)
>> not work and read better anyway?
> 
> The first version creates an actual list just to take its length,
> think about how much memory it may use.

yes it seems len() does not alternatively iterate or __len__ of
the generator objects don't allow for an optimization yet. This
could be improved so len(x for x in iterable ...) would work and
save memory.

> The second version requires the 'iterable' object to have a count()
> method, and in general this is false.

of course this always depends on the usecase.

>> even calculating with boolean values isn't neccessary
>> since 'and' and 'foo if bar else blub' are working much better
>> so the type coalescing
>> bool - int - float can really go away.
> 
> I don't understand.

if you have a operator b and type(a) <> type(b) then
coercing goes on to convert one partner to the type
of the other. So bool currently gets "upgrated" to int
(as int is upgraded to float and so on). If this goes away,
the type ambiguity is gone. This would result in

1==True -> False

HTH
Tino

PS: are you per chance using a news gateway to post? This seems
to screw up threading somehow...





> Bye,
> bearophile
> --
> http://mail.python.org/mailman/listinfo/python-list

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-list/attachments/20080922/f51aff62/attachment-0001.bin>