Friday Finking: following, weirdness with list()

[dn]

The in-person version of 'Friday Finking' has been set-aside by
COVID-precautions. Here's hoping the questions asked below will
stimulate some thinking, or mild entertainment...


On 02/03/2021 03.10, Grant Edwards wrote:
> On 2021-03-01, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>> On 28/02/21 1:17 pm, Cameron Simpson wrote:
>>> [its length in bytes] is presented via the object's __len__ method,
>>
>>> BUT... It also has a __iter__ value, which like any Box iterates over
>>> the subboxes.
>>
>> You're misusing __len__ here. If an object is iterable and
>> also has a __len__, its __len__ should return the number of
>> items you would get if you iterated over it. Anything else
>> is confusing and can lead to trouble, as you found here.
> 
> That was certainly my reaction. Can you imagine the confusion if len()
> of a list returned the number of bytes required for srorage insttead
> of the number of elements?


Why?

Isn't one of the 'fun' things about modern* languages is the
"over-loading" of operators/operations?

* ie newer than FORTRAN-IV or COBOL (or my grey hair)


Thus we have:

2 + 3    # int( 5 )

and

"2" + "3"    # "23"

...and we are quite comfortable with the dissonant 'sameness' and
'difference'.

If we can "over-load" __add__(), why not __len__()?


That said, it is confusing: what does len() mean? Are we talking about
the number of elements in a collection, or something else?

What do the docs say?

https://docs.python.org/3/library/functions.html#len talks of "the
length (the number of items) of an object". In the OP, what are the
"items" in this object/"subbox"?

https://docs.python.org/3/reference/datamodel.html covers
object.__len__(self) saying "Called to implement the built-in function
len(). Should return the length of the object, an integer >= 0." without
actually determining what "length of the object" may actually mean in
any or every context.


Here's another example/application:

If we were playing with our own custom-class to work with vectors,
should __len__() be coded to report (through len()) the number of
dimensions considered in the vector:

v = Vector( 1, 2, 3, 4 )
len( v )    # 4

...or should "len" stand for the "magnitude" of the vector, ie a
distance of 5.5 (rounded)?


Horses for courses?

In the case of (Unicode) strings len() reports in characters, yet lists
are sized in numbers of elements, etc. Each according to what we might
call the 'unit' which should be counted.

The implicit 'confusion' (and flexibility) of over-loading precedes (and
to a degree, causes) "imagine the confusion if len() of a list returned
the number of bytes required".

That said, shouldn't we agreeing with the statement? Should one (sort
of) class/file-structure demand that all other custom-, library-, and
'built-in'-classes report in bytes?

(but is that being proposed/demanded?)


The lengths of files are reported by the computer's
ls-command/file-manager in [M/K]-bytes!

This subject matter is a binary file/container format (MP4). Am working
on a similar container format at the moment, where the length of
sub-components may be reported in bytes (if not delineated by 'markers').

So, there are many reasons why "bytes" is a 'good' measure of length -
in this context.

Is it "misusing __len__" in a class/object designed to manipulate such
files? Hope not!
(or I'm 'in trouble' - again...)
-- 
Regards,
=dn