Re: String concatenation vs. string formatting

Andrew Berg <bahamutzero8825@xxxxxxxxx> writes:

Is it bad practice to use this
logger.error(self.preset_file + ' could not be stored - ' +

This is not necessarily bad practice, but there are not many points in
its favour. It's inflexible and makes the eventual formatting harder to

Instead of this?
logger.error('{file} could not be stored -
{error}'.format(file=self.preset_file, error=sys.exc_info()[1]))

With the caveat that the formatting of that line should be using PEP 8
indentation for clarity:

'{file} could not be stored - {error}'.format(
file=self.preset_file, error=sys.exc_info()[1]))

Other than the case where a variable isn't a string (format() converts
variables to strings, automatically, right?)

If you don't specify a conversion in the placeholder, it will default to
‘str’, yes.

and when a variable is used a bunch of times, concatenation is fine,

I don't see any argument for concatenation there; using a variable a
bunch of times works just fine with the ‘format’ method.

but somehow, it seems wrong. Sorry if this seems a bit silly, but I'm
a novice when it comes to design. Plus, there's not really supposed to
be "more than one way to do it" in Python.

There is often more than one way to do it. The Zen of Python is explicit
that there should be one obvious way to do it (and preferably only one).

The “OOW” in “TOOWTDI” is not “only one way”, but “one obvious way”.

The presence of multiple ways to format strings (the ‘%’ operator, the
‘format’ method) is for backward compatibility with code written before
the current recommended ‘format’ method.

Backward compatibility is a common reason for more than one way to do it
in Python. It's just preferable that all but one of them should be
non-obvious :-)

\ “The whole area of [treating source code as intellectual |
`\ property] is almost assuring a customer that you are not going |
_o__) to do any innovation in the future.” —Gary Barnett |
Ben Finney

Relevant Pages

  • Re: PEP 378: Format Specifier for Thousands Separator
    ... The myth that % string formatting is deprecated. ... That str.format looks like Java is irrelevant. ... common in Python, and is not original to Java. ...
  • Re: New Python 3.0 string formatting - really necessary?
    ... However these features have been discussed for ... Every single Python ... burden of formatting strings has been moved from the print ... formatting strings in the past. ...
  • Re: new to python - trouble calling a function from another function
    ... my checkQueue function below, the call to self.goUpis never executed. ... you didn't reduce the code to the smallest possible example), Python wont. ... The formatting here is completely removed, ... have a good reason not to. ...
  • Re: New Python 3.0 string formatting - really necessary?
    ... Python, the % formatting is probably one of the least common ... this change at least was a no cost change. ... all the things to complain about in python 3.0, ...
  • Re: .format vs. %
    ... % formatting was supposed to be deprecated in Python 3.1. ... So there will be no deprecation, just a gradual shift to PEP 3101 ... ordinary string concatenation), which according to the Zen of Python ...