[Python-Dev] PEP 399: Pure Python/C Accelerator Module Compatibility Requirements (original) (raw)

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