[Python-Dev] other "magic strings" issues
Guido van Rossum
guido at python.org
Fri Nov 7 19:10:15 EST 2003
> > > 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:
An example given earlier:
string.letters + string.digits + "_"
indicates that we want them to be concrete strings.
> > > 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?
No, I think it's being too clever.
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev
mailing list