Larry Hastings added the comment: I just realized, you're misunderstanding what the first line of the docstring is.
When you run help(function_written_in_Python), the first line of the help is the function's signature rendered in text. That's generated by "pydoc", which gets signature information from inspect. Now, it used to be that this didn't work for builtins. pydoc would look at the function, say "I can't get metadata for this function, I'll skip it". And it'd just print the builtin's docstring. Builtins worked around this problem by having their first line *look* like a Python signature. So the user kind of couldn't tell the difference. As part of adding Argument Clinic, I changed this. Now the first line of a docstring is a machine-readable representation of the signature of the function. Internally it gets split off from the docstring--you won't see it if you look at builtin.__doc__. Instead this first line is provided via a new property called __text_signature__. inspect.Signature supports builtins by parsing this string. As it happens, the format of the string happens to look exactly like a Python function definition. Because... it is! inspect.Signature parses the string by passing it in to ast.parse. "decompressobj([wbits], [zdict])" is not legal Python; if you gave that to ast.parse it would reject it. (I tried, with PEP 457, but so far nobody has been interested.) On the other hand, ast.parse is totally happy with "decompressobj(wbits=None, zdict=None)". ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20193> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
