PyFormat – Practical examples of old and new style string formatting

[sago]

A good reference.

My take home is that every single version that is possible to do in old style formatting is longer in new style formatting. Even more so if the old-style formatting were written without the extraneous 1-ples.

    '%4d' % 42

vs

    '{:4d}'.format(42)

It isn't surprising that so much code is still being written in old-style. The advantages of the new style, like padding with arbitrary characters; value reuse (particularly for I18n, though that tends to use a different mechanism for production systems that need it); and nested display; are really quite minor.

This feeds into the other python issue on HN today - why does py3 have so little uptake? Because it is a solution to a problem few people have.

[mixmastamyk]

Yes, very nice, helpful site.

.format() is mostly too verbose for my tastes. Even Guido himself put it into the "meh" category in a talk. To be clear, I do use it when I need quick lightweight templating, say building a very complicated string.

But for most simple output printf style is shorter, simpler and I know it by heart. There was a guy at work who insisted on using .format() for everything that soured me on it, sometimes even simple string concatenation:

    print 'result: {long_var_name}'.format({long_var_name=long_var_name})

Sometimes lines reached 200 chars. If lines were broken down, they might extend to 4 lines for each debug statement, adding tons of clutter. Said it was more readable because you could ignore the end. :/

As sago said, printf is more concise in the majority of use cases. Not to mention the logging niceties:

    log.info('result: %s %s', one, two)  # shorter and note that fmt is deferred!

A _big_ one in my eyes. Too bad logging doesn't support {} internally.

I've also wondered if .format could be improved if the % operator could be used with it, given appropriate precedence rules. Or perhaps use another char... dunno & or /?

    print 'results: {} {}' %  results
    print 'results: {} {}' %% results
    print 'results: {} {}' /  results

Pycon, are you listening? ;)

[userbinator]

Value reuse/positional parameter references could've been added easily to the old-style formatting in the same way POSIX added them to C's printf(), using the $ specifier (although printf() unusually indices from 1, not 0):

    '%1$s %0$s' % ('one', 'two', )

Changing the padding character would probably not be too difficult either - just add the appropriate specifier to the formatting DSL; and I'm not so keen on supporting nested structures in the format string, as it seems to be going in the direction of allowing arbitrary expressions/Python code into a formatting DSL - one that I think shouldn't be more than a regular language.

[aidos]

I had to read your statement a couple of times to understand it. You're saying that the old syntax is totally incompatible with the new syntax? It's a shame, but I'm sure it was necessary.

The various other improvements are all things I've made use of in real code. Format is now a tool that you can reach for before you need to go to a more heavyweight templating lib (like Jinja2).

    '{p.type}: {p.kinds[0][name]}'.format(p=Plant())

[Trumpet6]

Most of the examples of the brevity of the old style seem to be quite unconcerned with actual formatting. Honestly I just do simple print "Hello: " + a when I'm not too picky, and use .format when I actually want a nice output; the time of the few extra chars in format is unimportant compared to the time it takes to choose good field widths for the first time anyway, and I find the old syntax more cryptic.

[Grue3]

I almost always use format because it looks nicer, hence more readable. Shorter is not always better. It is also mandatory in i10n strings because if there are more than 2 arguments, they might be in different order in another language.

[amelius]

I think the following makes more sense:

'{}'.format(format_decimal_with_prepended_spaces(42, 4))

[fragmede]

They missed my favorite trick! locals() will give you a dict of, well, local variables, which generally coincides with what you want, so:

    a = 4
    'A is: {a}'.format(**locals())

works as expected.

[reidrac]

You can also:

    a = 4
    'A is: %(a)d' % locals()

Perhaps is my experience programming in C, but "format" looks lees familiar and I tend to use the old style formatting.

[quarktasche]

Might not work in some special cases though. Try:

  def foo():
      a = 4
      def bar():
          print("a = {a}".format(**locals()))
      bar()
        
  foo()

which will raise a KeyError, while it will work fine if you add a

  print(a)

to the end of bar().

[pfranz]

I've seen this and tried to avoid it since getting bitten my moving code around and not catching which variables were used. It might have been even more obscured with something like TEMPLATED_STRING.format(locals())

[wodenokoto]

Why not just

    a = 4
    'A is:{}'.format(a)

[maxerickson]

str.format_map takes a mapping directly (added in 3.2).

[kstrauser]

My last remaining complaint with new formatting is with Pylint and logging messages. The old-style way is to write:

    logging.debug('some value: %d', 123)

which avoids the cost of string interpolation if that log message wasn't going to be emitted, say because the log level is higher than DEBUG. If you instead write:

    logging.debug('some value: {}'.format(123))

then Pylint will complain that I "Use % formatting in logging functions but pass the % parameters as arguments (logging-format-interpolation)".

Yes, I can disable that particular warning, either by maintain a pylintrc file or adding annotations to the source code. Yes, this is a dumb complaint. But yes, it still bugs me.

