len() should always return something

[Emmanuel Surleau]

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 <steve at 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