3 ms·

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

by dalke 12y ago

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.

mixmastamyk 12y ago
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.
- dalke 12y ago
  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?
  - mixmastamyk 12y ago
    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.
    - dalke 12y ago
      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.
      - mixmastamyk 12y ago
        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.

by dalke 12y ago

mixmastamyk 12y ago

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.

dalke 12y ago
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?
- mixmastamyk 12y ago
  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.
  - dalke 12y ago
    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.
    - mixmastamyk 12y ago
      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.