[andy_ppp]

I really don't mind these apparent (small) improvements to Python.

However, the fact that Python 3 just went off and did it's own things rather than the usual cycle of:

    1) improve a language feature
    2) deprecate the old way of doing it
    3) give people time to update code (usually a couple of point releases)
    4) remove features that have been replaced

Python 3 should not have dropped lots of little changes with no backwards compatibility. They should still make 2.8 and 2.9 that are releases that remove features and add new ones until most python code works in Python 3.

[toyg]

Somebody should write a HN plugin that does something like this:

    if is_about_python3(post):
        insert_token_random_complaint_from_2008()

(edit: snake-case)

[kasabali]

they've already done it:

improve a language feature & deprecate the old way of doing it -> Python 2.6+ and 3.2+

remove features that have been replaced -> 3.x

Did I also mention it is not hard to have a single code base that is compatible with both 2.x and 3.x?

[infix]

There should be two-- and preferably only two --obvious ways to do it.

-- The Zen of Python

[erichurkman]

Python 2.7 also added a non-locale aware thousands separator that be be combined with other options:

    >>> "{:>40,.2f}".format(sys.maxint)
    '            9,223,372,036,854,775,808.00'

[jkbr]

    Basic formatting
    Old: '%d %d' % (1, 2)
    New: '{} {}'.format(1, 2)

It should rather be `{:d} {:d}'.format(1, 2)` but even that isn't strictly equivalent (try both styles with a float or a Decimal).

[foxylad]

I'm a c dinosaur, so I've always used old-style formatting because I know it off by heart. Having said that, the alignment operator (<^>) reminds me of my joy when learning python - power and simplicity!

[auscompgeek]

This fails to mention the str.format_map() shortcut method (new in Python 3.2). It's useful if you already have a dictionary of all your values!

[lumpypua]

Really cool and the site looks great too! Was a css framework used for the styling or is it hand written? Can't tell from the minification.

[civilian]

    '%d %d' % (1, 2)

I would have done this as

    '%s %s' % (1, 2)

Because we're turning everything into a string at the end of the day anyway!

Yeah. Having finished the article, .format() just isn't really needed. If I'm at the point where I'm doing templating with key:values, I'll be using jinja.

[jkbr]

%d converts the value to int first which might be useful:

    >>> '%d' % 3.14
    '3'
    >>> '%d' % 'foo'
    TypeError: %d format: a number is required, not str

[mangeletti]

I personally prefer the old style still, and I still don't see the value of deprecating it in favor of the new style. I started Python in 2008 (p3k was brand new), and I used new style formatting for about 2 years. After realizing that I was the only one using new style I switched and now I cannot imagines going back.

[dorfsmay]

I use the new style for three reasons:

• it is supposedly significantly faster

• new, means, eventually we'll have to use it, so might as well get used to it now!

• it's a method on an object, which makes my brain happy. I never managed to get my brain wrapped around the old style syntax, it's inconsistent with the rest of the python syntax.

[japaget]

One caution that this document does not mention is that the new formatting is available only in recent versions of Python. One of my projects runs on a CentOS 5.x server, which has Python 2.4, so I had to convert all of the new style formatting to old in order to get it to run there.

[huxley]

Wow, Python 2.4 was last updated on October 18, 2006.

Since Centos 5 still has about 2 years of life but fewer and fewer Python packages support 2.4, it might be worth looking at Pyenv:

https://github.com/yyuu/pyenv

Good overview of what it lets you do:

http://fgimian.github.io/blog/2014/04/20/better-python-versi...

[hobarrera]

No it's not. It's available on quite old versions of python.

Python 2.4 is actually pretty ancient. To put it into perspective, it's from when we had things Firefox 2.0, and IE6 was the latest IE.

[zenogais]

Can't tell you how many times I've Googled this and had to dig through the docs. Thank you!

[jegutman]

I use the format: foo = 'foo' bar = 'bar' print "%(foo)s%(bar)s" % locals() which I guess is what this is similar too.

basically locals(), vars(), and globals() I find very useful for string formatting.

[gamesbrainiac]

In Dash.app (on Mac), there's actually a nifty file that you can download that shows you how all the different formatting options work.

Its good, but I think this is even better.

[gcb0]

Its very lame that the new format kept the bad design from C hacks.

Why not 'field: {:center :minsize=8 varname}'.format(varname=123) ?

[roywiggins]

Once you start formatting more than one variable, isn't your proposed syntax going to be horribly long?

    '{:center :minsize=8 varname} {:center :minsize=8 varname2} {:center :minsize=8 varname2}'.format(varname=123, varname2=123,varname3=123)

instead of

    '{:^8} {:^8} {:^8}'.format(varname, varname2, varname3)

Concision is not always a good thing, but still...

[father_of_two]

Hey, very nice. I knew about the "new" format() but didn't know it was so powerful.