On Sat, Mar 2, 2013 at 10:28 AM, Antoine Pitrou <solip...@pitrou.net> wrote:
> On Sun, 3 Mar 2013 01:17:35 +1000 > Nick Coghlan <ncogh...@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. > Bare minimum? They all share the same module docstring. But it could be extended to explicitly import only the public API into zlib.py, helping to prevent leaking interpreter-specific APIs by accident (obviously would still be available off of _zlib if people wanted them).
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
