On Fri, Mar 6, 2015 at 2:09 PM Benjamin Peterson <benja...@python.org> wrote:
> > > On Fri, Mar 6, 2015, at 13:34, Brett Cannon wrote: > > On Fri, Mar 6, 2015 at 1:27 PM Neil Girdhar <mistersh...@gmail.com> > > wrote: > > > > > On Fri, Mar 6, 2015 at 1:11 PM, Brett Cannon <br...@python.org> wrote: > > > > > >> > > >> > > >> On Fri, Mar 6, 2015 at 1:03 PM Mark Shannon <m...@hotpy.org> wrote: > > >> > > >>> > > >>> On 06/03/15 16:34, Brett Cannon wrote: > > >>> > Over on the import-sig I proposed eliminating the concept of .pyo > files > > >>> > since they only signify that /some/ optimization took place, not > > >>> > /what/ optimizations took place. Everyone on the SIG was positive > with > > >>> > the idea so I wrote a PEP, got positive feedback from the SIG > again, > > >>> and > > >>> > so now I present to you PEP 488 for discussion. > > >>> > > > >>> [snip] > > >>> > > >>> Historically -O and -OO have been the antithesis of optimisation, > they > > >>> change the behaviour of the program with no noticeable effect on > > >>> performance. > > >>> If a change is to be made, why not just drop .pyo files and be done > with > > >>> it? > > >>> > > >> > > >> I disagree with your premise that .pyo files don't have a noticeable > > >> effect on performance. If you don't use asserts a lot then there is no > > >> effect, but if you use them heavily or have them perform expensive > > >> calculations then there is an impact. And the dropping of docstrings > does > > >> have an impact on memory usage when you use Python at scale. > > >> > > >> You're also assuming that we will never develop an AST optimizer that > > >> will go beyond what the peepholer can do based on raw bytecode, or > > >> something that involves a bit of calculation and thus something you > > >> wouldn't want to do at startup. > > >> > > > > > > I don't want to speak for him, but you're going to get the best results > > > optimizing ASTs at runtime, which is what I thought he was suggesting. > > > Trying to optimize Python at compile time is setting your sights really > > > low. You have so little information then. > > > > > > > OK, I don't want to derail the discussion of the PEP into one over how > > best > > to optimize CPython's performance relative to bytecode vs. runtime like > > PyPy. The point is that we have -O and -OO and people do have uses for > > those flags. People can also do custom optimizations thanks to the > > flexibility of loaders. > > I think it would be preferable deprecate -O and -OO and replace them > with flags like --no-docstrings or --no-asserts. Ideally, "optimization" > levels shouldn't change program semantics. > OK, but that doesn't influence the PEP's goal of dropping .pyo files. Are you suggesting that the tag be changed to be less specific to optimizations and more free-form? Like `importlib.cpython-35.__no-asserts_no-docstrings__.pyc`? Otherwise stuff like this gets baked into the .pyc file itself instead of the file name, but I don't think we should just drop the ability to switch off asserts and docstrings like Mark seemed to be suggesting.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
