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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
