[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?
Alex
More information about the Python-Dev
mailing list