<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, 11 Jul 2016 at 09:06 Paul Moore <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11 July 2016 at 14:11, Steven D'Aprano <<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</a>> wrote:<br>
> But generalising this to all possibly mismatches between a C class<br>
> implementation and a Python function implementation doesn't necessarily<br>
> follow. Raymond's general point about simplicity versus feature creep<br>
> still stands, even if in this case adding pickling is useful.<br>
<br>
On the specific case that started this thread, I think it's fair to<br>
say that when people see "object" in the documentation, they think in<br>
terms of "class instance", so an implementation that uses a closure<br>
instead of the standard (C implementation) approach is going to trip<br>
people up. So it would seem OK to me to say that both implementations<br>
should implement something described as an "object" in the same way<br>
(class, closure, or whatever else) - *unless* the documentation is<br>
explicit (for example by using a term like "opaque object" or<br>
"internal object") that the implementation details of the object are<br>
not public. (An alternative resolution to the original issue would<br>
hence be to update the documentation to make it explicit that the<br>
partial object's implementation is undefined, and cannot be relied on<br>
by user code).<br>
<br>
However, I don't think we can assume it'll be possible to make a<br>
high-level ruling on *every* possible situation. I don't think that's<br>
reasonable - there needs to be some level of judgement applied. The<br>
*documented* API is definitive, both implementations must follow the<br>
documented API - but if the documentation is silent or ambiguous, I<br>
don't think we should feel under undue pressure to replicate every<br>
behaviour of the CPython implementation - if we take that view, then<br>
we're back to implementation-defined semantics. Outside of documented<br>
behaviour, I don't think mandating compatibility without qualification<br>
is helpful.<br>
<br>
It's worth having guidelines on what implementers should be ensuring<br>
match between C and pure-Python implementation - and even more so<br>
having reminders about common pitfalls and places where extra work is<br>
needed to get the same behaviour - but I'd be concerned if the rules<br>
became dogma rather than guidance. We need to be prepared to trust the<br>
judgement of the core devs in this matter.<br></blockquote><div><br></div><div>The other thing to consider is that CPython isn't the only interpreter that might implement accelerated versions of modules in the stdlib. Those implementations could have their own needs, etc. that won't necessarily align with CPython's needs at the C level. And if we actually start managing the stdlib as its own project then this will just become more apparently as a separate stdlib repo could empower other implementations to more easily send contributions upstream.</div><div><br></div><div>IOW we need to be careful to not make this too CPython-specific. </div></div></div>