Jukka Lehtosalo
Jukka Lehtosalo
Another option is to reject the use of `Number` etc. as types (and maybe give a link to documentation that explains why this isn't supported and what to do instead).
> but if the typeshed attempt will work out are there any reasons not to do this? I'm wondering if the types will be useful for their intended purpose. If...
> Doesn't seem like this will ever get fixed. Can you at least add a note to the user doc somewhere? Perhaps somebody would like to contribute an item about...
I've seen this come up once in a while. These would primarily be useful for annotating legacy interfaces. Some observations: * We'd need at least two separate types for these...
I agree that something like `downcast()` would be quite useful. I remember discussing similar ideas before, but the discussions never went anywhere. One issue with the proposed semantics would be...
@SemMulder Since we still don't have a consensus of how the feature would behave exactly, the easiest way to move forward might be to add it to `mypy_extensions` (https://github.com/python/mypy_extensions) and...
> Maybe a good way to go about this is to start replacing argument types in typeshed with custom protocols in the respective modules (marked private so they do not...
This may be related to #718.
> Should that be opened as a separate bug? This is a good idea, since this looks quite different (exception within mypyc, not in compiled code).
Sorry, this is not going to be implemented any time soon. If you want to be able to do effective type checking, I'm afraid you'll have to rethink your design...