I'm playing around with list comprehensions and I came across this little snippet on another site:
return ''.join([`num` for num in xrange(loop_count)])
return ''.join([str(num) for num in xrange(10000000)])
return ''.join([`num` for num in xrange(10000000)])
Backticks are a deprecated alias for
repr(). Don't use them any more, the syntax was removed in Python 3.0.
Using backticks seems to be faster than using
num.__repr__() in version 2.x. I guess it's because additional dictionary lookup is required in the global namespace (for
repr), or in the object's namespace (for
dis module proves my assumption:
def f1(a): return repr(a) def f2(a): return a.__repr__() def f3(a): return `a`
>>> import dis >>> dis.dis(f1) 3 0 LOAD_GLOBAL 0 (repr) 3 LOAD_FAST 0 (a) 6 CALL_FUNCTION 1 9 RETURN_VALUE >>> dis.dis(f2) 6 0 LOAD_FAST 0 (a) 3 LOAD_ATTR 0 (__repr__) 6 CALL_FUNCTION 0 9 RETURN_VALUE >>> dis.dis(f3) 9 0 LOAD_FAST 0 (a) 3 UNARY_CONVERT 4 RETURN_VALUE
f1 involves a global lookup for
f2 an attribute lookup for
__repr__, whereas the backtick operator is implemented in a separate opcode. Since there is no overhead for dictionary lookup (
LOAD_ATTR) nor for function calls (
CALL_FUNCTION), backticks are faster.
I guess that the Python folks decided that having a separate low-level operation for
repr() is not worth it, and having both
repr() and backticks violates the principle
"There should be one-- and preferably only one --obvious way to do it"
so the feature was removed in Python 3.0.