Brett Cannon <br...@python.org> wrote: > Since they do not typically support the entire `C API of Python`_ they > are unable to use the code used to create the module. Often times this > leads these other VMs to either re-implement the modules in pure > Python or in the programming language used to implement the VM > (e.g., in C# for IronPython). This duplication of effort between > CPython, PyPy, Jython, and IronPython is extremely unfortunate as > implementing a module *at least* in pure Python would help mitigate > this duplicate effort. > > The purpose of this PEP is to minimize this duplicate effort by > mandating that all new modules added to Python's standard library > *must* have a pure Python implementation _unless_ special dispensation > is given. This makes sure that a module in the stdlib is available to > all VMs and not just to CPython (pre-existing modules that do not meet > this requirement are exempt, although there is nothing preventing > someone from adding in a pure Python implementation retroactively).
I'm not sure that I understand the duplication of effort: If there is a C module without a Python implementation in the stdlib, then the PyPy, Jython, and IronPython developers are free to cooperate and implement a single Python version. I would not consider this a duplication of effort. If, on the other hand, they choose to provide three individual implementations in C#, Java and (?), then that is their own choice and surely not the fault of the C module developer. By contrast, this PEP puts a great burden on the developers of new C modules. If this PEP is accepted, it is the C module developers who will have to do duplicate work. In my view, the PEP should have a clause that *active* participation of PyPy, Jython, and IronPython developers is expected if they want pure compatible Python versions to exist. > Re-implementing parts (or all) of a module in C (in the case > of CPython) is still allowed for performance reasons, but any such > accelerated code must pass the same test suite (sans VM- or C-specific > tests) to verify semantics and prevent divergence. To accomplish this, > the test suite for the module must have 100% branch coverage of the > pure Python implementation before the acceleration code may be added. Raymond has pointed out that the PEP seems to discourage C modules. This is one of the examples. Since implementing C modules takes a lot of time, I'd appreciate to know if they are just tolerated or actually welcome. > As an example, to write tests which exercise both the pure Python and > C accelerated versions of a module, a basic idiom can be followed:: [cut] > > heap = Spam() > self.assertFalse(isinstance(heap, > collections.abc.MutableSequence)) > with self.assertRaises(TypeError): > self.heapq.heappop(heap) If all possible exceptions must match, then in the case of decimal the PEP should give permission to change the published API of an existing Python module (in this case decimal.py). Otherwise, I see no way of accomplishing this goal. It is possible to give many frivolous examples: >>> from decimal import * >>> >>> class C(): ... def __init__(self): ... self.traps = 'invalid' ... >>> # No exception ... setcontext(C()) >>> >>> from cdecimal import * >>> class C(): ... def __init__(self): ... self.traps = 'invalid' ... >>> setcontext(C()) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: argument must be a context. >>> In the case of duck typing, the only solution I see is to lock down the types in decimal.py, thus changing the API. This is one of the things that should be decided *before* the PEP is accepted. Stefan Krah _______________________________________________ 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
