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

[Terry Reedy]

On 7/9/2016 9:50 AM, 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.
>
> That issue was opened due to a few things that work with the C
> implementation that fail with the Python implementation:
>
> - the C version can be pickled (and hence used with multiprocessing)
> - the C version can be subclassed
> - the C version can be used in "isinstance" checks
> - the C version behaves as a static method, the Python version as a
> normal instance method
>
> While I'm planning to accept the patch that converts the pure Python
> version to a full class that matches the semantics of the C version in
> these areas as well as in its core behaviour, that last case is one
> where the pure Python version merely exhibits different behaviour from
> the C version, rather than failing outright.
>
> 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?

+1 I would put it positively that both version have to use matching 
classes or matching functions. I assumed that this was already true.

> 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.

This same issue has come up in the itertools docs.  The C code callables 
are iterator classes that return iterator instances. The didactic doc 
'equivalents' are generator functions that return generator instances. 
The result is functionally the same in that the respective iterators 
yield the same sequence of objects.  In this, the doc equivalents 
concisely fulfill their purpose.

But non-iterator behaviors of C class instances and generators are 
different, and this confused some people.  Python-coded itertools would 
have to be iterator classes to be really equivalent.  In May, Raymond 
added 'Roughly' to 'equivalent'.

-- 
Terry Jan Reedy