There are libraries out there like this: https://docopt.readthedocs.io/en/0.2.0/
which use docstrings for runtime info. Today we already have -OO which allows us to create docstring-less bytecode files in case we have, after careful consideration, established that it is safe to do so. I think the current way (-OO) to avoid docstring loading is the correct one. It pushes the responsibility on whoever did the packaging to decide if -OO is appropriate. The ability to remove the docstrings after bytecode generation would be kinda nice (similar to Unix "strip" command) but given how fast bytecode compilation is, frankly I don't think it is very important. Stephan 2018-04-10 19:54 GMT+02:00 Zachary Ware <zachary.ware+py...@gmail.com>: > On Tue, Apr 10, 2018 at 12:38 PM, Chris Angelico <ros...@gmail.com> wrote: > > A deployed Python distribution generally has .pyc files for all of the > > standard library. I don't think people want to lose the ability to > > call help(), and unless I'm misunderstanding, that requires > > docstrings. So this will mean twice as many files and twice as many > > file-open calls to import from the standard library. What will be the > > impact on startup time? > > What about instead of separate files turning the single file into a > pseudo-zip file containing all of the proposed files, and provide a > simple tool for removing whatever parts you don't want? > > -- > Zach > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
