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

[Steven D'Aprano]

On Sat, Jul 09, 2016 at 11:50:59PM +1000, Nick Coghlan wrote:
> I'm in the process of trying to disentangle
> http://bugs.python.org/issue27137 which points out some of the
> behavioural differences that arise when falling back from the original
> C implementation of functools.partial to the pure Python emulation
> that uses a closure.
[...]
> Given that the issues that arose in this case weren't at all obvious
> up front, what do folks think of the idea of updating PEP 399 to
> explicitly prohibit class/function mismatches between accelerator
> modules and their pure Python counterparts?
> 
> The rationale for making such a change is that when it comes to true
> drop-in API compatibility, we have reasonable evidence that "they're
> both callables" isn't sufficient once the complexities of real world
> applications enter the picture.

Are these problems common enough, or serious enough, to justify a 
blanket ban on mismatches (a "MUST NOT" rather than a "SHOULD NOT" in 
RFC 2119 terminology)?

The other side of the issue is that requiring exact correspondence is 
considerably more difficult and may be over-kill for some uses. 
Hypothetically speaking, if I have an object that only supports pickling 
by accident, and I replace it with one that doesn't support pickling, 
shouldn't it be my decision whether that counts as a functional 
regression (a bug) or a reliance on an undocumented and accidental 
implementation detail?


-- 
Steve