Python as Guido Intended

[Mike Meyer]

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

>>>> Wrong. There are some thing which there should *not* be a way to do.
>>>> For instance, there should not be a way to produce a segmentation
>>>> fault - which means certain features common to other languages will
>>>> never be added.
>>> Then C-extentions shouldn't be allowed.
>> C-extensions aren't part of Python.
> As far as I understand, if you implement a class with a C-extension,
> then that class is understood to be part of Python. So if you
> think there should be no way to produce a segmentation fault in
> python you shouldn't allow such classes.

You understand wrong.

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

>>>> In summary, the design philosophy is that it's better to do without
>>>> some facility than to add it in a way that doesn't fit with the
>>>> language, and the process reflects that.
>>> I don't mind that a proposal is worked on and that counter-proposals
>>> can be made. But some people just seem to counter any new proposal,
>>> while other are more interrested in searching for ways to make
>>> the new proposal fit the language. Now sometimes a proposal can't
>>> be fitted and gets rejected, so be it. But maybe more could be
>>> fitted in the langauge if more people were willing to look for
>>> ways to fit something, instead of rejecting it simply because
>>> the current proposal doesn't fit properly yet.
>> The only way this would be good is if "more features" were inherently
>> better. That's simply not true. So the change in behavior you're
>> looking for isn't clearly good.
> No, this is good while there are still possible features that could make
> python a better language

In that case, they're doing exactly what you want: they're making sure
that possible features make python a better language. You seem to
think they should stop doing this. I disagree.

     <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.