why not "'in' in 'in'"?

[Grant Griffin]

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')
>1
>>>> 'foo' in mystr('hello world')
>0
>>>>

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".

just-because-guido-allows-it-doesn't-mean-you-should-use
   -it-injudicious-ly y'rs,

=g2

_________________________________________________________________________

Grant R. Griffin                                           g2 at dspguru.com
Publisher of dspGuru                               http://www.dspguru.com
Iowegian International Corporation                http://www.iowegian.com