Dealing with modules that don't expose type objects about typing HOT 6 CLOSED

My vote is for option 4. If the type object is still unavailable, falling back to Any is sadly the only option. Could we somehow use a decorator in a stub to inform the type checker that a class/function is a stub for a different name?

This looks like it's blocked on a decision what to do with protocols. @gvanrossum?

from typing.

More discussion here: https://github.com/JukkaL/typing/issues/18

from typing.

So we're not doing protocols this time around. Let's add a typing.re submodule that defines Match and Pattern, and also let's add a typing.io submodule for IO and its subclasses.

Separately, we should add re.Match and re.Pattern in 3.5 to the regular stdlib re module. But if you want to use them as generic types (e.g. Pattern[str] or Pattern[bytes]) you must import the types from typing.re.

from typing.

At least the following modules could also benefit from having typing.<module> submodules, since they contain classes that are generic in mypy stubs:

• asyncio
• collections
• urllib.parse
• weakref
• difflib (the stub is in a pull request)

There are most likely others that don't have any stubs yet. Maybe we should go through the standard library (or at least the most commonly used modules) and try to find additional examples of generic classes. Once the set of typing submodules is finalized in 3.5, I guess it's going to be difficult to add new ones for existing modules.

from typing.

At least for the duration of 3.5, this will be in provisional mode which means we can still make changes. (We do this for asyncio in 3.4 and it's great -- and nobody has complained so far.)

Also, adding new submodules (that have to be explicitly imported to be used) sounds like a fine thing to do at any point in the future. At some point it may be better to make the implementations themselves generic, so people can start using e.g. re.Pattern[str] rather than typing.re.Pattern[str]. But that may be a ways off and I propose not to do this for 3.5 (though authors of new 3.5 modules are welcome to use typing, as long as they use it correctly and run the checker).

One subtlety is, do we require import typing.re or should import typing implicitly import these submodules? (That could be expensive if there are many of them.) As a compromise, maybe have typing.re and typing.io pre-imported but require explicit import of all others? (There's a reason those have two-letter names. :-)

from typing.

Fixed in e2e6fc4.

from typing.