string goes away
Andreas Beyer
If I am getting the docs etc. correctly, the string-module is depricated
and is supposed to be removed with the release of Python 3.0.
I still use the module a lot and there are situations in which I don't
know what to do without it. Maybe you can give me some help.
I loved to use
>>> string.join(list_of_str, sep)
instead of
>>> sep.join(list_of_str)
I think the former is much more telling what is happening than the
latter. However, I will get used to it.
But what about this:
>>> upper_list = map(string.upper, list_of_str)
What am I supposed to do instead?
I am sure there has been lots of discussion on whether or not to remove
the string module. Maybe you can just direct me to the right place.
Thanks for help!
Andreas
Skip Montanaro
Andreas> What am I supposed to do instead?
Try
[s.upper() for s in list_of_str]
Skip
Andreas Beyer
at all is for improving the performance.
That is lost when using list comprehensions (as far as I know). So, this
is *no* option for larger jobs.
Andreas
Ivan Van Laningham
Andreas Beyer wrote:
>
> I loved to use
> >>> string.join(list_of_str, sep)
> instead of
> >>> sep.join(list_of_str)
>
> I think the former is much more telling what is happening than the
> latter. However, I will get used to it.
>
I disagree, but maybe you could think of it as a mutant list
comprehension?-)
> But what about this:
> >>> upper_list = map(string.upper, list_of_str)
>
> What am I supposed to do instead?
>
>>>
>>> u
['a', 'b', 'c']
>>> [i.upper() for i in u]
['A', 'B', 'C']
>>>
Works pretty well for me. Better'n map() any day.
> I am sure there has been lots of discussion on whether or not to remove
> the string module. Maybe you can just direct me to the right place.
>
I think we both missed it. I been off the list for four years. They
wouldn'ta listened to me anyhow.
Metta,
Ivan
----------------------------------------------
Ivan Van Laningham
God N Locomotive Works
http://www.andi-holmes.com/
http://www.foretec.com/python/workshops/1998-11/proceedings.html
Army Signal Corps: Cu Chi, Class of '70
Author: Teach Yourself Python in 24 Hours
Delaney, Timothy C (Timothy)
> Yeeh, I was expecting something like that. The only reason to use
> map() at all is for improving the performance.
> That is lost when using list comprehensions (as far as I know). So,
> this is *no* option for larger jobs.
Try it and see. You'll probably be pleasantly surprised.
Note that you can use `str.upper` in map ...
/usr/bin> C:/Python24/python.exe -m timeit -s "strings = ['a']*1000"
"map(str.upper, strings)"
1000 loops, best of 3: 304 usec per loop
/usr/bin> C:/Python24/python.exe -m timeit -s "strings = ['a']*1000"
"[s.upper() for s in strings]"
1000 loops, best of 3: 331 usec per loop
Pretty damn close.
Tim Delaney
alex23
> I loved to use
> >>> string.join(list_of_str, sep)
> instead of
> >>> sep.join(list_of_str)
>
> I think the former is much more telling what is happening than the
> latter. However, I will get used to it.
I find that binding a name to the separator makes it more readable
(YMMV):
>>> list_of_str = ['a','b','c']
>>> comma = ','
>>> comma.join(list_of_str)
'a,b,c'
> But what about this:
> >>> upper_list = map(string.upper, list_of_str)
>>> upper_list = [s.upper() for s in list_of_str]
>>> upper_list
['A', 'B', 'C']
Hope this helps.
-alex23
Skip Montanaro
Andreas> Yeeh, I was expecting something like that. The only reason to
Andreas> use map() at all is for improving the performance. That is
Andreas> lost when using list comprehensions (as far as I know). So,
Andreas> this is *no* option for larger jobs.
Did you test your hypothesis?
% python -m timeit -s 'lst = ("abc"*10).split() ; import string' 'map(string.upper, lst)'
100000 loops, best of 3: 9.24 usec per loop
% python -m timeit -s 'lst = ("abc"*10).split()' '[s.upper() for s in lst]'
100000 loops, best of 3: 4.18 usec per loop
% python -m timeit -s 'lst = ("abc"*100).split() ; import string' 'map(string.upper, lst)'
100000 loops, best of 3: 16.1 usec per loop
% python -m timeit -s 'lst = ("abc"*100).split()' '[s.upper() for s in lst]'
100000 loops, best of 3: 10.8 usec per loop
% python -m timeit -s 'lst = ("abc"*1000).split() ; import string' 'map(string.upper, lst)'
10000 loops, best of 3: 72.7 usec per loop
% python -m timeit -s 'lst = ("abc"*1000).split()' '[s.upper() for s in lst]'
10000 loops, best of 3: 67.7 usec per loop
% python -m timeit -s 'lst = ("abc"*10000).split() ; import string' 'map(string.upper, lst)'
1000 loops, best of 3: 844 usec per loop
% python -m timeit -s 'lst = ("abc"*10000).split()' '[s.upper() for s in lst]'
1000 loops, best of 3: 828 usec per loop
% python -m timeit -s 'lst = ["abc"*10]*10 ; import string' 'map(string.upper, lst)'
10000 loops, best of 3: 42.7 usec per loop
% python -m timeit -s 'lst = ["abc"*10]*10' '[s.upper() for s in lst]'
10000 loops, best of 3: 26.5 usec per loop
% python -m timeit -s 'lst = ["abc"*10]*100 ; import string' 'map(string.upper, lst)'
1000 loops, best of 3: 376 usec per loop
% python -m timeit -s 'lst = ["abc"*10]*100' '[s.upper() for s in lst]'
1000 loops, best of 3: 230 usec per loop
% python -m timeit -s 'lst = ["abc"*10]*1000 ; import string' 'map(string.upper, lst)'
100 loops, best of 3: 3.72 msec per loop
% python -m timeit -s 'lst = ["abc"*10]*1000' '[s.upper() for s in lst]'
100 loops, best of 3: 2.23 msec per loop
The above results are using Python CVS (aka 2.5a0).
Skip
Dan Christensen
> Andreas Beyer wrote:
>
>> Yeeh, I was expecting something like that. The only reason to use
>> map() at all is for improving the performance.
>> That is lost when using list comprehensions (as far as I know). So,
>> this is *no* option for larger jobs.
>
> Try it and see. You'll probably be pleasantly surprised.
In fact, in my test, the list comprehension won:
$ /usr/lib/python2.4/timeit.py -s "import string; slist=['aB'*100 for i in range(100)]" "map(string.upper, slist)"
1000 loops, best of 3: 522 usec per loop
$ /usr/lib/python2.4/timeit.py -s "slist=['aB'*100 for i in range(100)]" "[s.upper() for s in slist]"
1000 loops, best of 3: 461 usec per loop
Dan
Jack Diederich
> Hi:
>
> If I am getting the docs etc. correctly, the string-module is depricated
> and is supposed to be removed with the release of Python 3.0.
> I still use the module a lot and there are situations in which I don't
> know what to do without it. Maybe you can give me some help.
>
> >>> string.join(list_of_str, sep)
> instead of
> >>> sep.join(list_of_str)
>
> I think the former is much more telling what is happening than the
> latter. However, I will get used to it.
>
> >>> upper_list = map(string.upper, list_of_str)
>
>
['H', 'U', 'Z', 'Z', 'A', '!']
>>>
It doesn't work when passed a unicode string, but if you don't
care about that just start typing 'str' instead of 'string'
-jackdied
Duncan Booth
> I loved to use
> >>> string.join(list_of_str, sep)
> instead of
> >>> sep.join(list_of_str)
>
> I think the former is much more telling what is happening than the
> latter. However, I will get used to it.
No need to get used to it. Just reverse the order of the arguments and use:
str.join(sep, list_of_str)
Alternatively it can be clearer if you bind a name to the bound method:
joinLines = '\n'.join
joinWords = ' '.join
lines = joinLines(somelines)
words = joinWords(somewords)
Andreas Beyer
Python's performance that you should prefer map() compared to list
comprehensions. Apparently the performance of list comprehensions has
improved a lot, which is great. (Or the overhead of calling map() got
too big, but I hope this is not the case.) So, what is the purpose of
map()? Should it too be deprecated?
Andreas
Michael Chermside
> Yeeh, I was expecting something like that. The only reason to
Skip Montanaro replied:
> Did you test your hypothesis?
>
> % python -m timeit -s 'lst = ["abc"*10]*1000 ; import string'
'map(string.upper, lst)'
> 100 loops, best of 3: 3.72 msec per loop
> % python -m timeit -s 'lst = ["abc"*10]*1000' '[s.upper() for s in lst]'
> 100 loops, best of 3: 2.23 msec per loop
Andreas Beyer writes:
> OK, you won. I read in an (regretably old) guidline for improving
> Python's performance that you should prefer map() compared to list
> comprehensions. Apparently the performance of list comprehensions has
> improved a lot, which is great.
If the lesson you learned here was that list comprehensions are at
least as fast as list comprehensions, then you've learned the wrong
lesson.
The REAL lesson here is that you shouldn't follow any "optimization"
rules without actually testing them. If you don't have time to test,
then just don't optimize... write whatever is most readable. If you
NEED more speed, then profiling and testing will show you what to
fix. (Using a better algorithm is a different story... do that
whenever you need it.)
-- Michael Chermside
Ivan Van Laningham
Michael Chermside wrote:
>
> The REAL lesson here is that you shouldn't follow any "optimization"
> rules without actually testing them. If you don't have time to test,
> then just don't optimize... write whatever is most readable. If you
> NEED more speed, then profiling and testing will show you what to
> fix. (Using a better algorithm is a different story... do that
> whenever you need it.)
>
Tim Peters sayeth, "Premature Optimization is the Root of All Evil."
And he is not kidding.
Ever try to persuade a boatload of Java programmers that?
Peter Hansen
> Tim Peters sayeth, "Premature Optimization is the Root of All Evil."
> And he is not kidding.
And just to forestall another long thread about who
actually said that originally, it was really Mark
Twain, quoting Churchill. Tim just added a <wink>.
-Peter
Mike Meyer
> OK, you won. I read in an (regretably old) guidline for improving
> Python's performance that you should prefer map() compared to list
> comprehensions. Apparently the performance of list comprehensions has
> improved a lot, which is great. (Or the overhead of calling map() got
> too big, but I hope this is not the case.) So, what is the purpose of
> map()? Should it too be deprecated?
map() is already slated for removal in Python 3.0.
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
John J. Lee
[...]
> str.join(sep, list_of_str)
[...]
Doesn't work with unicode, IIRC.
John
"Martin v. Löwis"
> Yeeh, I was expecting something like that. The only reason to use map()
> at all is for improving the performance.
> That is lost when using list comprehensions (as far as I know). So, this
> is *no* option for larger jobs.
Don't believe anything you hear right away, especially not when it comes
to performance, especially not wrt. Python.
martin@mira:~$ python -m timeit -s "items=['']*10000;import string"
"map(string.upper, items)"
100 loops, best of 3: 6.32 msec per loop
martin@mira:~$ python -m timeit -s "items=['']*10000;import string"
"[s.upper for s in items]"
100 loops, best of 3: 2.22 msec per loop
So using map is *no* option for larger jobs.
Of course that statement is also false. Performance prediction is very
difficult, and you cannot imply much from this benchmark. In other
cases, list comprehension may be slower than map. More likely, for real
(i.e. non-empty) strings, the cost of .upper will make the precise
implementation of the loop irrelevant for performance reasons.
Regards,
Martin
"Martin v. Löwis"
> Yeeh, I was expecting something like that. The only reason to use map()
> at all is for improving the performance.
> That is lost when using list comprehensions (as far as I know). So, this
> is *no* option for larger jobs.
Don't believe anything you hear right away, especially not when it comes
"Martin v. Löwis"
> If I am getting the docs etc. correctly, the string-module is depricated
> and is supposed to be removed with the release of Python 3.0.
> I still use the module a lot and there are situations in which I don't
> know what to do without it. Maybe you can give me some help.
Out of curiosity: when thinking about Python 3.0, what is the timespan
in which you expect that to appear? Before 2010? After 2010? After 2020?
Regards,
Martin
Paul Rubin
> Out of curiosity: when thinking about Python 3.0, what is the timespan
> in which you expect that to appear? Before 2010? After 2010? After 2020?
I'm not terribly worried about Python 3.0 incompatibilities, whenever
those are. There are already three incompatible Python versions
(CPython, Jython, IronPython) with PyPy coming right along. If any of
those newer ones take off in popularity, there's going to be much more
interoperability hassle than 3.0 will cause.
Dan Bishop
>>> u" ".join(["What's", "the", "problem?"])
u"What's the problem?"
Greg Ewing
> John J. Lee wrote:
>
>>Doesn't work with unicode, IIRC.
>
>>>>u" ".join(["What's", "the", "problem?"])
>
> u"What's the problem?"
str.join(x, y) isn't quite a drop-in replacement for
string.join(y, x), since it's not polymorphic on the
joining string:
>>> str.join(u" ", ["a", "b"])
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: descriptor 'join' requires a 'str' object but received a 'unicode'
The strings being joined can be unicode, though:
>>> str.join(" ", [u"a", u"b"])
u'a b'
So it's probably not a serious problem, since in most
cases you'll know whether the joining string is unicode
or not when you write the code. If not, you'll just
have to do it the "new" way.
--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg
Duncan Booth
str.join won't work if sep is unicode, but generally you know what type the
separator is and str.join will quite happily join a list of strings where
one or more is unicode and return a unicode result.
If you know the separator is unicode then use unicode.join instead.
John J. Lee
> Of course that statement is also false. Performance prediction is very
> difficult, and you cannot imply much from this benchmark. In other
s/imply/infer/
John