Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Remove a same-variable-name class hierarchy #1092
pypa/pip#4545 is an attempt to add mypy type-checking to pip. In that PR, the vendored version of
This patch is really a workaround for mypy's crashing behaviour; as can be seen in https://travis-ci.org/pypa/pip/jobs/243330633#L120.
It would be nice if pip's vendoring task wouldn't have to do such a thing, given the triviality of this change.
referenced this pull request
Jul 26, 2017
My initial instinct is that Setuptools shouldn't be adopting a workaround for a defect in another system without a clear acknowledgement that it's a workaround. I don't yet understand how the current implementation is deficient or how changing it fixes things. Can you provide a distilled, minimal example of why the current behavior is problemmatic? I tried using _get_mro with mypy installed and I had no problems:
But I can't tell from the mypy docs how to activate it or use it.
I do think that the change you're proposing here looks sound. I'd just like to have an understanding why it's superior before accepting it.
Running mypy with
mypy thinks there's a cycle in the class hierarchy, at the class definition line (that has been changed in this PR) since the new class refers to the old class and has the same name. By changing the name of the new class, this issue is worked around.
I felt that this change was too trivial to deserve a comment in the sources.
If you still want one after the previous post, I'll happily look into make a reproducible example. :)
That's not how to trigger this. mypy refusing to check types on anything that refers to pkg_resources through an import - because it detects a cycle in the class hierarchy.
Here's running mypy on a file importing pkg_resources:
I do see an error when running against pkg_resources package itself.