Re: string goes away
John J. Lee wrote: Duncan Booth [EMAIL PROTECTED] writes: [...] str.join(sep, list_of_str) [...] Doesn't work with unicode, IIRC. 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: string goes away
Martin v. Löwis [EMAIL PROTECTED] writes: [...] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: string goes away
Duncan Booth [EMAIL PROTECTED] writes: [...] str.join(sep, list_of_str) [...] Doesn't work with unicode, IIRC. John -- http://mail.python.org/mailman/listinfo/python-list
Re: string goes away
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. Don't believe anything you hear right away, especially not when it comes to performance, especially not wrt. Python. [EMAIL PROTECTED]:~$ python -m timeit -s items=['']*1;import string map(string.upper, items) 100 loops, best of 3: 6.32 msec per loop [EMAIL PROTECTED]:~$ python -m timeit -s items=['']*1;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 -- http://mail.python.org/mailman/listinfo/python-list
Re: string goes away
Andreas Beyer wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: string goes away
Martin v. Löwis [EMAIL PROTECTED] writes: 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: string goes away
John J. Lee wrote: Duncan Booth [EMAIL PROTECTED] writes: [...] str.join(sep, list_of_str) [...] Doesn't work with unicode, IIRC. u .join([What's, the, problem?]) uWhat's the problem? -- http://mail.python.org/mailman/listinfo/python-list
Re: string goes away
Dan Bishop wrote: John J. Lee wrote: Doesn't work with unicode, IIRC. u .join([What's, the, problem?]) uWhat'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( , [ua, ub]) 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: string goes away
Andreas Beyer [EMAIL PROTECTED] 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. (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 [EMAIL PROTECTED] http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: string goes away
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. 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) -- http://mail.python.org/mailman/listinfo/python-list
Re: string goes away
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? Andreas Skip Montanaro wrote: 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)' 10 loops, best of 3: 9.24 usec per loop % python -m timeit -s 'lst = (abc*10).split()' '[s.upper() for s in lst]' 10 loops, best of 3: 4.18 usec per loop % python -m timeit -s 'lst = (abc*100).split() ; import string' 'map(string.upper, lst)' 10 loops, best of 3: 16.1 usec per loop % python -m timeit -s 'lst = (abc*100).split()' '[s.upper() for s in lst]' 10 loops, best of 3: 10.8 usec per loop % python -m timeit -s 'lst = (abc*1000).split() ; import string' 'map(string.upper, lst)' 1 loops, best of 3: 72.7 usec per loop % python -m timeit -s 'lst = (abc*1000).split()' '[s.upper() for s in lst]' 1 loops, best of 3: 67.7 usec per loop % python -m timeit -s 'lst = (abc*1).split() ; import string' 'map(string.upper, lst)' 1000 loops, best of 3: 844 usec per loop % python -m timeit -s 'lst = (abc*1).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)' 1 loops, best of 3: 42.7 usec per loop % python -m timeit -s 'lst = [abc*10]*10' '[s.upper() for s in lst]' 1 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 -- http://mail.python.org/mailman/listinfo/python-list
string goes away
Andreas Beyer writes: 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. 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: string goes away
Hi All-- 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? 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 -- http://mail.python.org/mailman/listinfo/python-list
Who said that? (was Re: string goes away)
Ivan Van Laningham wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
string goes away
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. 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: string goes away
upper_list = map(string.upper, list_of_str) Andreas What am I supposed to do instead? Try [s.upper() for s in list_of_str] Skip -- http://mail.python.org/mailman/listinfo/python-list
Re: string goes away
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. Andreas Skip Montanaro wrote: upper_list = map(string.upper, list_of_str) Andreas What am I supposed to do instead? Try [s.upper() for s in list_of_str] Skip -- http://mail.python.org/mailman/listinfo/python-list
Re: string goes away
Hi All-- 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 -- http://mail.python.org/mailman/listinfo/python-list
RE: string goes away
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. 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: string goes away
Hey Andreas, 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: string goes away
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)' 10 loops, best of 3: 9.24 usec per loop % python -m timeit -s 'lst = (abc*10).split()' '[s.upper() for s in lst]' 10 loops, best of 3: 4.18 usec per loop % python -m timeit -s 'lst = (abc*100).split() ; import string' 'map(string.upper, lst)' 10 loops, best of 3: 16.1 usec per loop % python -m timeit -s 'lst = (abc*100).split()' '[s.upper() for s in lst]' 10 loops, best of 3: 10.8 usec per loop % python -m timeit -s 'lst = (abc*1000).split() ; import string' 'map(string.upper, lst)' 1 loops, best of 3: 72.7 usec per loop % python -m timeit -s 'lst = (abc*1000).split()' '[s.upper() for s in lst]' 1 loops, best of 3: 67.7 usec per loop % python -m timeit -s 'lst = (abc*1).split() ; import string' 'map(string.upper, lst)' 1000 loops, best of 3: 844 usec per loop % python -m timeit -s 'lst = (abc*1).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)' 1 loops, best of 3: 42.7 usec per loop % python -m timeit -s 'lst = [abc*10]*10' '[s.upper() for s in lst]' 1 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: string goes away
On Thu, Mar 31, 2005 at 08:32:20PM -0800, Andreas Beyer wrote: 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. 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? map(str.upper, 'huzza!') ['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 -- http://mail.python.org/mailman/listinfo/python-list
