This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author methane
Recipients Guido.van.Rossum, gvanrossum, iritkatriel, methane, rhettinger, serhiy.storchaka, terry.reedy
Date 2021-09-04.00:52:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1630716722.13.0.707445591704.issue36521@roundup.psfhosted.org>
In-reply-to
Content
> I am still not convinced that it's a good idea to put the docstring in the surrounding code object. I'd like to be able to see it when I introspect a code object, not just when introspecting a function object (I may be analyzing code only, and it's hard to connect the code object with the NEW_FUNCTION opcode in the parent code object -- you have to scan the bytecode, which is fragile.)

I think that reasoning is not strong enough to add new member to code object.

* Modules and classes don't get docstring from their code objects. Why only functions need to store docstring?
* Lambdas, comprehensions, and PEP 649 (if acceptted) uses code objects but no docstring. Why they need to pay cost of `co_doc` member? (cost = memory + unmarshal time).

Code objects have filename and firstlineno. And there are many functions without docstring. So removing docstring from code object won't make inspection hard so much.
History
Date User Action Args
2021-09-04 00:52:02methanesetrecipients: + methane, gvanrossum, rhettinger, terry.reedy, serhiy.storchaka, Guido.van.Rossum, iritkatriel
2021-09-04 00:52:02methanesetmessageid: <1630716722.13.0.707445591704.issue36521@roundup.psfhosted.org>
2021-09-04 00:52:02methanelinkissue36521 messages
2021-09-04 00:52:01methanecreate