Type hinting parameters of standard library functions
I was thinking of working on a tool which interacts with Astroid's type inference capabilities. It would either get the type hints of parameters through function annotations or from @param tags in docstrings. This would help create warnings where the parameter or something which uses it is being used in an unexpected way, inconsistent with documentation. I was wondering if there is any machine-readable information about what types functions in the standard library expect? For example, PyCharm seems to know that os.path.split cannot return a tuple of three values, so x, y, z = os.path.split("a/path/here") causes the IDE warning "needs more values to unpack". When I jump to the documentation it's described like this: def split(p) Inferred type: (p: one of (str, unicode)) -> (one of (str, unicode, unknown),one of (str, unicode, unknown)) Split a pathname. Returns tuple "(head, tail)" where "tail" is everything after the final slash. Either part may be empty. Did JetBrains (who make PyCharm) gather this information themselves, or is this kind of thing publicly available somewhere? Thanks for your help, -George
Hi George,
def split(p) Inferred type: (p: one of (str, unicode)) -> (one of (str, unicode, unknown),one of (str, unicode, unknown)) Split a pathname. Returns tuple "(head, tail)" where "tail" is everything after the final slash. Either part may be empty.
Did JetBrains (who make PyCharm) gather this information themselves, or is this kind of thing publicly available somewhere?
I'm a developer of PyCharm. We've created a type database for some parts of the standard library manually based on the docs. As for now, its format is an implementation detail of PyCharm, but we have some plans making it available and extendable for other people and tools. We also interested in efforts regarding the standardization of type annotations. We'll announce our plans later on, stay tuned. -- Andrey Vlasovskikh Senior Software Developer JetBrains, Inc. http://www.jetbrains.com/ "Develop with pleasure!"
On 03 août 20:12, Andrey Vlasovskikh wrote:
Hi George,
def split(p) Inferred type: (p: one of (str, unicode)) -> (one of (str, unicode, unknown),one of (str, unicode, unknown)) Split a pathname. Returns tuple "(head, tail)" where "tail" is everything after the final slash. Either part may be empty.
Did JetBrains (who make PyCharm) gather this information themselves, or is this kind of thing publicly available somewhere?
I'm a developer of PyCharm. We've created a type database for some parts of the standard library manually based on the docs. As for now, its format is an implementation detail of PyCharm, but we have some plans making it available and extendable for other people and tools. We also interested in efforts regarding the standardization of type annotations. We'll announce our plans later on, stay tuned.
Sounds like such a library, as we're targeting with astroid, would be of interest for a lot of people and would allow great gain to python code-quality tool. Would you be interested in attempting to share efforts? Anyway I can't wait to read more on this. -- Sylvain Thénault, LOGILAB, Paris (01.45.32.03.12) - Toulouse (05.62.17.16.42) Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services CubicWeb, the semantic web framework: http://www.cubicweb.org
Sylvain,
I'm a developer of PyCharm. We've created a type database for some parts of the standard library manually based on the docs. As for now, its format is an implementation detail of PyCharm, but we have some plans making it available and extendable for other people and tools. We also interested in efforts regarding the standardization of type annotations. We'll announce our plans later on, stay tuned.
Sounds like such a library, as we're targeting with astroid, would be of interest for a lot of people and would allow great gain to python code-quality tool. Would you be interested in attempting to share efforts? Anyway I can't wait to read more on this.
I've seen your pylint-brain repo, where you use an imperative approach for creating static equivalents of dynamic objects. In PyCharm we also use a similar approach, but we are interested in a more declarative database of static skeletons of dynamic objects (Python code + type annotations) that could be useful for various tools. As I've mentioned above, we will publish more info and our ideas regarding possible collaboration on this subject later on. -- Andrey Vlasovskikh Senior Software Developer JetBrains, Inc. http://www.jetbrains.com/ "Develop with pleasure!"
participants (3)
-
Andrey Vlasovskikh -
George Schneeloch -
Sylvain Thénault