Repository navigation
Support partial/incomplete stubs #5
Description
Maybe we should have a way of specifying a stub as (potentially) incomplete for libraries that are changing rapidly and there is no dedicated maintainer for the stub. In cases like this a type checker / inferencer would either treat all names as implicitly defined in the module (with type Any), or it could parse the actual main Python implementation and merge the annotations from the stubs to the full module AST.
Activity
gvanrossum commentedon Jan 26, 2016
Hm. Do you mind if I close this? It feels kind of over-complicated. In practice people seem to be okay with contributing a PR to the stubs when they run into this.
matthiaskramm commentedon Feb 11, 2016
It's useful to be able to say "this module exists" without actually having to describe in detail what it contains. pytype uses it to describe inference results for things that aren't in typeshed and can't be autogenerated (like C extensions) without having them cause an import error.
pytype is going to use
on the pyi module level. Does that sound like a reasonable way to express this, and is that something we should allow in typeshed?
gvanrossum commentedon Feb 11, 2016
That's a unique thing at the toplevel (though people have asked for it before so they can overload module attributes) but it's syntactically nothing new, so I'm fine with it. Can you propose a sentence to add to PEP 484 about this? Or do you think it can be left out of there and just be a pytype/mypy extension to the PEP? (Well I guess it would be nice if PyCharm also understood it.)
Add bullet point about module-level __getattr__.
Add bullet point about module-level __getattr__.
JelleZijlstra commentedon May 11, 2018
PEP 484 now specifies module-level
__getattr__and mypy supports it, so this can be closed.Merge pull request python#5 from cocoatomo/update-master-2