Raymond Hettinger <raymond.hettin...@gmail.com> added the comment: In general, I think we can prevent confusion about the meaning of __len__ by sticking to the general rule: len(object)==len(list(obj)) for anything that produces an iterable result. In the case of struct, that would be the length of the tuple returned by struct.unpack() or the number of values consumed by struct.pack().
This choice is similar to what was done for collections.Counter where len(Counter(a=10, b=20)) returns 2 (the number of dict keys) rather than 30 (the number of elements in the Bag-like container). A similar choice was make for structseq objects when len(ss) == len(iter(ss)) despite there being other non-positional names that are retrievable. It's true that we get greater clarity by spelling out the specific meaning in the context of structs, as in s.num_members or some such, but we start to lose the advantages of polymorphism and ease of learning/remembering that comes with having consistent API choices. For any one API such as structs, it probably makes sense to use s.num_members, but for the standard library as a whole, it is probably better to try to make len(obj) have a consistent meaning rather than having many different names for the size of the returned tuple. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12740> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
