[Python-Dev] PEP 399: Pure Python/C Accelerator Module Compatibility Requirements

R. David Murray rdmurray at bitdance.com
Sun Apr 17 19:50:55 CEST 2011


On Sun, 17 Apr 2011 19:17:11 +0200, Stefan Krah <stefan at bytereef.org> wrote:
> R. David Murray <rdmurray at bitdance.com> wrote:
> [snip a lot]
> 
> Thank you, this cleared up many things.

Heh.  Keep in mind that this is my viewpoint.  I *think* Brett agrees
with me.  I'm sure he'll speak up if he doesn't.

> The technical reason is that the context is a speed critical data structure,
> so I'm doing some tricks to emulate the context flags and traps dictionaries.

[snip]

Thanks, your explanation seems to me to make a good case for making the
decimal.py implementation less permissive.

> So, if one of the goals of the PEP is to clean up various APIs, I'm all
> for it. My concern is though that the process will be very slow due to
> lack of time and general reluctance to change APIs. And this is where
> I see a potentially negative effect:

Well, the general reluctance to change APIs is certainly an issue.
But since you are advocating cdecimal changing the API *anyway*, if it
is going to go in to CPython this would have to be addressed regardless.
So I don't see that the PEP affects the speed of that part of the process
from CPython's point of view.

> Is it worth to stall development over relatively minor issues? Will
> these differences actually affect someone in practice? Will the
> four Python implementations block each other?

In my vision it wouldn't stall development in any place it shouldn't
be stalled by our normal backward compatibility rules.  It would be a
bug in the bug tracker saying "the API of module X has some undesirable
characteristics that get in the way of implementing accelerators, can
we change it?"  Again, I don't see this as changing what the current
procedure should be anyway, just clarifying it and making it more likely
that we will *notice* the changes and deal with them proactively rather
than finding out about them after the accelerator is in the field, having
introduced a backward-incompatible change unintentionally.  (Note: I'm
sure that we will still accidentally do this anyway, I'm just hoping to
reduce the frequency of such occurrences).

--
R. David Murray           http://www.bitdance.com


More information about the Python-Dev mailing list