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 - ' +
sys.exc_info()[1])

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
discern.

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:

logger.error(
'{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
.