On Sat, May 8, 2021 at 2:40 PM Jonathan Goble <jcgob...@gmail.com> wrote:
> On Sat, May 8, 2021 at 5:08 PM Pablo Galindo Salgado <pablog...@gmail.com> > wrote: > >> > Why not put in it -O instead? Then -O means lose asserts and lose >> fine-grained tracebacks, while -OO continues to also >> strip out doc strings. >> >> What if someone wants to keep asserts but do not want the extra data? >> > > What if I want to keep asserts and docstrings but don't want the extra > data? > > Or actually, consider this. I *need* to keep asserts (because rightly or > wrongly, I have a dependency, or my own code, that relies on them), but I > *don't* want docstrings (because they're huge and I don't want the overhead > in production), and I *don't* want the extra data in production either. > > Now what? > > I think what this illustrates is that the entire concept of optimizations > in Python needs a complete rethink. It's already fundamentally broken for > someone who wants to keep asserts but remove docstrings. Adding a third > layer to this is a perfect opportunity to reconsider the whole paradigm. > Reconsidering "the whole paradigm" is always possible, but is a much larger effort. It should not be something that blocks this enhancement from happening. We have discussed the -O mess before, on list and at summits and sprints. -OO and the __pycache__ and longer .pyc names and versioned names were among the results of that. But we opted not to try and make life even more complicated by expanding the test matrix of possible generated bytecode even larger. I'm getting off-topic here, and this should probably be a thread of its > own, but perhaps what we should introduce is a compiler directive, similar > to future statements but not that, that one can place at the top of a > source file to tell the compiler "this file depends on asserts, don't > optimize them out". Same for each thing that can be optimized that has a > runtime behavior effect, including docstrings. > This idea has merit. Worth keeping in mind for the future. But agreed, this goes beyond this threads topic so I'll leave it at that.
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PCZGEWFIPS2YPMJWTILVANJYT6VWS27B/ Code of Conduct: http://python.org/psf/codeofconduct/
