Python as Guido Intended

[Antoon Pardon]

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.

> and that's as false as the belief
> that adding things always makes a language more powerful.
>
>>> 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.

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

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

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.

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

-- 
Antoon Pardon