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 -- http://mail.python.org/mailman/listinfo/python-list
