Quoting Steven D'Aprano <st...@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 -- http://mail.python.org/mailman/listinfo/python-list
