Comment by mixmastamyk | Hacker News Reader

Comment by mixmastamyk | Hacker News Reader

Parent Full thread

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? ;)

This is what your co-worker does now:

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

A similar option is possible with '%'-style formatting:

  'result: %(long_var_name)s'%{"long_var_name":long_var_name}
    -or-
  'result: %(long_var_name)s'%dict(long_var_name=long_var_name)

The first of these alternatives is indeed shorter, so long as there's only a single parameter. If there are multiple parameters then the .format() solution will be shorter.

My experience with '%(name)s' % dict formatting is that I would often forget the terminal 's', and write it as '%(name)'. For template-like strings, where I want named substitutions, I am very much in favor of {}-style formatting.

So if your co-worker insists on named substitutions, then s.format() is less verbose than s % dict.

Regarding logging, there's a section of how to use format templates in the logging system, at https://docs.python.org/3/howto/logging-cookbook.html#format... . In addition to using a LogRecord factory, you could reduce the overhead in old-style logging to only an extra constructor calls:

  log.info(M('result: {} {}', one, two))

where M.__str__ forwards to str.format.

Personally, I would like a way to pre-compile the format string:

  fmt = format_compile("result: {} {} {}")
  for result in results:
    print(fmt(*result))

because currently (in Python 3.3) "%d %d %d" is about 40% faster than "{} {} {}".

EDIT: Never mind: It can be faster to interpolate the string each time than to call a constructor:

  % python3.3 -mtimeit 's="%s %s %s"' 's % (1, 3, 9)'
  1000000 loops, best of 3: 0.36 usec per loop
  % python3.3 -mtimeit 'class Spam:pass' 'Spam()'
  10000 loops, best of 3: 23.6 usec per loop

I did not expect a factor of 65!

Your timeit calls in the edit need the -s parameter before the first statements, so they aren't executed on each loop iteration. The overhead is in creating the class, not the instances.

  $ python3 -mtimeit -s 's="%s %s %s"' 's % (1, 3, 9)'
  1000000 loops, best of 3: 0.343 usec per loop
  $ python3 -mtimeit -s 'class Spam:pass' 'Spam()'
  10000000 loops, best of 3: 0.106 usec per loop

Thanks! That's a big forehead smack on my side.

The numbers are more in line with what I expected. Meaning it is possible to defer some of the time cost by using a single constructor rather than evaluating the string.

I don't like all that verbosity in short debug text at all, no matter which syntax is used. I would have done, e.g.:

    print 'result:', long_var_name

I do like your idea of a custom formatter though, perhaps it could be installed as a formatter into the logger beforehand, getting the slightly improved syntax without frequent object creation.

Right, but the verbosity here is primarily due to your co-worker, given that the guy at your work would likely have used %(name)s instead of {name}.

Regarding logging, the docs suggest that setting your own LogRecord factory is the way to go if that's what you want.

Still, with % you can skip the .format() and while logging you can even skip the %. If {} was more "built-in" with an operator/logging I think it'd be a clearer win.

My point is that even with the ".format()", if you use named arguments then .format() is shorter than '%' if you have two or more terms:

    "%(name1)s %(name2)s"%{"name1":"ABC","name2":"DEF"}
    "{name1} {name2}.format(name1="ABC",name2="DEF")

To get what you want, you need to convince your co-worker to 1) switch to positional arguments, and 2) switch to '%' instead of .format.

Even if Python never gained the .format() option, so #2 weren't an issue, you would still be stuck with #1, because '%' supported them as well.

As for logging, I pointed out two possible ways to address the problem. Personally, I don't log in performance critical loop since Python's function call overhead is so high. Testing now, you can see that 3/4ths of the overhead for logging a simple format statement is just in calling the logger:

  % python3.3 -mtimeit -s 'import logging' 'logging.info'
  10000000 loops, best of 3: 0.0525 usec per loop
  % python3.3 -mtimeit -s 'import logging' 'logging.info("abc")'
  1000000 loops, best of 3: 1.59 usec per loop
  % python3.3 -mtimeit -s 'import logging' 'logging.info("abc %d %d %d", 1, 2, 3)'
  1000000 loops, best of 3: 1.71 usec per loop
  % python3.3 -mtimeit -s 'import logging' 'logging.info("abc %d %d %d"%(1, 2, 3))'
  1000000 loops, best of 3: 1.64 usec per loop
  % python3.3 -mtimeit -s 'import logging' 'logging.info("abc %d %d %d".format(1, 2, 3))'
  1000000 loops, best of 3: 1.99 usec per loop

According to this, calling info() with more than one argument is actually slower than calling '%' every time(!).

Is your objection based on a measured performance impact (eg, more complicated formats will be worse) or a theoretical evaluation?

He and I'd never write out the full dictionary and would use a single arg or tuple.

Why? dunno... probably habit, sample code never showed it, mostly because it would be ridiculous. Why is it not ridiculous with {}? It is, though he would never agree.

I usually don't care about performance either, but the third example is easier to read and type. Looks just like a printf.

Going back a few posts:

> There was a guy at work who insisted on using .format() for everything that soured me on it, sometimes even simple string concatenation

It sounds like you are soured on new-style .format() because someone else doesn't use it appropriately. You concluded that it's intrinsic to .format(), even though s%{} is even more verbose, because of what seems to be an idiosyncratic preferences of one person.

I empathize with your other arguments. I too am much more familiar with printf-style % arguments than the Python-specific .format() syntax, which still cause me to reach for the documentation. But I do not think that it's reasonable to complain about its verbosity.

It is, Guido said it himself. Looks like I added an extra pair of curly brackets into the example that I first mentioned. That was a typo, sorry about that, it shouldn't have existed, and unfortunately probably why you insist that someone should do this 's%'%{...} though no one ever has to my knowledge.

I use format because you can break lines within the parentheses. You also get to name parameters, which is nice and explicit.

I also import print_function from the future, mainly because you can break lines inside the parentheses.

I also use ' '.join([...]) for the same reason when building a large-ish string, you can break lines inside parentheses (or square brackets in this case).

I like breaking lines inside parentheses and other delimiters.

Should be able to do both of those with % as well:

    print '%(foo)s %(bar)s' % dict(
        foo='foo',
        bar='bar',
    )

huh. I like it when I learn something new every day.

Reply on news.ycombinator.com