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

[Nick Coghlan]

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?

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.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia