string.py

[Michael Hudson]

While we're at it, I've just noticed that some things aren't string
methods that you might expect to be.

The heuristic:

>>> for i in dir(string):
...  if i in dir(""): continue
...  if type(getattr(string,i)) not in [types.FunctionType]: continue
...  print i

produces:

atof
atoi
atol
capwords
center
expandtabs
joinfields
ljust
rjust
splitfields
zfill

atof/atoi/atol I can understand - use float/int/long instead.
splitfields, joinfields and zfill were obsolete anyway.

That leaves capwords, center, ljust, rjust and expandtabs. Is there a
reason for their omission?

just-curiously-ly y'rs
Michael

"Fredrik Lundh" <effbot at telia.com> writes:

> Adrian Eyre <a.eyre at optichrome.com> wrote:
> > I suspect, however, that JPython has this already implemented,
> > so this is unlikely to change in CPython.
> 
> don't know about JPython, but it's definitely implemented
> in the current CPython code base.
> 
> > Doesn't really bother me too much. It just feels like a kludge.
> 
> it isn't, when compared to the alternatives.
> 
> > And the similarity of index() and find() makes me feel that one
> > should be redundant (probably the one which returns -1).
> 
> like getattr/hasattr, you mean?
> 
> </F>