On Sun, 3 Mar 2013 01:17:35 +1000 Nick Coghlan <ncoghlan at gmail.com> wrote: > > I'd go further and say we *should* move to that solution. > > Here's an interesting thought: for pure C modules without a Python > implementation, we can migrate to this architecture even *without* > creating pure Python equivalents. All we shou;d have to do is change > the test of the pure Python version to be that the module *can't be > imported* without the accelerator, rather than the parallel tests that > we normally implement when there's a pure Python alternative to the > accelerated version. (There would likely still be some mucking about > to ensure robust pickle compatibility, since that leaks implementation > details about exact module names if you're not careful) What benefit would this have? Current situation: each Python implementation has its own implementation of the zlib module (as a C module for CPython, etc.). New situation: all Python implementations share a single, mostly empty, zlib.py file. Each Python implementation has its own implementation of the _zlib module (as a C module for CPython, etc.) which is basically the same as the former zlib module. Regards Antoine.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4