On 11 July 2016 at 14:11, Steven D'Aprano <st...@pearwood.info> wrote: > But generalising this to all possibly mismatches between a C class > implementation and a Python function implementation doesn't necessarily > follow. Raymond's general point about simplicity versus feature creep > still stands, even if in this case adding pickling is useful.
On the specific case that started this thread, I think it's fair to say that when people see "object" in the documentation, they think in terms of "class instance", so an implementation that uses a closure instead of the standard (C implementation) approach is going to trip people up. So it would seem OK to me to say that both implementations should implement something described as an "object" in the same way (class, closure, or whatever else) - *unless* the documentation is explicit (for example by using a term like "opaque object" or "internal object") that the implementation details of the object are not public. (An alternative resolution to the original issue would hence be to update the documentation to make it explicit that the partial object's implementation is undefined, and cannot be relied on by user code). However, I don't think we can assume it'll be possible to make a high-level ruling on *every* possible situation. I don't think that's reasonable - there needs to be some level of judgement applied. The *documented* API is definitive, both implementations must follow the documented API - but if the documentation is silent or ambiguous, I don't think we should feel under undue pressure to replicate every behaviour of the CPython implementation - if we take that view, then we're back to implementation-defined semantics. Outside of documented behaviour, I don't think mandating compatibility without qualification is helpful. It's worth having guidelines on what implementers should be ensuring match between C and pure-Python implementation - and even more so having reminders about common pitfalls and places where extra work is needed to get the same behaviour - but I'd be concerned if the rules became dogma rather than guidance. We need to be prepared to trust the judgement of the core devs in this matter. Paul _______________________________________________ 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