weirdness with list()
Cameron Simpson
cs at cskk.id.au
Mon Mar 1 16:56:34 EST 2021
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>
More information about the Python-list
mailing list