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. 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 would be minimally disruptive since we can then stay at only two optimization levels and put column info at whichever level we feel makes sense, but (provided the compiler directives are used properly) information a particular file requires to function correctly will never be removed from that file even if the process-wide optimization level calls for it. I see no reason code with asserts in one file and optimized code without asserts in another file can't interact, and no reason code with docstrings and optimized code without docstrings can't interact. Soft keywords would make this compiler directive much easier, as it doesn't have to be shoehorned into the import syntax (to suggest a bikeshed color, perhaps "retain asserts, docstrings"?)
_______________________________________________ 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/QV7LVUKWC72XA23NBZMFA573V7HPU72Y/ Code of Conduct: http://python.org/psf/codeofconduct/
