weirdness with list()

[Cameron Simpson]

On 01Mar2021 14:10, Grant Edwards <grant.b.edwards at gmail.com> wrote:
>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?

Yeah, well the ancestry of these classes is a binary 
deserialise/serialise base class, so __len__ _is_ the natural thing - 
the length of the object when serialised.

The conflation came when making a recursive hierarchical system to parse 
ISO14496 files (MOV, MP4). These have variable sized binary records 
which can themselves enclose other records, often an array of other 
records.

That led me down the path of making an __iter__ (not previously 
present), without considering the __len__ interaction.

I've split these things apart now, and will probably go the full step of 
not providing __iter__ at all, instead requiring things to reach for the 
.boxes attribute or a generic .subboxes() method, since not all these 
things have .boxes (depends on the record type).

The design question is answered, and I consider myself at least somewhat 
spanked. However, the primary question was about sidestepping list()'s 
preallocation feature. That is also answered.

Cheers,
Cameron Simpson <cs at cskk.id.au>