Skip to content
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

Provide option in attrs.define to allow users to exclude parameters set to default value from repr #1276

Open
wants to merge 26 commits into
base: main
Choose a base branch
from

Conversation

RNKuhns
Copy link

@RNKuhns RNKuhns commented Apr 11, 2024

Summary

This PR provides functionality in line with #1193.

It adds a new parameter to attrs.define to allow users to toggle on/off the ability to create classes that dynamically generate their repr to include only parameters set to values other than their default. The added parameter is set to a default value that maintains the existing functionality (always have static repr).

The functionality is designed to work such as follows:

@attrs.define(kw_only=True, only_non_default_attr_in_repr=True)
class SomeClass:

    something: int | None = attrs.field(default=None, repr=True)
    something_else: bool = attrs.field(default=False, repr=True)
    another: float | None = attrs.field(default=11.0, init=False, repr=False)


some_class = SomeClass(something=7)
SomeClass(something=7)


# If we wanted to exclude the something param from the repr in the field def we still can
@attrs.define(kw_only=True, only_non_default_attr_in_repr=True)
class SomeClass:

    something: int | None = attrs.field(default=None, repr=False)
    something_else: bool = attrs.field(default=False, repr=True)
    another: float | None = attrs.field(default=11.0, init=False, repr=False)


some_class = SomeClass(something=7)
SomeClass()


# The default is equivalent of only_non_default_attr_in_repr=False, so existing behavior is default
@attrs.define(kw_only=True)
class SomeClass:

    something: int | None = attrs.field(default=None)
    something_else: bool = attrs.field(default=False)
    another: float | None = attrs.field(default=11.0, init=False, repr=False)


some_class = SomeClass(something=7)
SomeClass(something=7, something_else=False)


# The use of repr in a field works just like it did before so we can exclude individual attributes
# from the repr (or pass custom callable)
@attrs.define(kw_only=True)
class SomeClass:

    something: int | None = attrs.field(default=None, repr=False)
    something_else: bool = attrs.field(default=False)
    another: float | None = attrs.field(default=11.0, init=False)


some_class = SomeClass(something=7)
SomeClass(something_else=False, another=11.0)

@hynek I'll look into creating some simple test cases (like above examples) to test cases for this. But I'd appreciate some feedback on whether this approach makes sense to you before I finish up with that.

Note there might be some nuisance edits to the _make.py that ruff made when I saved the file in my setup, but these should be minor.

Pull Request Check List

  • Do not open pull requests from your main branch – use a separate branch!
    • There's a ton of footguns waiting if you don't heed this warning. You can still go back to your project, create a branch from your main branch, push it, and open the pull request from the new branch.
    • This is not a pre-requisite for your your pull request to be accepted, but you have been warned.
  • Added tests for changed code.
    Our CI fails if coverage is not 100%.
  • New features have been added to our Hypothesis testing strategy.
  • Changes or additions to public APIs are reflected in our type stubs (files ending in .pyi).
    • ...and used in the stub test file tests/typing_example.py.
    • [X ] If they've been added to attr/__init__.pyi, they've also been re-imported in attrs/__init__.pyi.
  • [ X] Updated documentation for changed code.
    • [ X] New functions/classes have to be added to docs/api.rst by hand.
    • [ X] Changes to the signature of @attr.s() have to be added by hand too.
    • [ X] Changed/added classes/methods/functions have appropriate versionadded, versionchanged, or deprecated 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.
  • [ X] Documentation in .rst and .md files is written using semantic newlines.
  • Changes (and possible deprecations) have news fragments in changelog.d.
  • Consider granting push permissions to the PR branch, so maintainers can fix minor issues themselves without pestering you.

@RNKuhns
Copy link
Author

RNKuhns commented Apr 11, 2024

Note that I'll also add examples to the docs before this is finalized/merged if the concept moves forward.

@RNKuhns
Copy link
Author

RNKuhns commented Apr 25, 2024

@hynek I know you are probably busy, but I just wanted to check in to see if you had a chance to take a look and provide feedback.

@hynek
Copy link
Member

