[Python-Dev] Re: [Python-checkins] python/dist/src/Python compile.c, 2.319, 2.320 (original) (raw)
David Abrahams dave at boost-consulting.com
Thu Aug 19 19:31:47 CEST 2004
- Previous message: [Python-Dev] Re: [Python-checkins] python/dist/src/Python compile.c, 2.319, 2.320
- Next message: [Python-Dev] Re: [Python-checkins] python/dist/src/Python compile.c, 2.319, 2.320
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Guido van Rossum <guido at python.org> writes:
> Hm, shouldn't the bytecode optimizer only be used when -O is used, and > hence pyo files are being written?
Why? That would throw away most of the benefits to most of the users and gain nothing in return. The peepholer was in place in for Py2.3 and only benefits were seen. I would save the -O option for something where there is a trade-off (loss of docstrings, excessive compilation time, possibly risky optimizations, or somesuch). Here, the peepholer is superfast and costs almost nothing. Maybe I'm out of tune, but I thought that optimizations should be turned off by default because most people don't need them and because of the risk that the optimizer might break something. Haven't there been situations in Python where one optimization or another was found to be unsafe after having been in use (in a release!) for a long time?
Isn't that a good argument for having them turned on all the time? The easiest way to ship code that suffers from an optimizer bug is to do all your development and most of your testing with unoptimized code.
In C/C++, there's a good reason to develop code unoptimized: it's much easier to debug. I'm not sure that applies to Python.
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com
- Previous message: [Python-Dev] Re: [Python-checkins] python/dist/src/Python compile.c, 2.319, 2.320
- Next message: [Python-Dev] Re: [Python-checkins] python/dist/src/Python compile.c, 2.319, 2.320
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]