On Sun, 25 Jan 2009 17:15:47 -0800, Paul Rubin wrote: > Steven D'Aprano <st...@remove-this-cybersource.com.au> writes: >> How is this scenario different from an API change where >> self.some_attribute gets changed to self.attribute? > > That would be a backward incompatible change to a published interface, > something that should not be done without a good reason, and which was > mostly avoided through the whole Python 2.x series (incompatible changes > were saved for Python 3.0). Changing an undocumented and supposedly > private interface is something different entirely.
We're not talking specifically about Python standard library changes, we're talking about any project which may have more entertaining *cough* policies regarding API changes. Or if you prefer... some projects take the philosophy that the API isn't fixed until version 1.0, and so they can change anything until then. 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. However, I do see his point that if we take the presence of a leading underscore in the name as semantically significant, then we're recording that information *everywhere* instead of in one place. That is a lesser version of Hungarian notation -- not as bad as redundantly storing type information that the compiler already knows, but still not ideal. -- Steven -- http://mail.python.org/mailman/listinfo/python-list