On Jan 25, 5:31 pm, Steven D'Aprano <st...@remove-this- cybersource.com.au> wrote:
> It seems to me that Russ' latest objection to _private names is not > specific to _private names. The same problem: > > "You will get no warning at all. You will just be inadvertently > creating a new "private" attribute -- and the assignment that you > really want will not get done." > > occurs with public names as well. That is true. Any name change could cause that sort of problem. But I brought it up specifically in reply to Mr. Wooding, who pointed out that it is hard to "accidentally" type a name with a leading underscore without realizing what you are doing. You may fully understand what you are doing when you type it, but you may not realize what has happened later when you forget to change it to be consistent with the new version of the library (or another module in an application). To change an attribute from private to public, the leading-underscore convention requires that every occurrence of the name be changed. That is more error prone than if the change only needs to be done in one place. And the fact that Python allows you to create new attributes on the fly also contributes to this problem, of course. That makes renaming and refactoring riskier in general in Python than in statically typed languages with enforced access restrictions. More care and attention to detail is needed to do it right in Python. -- http://mail.python.org/mailman/listinfo/python-list