Python as Guido Intended

[Antoon Pardon]

On 2005-11-28, Mike Meyer <mwm at mired.org> wrote:
> 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.

I don't beleif this. What I do believe is, that it is better
to produce more good with those who think likewise than to
prevent those who think differently, from doing what you
think is bad.

> Falsehood #2) Adding things makes a language better.

I don't believe this either.

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

You cast this in way to general terms. The logic conclusion
from this statements is that the most powerfull language
is the empty language.

> Removing static typing leaves you with dynamic typing or duck
> typing, both of which are more powerful than static typing.

Static typing allows for some things that dynamic typing can't do.
At least not as python uses it.

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

Well if you call eliminating restrictions, removing something from
the language I guess you can say that removing things can make
a language more powerfull. But eliminating restrictions IMO is
adding things to the language, those things that were formerly
unallowed because of the restrictions, not removing things from
the language.

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

Then C-extentions shouldn't be allowed.

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

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

That is a highly subjective question, answering it says more about
the person then about the proposal.

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

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

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

This is not the kind of rejection I'm talking about. This is a
problem of implementation, not a rejection of an idea.

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

-- 
Antoon Pardon