[Python-Dev] Re: other "magic strings" issues
Marangozov, Vladimir (Vladimir)
vladimir.marangozov at optimay.com
Tue Nov 11 05:13:50 EST 2003
> > Put it another way, it's good to have all string functions being
> > attributes to a single well-known object, that object being the
> > 'string' module, instead of spreading it all over... So add the
> Not sure anybody wants to "spread it all over", for whatever "it".
> str.whatever should be usable where string.whatever is usable
> now, so, what would the problem be...?
"Should" is a bit of an overstatement, provided that Python lived
happily without all string functions as attributes for 10+ years.
Now you've grown OO and appreciate having all functions as attributes
and that's fine. Noone has objected to enlarge the set of attributes.
The objection is towards deprecating the 'string' module thus closing
the door for a procedural approach to strings. And if I say that 5%
of all programmers don't care about string polymorphism nor Unicode,
that is probably true as well, so no point in arguing that o.upper()
is better than string.upper(o).
o.upper() is really StringType.upper(o) under the hood, which is the
same as import string / string.upper(o). Both StringType and 'string'
act as function packages (containers). Yes, I see you coming with
arguments that they aren't really the same because of subtleties like
Unicode, etc. but that's irrelevant for those 95% of the people who
aren't heavily invested in strings and simply don't care.
The catch is that if we favor the OO approach and deprecate 'string',
we deprecate one explicit way of spelling things, which is import
string / string.upper(o). This has been adopted and is widely used.
Python has always tried to balance purity with practicality and OO
in Python is still perceived as optional, especially for the newcomer
who needs to write a couple of quick scripts to get the job done.
I am not sure we have to favor the OO reasoning for everything.
There are also backward compatibility issues arising from deprecating
'string' but I belive this is manageable. 'string' can be aliased to
StringType so that it is backwards compatible. Removing the 'string'
module as a name completely would be a bit of a challenge though...
More information about the Python-Dev