<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, 9 Jul 2016 at 06:52 Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm in the process of trying to disentangle<br>
<a href="http://bugs.python.org/issue27137" rel="noreferrer" target="_blank">http://bugs.python.org/issue27137</a> which points out some of the<br>
behavioural differences that arise when falling back from the original<br>
C implementation of functools.partial to the pure Python emulation<br>
that uses a closure.<br>
<br>
That issue was opened due to a few things that work with the C<br>
implementation that fail with the Python implementation:<br>
<br>
- the C version can be pickled (and hence used with multiprocessing)<br>
- the C version can be subclassed<br>
- the C version can be used in "isinstance" checks<br>
- the C version behaves as a static method, the Python version as a<br>
normal instance method<br>
<br>
While I'm planning to accept the patch that converts the pure Python<br>
version to a full class that matches the semantics of the C version in<br>
these areas as well as in its core behaviour, that last case is one<br>
where the pure Python version merely exhibits different behaviour from<br>
the C version, rather than failing outright.<br>
<br>
Given that the issues that arose in this case weren't at all obvious<br>
up front, what do folks think of the idea of updating PEP 399 to<br>
explicitly prohibit class/function mismatches between accelerator<br>
modules and their pure Python counterparts?<br></blockquote><div><br></div><div>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".</div><div><br></div><div>-Brett</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The rationale for making such a change is that when it comes to true<br>
drop-in API compatibility, we have reasonable evidence that "they're<br>
both callables" isn't sufficient once the complexities of real world<br>
applications enter the picture.<br>
<br>
Regards,<br>
Nick.<br>
<br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/brett%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/brett%40python.org</a><br>
</blockquote></div></div>