On Sunday 26 July 2009 00:42:26 Marcus Wanner wrote: > On 7/25/2009 10:08 AM, Piet van Oostrum wrote: > >>>>>> Steven D'Aprano <st...@remove-this-cybersource.com.au> (SD) wrote: > >> > >> SD> Ambiguity essentially boils down to being unable to reasonably > >> predict SD> the expectation of the coder. I say "reasonably", because if > >> you allow SD> unreasonable situations, everything is "ambiguous": > > > > That's for me the reason that len(42) is ambiguous. The OP apparently > > had 1 as expectation, whereas my first thought was the minimal number of > > bits to represent the number and 7.5 million came later :=). The number > > of bits I certainly find reasonable, and I would find the number of > > decimal digits equally reasonable. More so than 1, actually. 1 as the > > length of an int doesn't give any information. > > Well, for my two cents, I will say that the number of binary bits or > decimal digits is certainly the most sensible return value, and that the > former is the most useful, because the latter can be got with > len(str(42)). However, the former can also be (/slightly/ less)easily > got with len(bin(42))-2...
For my two eurocents, I'd expect such an operator to be called "sizeof" and when applied to a collection, to also return the number of bits it uses. I don't think a 'len' function has meaning when applied to something else than a collection, really... > I also think that "Explicit is better than implicit." says that there > should be no return value in this case, as any return value would be > implicit. Agreed. Cheers, Emm -- http://mail.python.org/mailman/listinfo/python-list