range() is not the best way to check range?

[Alex Martelli]

Paul Boddie <paul at boddie.org.uk> 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