In article <[EMAIL PROTECTED]>, Alex Martelli <[EMAIL PROTECTED]> wrote: . . . >I'd be a bit worried about having len(x) change x's state into an >unusable one. Yes, it happens in other cases (if y in x:), but adding >more such problematic cases doesn't seem advisable to me anyway -- I'd >evaluate this proposal as a -0, even taking into account the potential >optimizations to be garnered by having some iterables expose __len__ >(e.g., a genexp such as (f(x) fox x in foo), without an if-clause, might >be optimized to delegate __len__ to foo -- again, there may be semantic >alterations lurking that make this optimization a bit iffy). > > >Alex
Quite so. My proposal isn't at all serious; I'm doing this largely for practice in thinking about functionalism and its complement in Python. However, maybe I should take this one step farther: while I think your caution about "attractive nuisance" is perfect, what is the precise nuisance here? Is there ever a time when a developer would be tempted to evaluate len() on an iterable even though there's another approach that does NOT impact the iterable's state? On the other hand, maybe all we're doing is observing that expanding the domain of len() means we give up guarantees on its finiteness, and that's simply not worth doing. -- http://mail.python.org/mailman/listinfo/python-list