4 ms·

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 ne

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 12y ago
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.
- dalke 12y ago
  My timing tests have never come across a case where it's faster, for those cases that can be expressed directly in a '%' format string: % python3.3 -mtimeit 's="%s %s %s"' 's % (1, 3, 9)' 1000000 loops, best of 3: 0.361 usec per loop % python3.3 -mtimeit 's="{} {} {}"' 's.format(1, 3, 9)' 1000000 loops, best of 3: 0.593 usec per loop % python3.3 -mtimeit 'f="{} {} {}".format' 'f(1, 3, 9)' 1000000 loops, best of 3: 0.569 usec per loop The construct "x % y" has special support in CPython. Quoting from ceval.c: TARGET(BINARY_MODULO) w = POP(); v = TOP(); if (PyUnicode_CheckExact(v)) x = PyUnicode_Format(v, w); else x = PyNumber_Remainder(v, w); Py_DECREF(v); Py_DECREF(w); SET_TOP(x); if (x != NULL) DISPATCH(); break; That is, in the '%' case, if the left-hand side is a string, then go directly to the string format. Otherwise, go though the normal binary operation resolution mechanism. While the "".format(x) path goes through the normal method invocation path - it has no special treatment.
- _ZeD_ 12y ago
  • 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. uhh... so you'd prefer to do something like `1.add(2)` ???
  - jnpatel 12y ago
    While arithmetic syntactic sugar is useful since it's much clearer, I agree that I'd often prefer a function call to some unintuitive symbol syntax. Another example for me, in Python, is: print >> sys.stderr, 'foo' vs. print ('foo', file=sys.stderr)
    - dorfsmay 12y ago
      Ah yes, I've been doing from __future__ import print_function pretty much since it has been available. flush=True, end='' etc.... much more intuitive.
  - dorfsmay 12y ago
    I'd be happy with `int().add(1, 2)`, it'd be more consistent. If we carry on this discussion lispers are going to tell us we're the ones with the funny syntax!
- unfamiliar 12y ago
  None of those seem like very good reasons, except for the speed argument, and that is surely just an implementation issue.

dorfsmay 12y ago

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.

dalke 12y ago
My timing tests have never come across a case where it's faster, for those cases that can be expressed directly in a '%' format string: % python3.3 -mtimeit 's="%s %s %s"' 's % (1, 3, 9)' 1000000 loops, best of 3: 0.361 usec per loop % python3.3 -mtimeit 's="{} {} {}"' 's.format(1, 3, 9)' 1000000 loops, best of 3: 0.593 usec per loop % python3.3 -mtimeit 'f="{} {} {}".format' 'f(1, 3, 9)' 1000000 loops, best of 3: 0.569 usec per loop The construct "x % y" has special support in CPython. Quoting from ceval.c: TARGET(BINARY_MODULO) w = POP(); v = TOP(); if (PyUnicode_CheckExact(v)) x = PyUnicode_Format(v, w); else x = PyNumber_Remainder(v, w); Py_DECREF(v); Py_DECREF(w); SET_TOP(x); if (x != NULL) DISPATCH(); break; That is, in the '%' case, if the left-hand side is a string, then go directly to the string format. Otherwise, go though the normal binary operation resolution mechanism. While the "".format(x) path goes through the normal method invocation path - it has no special treatment.
_ZeD_ 12y ago
• 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. uhh... so you'd prefer to do something like `1.add(2)` ???
- jnpatel 12y ago
  While arithmetic syntactic sugar is useful since it's much clearer, I agree that I'd often prefer a function call to some unintuitive symbol syntax. Another example for me, in Python, is: print >> sys.stderr, 'foo' vs. print ('foo', file=sys.stderr)
  - dorfsmay 12y ago
    Ah yes, I've been doing from __future__ import print_function pretty much since it has been available. flush=True, end='' etc.... much more intuitive.
- dorfsmay 12y ago
  I'd be happy with `int().add(1, 2)`, it'd be more consistent. If we carry on this discussion lispers are going to tell us we're the ones with the funny syntax!
unfamiliar 12y ago
None of those seem like very good reasons, except for the speed argument, and that is surely just an implementation issue.