Python as Guido Intended

[Mike Meyer]

Antoon Pardon <apardon at forel.vub.ac.be> writes:
> Op 2005-11-25, Mike Meyer schreef <mwm at mired.org>:
>> Antoon Pardon <apardon at forel.vub.ac.be> writes:
>>> Well this is, is one thing I have a problem with.
>>> The python people seem to be more concerned with fighting things
>>> that could be used counter the python philosophy, than search for
>>> things that enable working in the python philosophy.
>> And what's wrong with that?
> It seems a bit intollerant and contraproductive to me.

I suspect it seems that way because you belief two falsehoods:

Falsehood #1) There's little or no value in protecting something good.
Anyone who's seen a good thing vanish will tell you this isn't
so.

Falsehood #2) Adding things makes a language better.

This simply isn't so. Anyone who's been around computers for any
length of time has heard of featuritis. It afflicts programming
languages as well. A language with 2n features is not inherently
better than a language with n features - it's just got more
features. The 2n language may actually be less powerful.

You see, you can make languages more powerful by *removing* things
from it. Removing static typing leaves you with dynamic typing or duck
typing, both of which are more powerful than static typing. Removing
the need to explicitly free things - even though explicit is better
than implicit - means programmers don't have to worry about such, and
pretty much eliminates several classes of bugs. Removing restriction
on what you can do to an object - making them "first class" - results
in some very powerful facilities that simply don't exist in languages
where that hasn't happened. Since I've been writing Python, it's
gotten more powerful because of such removals.

> If thet would just concentrated on what they want, they could
> have progressed further on that road, then where they are now,
> because progress sometimes simple stops because other could
> use something for what it was not intended.

They know what they want. They want python to remain unbroken. Having
seen languages that have been broken to appeal to a new user
population, to appease a software vendor, and - in an extreme case -
because a drunk developer thought it was amusing, I'm *glad* that new
features are only added to Python after they've been beaten on and
thought about and in general had the implications of adding them
explored in depth by the community.

>>>> Yes. And if you need a red hammmer, you should get a red hammer, not
>>>> use red spray paint on one that wasn't designed to be red. Just
>>>> because *you* don't see how providing a red option violates the
>>>> philosophy of python doesn't mean that it doesn't do so.
>>> Well this seems to be the main conflict between those who would
>>> like Python to go a bit further and those that oppose it.
>>> Should the priority be to enable python's philosophy or should
>>> it be the priority to limit python to only allow it's philosophy.
>> Those two statements say the same thing.
> They are not. 

Yes, they are.

>> Part of the Python philosphy,
>> from "import this", is that there should only be one obvious way to do
>> it.
> It doesn't say that. It says:
> There should be one-- and preferably only one --obvious way to do it.
> Here you see the difference on emphasis. You are focussing on the
> only one, while the original Python Koan seems to focus on the
> there should be one.

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

> So supose someone proposes a change that will introduce one
> obvious way, to solve a particular problem. However it
> introduces a second obvious way to solve an other problem
> too.

In other words, they propose a change and come up with a use case,
which is SOP.

> I think we should accept such a proposal. It seems you and
> a lot of others seem to think such proposals should be
> rejected.

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? Is it prone to abuse? 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
see if there's some way to do this without negative side
effects. Finally, you have to consider the implementation: can it be
implemented efficiently and in such a way that it won't be confusing?
Features have been rejected at this stage - meaning if the answer
changes, they'll show up.

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. This process has worked well
so far, and there's no obvious reason to think that things would
improve if it changed. Python isn't the only language that has that
kind of philosophy underlying it, and I find languages built with this
philosophy to in general be languages I enjoy writing in, even if they
have nothing else in common.

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