Size: 3706
Comment:
|
Size: 3839
Comment: (kind of) fixed code
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
DubiousPython |
|
Line 5: | Line 3: |
Anyway, I thought it was a good idea, and a wiki page seems the best way to distribute the lifting. I'm hopeful this will get it started, but don't have any investment in the form or content of what is here; refactor at will. -- BrianvandenBroek | Anyway, I thought it was a good idea, and a wiki page seems the best way to distribute the lifting. I'm hopeful this will get it started, but don't have any investment in the form or content of what is here; refactor at will. (I don't know how to format code in moinmoin, so if you see it goofy before I've figured it out, please be a gnome!-- BrianvandenBroek |
Line 15: | Line 13: |
>>> new_string = "" >>> for s in string_list: |
>>> new_string = "" >>> for s in string_list: |
Line 19: | Line 20: |
>>> print new_string onebigstringinpieces |
>>> print new_string onebigstringinpieces |
Line 31: | Line 34: |
Line 39: | Line 43: |
Line 46: | Line 51: |
Line 57: | Line 63: |
Line 62: | Line 69: |
Line 63: | Line 71: |
Line 64: | Line 73: |
Line 65: | Line 75: |
Line 72: | Line 83: |
Line 75: | Line 87: |
Following a suggestion (not yet linkable on google groups) of FernadoPerez on comp.lang.python, I am inaugurating this wiki page. Fernado's suggestion was that there should somewhere be a collection of bad python practices together with an explanation of the badness and a preferred alternative. As a hobbyist uni-lingual programmer, I can say that I'd certainly find such a resources useful. I can kick it off, but I'm afraid that I likely have more to offer on the dubious than the preferred side of the ledger.
Anyway, I thought it was a good idea, and a wiki page seems the best way to distribute the lifting. I'm hopeful this will get it started, but don't have any investment in the form or content of what is here; refactor at will. (I don't know how to format code in moinmoin, so if you see it goofy before I've figured it out, please be a gnome!-- BrianvandenBroek
String Concatenation
String concatenation is building up a relatively lengthy string from a collection of strings.
Dubious Way
Newcomers to Python often try to build strings up like this:
>>> string_list = ['one', 'big', 'string', 'in', 'pieces']
>>> new_string = ""
>>> for s in string_list:
- new_string = new_string + s
>>> print new_string
onebigstringinpieces
>>>
The Problem
This is slow and resource heavy. Each time through the for loop, a new string is built and the old on is discarded. That might not matter so much for such a small case, but as the number of elements to be joined creeps up, so too does the inefficiency.
Preferred Alternatives
String Formatting
For short cases where the number of strings to be joined is know, you can use string formatting as follows:
>>> print '%s%s%s%s%s' %tuple(string_list)
onebigstringinpieces
This is much more efficient, but is also rather more limited in the range of circumstances to which it applies. It could be made more general by constructing the formatting string as a function of len(string_list), but this would be a bit dubious, too, when we have
The join method of strings
The join method of the string type lets you perform the concatenation as follows:
>>> print "".join(string_list)
onebigstringinpieces
This is quite efficient and perfectly general as it applies to any arbitrary list of strings. (You don't need to know the list length in advance.)
The major thing to puzzle the newcomer here is why "".join(some_list) rather than some_list.join(). The way to think of this is that you are using the string "" to join the elements of some_list. Hence,
>>> print 'JOINT'.join(string_list)
oneJOINTbigJOINTstringJOINTinJOINTpieces
That said, some do consider this aspect of the join method of strings odd enough to count as a PythonWart.
Boolean Redundancy
(Please name me better!)
Among the most common tasks in programming is to test if a condition obtains and act accordingly. It is common for newcomers to Python to adopt an all-together overly verbose idiom for this.
Dubious Way
if (count > 10) == True:
- # continue process
and
def count_tester(count):
if count > 10:
- return True
- return False
The Problem
There is a (very slight) speed of execution inefficiency in these examples. But much more important is the speed of entry and understanding inefficiency. All other things being equal, extra typing is evil. And, unless some gain in clarity is purchased by the extra characters, the more characters in the code, the longer that code will take to understand. (The programming time you save could well be your own!)
Preferred Alternatives
if count > 10:
- # continue process
def count_tester(count):
return count > 10