Yeah, for really old (<2.6) backports like multiprocessing, hashlib, etc., that see ≈<100,000 monthly downloads, the calculus above changes and yanking all releases (like @gpshead did) is probably the way to go (and is strictly superior to deleting, as discussed above), as the breakage is less, the benefit is more, and it’s the easiest option to implement (just click a button). (Newer or more widely used backports will need more thought, though, per the analysis above.)
2 Likes
Right. Um. Yeah. So it seems that I had, indeed, misunderstood the intent of specifying the Python version to mypy. I thought it was more like “…but bear in mind that this version of Python might also need to run that code, so do complain if I use newer features”, and now that I think about it, this kind of contradicts the other thing I thought mypy should do: “…but please also use the newer features of the currently-running version” 
So yeah, thanks for pointing this out. In the past two weeks since you wrote that I have already started dropping the python_version option from the mypy invocations in some of my projects, so, yeah. Thanks, and sorry for the noise. It seems that this is indeed not a valid concern WRT the actual topic.
G’luck,
Peter