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 13:07:55 -0500, Luis Zarrabeitia wrote:
> 
> > It should be in _our_ power as the team of all participant coders on
> > _our_ project to decide if we should mess with the internals or not.
> > 
> > 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.
> 
> 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. Or, if external forces make him do it (maybe
like, 'oh, if I change python, then I'm not using python anymore').

> Let's be specific here. The list implementation in CPython is an array 
> with a hidden field storing the current length. If this hidden field was 
> exposed to Python code, you could set it to a value much larger than the 
> actual size of the array and cause buffer overflows, and random Python 
> code could cause core dumps (and possibly even security exploits).

In which case, my code would be broken. (Wait, let me be clear: in which case,
our team's code may be broken - but it was _our_ team's decision, knowing the risk).

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.

Anyway, did you notice that your "counter-example" was a radical
change-the-way-python-works scenario? I also don't want to change the
interpreter's code on the fly. Now, if you take that as a confession that I
really, really, want enforced data hiding and that everything I've said is plain
wrong, so be it. After all, I treat python's interpreter as a black box, don't I?
 
> 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.

> As I see it, you have two coherent positions. On the one hand, you could 
> be like Mark Wooding, and say that Yes you want to risk buffer overflows 
> by messing with the internals -- in which case I'm not sure what you see 
> in Python, which protects so many internals from you. Or you can say that 
> you made a mistake, that there are *some* good reasons to protect/hide 
> internals from external access.

Or, I could have a third option: assume that I am a grownup who knows what he is
doing. After all, even with all those "protections" in list, I could just create
an extension module to shoot me in the foot anyway, if I really wanted to.

> In the second case, the next question is, why should it only be code 
> written in C that is allowed that protection?

Bug? Not worth the effort of exposing those variables? I don't know...

[Btw, do you realize that C++'s private also don't provide that protection? I
have almost no experience with C++ and found it trivial to circumvent]

I don't think this is going anywhere. Now you are trying to push me to the
extremes, changing what I _said_ for your exaggerated interpretation of it just
so you could shoot it down, or force me to say that I want buffer overflows in
python. I believe that's called "strawman".

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?

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