Hi, [EMAIL PROTECTED] 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
smime.p7s
Description: S/MIME Cryptographic Signature
-- http://mail.python.org/mailman/listinfo/python-list
