[Python-Dev] other "magic strings" issues

[Guido van Rossum]

> > > 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/)