Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
17.3.0 changes the order how inherited class attributes are defined if they have the same base class #285
Minimal working example:
This works with attrs==17.2.0 and breaks with attrs==17.3.0. In 17.3.0 the list of non_super_names in base.py:
When looking at what
As a minimal workaround, this change fixes the order for our usecase:
@@ -278,7 +278,9 @@ # list in the end and get all attributes in the order they have # been defined. for a in reversed(sub_attrs): - if a.name not in taken_attr_names: + if a.name in super_cls.__super_names__: + continue + elif a.name not in taken_attr_names: super_attrs.append(a) taken_attr_names.add(a.name) @@ -354,6 +356,7 @@ self._has_post_init = bool(getattr(cls, "__attrs_post_init__", False)) self._cls_dict["__attrs_attrs__"] = self._attrs + self._cls_dict["__super_names__"] = self._super_names if frozen: self._cls_dict["__setattr__"] = _frozen_setattrs
The downside is obviously cluttering the generated classes with the
added a commit
Nov 9, 2017
referenced this issue
Nov 9, 2017
I think it’s simpler. The problem is that it’s possible to overwrite attribute definitions now and that’s exactly what’s happening here. The bug is that I didn’t take into account such hierarchies that introduce the same attribute multiple times.
#287 should fix that, would you mind checking it out?