Should the Crypto stubs be for pycrypto or pycryptodome? #2952
Comments
|
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. |
|
Hello, I meet this problem with pycryptodome. Is there some workaround? |
|
@Hanaasagi we should probably just update our stubs to be for pycryptodome, PRs would be appreciated. |
|
I see pycryptodome already distributing it's own stub files in the pypi package. Is there some way to use the stub files? |
|
This is a good example of why we need the new typeshed structure... |
|
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. |
Crypto is a package that comes from pycrypto, which was last updated in 2013. It proudly supports Python 2.1 through 3.3. There's a near drop-in replacement from pycryptodome, which seems well maintained. pycryptodome has provided stubs for the last two years. I propose we get rid of the whole thing. pycrypto seems about as dead as software can get. These stubs have received two fixes since 2016. python#2952 https://pycryptodome.readthedocs.io/en/latest/src/vs_pycrypto.html https://github.com/Legrandin/pycryptodome/blob/master/Changelog.rst#371-25-november-2018
Crypto is a package that comes from pycrypto, which was last updated in 2013. It proudly supports Python 2.1 through 3.3. There's a near drop-in replacement from pycryptodome, which seems well maintained. pycryptodome has provided stubs for the last two years. I propose we get rid of the whole thing. pycrypto seems about as dead as software can get. These stubs have received two fixes since 2016. python#2952 https://pycryptodome.readthedocs.io/en/latest/src/vs_pycrypto.html https://github.com/Legrandin/pycryptodome/blob/master/Changelog.rst#371-25-november-2018
Crypto is a package that comes from pycrypto, which was last updated in 2013. It proudly supports Python 2.1 through 3.3. There's a near drop-in replacement from pycryptodome, which seems well maintained. pycryptodome has provided stubs for the last two years. I propose we get rid of the whole thing. pycrypto seems about as dead as software can get. These stubs have received two fixes since 2016. #2952 https://pycryptodome.readthedocs.io/en/latest/src/vs_pycrypto.html https://github.com/Legrandin/pycryptodome/blob/master/Changelog.rst#371-25-november-2018 Co-authored-by: hauntsaninja <>
|
Resolved by #4606 |
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.
The text was updated successfully, but these errors were encountered: