Skip Montanaro wrote:
>
> Moshe> In fact, putting an implementation of pad() like that in the
> Moshe> string.py module would be wonderful, because it would work with
> Moshe> both regular strings and unicode. However, string.py is looking
> Moshe> as though as it's going to be deprecated. In short, I'd want
> Moshe> Guido/Tim/effbot/MAL opinions here before we make a move.
>
> Don't know about the powers that be, but I don't see how you can
> realistically deprecate string.py until you deprecate map(). My most
> frequent use of map() is the simple
>
> newlist = map(string.strip, oldlist)
>
> where oldlist is a list of strings. (Replace "strip" by "upper", "lower",
> etc, depending on your needs.)
>
> As far as I'm aware, there's no clean way to do that with string methods.
True, we'll need somthing like this for methods too... e.g.
like the following API in mx.Tools:
method_mapply(objects,methodname[,args=(),kw={}])
Creates a tuple of values by applying the given arguments to each object's <methodname> method.
The objects are processed as given in the sequence objects.
A simple application is e.g. method_mapply([a,b,c],'method', (x,y)) resulting in a tuple
(a.method(x,y), b.method(x,y), c.method(x,y)). Thanks to Aaron Waters for
suggesting this function.
The name is clumsy... suggestions welcome :-)
--
Marc-Andre Lemburg
______________________________________________________________________
Business: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/
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