This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rhettinger
Recipients Muhammad Alkarouri, abarry, apatrushev, ncoghlan, r.david.murray, rhettinger, uriyyo, xiang.zhang, xtreak, ztane
Date 2020-12-27.22:52:55
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1609109575.5.0.065687500826.issue27794@roundup.psfhosted.org>
In-reply-to
Content
> In my opinion, it's expected behavior that `name` is 
> overwritten by `__set_name__` method.

It is almost certain that there will be others won't share that expectation.  The StackOverflow questions and bug reports are inevitable.

Most examples of __set_name__() use a private attribute.  I recommend that you go that route and stick to the spirit of the original bug report.  The OP asked for better error messages when possible.  They didn't ask for an API expansion.

> I have added `name` to `property` constructor to support cases
> when a property is added to a class after it was declared.

That rarely occurs in practice.  I wouldn't worry about it.  Also AFAICT the only time the new error message matters is in the context of a setattr() where the attribute isn't already shown in the traceback.  So the case in question is really a rarity inside another rarity.  Let's declare YAGNI unless an actual end-user problem arises in real-world code.
History
Date User Action Args
2020-12-27 22:52:55rhettingersetrecipients: + rhettinger, ncoghlan, r.david.murray, ztane, xiang.zhang, abarry, apatrushev, Muhammad Alkarouri, xtreak, uriyyo
2020-12-27 22:52:55rhettingersetmessageid: <1609109575.5.0.065687500826.issue27794@roundup.psfhosted.org>
2020-12-27 22:52:55rhettingerlinkissue27794 messages
2020-12-27 22:52:55rhettingercreate