[Python-Dev] Decision on the docstring hack (was Re: The docstring hack for signature information has to go)
Larry Hastings
larry at hastings.org
Wed Feb 5 04:20:21 CET 2014
In the absence of a ruling from above I'm making a decision. I say we
keep the docstring hack, but go back to the human-readable version, only
this time with a *much* stricter signature. That should reduce the
number of false positives to zero.
Furthermore, I say we don't add any flags--adding a flag to the callable
would mean doing it three different ways, and adding a flag to the type
might not work in all cases.
And finally, I agree with Nick, that publishing signatures shall not be
a supported API for Python 3.4. If external modules publish signatures,
and we break their support in 3.5, it's on them.
The rules enforced on the signature will be as per Georg's suggestion
but made slightly more stringent:
The signature must start with "<name-of-function>(".
The signature must end with ")\n--\n\n".
The signature may contain newlines, but must not contain empty lines.
The signature may have non-Python syntax in it, such as "$"
indicating a self parameter, "/" to indicate positional-only
parameters, and "[" and "]" to indicate optional groups (though I
don't expect 3.4 will ship with support for this last one).
Here it is in non-working pseudo-code:
s = function.docstring
if not s.startswith(function.name + "(")
return failure
end = s.find(")\n--\n\n")
if end < 0:
return failure
newline = s.find("n\n")
if newline > 0 and newline < end:
return failure
return success
(The actual implementation will be in C, in find_signature in
Objects/typeobject.c.)
Expect a patch in about 24 hours,
//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140204/46f4a5c7/attachment.html>
More information about the Python-Dev
mailing list