8

I'm probably missing something here, after searching I couldn't find an answer.

I've explored quite a few Python projects and one thing I keep noticing is the fact that the majority of them continue to use the % operator for formatting strings rather than the newer, recommended .format() method. Is there a reason for this? it seems like a trivial change, unless I'm missing something entirely.

For example:

# count how many times the % operator technique is used
find . -name "*.py" -exec grep -HE "\"[^\"]+\"\s\%\s\w+|'[^']+'\s\%\s\w+" {} \; | wc -l

# and the same for format()
find . -name "*.py" -exec grep -HE "\w+\.format\(" {} \; | wc -l

# Results:
#
#               % operator        format()
# iPython          670               63
# Django           977               8
# Tornado          91                0
# requests         25                1

No real reason for this question, just curious.

Cheers guys!

Improve this question
2
  • 2
    People like to type less, and also have code that was written before there was a .format() method?
    – Wooble
    Commented Feb 21, 2013 at 13:03
  • FWIW, the old % is more efficient, and less verbose for simple string replacements. I use it most of times, and when I need more powerful formatting I go for .format
    – bgusach
    Commented Nov 14, 2014 at 13:44

4 Answers 4

Reset to default
16

Three extremely strong inclinations come together to produce this effect:

  1. Comfort: "I know how to do this the old way, learning the new way would be more effort."
  2. effort/effect trade-off: "Is the old method gone? Is it even deprecated? No? Then there is no business case whatsoever for changing this. Create new code instead."
  3. Safety: "Are you sure the proposed new way of doing things is exactly equivalent? No? Then better leave the old code as it is - you might introduce defects."

All three are, in fact, quite sensible (the first one least so, since continual learning is what information workers should thrive on).

(Edit: As pointed out below there is a fourth point: not knowing that the new method even exists! This is less sensible, but might actually be the most common one.)

Improve this answer
5
  • 4
    +1 there is perhaps 4. ignorance that there even is a new way
    – jk.
    Commented Feb 21, 2013 at 13:17
  • 1
    @jk. +1 I didn't know format() existed.
    – Joe Z.
    Commented Feb 21, 2013 at 13:27
  • +1, but do include that 4th point. I notice time and again on SO that whenever I show the .format() method or format() function that people just don't know they exist.
    – Martijn Pieters
    Commented Feb 21, 2013 at 15:07
  • 1
    I'd add that format is not an equivalent of %. For example using % you can use * to specify the minimum field width(e.g. '%.*f' % (7, 2.34) formats the float 2.34 with at least 7 digits), while with format you can't do this. And probably there exist other things that format can do while % can't.
    – Bakuriu
    Commented Feb 21, 2013 at 17:26
  • 3
    Great answer. Also, @Bakuri it is possible with format, it's not as concise though – "{0:.{1}f}".format(2.34, 7). I haven't found anything % can do that format can't.
    – Matt
    Commented Feb 21, 2013 at 18:29
6

In addition to the other reasons, I would add backward compatibility and consistency. Often you need to write scripts that can run on other people's computers, who are be unwilling or unable to upgrade to the latest and greatest Python. So you write to the lowest common denominator. By the time enough of your users have upgraded to a sufficiently recent version of Python you have probably forgotten which features appeared in which version of Python. Unless they are exceptionally valuable features, it may well not be worth the time to research, consider and decide whether it's now safe to use each feature. The format method method is a nice API to use in new code, but the case for introducing it to a code-base that already uses % extensively is not so strong.

Improve this answer
2

When developing software for your own use, it's often to your benefit to use newer versions of your libraries and development tools. However, the projects you're looking at are libraries and development tools meant to be shared with the community. In these cases, you want to be conservative in the features you require in order to get the broadest installed base & get the most people involved in the project.

The format() method wasn't added until the release of Python 3.0/2.6 in 2008. That seems like a long time ago but keep in mind that people seldom use the first release of software. Let's put this in context of when it became available in two of the more 'serious' Linux distros. RHEL 5.x still uses Python 2.4 and is supported until 2017 - 6.x has Python 2.6 but that wasn't released until 2010. In the Debian camp they didn't have Python 2.6 until the 6.x series which became stable in 2011.

So, while it might make sense, if you were starting a project like Django (originally released in 2005) today, to standardize on the new method, there's very little value in going back and changing all 1000 occurrences of the old method without it having been formally deprecated. It makes work, creates the possibility of introducing bugs & needlessly increases the system requirements.

Improve this answer
0

Addition to @KilianFoth's answer; porting a big project to an upper software version have too much work to do. And changing an un-deprecated usage have the least importance in the upgrade process.

Probably they are using new format in totally re-written parts and do not change the existing usage on the rest.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.