Python as Guido Intended

[Mike Meyer]

Antoon Pardon <apardon at forel.vub.ac.be> 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 <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.