Modernizing the codebase after Python 2

Looking forward into the post-Python-2-support world (i.e. post pip 20.3), we’re going to want to modernize pip’s codebase. That’s going to involve a lot of things.

Consider this issue an attempt to try to create a singular location, to create the list of all of the things we’d want to free from the chains of maintaining Python 2 support. 😃

• Cleanup the mypy configuration.
• Enum usage.
• Drop __ne__ when not needed.
• Drop Python-2 compatibility-related vendored modules.

[obi1kenobi]

While looking into the “cleaning up the mypy config” task mentioned here, I happened to come across an issue with how mypy is being used, so I opened #9502. In particular, I found that issue by attempting to improve the mypy config via typing_copilot: https://github.com/obi1kenobi/typing-copilot

It is a tool designed to help projects gradually move toward strict mypy compliance: it auto-detects the strictest passing mypy config for the current state of the codebase, and can then set up a “ratcheting” mechanism for type correctness where type quality can only improve in the future. With typing_copilot, you can set up a CI check enforcing that any time the mypy configuration can be made stricter, it is done so — tightening the ratchet whenever possible.

I am the maintainer of typing_copilot, and while it is a relatively young tool, it is already being used across more than 100kLOC of Python across a few projects. While supporting pip’s vendorized dependencies would require some additional configuration functionality in typing_copilot, I’d be happy to add that functionality if it would be useful to the pip project or other core Python ecosystem tools.

I’d also be happy to help improve the mypy config used in pip, including helping resolve #9502 itself.

Thanks for all your hard work building and maintaining pip!

[pradyunsg]

That’s in-progress. 😃

https://github.com/pypa/pip/pulls?q=is%3Apr+sort%3Aupdated-desc+complete+type+annotations