GeezerVison

I don't think that would work right e.g. for properties either.
What was the actual case where you needed this?
I guess the correct solution would be something like checking whether attr in vars(obj) (in which case we grab the value and restore it later) or, if not, whether hasattr(type(obj), attr) (in which case we don't restore it later) (the second check can't be attr in vars(type(obj)) as that would mishandle inheritance).

This closes #17542 ? EDIT: sorry, confused the PRs...

I added a test for a property as well, it seems to work.

Noticed this while I was working on #17515 (where I ended up just doing it all "by hand") and this will be relevant for #17560 .

I do see how this is still going to go sideways for class attributes (as we end up with an equal value at the instance level shadowing something is the class hierarchy), but I think that this is still a net improvement.

@jklymak To be fair I almost put these commits in #17560 .

Added comments with links to both the tests and the implementation. I had tweaked the implementation a bit to give a better path to support un-masking class level attributes but in the process of writing out how it could be implemented I saw how to implement it. If people are unsure, I'm happy to drop the second commit.

Well, this started as a special case for methods and turned into the full general case for descriptors and class level attributes...

This is also now a bigger change than I think we should backport.

Pushed to 3.4, can be moved back but I would rather focus on other PRs for 3.3.

If you want to get something in for 3.3, can we instead just error out for anything that's not in the instance __dict__ for now (and perhaps special case methods too), and add in features in an as-needed fashion? I'm not sure setattr_cm makes sense for arbitrary properties (or worse, arbitrary descriptors) anyways...

I rebased this, but am going to orphan it.

I think the next step here is to write out a couple more pathological test cases involving custom descriptors.

Labeled as "good first issue" because there is not API design ("it goes back to as it was" is the API) but medium difficulty as it requires and understanding of the Python descriptor protocol (see https://docs.python.org/3/howto/descriptor.html ) which is not basic Python.

(I think we should just support instance attributes and a small, explicitly listed subset of descriptors (each of which should be motivated by an actual use case), as writing a general utility seems to be way more complex than it is really worth).

Fair, I'm also open to "close this as a bad idea" ;)

I agree with @anntzer. Let's do all the things we need but not more (=motivated by an actual use case).

Given the feedback, I'm going to close this.

If we end up needing something more sophisticated we will either remember and revive this or implement something more narrowly tailored.