>> It has nothing to do with 11k worth of disk space and everything to
>> do with "there's one (best) way to do it".
Fredrik> in this case, it sounds more like "purity over practicality"
Fredrik> (or maybe "I'm bored, let's get some discussion going")
Fredrik> and frankly, it doesn't sound much like you either. didn't you
Fredrik> use to be a rather practical programmer?
I am a rather practical programmer, however my programming goals are
generally different than yours. I don't write software that is widely
distributed. I understand there is bound to be pushback on such a topic.
I was also not motivated by boredom. I was motivated by reading this recent
addition to the Style Guide:
- Avoid the use of the string module; instead use string methods.
These are always much faster and share the same API with unicode
strings.
Now, granted, Guido and Barry weren't saying, "the string module is
deprecated". In my original message I even suggested this change in wording
to the above:
Avoid the use of the string module unless backward-compatibility
with versions earlier than Python 2.0 is important; instead use
string methods. These are always much faster and share the same API
with unicode strings.
Still, it sounds to me like for most purposes there is ample reason to
advocate not using the string module. Then, my natural inclination is to
wonder if it should simply be deprecated. Three functions in the string
module are already officially deprecated (atof, atoi, atol since 2.0 -
shouldn't their continued use be generating warnings by now?). At least one
other should be (capwords and possibly zfill). I would argue that if Guido
feels strongly enough to make an "avoid the string module" statement in the
Style Guide, a similarly worded statement should also be made at the top of
the string module docs.
Skip
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4