On Tue, Jun 19, 2018 at 12:57 AM, Schachner, Joseph <joseph.schach...@teledyne.com> wrote: > Assuming that we want Python to remain a dynamically typed (but strongly > typed) language, I believe the proposed type hints are only necessary for > function definitions, where the caller really needs to know the types of > arguments to pass in. At the moment that purpose is (I think adequately) > served by def strings, triple quoted strings immediately following the > function declaration. When I do code reviews for Python developed here, if > the argument names of a function do not hint at the type they should be and > there is no def string then I insist that something be added. Often what > gets added is a def string that says something about what the function does > and explains what argument types are expected. >
(The official term is "docstring", and you can find some specifics on them in PEP 257.) What you're doing is all very well, but it isn't very machine-readable. Type hints as defined in PEP 3107 and 484 are designed to be understood by linters and autocompletion tools and the like. And once you have the machine-readable, you should be able to leave off any type information in the purely-human-readable parts of documentation. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
