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

[Steven D'Aprano]

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?

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

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?

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.

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


-- 
Steven