Python as Guido Intended

[Antoon Pardon]

On 2005-11-30, Mike Meyer <mwm at mired.org> wrote:
> Antoon Pardon <apardon at forel.vub.ac.be> writes:
>> On 2005-11-29, Mike Meyer <mwm at mired.org> wrote:
>>> Antoon Pardon <apardon at forel.vub.ac.be> writes:
>>>>> You see, you can make languages more powerful by *removing* things
>>>>> from it.
>>>> You cast this in way to general terms. The logic conclusion
>>>> from this statements is that the most powerfull language
>>>> is the empty language.
>>> The only way you reach that conclusion is if you read the statement as
>>> saying that removing things *always* makes a langauge more
>>> powerful. That's not what I said,
>> I would say it is the common interpretation for such a sentence.
>
> You'd be wrong. "Can" denotes a possibility, not a certainty.

You didn't write:

  Removing things can make a language more powerfull.
  
You wrote:

  You can make a language more powerfull by removing things.


In the first case "can" describes a possible outcome of
removing things.

In the second case "can" describes that this is a decision
you are allowed and able to make. Not the possibility
of the outcomes should you make the decision. 

What your sentence states is that you can make this decision and
that if you do so, removing things will accomplish this goal

> If I'd
> say "You *will* make languages more powerful by removing features",
> then you'd be right. But that isn't what I said.

No this states that I don't have a choice in removing features or not.

Anyway that is how I read those sentences.

I just want to add that I'm not interrested in whether your
interpretation is the right one or mine. I understand now
what you meant and that is enough for meu. The above should
be considered as an explanation of how understood, not as
a correction of how yuo should have wrote it.

>>>>> 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.

And I seem to remember people asking about the possibility of overflow
in Python, but I never understood those inquiries in the sense they
would want it, but more in a sense of how python protects against it.

So I have a bit of a problem understanding the relevance here.

>>>>> 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.

One of my nefews has this kind of army swiss knife with tons of
possibilities. But I find the few tools I have that total less
possibilities more usefull.

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.

> 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.

> 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.

-- 
Antoon Pardon