Serhiy Storchaka added the comment:
Thank you for your review Eric.
As for using Py_TYPE(self) instead of the __class__ attribute in #3, this is
consistent with the rest of Python core and stdlib. All C implementations use
Py_TYPE(self) for repr and pickling, even if Python implementations can use
__class__.
>>> class S(set): __class__ = str
...
>>> s = S()
>>> s.__class__
<class 'str'>
>>> s
S()
>>> s.__reduce_ex__(2)
(<class '__main__.S'>, ([],), {})
>>> s+''
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'S' and 'str'
Note that you can't just set s.__class__ = str, this is forbidden (issue24912).
You should set __class__ in class definition or make it a property, and this
doesn't have affect object's behavior, the only visible effect is the value of
the __class__ attribute itself.
One possible argument for Py_TYPE(self) (besides simplicity and historical
reasons) is that it is more reliable. It doesn't cause executing arbitrary
Python code and therefore is thread-safe and reentrant. It returns the true
type of the object, that can be important for debugging.
We should not care about exactly matching Python implementation, but rather
about consistency with the rest of Python. If such type of mismatching is
considered a bug, Python is full of such bugs.
About #5, be sure that the new code is exact semantic equivalence to the old
code besides copying the dict that is not needed now. I just dropped an
iteration on always empty dict and related code.
I don't see re-entrancy problem in #7. Could you please provide an example?
----------
_______________________________________
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
