Serhiy Storchaka added the comment: > Regarding Py_TYPE(od) vs. od.__class__, there is a difference for > subclasses, as you demonstrated in your example. [1] Thanks for explaining > your rationale. I now understand your argument about using PyTYPE() for > repr and pickle in C types. I still have concerns, though, regarding > parity between the two OrderedDict implementations. > > The key difference is that we're talking about an after-the-fact C port of > an existing pure Python implementation.
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. 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. > That particular difference in the implementations (i.e. you *can* change > od.__class__ for the pure Python one) is an acceptable compatibility break > since it's unlikely anyone is changing od.__class__ *and* if they are then > they can just switch to a simple subclass that wraps OrderedDict: > > # before: > from collections import OrderedDict > od = OrderedDict() > od.__class__ = SomethingElse > > # after: > import collections > class OrderedDict(collections.OrderedDict): > pass > od = OrderedDict() > od.__class__ = SomethingElse No, this assignment is forbidden (due to #24912). You can't set __class_ for an instance of a subclass of non-heap type. > It may be worth taking this to python-dev to get a clearer consensus on both > "Py_TYPE(obj) vs. obj.__class__", as well as about parity between dual > pure-Python/C implementations in the stdlib, regardless of the outcome of > this issue. Both are points about which we should be consistent throughout > Python. The type() vs. __class__ question may deserve an entry in the > language reference and both may deserve a PEP. Could you please raise a discussion on Python-Dev? You will formulate the problem better. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25410> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
