Does Python really follow its philosophy of "Readability counts"?

[Steven D'Aprano]

On Sun, 25 Jan 2009 17:15:47 -0800, Paul Rubin wrote:

> Steven D'Aprano <steve at 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