Chuck Esterbrook wrote:
Typically, when working with strings, I prefer to use string methods
like join() or string formatting operations with % instead of
addition. [...]
I think your intentions are good and your general point is sound, but possibly applied to the wrong case.
[...]
But my most important point is that for most apps it doesn't matter. Better to get your app features built and stable, then worry about performance if you have to!
As I pointed out, in this particular case the difference is probably negligable either way. However, I've seen too many people try to use something like:
result = ""
for each in mylist:
result = result + '\n' + each
to allow this sort of string addition to pass without comment. In cases where an entire list is being processed, or where a series of additions can easily be converted to list.append()s, using join() is usually more efficient, sometimes by large orders of magnitude. In cases where addition is more efficient, it's usually by a pretty small amount. Similarly for string formatting, when combining two or three variables addition may be slightly more efficient, but when combining half a dozen or more variables then string formatting can be a very big win. On the average of all of these cases, addition is less efficient than the alternatives, therefore I consider using addition in cases where it might be faster to be one of those premature optimizations. 
- Stylistically, I recommend eval(s) instead of `s`.
eval() fits nicer with all the other cool functions
and
statements like dir(), hasattr(), exec, etc.
First, backticks (`s`) are not equivalent to eval(), they're
equivalent to repr(). I also prefer to avoid using the backticks,
because the function usage is much less cryptic.
Not on my box. 
$ python
Python 2.2.2 (#1, Nov 26 2002, 16:14:37)
[GCC 3.2 (Mandrake Linux 9.0 3.2-1mdk)] on linux2
print `3+4`
7
That's clearly an interpretation of "3" and "4" as ints and "+" as an operator to execute. I used to print to avoid the implicit repr() call that the interpreter makes, which would have just been confusing for this discussion.
print repr('3+4')
'3+4'
repr() returns strings as-is. No interpretation.
Ah, but you're not repr()'ing the same thing that you printed.
>>> print repr(3+4)
7
>>> print `'3+4'`
'3+4'
>>>
In your first case, you're using backticks on the result of an arithmetic expression (3+4), in the second case you're using it on a string that represents an arithmetic expression ('3+4'). These are not at all the same thing, and that's why you're getting different results.
Using an intermediate variable makes this even clearer:
>>> spam = 3+4
>>> print `spam`
7
>>> print repr(spam)
7
>>> spam = '3+4'
>>> print `spam`
'3+4'
>>> print repr(spam)
'3+4'
>>>
In addition, the equivalence of backticks and repr() is commented on in the documentation.
I can't recall a single time
that I've seen eval() used, that I couldn't think of some other way
to achieve the same ends that was cleaner and safer.
I agree to some extent. For example, int(), str(), float() and such are more appropriately for converting values from one type to another. My most common use of eval() is for sucking in a dictionary config file:
# my.config
{
'numThis': 5,
'numThat': 10,
'filename': '/some/path',
}
You might find something safer, but you probably won't find something "cleaner" than this:
eval(open('my.config').read())
I would argue that you're perhaps confusing "clean" with "concise", and these are not necessarily the same thing, nor is conciseness always a virtue. To quote from Python Zen ('import this'), "Explicit is better than implicit" and "Readability counts". I'd really rather see this:
# ---- my.config
numThis 5
numThat 10
filename /some/path
# note that those are tabs separating key from value
configdict = {}
for line in file('my.config').readlines():
key, value = line.split('\t')
configdict[key] = value.strip()
This lets me know, without examining the config file, exactly what form the data ends up in -- I can see that I'm creating a dictionary. In your version, I have to look into the my.config file to determine what I can do with the result of that one-liner -- is it a dict? a string? a list? an entire module? Not only that, but the my.config file is easier to maintain, since it doesn't require that the sysadmin who alters it understand Python syntax, and a misplaced quote won't throw the entire file off. I also don't have to worry about the safety issues involved in the possibility of someone replacing the config file with something malicious (config files typically being considered lower-security than program files, and thus more likely for an arbitrary user to gain permissions to modify).
Actually, I'd *really* rather see the whole thing done using the standard module ConfigParser, or wxConfig in a wxPython app, but that's another story.
Jeff Shannon
Technician/Programmer
Credit International
···
On Wednesday 30 April 2003 10:52 am, Jeff Shannon wrote: