Jukka Lehtosalo

This could be somewhat useful feature, especially for retrofitting types to a legacy codebase. However, supporting anything beyond simple classes would be hard (see below). > TBH I don't see...

Sounds good. We should perhaps explicitly specify how module-level functions would work, since they don't take a `self` argument. Example: ```py # m.py def f(x: int) -> None: pass #...

Removed the "needs discussion" label since we would definitely want to have this. However, the design of the implementation will still need some discussion :-)

Agreed that the code is not super clear, as there is no explicit documentation about what the mixin expects. I probably wouldn't use this for new code -- it would...

There seem to be two things to fix: * Support negative integers as constants (or more generally, various integer operations involving constants expressions, such as addition and bitwise ops). *...

I like this plan! This will allow sharing much of the implementation between the three methods, and we should be able to ensure that they all perform in a similar...

In my opinion this is not something we should support even if it was technically possible. Type annotations are primarily for static checking, not for runtime purposes. Any runtime uses...

@saulshanabrook The typing-sig@ mailing list a focused on discussing improvements to Python static typing. However, I suspect that most of the existing subscribers are primarily interested in static approaches. Note...

I verified that the slow performance can be reproduced manually, but I couldn't find a regression. I.e., the performance is consistently poor, even with older commits. The benchmark may trigger...

Microbenchmarks (and even larger benchmarks) are prone to mysterious changes in performance when some seemingly unrelated thing is changed.