-
-
Notifications
You must be signed in to change notification settings - Fork 387
Add reuse()
to Attribute
for field evolution
#1429
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
with additional `inherited` kwarg to preserve inherited class order
for more information, see https://pre-commit.ci
Why does it need to be |
If the goal is to reduce function chains, then how about the keyword class A:
x = attrs.fields(Example).x.reuse()
y = attrs.fields(Example).y.reuse(default="whatever")
_z = attrs.fields(OtherExample).a.reuse(alias="z") |
I like it! |
What exactly should I annotate for mypy? I notice that neither the return result of Line 311 in 755b177
Should I just try to annotate everything this new feature touches? The contribution guidelines are a bit sparse in this regard. |
* Added material in "Other goodies" section in `examples.md` * docstrings for `field`, `attrib`, and `reuse` *Added towncrier changelog message
for more information, see https://pre-commit.ci
to_field()
to Attribute
reuse()
to Attribute
for field evolution
Summary
Preliminary implementation of "evolving" existing
Attribute
instances back into_CountingAttr
instances, so that users may (easily) reuse attribute definitions from alreadydefine
d classes. Should resolve #637, #698, #829, #876, #946, and #1424.Usage:
This syntax is verbose, but least magical. And because you manually specify which class you want to pull attributes from, inheritance is not required; you can compose new classes entirely from parts of existing classes regardless of structure:
Utility methods like
attrs.make_class()
and thethese
kwarg inattrs.define()
also work as you would expect.One potential pain point with a simple implementation of this feature is inherited attributes being reordered when redefined in this manner:
In my opinion, this behavior is a failure of the implementation, as it is reasonable to expect users to want to preserve this ordering, as in a worst-case scenario it can lead to non-constructable classes. This PR implements a new bool keyword argument
inherited
tofield
, which tells attrs to use the ordering of the field in the parent class as opposed to adding to the end:Criticisms of this
inherited
keyword are welcome, as I'm not convinced it is the best solution. However, I do think this functionality needs to be present in attrs in order to make this kind of attribute evolution a tenable approach.Pull Request Check List
main
branch – use a separate branch!.pyi
).tests/typing_example.py
.attr/__init__.pyi
, they've also been re-imported inattrs/__init__.pyi
.docs/api.rst
by hand.@attr.s()
and@attrs.define()
have to be added by hand too.versionadded
,versionchanged
, ordeprecated
directives.The next version is the second number in the current release + 1.
The first number represents the current year.
So if the current version on PyPI is 22.2.0, the next version is gonna be 22.3.0.
If the next version is the first in the new year, it'll be 23.1.0.
attrs.define()
andattr.s()
, you have to add version directives to both..rst
and.md
files is written using semantic newlines.changelog.d
.