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

[Stefan Krah]

R. David Murray <rdmurray at bitdance.com> wrote:
[snip a lot]

Thank you, this cleared up many things.


> > 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.
> 
> Here you perceive the burden we are currently placing on the other
> implementations.  That's the world they live in *now*.  The PEP is asking
> CPython to share this pain equally.
> 
> I agree that this is a concrete example that the PEP could address.
> I myself don't know enough about decimal/cdecimal or the Python C API
> to know why cdecimal can't duck type here, but it certainly sounds
> like a good example to use to clarify the requirements being advocated
> by the PEP.  I won't be surprised to find that the issues involved are
> the same issues that an accelerator module for the other Python
> implementations would face.

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.


But I actually prefer that the context is locked down. The context
settings are absolutely crucial for the correctness of the result.
Here is a mistake that I've made multiple times while trying something
out with decimal.py:

>>> from decimal import *
>>> c = getcontext()
# Meaning c.Emax and c.Emin:
>>> c.emax = 99
>>> c.emin = -99
# The operation silently uses the unchanged context:
>>> Decimal(2)**99999
Decimal('4.995010465071922539720163822E+30102')
>>> 


cdecimal raises an AttributeError:

>>> from cdecimal import *
>>> c = getcontext()
>>> c.emax = 99
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'cdecimal.Context' object has no attribute 'emax'
>>> 


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:

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?



Stefan Krah