[Python-Dev] Proposal: explicitly disallow function/class mismatches in accelerator modules

[Paul Moore]

On 11 July 2016 at 14:11, Steven D'Aprano <steve at pearwood.info> wrote:
> But generalising this to all possibly mismatches between a C class
> implementation and a Python function implementation doesn't necessarily
> follow. Raymond's general point about simplicity versus feature creep
> still stands, even if in this case adding pickling is useful.

On the specific case that started this thread, I think it's fair to
say that when people see "object" in the documentation, they think in
terms of "class instance", so an implementation that uses a closure
instead of the standard (C implementation) approach is going to trip
people up. So it would seem OK to me to say that both implementations
should implement something described as an "object" in the same way
(class, closure, or whatever else) - *unless* the documentation is
explicit (for example by using a term like "opaque object" or
"internal object") that the implementation details of the object are
not public. (An alternative resolution to the original issue would
hence be to update the documentation to make it explicit that the
partial object's implementation is undefined, and cannot be relied on
by user code).

However, I don't think we can assume it'll be possible to make a
high-level ruling on *every* possible situation. I don't think that's
reasonable - there needs to be some level of judgement applied. The
*documented* API is definitive, both implementations must follow the
documented API - but if the documentation is silent or ambiguous, I
don't think we should feel under undue pressure to replicate every
behaviour of the CPython implementation - if we take that view, then
we're back to implementation-defined semantics. Outside of documented
behaviour, I don't think mandating compatibility without qualification
is helpful.

It's worth having guidelines on what implementers should be ensuring
match between C and pure-Python implementation - and even more so
having reminders about common pitfalls and places where extra work is
needed to get the same behaviour - but I'd be concerned if the rules
became dogma rather than guidance. We need to be prepared to trust the
judgement of the core devs in this matter.

Paul