On Sat, Jul 09, 2016 at 11:50:59PM +1000, 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. [...] > 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.
Are these problems common enough, or serious enough, to justify a blanket ban on mismatches (a "MUST NOT" rather than a "SHOULD NOT" in RFC 2119 terminology)? The other side of the issue is that requiring exact correspondence is considerably more difficult and may be over-kill for some uses. Hypothetically speaking, if I have an object that only supports pickling by accident, and I replace it with one that doesn't support pickling, shouldn't it be my decision whether that counts as a functional regression (a bug) or a reliance on an undocumented and accidental implementation detail? -- Steve _______________________________________________ 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