hynek commented Apr 27, 2024

yeah sorry I'm swamped right now, as you can tell in my own PR #1267 that hasn't moved in a while. I don't have the headspace for bigger changes right now, but it won't get lost as long as you leave it open. I hope to be able to clean up the trackers before leaving for PyCon US (2024 – just in case ;))

@RNKuhns
Copy link
Author

RNKuhns commented Apr 27, 2024

yeah sorry I'm swamped right now, as you can tell in my own PR #1267 that hasn't moved in a while. I don't have the headspace for bigger changes right now, but it won't get lost as long as you leave it open. I hope to be able to clean up the trackers before leaving for PyCon US (2024 – just in case ;))

No problem at all! I'll leave it open and add some of the finishing touches (tests cases, docs) as I have time on the next week or two.

@RNKuhns
Copy link
Author

RNKuhns commented Jun 9, 2024

@hynek I've updated this to handle default factories and include a description of the functionality in the attrs by examples section of the documentation.

Let me know when you have a chance to take a look.

Copy link

codspeed-hq bot commented Jul 17, 2024

CodSpeed Performance Report

Merging #1276 will degrade performances by 28.49%

Comparing RNKuhns:repr_optionally_exclude_param_defaults (9f1963b) with main (f5683b8)

Summary

❌ 3 regressions
✅ 5 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

Benchmark main RNKuhns:repr_optionally_exclude_param_defaults Change
test_create_frozen_class 1.7 s 2.3 s -25.32%
test_create_simple_class 1.5 s 2.1 s -28.06%
test_create_simple_class_make_class 1.5 s 2 s -28.49%

@hynek
Copy link
Member

hynek commented Jul 22, 2024

Hey sorry once again, for all the delays. :( Before starting investigating, do you have any idea why this PR slows down class creation (not instantiation) by almost 30%? That's quite a lot and sadly a rather critical benchmark in the whole space of creating classes. :|

" else:",
" default_ = a.default.factory()",
" else:",
" default_ = a.default",
Copy link

@mara004 mara004 Jul 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • I think you could generate the defaults only once and cache them for subsequent runs.
  • IIRC, attrs applies converters on defaults, so shouldn't this do, too?
  • Calling factories unconditionally is a bit problematic for things like factory=lambda: next(generator) because it would advance the caller's generator without an actual instantiation. Also, if a factory takes self, it might contain some more elaborate computation that should not be done over and over again (e.g. determining a file type). Overall, it might be better to keep track of the defaults produced on construction and compare against that?

FWIW, I had written a caller-side wrapper to hide defaults. (The way it works around the factory problem is by letting you mark a factory as dynamic if you don't want it called in repr.)

Disclaimer: I'm not an attrs maintainer, so my views may not matter here.

field's value is not the default.

But the field is still excluded from the repr when it is set to the default value
because `only_non_default_attr_in_repr` overrides `repr=True` or the repr being a
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wouldn't it be nice for an explicit repr=True to override the defaults hiding?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, no, because then this wouldn't be available if a custom repr is given. so perhaps add a new argument always_repr or something?

C()
>>> C(x=1)
C(x=1.5)
```
Copy link

@mara004 mara004 Jul 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this functionality expects the defaults in the converted format.

I don't think this is correct (see the other comment). The real default for field x would be 1.5 here:

>>> import attrs
>>>
>>> @attrs.define()
... class Test:
...     x = attrs.field(default=1, converter=lambda v: v + 0.5)
... 
>>> test = Test()
>>> test.x
1.5

(note: expand the file to see context)

@RNKuhns
Copy link
Author

RNKuhns commented Aug 16, 2024

@hynek I do plan to circle back on this. I've just got a couple things going on at the moment.

@RNKuhns
Copy link
Author

RNKuhns commented Aug 16, 2024

Hey sorry once again, for all the delays. :( Before starting investigating, do you have any idea why this PR slows down class creation (not instantiation) by almost 30%? That's quite a lot and sadly a rather critical benchmark in the whole space of creating classes. :|

Not a problem -- I'll take a look at this and work through what is driving those performance degradations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants