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

[Luis Zarrabeitia]

Quoting "Russ P." <Russ.Paielli 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".

> 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.

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.

> 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".

> 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 there are other reasons... dust, protection against physical damage, etc.
My PC is locked enough to protect them, but opened enough so I can "play" with
it whenever I need)

> > And, FYI, when programming in java, C++ or C#, I do use "private" and
> > "protected" variables, not becasue I want to forbid others from using it,
> but
> > because it is [rightly?] assumed that everything marked as public is safe
> to use
> > - and I consider that a strong enough "external" reason to do it.
> 
> You could just use leading underscores and note their meaning in the
> documentation. If that's such a great approach, why not do it? Yes, I
> know, it's not a widely used convention in those other languages. Fair
> enough. 

It is not a widely used convention, and that is reason enough for me. It's quite
a contradiction to say in the code "this thing is safe to use" and then document
it as "highly unsafe - do not touch". With Java and C# I'm more lenient (and
work more with explicit interfaces rather than just the public/protected/private
thing).

BTW, the actual 'private' case for most languages is a different beast: it is
used to prevent namespace pollution/name clashes. I can't easily simulate those
with public attributes in C#/Java/C++ (but I concede that their 'privates' do a
better job at this than python's self.__local)

> But you could still do it if it's such a good idea.

I think someone commented in this thread about a case where he had to do exactly
that.

[copying from your other reply]

> But what if I want an automatic check to verify that I am using it as
> the author intended? Is that unreasonable? Think of enforced access
> restriction as an automatic "assert" every time an attribute is
> accessed that it is not a private attribute.

I think that was a reply to a message where I said that I used pylint run those
checks on third party libraries. And I obviously can do the same with my own
code. I don't have threading now, so I can't check if I really said that. If I
didn't, well, I'm saying it now.

Now, as Paul Robin pointed out, those statics checks done by pylint can't catch
a runtime workaround using eval, exec or getattr/setattr. But neither can C++.

By the way, I urge you to try to write code that pylint doesn't complain about.
It's easy to not be satisfied with the checks it provides if you haven't used it.




-- 
Luis Zarrabeitia
Facultad de Matemática y Computación, UH
http://profesores.matcom.uh.cu/~kyrie