In article <4b3b498a-c9b0-443d-8514-87ccd8e98...@googlegroups.com>,
rantingrickjohn...@gmail.com says...
>
> (Example modified for PEP8 compliance ;-)
>
> @typehint(arg1:str, arg2:int, returns:bool)
> def myfunction(arg1, arg2):
> return True
>
> Of course "@typehint" could be an extension of the decorator
> syntax, a keyword, a build-in function or whatever, i don't
> care.
I'd rather it'd be a docstring parameter.
- Decorators are transformation tools. Which type hints are not.
- keywords should be few and used only for language features. Static
analysis isn't and should never be a language feature. It's an
extension, perhaps.
- Same with built-in functions... although a case could be made for a
static analysis package, hmmm.
So I'd rather see:
def myfunction(arg1, arg2):
"""
Normal docstring.
"""
"@typehint: (str, int) -> bool"
return True
This conforms to PEP 258, but not to PEP 8, but you can always use the
triple quotes. I would just use the single-quote myself for matters of
taste.
I removed the arguments names on purpose. They are only necessary on the
PEP because type hinting is a part of the function header there.
However, when using a documentation like pattern as above (or as in your
own example), they can be safely removed, with the added benefit of
making the syntax simpler.
Alternatively, because dangling strings are always considered
documentation and completely ignored by the interpreter (PEP 258), one
could also do:
"@typehint: (str, int) -> bool"
def myfunction(arg1, arg2):
"""
Normal docstring.
"""
return True
Again the choice of triple quotes or not is something not worth
debating.
--
https://mail.python.org/mailman/listinfo/python-list
