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

[Luis Zarrabeitia]

Quoting Steven D'Aprano <steve at REMOVE-THIS-cybersource.com.au>:

> On Fri, 23 Jan 2009 21:36:59 -0500, Luis Zarrabeitia wrote:
> 
> > Quoting Steven D'Aprano <steve at REMOVE-THIS-cybersource.com.au>:
> >> Makes *no* sense? There's *no* good reason *at all* for the original
> >> author to hide or protect internals?
> > 
> > My bad, sorry.
> > It makes sense... if the original author is an egotist who believes he
> > must control how I use that library.
> 
> Then I guess Guido must be such an egotist, because there's plenty of 
> internals in Python that you can't (easy) mess with.

Yeap, ignore the second part, and claim that I only said this.
 
> > Or, if external forces make him do
> > it (maybe like, 'oh, if I change python, then I'm not using python
> > anymore').
> 
> That parenthesised comment makes no sense to me.

It was directly countering your 'list' example. _I_ don't want to change
_python_, nor python's assumptions and assurances. A standard python that can
segfault would be no python. Again, if you think that means that deep down I
like enforced data hiding, so be it.

> [...]
> > If a variable is marked as... I don't like 'private', I'll call it
> > 'implementation detail', I would not use it without good reason. Not
> > even by subclassing it. Why do you assume that I'd change list._length
> > if I could? I wouldn't.
> 
> I didn't say you would change it on a whim. I said that *if* it were 
> exposed to Python code, you *could* change it. You might change it 
> because you thought you had a good reason to. You might change it by 
> accident. You might not realise the consequences of changing it. Who 
> knows? It doesn't matter what your motives are.

Exactly, they don't matter to you, unless you happen to be running my code.

> My point is that you claimed that there is no good reason at all for 
> hiding implementation details. Python is full of implementation details 
> which are quite effectively hidden from Python programmers. So there are 
> two possibilities:

I didn't say "at all". Those were your words, not mine.
I said that it makes no sense that the power lies on _you_ instead of on _my
team_. And, when I said that, I recall we were talking about the python
language, not C.

> (1) you are right that it "makes no sense" (your words) for the original 
> author (in this case, Guido) to hide those implementation details from 
> Python programmers; or

Just to be clear: I think the opposite.
He made a language and interpreter, and it ensures that it will not segfault
because of incorrect pure python code. That is my blackbox. In doing that, he
made a language where I don't have to worry that much about enforcing access
restrictions. Again, if you think that means that I want enforced data hiding in
python, so be it. 

> (2) you are wrong that it "makes no sense", because there is at least one 
> case where the original author (Guido again) did a sensible thing by 
> hiding implementation details.

hiding the implementation details of a C implementation... not python.

> In an effort to avoid going round and round in circles, let me explicitly 
> say that option (2) does not imply that it always makes sense to hide 
> implementation details.

Huh?
It makes sense to hide implementations details. I'd say it always makes sense.
What doesn't make sense is that someone fights so vehemently to stop me from
getting at them, on my code, on my systems. 

> [...]
> >> So what you're saying is that the fundamental design of Python -- to be
> >> a high-level  language that manages memory for you while avoiding
> >> common programming errors such as buffer overflows -- makes "no sense".
> >> Is that what you intended?
> > 
> > Yes, that's what I intended, obviously. I'd like to have buffer
> > overflows in python. In case you don't understand irony: don't go
> > putting words in my mouth. I'm not putting words in yours.
> 
> And neither am I. I'm pointing out the logical implications of your 
> position. If you find those implications unpleasant, then perhaps you 
> should modify your position to be less extreme and more realistic.

But it is realistic. You put the words "at all", and you shifted the discussion
from Python to C, and from programs in python to python's implementation.

[snip the comments about the advantages of data hiding. We are not talking about
data hiding, we are talking about having data hiding enforced against me]

> > I stand by my words - but not by your "interpretation" of them:
> > 
> >> > What makes no sense is that it should be in the original author's
> >> > power to decide, if he is not part of _our_ team.
> > 
> > Do you _really_ read from that sentence that I should dislike python
> > because it makes it a bit harder to get a buffer overflow with their
> > native types?
> 
> Well, you tell me: does it make sense for Guido to have decided to make 
> it hard for pure Python developers to cause buffer overflows?

Yes it does.
And this answers my question... You do consider the fact that I like python, 
that I like that python is not C, and that I use python as a blackbox, as a
confirmation that I want enforced data hiding. 

I was truthful when I said that: if you think so, then so be it, feel free to
think that I want it. We are obviously not on the same page here, we are not
even talking about the same language. I guess (just a guess) that in your view,
if I really didn't want enforced data hiding, I'd be programming directly in
machine code or maybe making my own CPUs. If your idea of enforced data hiding
includes that (it obviously includes the interpreter), then what I said was
wrong. I assumed we were talking about python and that I didn't need to
explicitly quantify my expressions.

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.

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