len() should always return something

Rhodri James rhodri at wildebst.demon.co.uk
Fri Jul 24 19:52:41 CEST 2009


On Fri, 24 Jul 2009 16:10:07 +0100, Piet van Oostrum <piet at cs.uu.nl> wrote:

>>>>>> "Rhodri James" <rhodri at wildebst.demon.co.uk> (RJ) wrote:
>
>> RJ> On Fri, 24 Jul 2009 14:57:02 +0100, Grant Edwards <invalid at invalid>  
>> wrote:
>>>> On 2009-07-24, Dr. Phillip M. Feldman <pfeldman at verizon.net> wrote:
>>>>>
>>>>> Some aspects of the Python design are remarkably clever, while
>>>>> others leave me perplexed. Here's an example of the latter:
>>>>> Why does len() give an error when applied to an int or float?
>>>>> len() should always return something; in particular, when
>>>>> applied to a scalar, it should return a value of 1.
>>>>
>>>> If len(7) returned a value of 1, then wouldn't one expect 7[0]
>>>> to be valid?  It isn't, so you'd then have to redefine all
>>>> types so that they are sequences that can be indexed.  Sounds
>>>> like a big mess to me...
>>>>
>>>> [Are there types for which len() returns a value that can't be
>>>> indexed?]
>>>>
>
>> RJ> Dictionaries.
>
>> RJ> Which doesn't make your point less valid.  In fact I'd go so
>> RJ> far as to argue that what len() gives you is the number of
>> RJ> items in a container, so len(7) should return 0.
>
> But len(7) could as well be defined as 3, 1, 32, or 64 (depending on the
> implementation). Therefore it doesn't make much sense.

Quite.

-- 
Rhodri James *-* Wildebeest Herder to the Masses



More information about the Python-list mailing list