[Python-Dev] Cython for cPickle?
Guido van Rossum
guido at python.org
Mon Apr 23 04:09:35 CEST 2012
On Sun, Apr 22, 2012 at 6:34 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Mon, Apr 23, 2012 at 9:27 AM, Alexandre Vassalotti
> <alexandre at peadrop.com> wrote:
>> On Sun, Apr 22, 2012 at 6:12 PM, <martin at v.loewis.de> wrote:
>>> Of course, this being free software, anybody can spend time on whatever
>>> please, and this should not make anybody feel sad. You just don't get
>>> if you work on stuff that nobody cares about.
>> Yes, of course. I don't want to discourage anyone to investigate this
>> option—in fact, I would very much like to see myself proven wrong. But, if I
>> understood Stefan correctly, he is proposing to have a GSoC student to do
>> the work, to which I would feel uneasy about since we have no idea how
>> valuable this would be as a contribution.
> So long as it's made clear to the students applying that it's a proof
> of concept that may return a negative result (i.e. "it was tried, it
> proved to be a bad idea") I don't see a problem with it. The freedom
> to try out multiple ideas in parallel is one of the great strengths of
> open source.
> We've had GSoC students try unsuccessful experiments in the past and
> have gained useful information as a result (e.g. the main reason I
> know the Import Engine API proposed in the deferred PEP 406 isn't
> adequate as currently written is because of the design level problems
> Greg found when implementing it last summer. The currently documented
> design simply doesn't achieve the full objectives of the PEP)
However, I think that in this case the success may be predetermined,
or at least not determined by technical success alone. I have a lot of
respect for Cython, but I don't think it is right to have any part of
core Python depend on it. Cython is an incredibly complex and
relatively young (and still fast evolving) piece of technology, while
I think that core dependencies should be minimized and limited to
absolutely fundamental building blocks.
--Guido van Rossum (python.org/~guido)
More information about the Python-Dev