Docstrings and PEP 3174

[Steven D'Aprano]

On Sat, 31 Jul 2010 19:52:05 -0700, Carl Banks wrote:

> PEP 3174 got me to thinking.
> 
> There is now a subdirectory to deposit as many *.pyc files as you want
> without cluttering the source directory (never mind the default case). 
> Which means you can pretty much write files with impunity.
> 
> So I was wondering: what about a separate file just for docstrings.

I'm not sure I understand what you mean by that? Do you mean that, when 
writing code for a function, you would open a second file for the 
docstring? If so, a big -INFINITY from me. The biggest advantage of 
docstrings is that the documentation is *right there* with the function 
when reading/writing code. If you're suggesting we should write them in 
another file, no thank you.

If you mean a runtime optimization with no change to the source file, 
then maybe, tell me more. What I *think* you mean is that the coder would 
write:

def spam(*args):
    "docs go here"
    pass

as normal, but when it is compiled and loaded into memory, the docstring 
itself was *not* loaded until needed.

If so, then I think you'd need to demonstrate significant practical 
benefit to make up for the complexity. I imagine Python-Dev will be very 
dubious.


> __doc__ would become a descriptor that loads the docstring from the file
> whenever it is referenced.

"The file" being the source file, or a separate docstring file, or a 
temporary file generated by the compiler, or... ?


> The vast majority of the time docstrings
> just take up memory and do nothing, so why not lazy load those things?

A guarded and provisional +0 on that. +1 if you can demonstrate real 
performance (memory or speed) gains.



-- 
Steven