Python as Guido Intended

Mike Meyer mwm at mired.org
Tue Nov 29 12:40:03 EST 2005


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

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

>> Etc. These could cause a specific proposal
>> to be rejected, even if the proposed facility acceptable. Then you
>> have to consider how it affects the rest of the language. Adding
>> another way to do something isn't reason to reject it out of hand, but
>> it's a minus. Consider whether the same end can be achieved in another
>> way - preferably without changing the language (Python is *very*
>> powerful, a you can do quite a bit with it that isn't obvious),
> But there should be one obvious way to do things. That there are
> lots of unobvious way to do the same thing thus shouldn't count
> against a proposal that introduces an obvious way to do it.

"Obvious" is also a subjective statement, so adding *any* other way to
do things is a minus.

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

Further, if someone doesn't have a need, trying to make someone elses
need fit is largely a waste of their time, though some people -
language wonks - will do it anyway. On the other hand, pointing out
that something is bad is *not* a waste of their time, as it protects
something good. So basically, you're asking that people waste their
time on something of dubious value. Not a request that's likely to be
get very far.

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



More information about the Python-list mailing list