Does Python really follow its philosophy of "Readability counts"?
steve at REMOVE-THIS-cybersource.com.au
Sat Jan 24 00:39:57 CET 2009
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?
More information about the Python-list