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
--
http://mail.python.org/mailman/listinfo/python-list
