On Sat, 9 Jul 2016 at 06:52 Nick Coghlan <ncogh...@gmail.com> 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? >
I think flat-out prohibiting won't work in the Python -> C case as you can do things such as closures and such that I don't know if we provide the APIs to mimic through the C API. I'm fine saying we "strongly encourage mirroring the design between the pure Python and accelerated version for various reasons". -Brett > > 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/brett%40python.org >
_______________________________________________ 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
