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+pydev@gmail.com>:

On Tue, Apr 10, 2018 at 12:38 PM, Chris Angelico <rosuav@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/