Traceback: "ValueError: Unresolved class: 'False'" about pytype HOT 7 CLOSED

I can't reproduce this. Are you using a custom typeshed?

In any case, it looks like it's stumbling over a module-level or class-level constant in typeshed, that's declared as

  x = False

instead of

  x = ...  # type: bool

.

I'll tweak my parser to allow this, unless we decide that we want to discourage this kind of shortcut.

(The backtrace might also be due to default parameters declared as x:bool = False instead of x:bool = .... I'm in the process of fixing those in typeshed)

from pytype.

The typeshed module is exactly as determined by 'git submodule update' in
pytype.

My code uses import time and typeshed/stdlib/2.7/time.pyi has this line:

accept2dyear = False

But replacing that with

accept2dyear = ... # type: bool

doesn't make a difference.

There are also several occurrences of ": bool = False" in typeshed.

I hope you can make your parser more lenient -- stubs are basically allowed
to contain arbitrary Python code. The common idioms are merely recommended
by the PEP.

(If you want to make the stub syntax significantly smaller we should
probably draw up a spec and rubber-stamp it as a PEP.)

from pytype.

Yeah, it's odd this doesn't happen on my machine! But since the root cause is identified, maybe it doesn't matter.

With regards to the syntax of optional parameters, I'm mostly concerned with a consistent coding style in typeshed. (Although I have to admit that I do miss the orthogonality of pytypedecl's pytd. In comparison, pyi feels like the wild west)

Long term, I want to load .pyi in pytype the same way as .py: Compile to bytecode and then interpret, with some preprocessing to get the type comments in there, too.

from pytype.

from pytype.

I have a fix. It's in (our internal) code review.

from pytype.

Fix pushed.

(Also, the reason I couldn't reproduce this on my machine is because I had TYPESHED_HOME in my environment. D'oh!)

from pytype.

from pytype.