On 01Mar2021 14:10, Grant Edwards <grant.b.edwa...@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 <c...@cskk.id.au> -- https://mail.python.org/mailman/listinfo/python-list