Re: [Python-Dev] Banishing apply(), buffer(), coerce(), and intern()
Guido van Rossum wrote Yes, backticks will be gone in 3.0. But I expect there's no hope of getting rid of them earlier -- they've been used too much. I suspect
Then let's kill all use of backticks in the standard library. There's a lot of them. Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never to late to have a happy childhood.
Then let's kill all use of backticks in the standard library. There's a lot of them.
That's one reason why we have to support them for a long time; there standard library has widely been used as sample code, so there's likely to be a lot of them elsewhere. As always, be careful with doing peephole changes to the standard library -- historically, we've seen a 1-5% error rate in these change sets that persists for months or years afterwards. --Guido van Rossum (home page: http://www.python.org/~guido/)
[Anthony]
Then let's kill all use of backticks in the standard library. There's a lot of them.
[Guido]
As always, be careful with doing peephole changes to the standard library -- historically, we've seen a 1-5% error rate in these change sets that persists for months or years afterwards.
FWIW, Walter and I did a bunch of these for Py2.3 and had excellent success because of a good process. Some ideas are: * start it now (don't wait until a beta release). * skip the packages like email which are maintained separately * think out ways it could go wrong (operator precedence, double backticks, escaped backticks, backticks inside strings or comments, etc.). * do it manually (not brainlessly), then do it with automation to compare the results. * make sure every affected module still imports. * run the whole unittest suite in debug mode with -u all. * self-review the diff file. * get a second person to do a 100% review of the diff (Walter or I would be a good choice). * put on an asbestos suit because the flames will come even if no mistakes are made. IMO, this change is much easier to get right than the ones that were done before. Good luck, Raymond
On Sun, Nov 30, 2003 at 03:26:16AM -0500, Raymond Hettinger wrote:
[Anthony]
Then let's kill all use of backticks in the standard library. There's a lot of them.
[Guido]
As always, be careful with doing peephole changes to the standard library -- historically, we've seen a 1-5% error rate in these change sets that persists for months or years afterwards.
FWIW, Walter and I did a bunch of these for Py2.3 and had excellent success because of a good process. Some ideas are:
* start it now (don't wait until a beta release).
* skip the packages like email which are maintained separately
* think out ways it could go wrong (operator precedence, double backticks, escaped backticks, backticks inside strings or comments, etc.).
* do it manually (not brainlessly), then do it with automation to compare the results.
Here's an idea for verifying an automated translator: Instead of converting `expr` to repr(expr) convert it first to (`expr`) or even (`(expr)`) and make sure it still compiles into exactly the same bytecode. It should catch all the problem you mention except backticks in comments and strings. These need manual inspection. Oren
On Sunday 30 November 2003 03:44 pm, Oren Tirosh wrote:
Instead of converting `expr` to repr(expr) convert it first to (`expr`) or even (`(expr)`) and make sure it still compiles into exactly the same bytecode. It should catch all the problem you mention except backticks in comments and strings. These need manual inspection.
I don't know if it should be *that* mechanical; there are a lot of places where I've seen " 'something %s' % repr(foo)" when I think it's much more clearly written as " 'something %r' % foo". I don't know which is the officially preferred style, but if it's the latter (and I hope it is ;)) then it may not be good to mechanically change backticks to a repr call. Jeremy
I don't know if it should be *that* mechanical; there are a lot of places where I've seen " 'something %s' % repr(foo)" when I think it's much more clearly written as " 'something %r' % foo". I don't know which is the officially preferred style, but if it's the latter (and I hope it is ;)) then it may not be good to mechanically change backticks to a repr call.
If you're going to do that, I would beware of one thing. If x is a tuple, "foo %r" % x will not do the right thing: it will expect x to be a 1-tuple and produce the repr of x[0]:
a = (42,) print "foo %s" % repr(a) foo (42,) print "foo %r" % a foo 42 a = (4, 2) print "foo %r" % a Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: not all arguments converted during string formatting
This is only a problem when there's only one % format in the string; if there are two or more, the argument is already a tuple and the substitution of %s/repr(x) to %r/x works fine. This also suggests a solution: if there's only one argument, create an explicit tuple:
print "foo %r" % (a,) foo (4, 2)
--Guido van Rossum (home page: http://www.python.org/~guido/)
Raymond Hettinger wrote:
[...]
As always, be careful with doing peephole changes to the standard library -- historically, we've seen a 1-5% error rate in these change sets that persists for months or years afterwards.
FWIW, Walter and I did a bunch of these for Py2.3 and had excellent success because of a good process.
If you're willing to review the patch, I'm going to give it a try. Bye, Walter Dörwald
Raymond Hettinger wrote:
[...]
As always, be careful with doing peephole changes to the standard library -- historically, we've seen a 1-5% error rate in these change sets that persists for months or years afterwards.
FWIW, Walter and I did a bunch of these for Py2.3 and had excellent success because of a good process.
[Walter]
If you're willing to review the patch, I'm going to give it a try.
The honor of second review should go to Anthony ;-) This is his itch. If a third review is needed to make it error free, I would be happy to accommodate. Raymond
Raymond Hettinger wrote:
[...]
FWIW, Walter and I did a bunch of these for Py2.3 and had excellent success because of a good process.
[Walter]
If you're willing to review the patch, I'm going to give it a try.
The honor of second review should go to Anthony ;-) This is his itch. If a third review is needed to make it error free, I would be happy to accommodate.
OK, the patch is done (http://www.python.org/sf/852334) and assigned to Anthony. I couldn't upload the patch itself, as it's too big, so the patch can be found at http://styx.livinglogic.de/~walter/backticks2repr.txt Bye, Walter Dörwald
Yes, backticks will be gone in 3.0. But I expect there's no hope of getting rid of them earlier -- they've been used too much. I suspect
Then let's kill all use of backticks in the standard library. There's a lot of them.
Advisory from a micro-performance hawk: Backticks are faster than repr()
from timeit import Timer min(Timer('`x`', 'x=1').repeat(3)) 1.4857213496706265 min(Timer('repr(x)', 'x=1').repeat(3)) 1.7748914665012876
Raymond Hettinger
participants (6)
-
Anthony Baxter -
Guido van Rossum -
Jeremy Fincher -
Oren Tirosh -
Raymond Hettinger -
Walter Dörwald