[Python-Dev] Proposal: explicitly disallow function/class mismatches in accelerator modules
tjreedy at udel.edu
Sat Jul 9 14:48:06 EDT 2016
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
More information about the Python-Dev