why not "'in' in 'in'"?
not.this at seebelow.org
Thu Jun 13 23:14:58 CEST 2002
In article <mailman.1023989567.18847.python-list at python.org>, "Bjorn says...
>Ok, how about:
>>>> class mystr(str):
>... def __contains__(self, s):
>... return self.find(s) >=3D 0
>>>> 'hello' in mystr('hello world')
>>>> 'foo' in mystr('hello world')
Well, sure--but where's the fun in that?
Actually, I don't much like this approach for a couple of reasons. First, you
then have to remember to wrap each string literal inside the name of your new
class, a practice which is both tedious and ugly. It isn't worth it.
Second, although Python's newfound ability to subclass from built-in types
allows one to change nearly anything one doesn't like about the way the type
works, I generally think that's going in the wrong direction because it makes
your code work different than it reads.
Instead, I find the ability to subclass from built-in types to be useful
primarily to _add_ behavior to a type. The most common example is some sort of
specialized list or dictionary which provides new methods appropriate only for
its special use. These cases are, of course, simply a more elegant way of
implementing what we used to implement less elegantly via an explicit list
member, e.g., "self.list".
Grant R. Griffin g2 at dspguru.com
Publisher of dspGuru http://www.dspguru.com
Iowegian International Corporation http://www.iowegian.com
More information about the Python-list