New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Find out what stdlib modules lack a pure Python implementation #60855
Comments
I'm wondering which modules in the stdlib lack pure Python implementations (and could legitimately have one, e.g. sqlite can't really have a pure Python implementation). Once we know how big/small the list is a decision could be made as to whether to take on the effort to bring over some pure Python version from another VM or something for any of these modules. To start the list: csv |
array zlib, bz2, lzma and crypts also can be implemented in pure Python. |
hashlib backends (md5, sha1, sha256 / 384 / 512) either through openssl wrappers or implementations based on libtomcrypt. |
Would it make sense for this list to be somehow reflected in or be reconstructible from the documentation? |
So expat doesn't count as that literally wraps the expat library. Random also requires accessing the system randomization libraries to work properly so I don't think that is a candidate either. As for the compression libraries, those could be re-implemented, but I view those as wrappers around the libraries (same as the crypto stuff). I mean it doesn't have to be that way, but I'm trying to keep this framed in a tractable problem to start. So to summarize the non-contentious modules (including adding functools) in alphabetical order, that puts us at: array I would be curious to see what frequency these modules are used to know what might be higher priority so that the least used modules could eventually be marked as CPython-specific. And to answer Chris' question, there is no need to be able to generate this from the docs until there is some PEP listing what modules must be implemented by a VM in order to considers its stdlib complete. And thanks for the help so far, everyone! |
PyPy has a pure Python implementation of sqlite (using ctypes): It most probably works on CPython as well. |
All cryptographic hash function are available as pure Python implementations. Although the Python based variants are super slow (except maybe on PyPy), they still serve as an academic show case. IIRC PyPy has pure Python implementations of MD5, SHA-1 and SHA-2 family. |
No, sqlite does not belong on this list as it wraps a C library. Plus there is an explicit block for ctypes-based modules in the stdlib which would prevent moving over the PyPy implementation. And I'm sure pure Python versions of all the crypto libraries are out there, but I would be worried about them being implemented wrong, too slow to care, etc. Plus short of PyPy all of the other VMs have access to those crypto libraries in their own standard library so there is no need to provide it in Python's in pure Python. |
Agreed with Brett. |
zipimport |
winreg does not have a pure equivalent, nor could it |
XML parser can be implemented in pure Python. There are a lot of XML parsers
No, random have C implemented some basic methods only for speed. It uses Some OS-specific modules (pwd, grp, spwd, resource, ossaudiodev, etc) can be |
Sure, a general XML parsing library could be written in Python, but they wouldn't be named expat. =) The expat module wraps a specific XML parser (expat) so I still do not consider it applicable for this list. As for random, you are right that it doesn't use platform-specific random code. |
A lot of builtins :) |
What's the purpose of these alternate implementations? For education, experiments? As a replacement for other VMs? Other modules that could be considered: |
Alex: yes, the builtins could almost all be re-implemented in pure Python, but there is a performance consideration vs. benefit (e.g. if we re-implemented map() in Python which VMs would use it vs. implement it in some native way for performance?). But one place I think there could be a benefit w/o performance issues is the built-in exceptions as you should be able to store references to the classes to help minimize the added cost of startup creating the exceptions from Python code. Amaury: other VMs and easier extensibility in the future. We might as well all share the burden of maintaining pure Python versions instead of re-implementing the same thing over and over in little VM silos. And if some new thing needs to be added for a module it's easier to do it in Python than C (which then also continues to benefit other VMs). |
Should itertools be in the list, as its stated purpose is to provide highly efficient functions? |
Eric, I know you didn't just mean to suggest Python != efficient. =) Yes, it should be in the list because other VMs might not want to re-implement that code in some native language to the VM. And I assume all code in the stdlib tries to be efficient, so that label holds no sway with me. |
itertools should be fairly easy as the docs already contain Python equivalents (or near equivalents). |
PyPy had a pure python itertools until recently (it's been deleted): https://bitbucket.org/pypy/pypy/src/c1aa74c06e86/lib_pypy/itertools.py?at=py3k |
Oops, sorry I slipped :) |
I'm involved in both issues and I think it's good to have so much simple Python implementations as possible and to have C accelerators for any performance critical code. |
One thing I should say about this list of modules is please don't go nuts porting every single module blindly. There is always a possibility that another VM has already ported the code and has simply not contributed it back and so there is no need to write it from scratch and more just political wrangling to get contributions pushed upstream from other VMs. There might also be reasons to not worry about porting something. Always start a conversation first before starting a port; last thing I want is someone putting in the time to port some code that no one will necessarily use for a while. |
There is one additional benefit. I have already implemented audioop module in Python, and due to this it has found many bugs in the current C implementation (bpo-16686). |
Also missing a pure-Python implementation: collections.defaultdict (relatively trivial) In the spirit of what Brett said, I found that PyPy has an implementation already: https://bitbucket.org/pypy/pypy/src/default/lib_pypy/_collections.py Jython and IronPython do not have pure Python implentations: |
I don't think itertools or collections.deque should go on this list. The other implementations already have these and a pure python versions miss the point of these being high performance tools. AFAICT, there is zero benefit to adding a bunch of extra code that will never get used. It will only complicate my maintenance of those modules. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: