Antoon Pardon <[EMAIL PROTECTED]> writes: >>>>>> We don't talk much about how you produce buffer >>>>>> overfows in Python, but people have asked for that as well. Adding >>>>>> ways to write hard-to-read code is frowned upon. And so on. >>>>> Do you mean people have asked for the possibility that a buffer >>>>> overflow would overwrite other variables? >>>> Buffer overflows don't have to overwrite variables. They just asked >>>> how you create buffer overflows in Python. >>> I do wonder what they mean with a buffer overflow. Would the following >>> classify: >>> buf = range(10) >>> buf[10] = 10 >> Well, you'd have to ask them. Personsally, I wouldn't count that, >> because no data outside the scope of buf got written to. > I find this odd. You seem to argue that you don't want bufferoverflows > allowed in python, but then you don't seem to know what is meant by it. > If you don't know what they mean, how can you decide you don't want it.
I know what *I* mean by it, and I don't want to allow that. You asked what someone else meant by it - I don't know that. The best I can do is give you my take on it. > So I have a bit of a problem understanding the relevance here. It's one of the list of things people ask about an extensions. FWIW, that list is meant to be examples, not a definition. There are *lots* of other things to check. >>>>>> I won't speak for others, but I wouldn't reject it out of hand. You >>>>>> haven't provided enough information. Accepting it just because it adds >>>>>> a way to do something is wrong. First, you have to ask whether or not >>>>>> that something is something we want in Python at all. Then you >>>>>> consider whether how the way proposed fits with the language: is it >>>>>> ugly? >>>>> That is a highly subjective question, answering it says more about >>>>> the person then about the proposal. >>>> True. But whether or not a language is good is a highly subjective >>>> question. Since the goal - keeping python good to the people who >>>> already consider it good - is subjective, it's only natural that part >>>> of the evaluation process be sujectie. >>>>>> Is it prone to abuse? >>>>> I don't see why this is always brought up, given the number of >>>>> features that can be abused in python. >>>> Just because Python isn't perfect is no reason to make it worse. >>> Why is it worse. You seem to think that if one has a toolbox, which >>> lacks a hammer, that the fact that the hammer can be abused makes >>> your toolbox less usefull if you add a hammer to it. >> Look again. I never said it would make Python less useful, I said it >> would make it worse. Those aren't the same thing. It's possible to >> make a language both more useful and worse at the same time. For >> instance, Python would clearly be more useful if it could interpret >> perl 6 scripts. > > I disagree. Having more possibilities doesn't imply more usefull. You're right. But I didn't say that. > Now adding a extra possibilty to the army swiss knife may make > it worse, less usefull. Putting an extra tool in my toolbox > doesn't make it worse or less usefull, since I can just ignore > the tools I don't use. Not true. If I put enough extra tools in your toolbox, it will eventually get to heavy to lift. A single tool, poorly chosen - like a band saw - could have the same effect. >> Personally, I think adding the features required to do >> that would make the language (much, much) worse. Oddly enough, I think >> adding the features to Perl so it could interpret Python scripts would >> make it better as well as more useful :-). >>> We have a toolbox, full of equipment that can be abused, yet >>> that something else can be abused too, seems to be a mayor >>> stumbling block for adding it. >> "Major" is your word, not mine. > That is the impression I get from the emphasis that is always > put on abuse possibilities of a proposed addition in this > group. Well, if they're bad enough to bring up, they probalby are major. >> I just listed it as something to >> consider. It may be there's an obscure corner case that's really >> abusive, but chances are no one would ever stumble over it. That's not >> a major problem. On the other hand, if there's an obvious and >> attractive use that's abusive, that's a reason for looking for another >> way to add that functionality. > Well you said it, that's a reason for looking for another way to add > that functionality. My impression is that few people look at it > that way, but instead seem to think it a reason to simply reject the > functionality. So? If they don't need the functionality, why should they look for another way to add it? In fact, there's a fair chance they aren't really qualified to evaluate a proposed solution in terms of adding the proper functionality. Like I said before (or elsewhere), most people won't bother with that, but a few language wonks will. If you want another feature, it's up to you to propose an acceptable mechanism to add it - or convince someone else to do it for you. If you expect people to do work for you gratis on a regular basis, I'm afraid you're in for a lot of dissapointment. <mike -- Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list