Paul Boddie <[EMAIL PROTECTED]> wrote: > John Machin wrote: > > > > range() and xrange() are functions. You are suggesting that 2 > > *functions* should acquire a __contains__ method each? I trust not. > > Well, range is a function in the current implementation, although its > usage is similar to that one would get if it were a class, particularly > a subclass of list or one providing a list-style interface. With such a > class, you could provide a __contains__ method which could answer the > question of what the range contains based on the semantics guaranteed > by a range (in contrast to a normal list).
You'd also have to override just about every mutating method to switch back to a "normal" __contains__ (or change self's type on the fly) -- a pretty heavy price to pay. I have often noticed that subclassing list, dict and maybe set has this kind of issue: the need to track every possible change to the object. Maybe a good mechanism to have for the purpose would be to add to mutable types a "hook" method, say __mutator__, which gets called either right before or right after any mutating method (there are different tradeoffs for before-calls and after-calls), presumably passing along the *a and **k for generality (although it might be faster for the base case to avoid that); the base types would have a no-op implementation, but subtypes could easily override just the hook to facilitate their task of maintaining extra state (could be as little as a per-instance flag recording whether the object is guaranteed to be still "pristine"). At C level, that might be an extra slot tp_mutator, left NULL in base types to indicate "no mutator-hook method implemented here". Like any other addition of, or change to, functionality, this would of course be a proposal for 2.6, since 2.5 is feature-frozen now. Alex -- http://mail.python.org/mailman/listinfo/python-list
