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

[Russ P.]

On Jan 24, 9:54 pm, Luis Zarrabeitia <ky... at uh.cu> wrote:
> Quoting "Russ P." <Russ.Paie... at gmail.com>:
>
> > Once again, if you have the source code for the library (and the right
> > to modify it), how does the "power" lie with the library implementer
> > rather than you the user?
>
> > You say you don't want to "fork" the library. Let's stipulate for the
> > sake of argument that a one-line change is indeed a "fork."
>
> It is. For starters, I'd lose the information of "this attribute was intended to
> be internal and I'm accessing it anyway".

Not really. When you get a new version of the library and try to use
it, you will quickly get a reminder about the change (assuming your
tests provide sufficient converage, and also assuming that the
attribute is not made public in the new version). So you don't really
even need to keep track of the change.

> > Think
> > about what you are saying. You are saying that you should dictate how
> > the producer of the library should implement it because you don't want
> > to be bothered to "fork" it.
>
> No. I am not dictating _anything_. The beauty of it, you don't have to do
> _anything_ for this to happen.

You are trying to dictate that the library implementer not be allowed
to use enforced access restriction. And, in the larger sense, you are
trying to dictate that access restrictions not be enforced in Python.

> Now, you may say that I'm trying to force you to relax and do nothing instead of
> complaining because the language I use doesn't put enough restrictions on me.

And you are trying to put restrictions on anyone who might prefer to
enforce access restrictions. If you don't allow them to do that, you
are restricting them.

> > If you don't like his design decisions,
> > shouldn't the onus be on *you* to make the trivial change necessary to
> > get access to what you want?
>
> Or contacting him about it and maybe send him a patch, sure, why not. But this
> has nothing to do with enforced data hiding. Having obj._public_var is just as
> badly designed as having "private public_var".

Sure, go ahead and contact him. If he agrees that a private attribute
should be public, then the problem is solved. But if he does not
agree, he should not be forced to bend to your desire.

> > Imagine a person who repairs computers. He is really annoyed that he
> > constantly has to remove the cover to get at the guts of the computer.
> > So he insists that computers cases should be made without covers.
> > After all, manufacturers put covers on computers only because they
> > don't trust us and think we're too "stupid" to safely handle an
> > uncovered computer box.
>
> > That is logically equivalent to your position on enforced access
> > restrictions in software.
>
> Do you realize that most computer cases are trivially easy to open? (Nevermind

That was exactly my point. Deleting the word "private" (or whatever)
is also trivially easy if you have access to the source code.