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 gvanrossum
Recipients docs@python, gvanrossum, phr, rhettinger, veky
Date 2019-10-02.22:13:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1570054380.69.0.49203887201.issue38333@roundup.psfhosted.org>
In-reply-to
Content
@phr

To be clear, I agree that there's nothing wrong with adding signatures to docs. We just need to find a way to do it. There will definitely be some cases where it's better not to have a type rather than trying to spell out the actual type in the docs.

My "unacceptable" comment was meant in response to Vedran's suggestion that it would be okay to lie in the docs about the signature for sum(). If the truth is too subtle to use a specific type signature we should keep the words. (The words for sum() are actually pretty clear.)

FWIW: My objection against vague docs was specifically about situations where the word "string" is used without clarifying if this allows bytes. I've also seen docs that were even more vague, e.g. "a name" or "a filename".

Signatures in the code won't "break" the code (they are ignored at runtime) but if present they should nevertheless be precise since they will be used by type checkers. Signatures in code are *not* just documentation. Only in very limited situations would I be okay with lies in signatures -- this would have to be done on a case by case basis.
History
Date User Action Args
2019-10-02 22:13:00gvanrossumsetrecipients: + gvanrossum, rhettinger, phr, docs@python, veky
2019-10-02 22:13:00gvanrossumsetmessageid: <1570054380.69.0.49203887201.issue38333@roundup.psfhosted.org>
2019-10-02 22:13:00gvanrossumlinkissue38333 messages
2019-10-02 22:13:00gvanrossumcreate