Re: [Python-Dev] compatibility for C-accelerated types
Apart from Serhiy's detraction of the 3.5 bug report there wasn't any discussion in this thread. I also don't really see any specific questions, so maybe you don't have any. Are you just asking whether it's okay to merge your code? Or are you asking for more code review? On Sat, Oct 17, 2015 at 3:20 PM, Eric Snow wrote: > A recent discussion in a tracker issue [1] brought up the matter of > compatibility between the pure Python implementation of OrderedDict > and the new C implementation. In working on that port I stuck as > closely as possible to the Python implementation. This meant some > parts of the code are bit more complex than they would be otherwise. > (Serhiy has been kind enough to do some cleanup.) > > Compatibility was one of the fundamental goals of the porting effort. > Not only does compatibility make sense but it's also specifically > required by PEP 399 [2]: > > Any new accelerated code must act as a drop-in replacement > as close to the pure Python implementation as reasonable. > Technical details of the VM providing the accelerated code > are allowed to differ as necessary, e.g., a class being a type > when implemented in C. > > For the most part I have questions about what is "reasonable", > specifically in relation to OrderedDict. > > I've already opened up a separate thread related to my main question: > type(obj) vs. obj.__class__. [3] In the tracker issue, Serhiy pointed > out: > > There is no a difference. io, pickle, ElementTree, bz2, virtually > all accelerator classes was created as replacements of pure > Python implementations. All C implementations use > Py_TYPE(self) for repr() and pickling. I think this deviation is > common and acceptable. > > In a review comment on the associated patch he said: > > Isn't type(self) is always the same as self.__class__ for pure > Python class? If right, then this change doesn't have any effect. > > To which he later replied: > > It is the same if you assigned the __class__ attribute, but can > be different if set __class__ in the subclass declaration. > > So it isn't clear if that is a compatibility break or how much so it might > be. > > Serhiy also noted that, as of 3.5 [4], you can no longer assign to > obj.__class__ for instances of subclasses of builtin (non-heap) types. > So that is another place where the two OrderedDict implementations > differ. I expect there are a few others in dark corner cases. > > On the tracker he notes another OrderedDict compatibility break: > > Backward compatibility related to __class__ assignment was > already broken in C implementation. In 3.4 following code > works: > > >>> from collections import * > >>> class foo(OrderedDict): > ... def bark(self): return "spam" > ... > >>> class bar(OrderedDict): > ... pass > ... > >>> od = bar() > >>> od.__class__ = foo > >>> od.bark() > 'spam' > > In 3.5 it doesn't. > > As PEP 399 says, we should go as far "as reasonable" in the pursuit of > compatibility. At the same time, I feel not insignificant > responsibility for *any* incompatibility that comes from the C > implementation of OrderedDict. The corner cases impacted by the above > compatibility concerns are borderline enough that I wanted to get some > feedback. Thanks! > > -eric > > > [1] http://bugs.python.org/issue25410 > [2] https://www.python.org/dev/peps/pep-0399/ > [3] https://mail.python.org/pipermail/python-dev/2015-October/141953.html > [4] http://bugs.python.org/issue24912 > ___ > 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/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] compatibility for C-accelerated types
On Mon, Oct 19, 2015 at 3:00 PM, Guido van Rossum wrote: > Apart from Serhiy's detraction of the 3.5 bug report there wasn't any > discussion in this thread. I also don't really see any specific questions, > so maybe you don't have any. Are you just asking whether it's okay to merge > your code? Or are you asking for more code review? Basically, I've had all my questions answered. PEP 399 covers the matter well enough. -eric ___ 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
Re: [Python-Dev] compatibility for C-accelerated types
On 20.10.15 00:00, Guido van Rossum wrote: Apart from Serhiy's detraction of the 3.5 bug report there wasn't any discussion in this thread. I also don't really see any specific questions, so maybe you don't have any. Are you just asking whether it's okay to merge your code? Or are you asking for more code review? I think Eric ask whether it's okay to have some incompatibility between Python and C implementations. 1. Is it okay to have a difference in effect of __class__ assignment. Pure Python and extension classes have different restrictions. For example (tested example this time) following code works with Python implementation in 3.4, but fails with C implementation in 3.5: from collections import OrderedDict od = OrderedDict() class D(dict): pass od.__class__ = D 2. Is it okay to use obj.__class__ in Python implementation and type(obj) in C implementation for the sake of code simplification? Can we ignore subtle differences? 3. In general, is it okay to have some incompatibility between Python and C implementations for the sake of code simplification, and where the border line lies? ___ 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
Re: [Python-Dev] compatibility for C-accelerated types
On Mon, Oct 19, 2015 at 2:47 PM, Serhiy Storchaka wrote: > On 20.10.15 00:00, Guido van Rossum wrote: > >> Apart from Serhiy's detraction of the 3.5 bug report there wasn't any >> discussion in this thread. I also don't really see any specific >> questions, so maybe you don't have any. Are you just asking whether it's >> okay to merge your code? Or are you asking for more code review? >> > > I think Eric ask whether it's okay to have some incompatibility between > Python and C implementations. > > 1. Is it okay to have a difference in effect of __class__ assignment. Pure > Python and extension classes have different restrictions. For example > (tested example this time) following code works with Python implementation > in 3.4, but fails with C implementation in 3.5: > > from collections import OrderedDict > od = OrderedDict() > class D(dict): pass > > od.__class__ = D > Yes. > 2. Is it okay to use obj.__class__ in Python implementation and type(obj) > in C implementation for the sake of code simplification? Can we ignore > subtle differences? > Yes. > 3. In general, is it okay to have some incompatibility between Python and > C implementations for the sake of code simplification, and where the border > line lies? > I don't want to rule in general -- the above two look pretty clear-cut to me in this case, but even for __class__ vs. type() it's conceivable that it might be important in some other case (e.g. if it was for a proxy class :-). I think it's fine to ask here the next time there is some doubt about how far a C implementation would need to go. -- --Guido van Rossum (python.org/~guido) ___ 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
