Should the Crypto stubs be for pycrypto or pycryptodome?

[JelleZijlstra]

We currently have a set of stubs in third_party/2and3/Crypto for a library called pycrypto However, pycrypto was apparently abandoned (the last release was in 2013), and a new library called pycryptodome replaces it. This library also uses the "Crypto" name when imported. It started as a fork but has added new features since then.

Should we update the stubs to cover pycryptodome instead of pycrypto?

I'm not sure how widely used pycryptodome is. I ran into this because I was trying to typecheck some code using "Crypto" that turned out to be using pycryptodome, not pycrypto.

[srittau]

A bit off-topic for this issue, but when we implement #2491 (third-party stubs as packages) we should support multiple distributions providing the same packages.

pycryptodome looks to be well maintained and describes itself as a near-drop-in, so replacing it looks like a good idea to me.

[Hanaasagi]

Hello, I meet this problem with pycryptodome. Is there some workaround?

[JelleZijlstra]

@Hanaasagi we should probably just update our stubs to be for pycryptodome, PRs would be appreciated.

[Hanaasagi]

I see pycryptodome already distributing it's own stub files in the pypi package. Is there some way to use the stub files?

[gvanrossum]

This is a good example of why we need the new typeshed structure...

[JelleZijlstra]

Following PEP 561, the stubs in the package should supersede the ones in typeshed already (https://www.python.org/dev/peps/pep-0561/#type-checker-module-resolution-order). So if pycryptodome properly includes a py.typed file, the typeshed stubs should already be ignored.

[hauntsaninja]

Resolved by #4606