On Tue, 19 Apr 2011 10:37:41 -0400 "R. David Murray" <rdmurray at bitdance.com> wrote: > On Tue, 19 Apr 2011 07:06:09 +0200, Stefan Behnel <stefan_ml at behnel.de> wrote: > > That's what makes the PEP feel so unfair to CPython developers, because > > they are the ones who carry most of the burden of maintaining the stdlib in > > the first place, and who will most likely continue to carry it, because > > other implementations will continue to be occupied with their own core > > development for another while or two. It is nice to read that other > > implementations are contributing back patches that simplify their own reuse > > of the stdlib code. However, that does not yet make them equal contributors > > to the development and the maintenance of the stdlib, and is of very little > > worth to the CPython project. It often even runs counter to the interest of > > CPython itself. > > So, the PEP makes the burden worse in that it requires that someone who > works on a module with a C accelerator must make sure that any existing > Python version and the C version stay in sync, and that *anyone* who wants > to introduce a new module into the stdlib must make sure it has a Python > version if that is practical. IMO both of these are policies that make > sense for CPython even aside from the existence of other implementations: > Python is easier to read and understand, so where practical we should > provide a Python version of any module in the stdlib, for the benefit > of CPython users. > > It doesn't sound like a great burden to me, but I'm not really qualified > to judge, since I don't generally work on C code. I think it's ok. Our experience on the io module proves, I think, that's it's indeed useful to have a pure Python (pseudocode-like) implementation. 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