[Python-Dev] other "magic strings" issues

Alex Martelli aleaxit at yahoo.com
Fri Nov 7 19:02:04 EST 2003

On Friday 07 November 2003 23:49, Guido van Rossum wrote:
> > I guess the tests should be faster, yes, but I would still want
> > _iterables_ for ascii_*  and digits.
> Why?  It's not like you're going to save much space by not creating a
> string of 52 bytes.

Strings are iterables.  What I'm saying is that I don't necessarily need
them to be strings, if having iterables that aren't strings (perhaps a 
string subclass redefining just __contains__) would help with:

> > One issue with allowing "if char in string.letters:" is that these
> > days this will not raise if the alleged 'char' is more than one
> > character -- it will give True for (e.g.) 'ab', False for (e.g.)
> > 'foobar', since it tests _substrings_.
> Right.

> > So, maybe, str.letters and friends should be iterables which also
> > implement a __contains__ method that raises some error with helpful
> > information about using .iswhatever() instead -- that's assuming we
> > want people NOT to test with "if char in str.letters:".  If we DO
> > want people to test that way, then I think str.letters should
> > _still_ have __contains__, but specifically one to optimize speed in
> > this case (if supported it should be just as fast as the
> > .is... method -- which as Skip reminds us may in turn need
> > optimization...).
> Hm.  The iterable idea seems overblown for something as simple as
> this.

Is presenting this as "a subtype of str that overrides __contains__
appropriately" more acceptable?


More information about the Python-Dev mailing list