Stefan Richthofer

Thanks for spotting this. ``_auto_override_modules(mod_name)`` is supposed to be ``auto_override_module(mod_name)``. Regarding the possibly uninitialized ``None`` values, I believe that the code is actually okay, however it is non-trivial to be...

See https://github.com/Stewori/pytypes/commit/d5c08b036efa13ab198a6f2e859771df7ffc2780

Perfect. Then please feel free to add asserts as required.

I think the module case does return the module only to be consistent with its behavior in decorator case, where it always returns the input member. I agree it should...

This was closed automatically due to https://github.com/Stewori/pytypes/commit/95d58a30a8ddb665500d8e88b13a94e0e0f76373. However, that commit only adds annotations for `typechecker.py` not for the rest of `pytypes`. So, I'll reopen since this issue is only partially...

I think there's nothing wrong with adding remaining type info (in long term). Last but not least because it serves documentation purposes.

Note on the use case: Advertising this mainly for Python 3.4 feels somewhat disappointing or like an understatement at least. I think there are use cases for stubfiles way beyond...

> I thought C-extensions wouldn't be feasible to cross-check I think that should work based on inspection just like ordinary python modules, except that type annotations are *only* possible via...

Given that subclasses can be created any time, how could such a method query the set of possible subclasses? Would it query the subclasses currently defined in the runtime? Or...

Can you post some imaginary code examples how the method would behave, e.g. what result it should give based on which call. Ideally in a form that can easily be...