Python as Guido Intended

[Antoon Pardon]

Op 2005-11-24, Mike Meyer schreef <mwm at mired.org>:
> "bonono at gmail.com" <bonono at gmail.com> writes:
>> Mike Meyer wrote:
>>> > I do think that the Python development community believes they do,
>>> > or more accurately, that if someone wants to use a different style,
>>> > they can go use something else.
>>> In other words, they believe that you should use a screwdriver to
>>> drive screws, and not a hammer. You apparently disagree with them.
>> That is the kind of argument I see all the time on this thread. It is
>> more appropriate to say that "I don't believe it is a screw, but
>> something else and don't want to use a screw driver with it".
>
> Whatever it is, trying to turn Python into a tool for dealing with it
> isn't the right thing to do.
>
>>> > I think that it is possible to include in Python, things that are
>>> > non-Pythonic (such as a return value from sort()) that allow users
>>> > more stylistic freedom, without degrading the ability of those who
>>> > don't want to use such features, to write in a pure Pythonic manner.
>>> So you think we can turn a hammer into a screwdriver without degrading
>>> the ability to use the hammer to drive nails. The problem is, doing
>>> this means you have a bigger, heavier hammer - which almost certainly
>>> degrades the ability to use it as a hammer.
>> And it follows through, first said it is a screw and since you
>> disagree, you are trying to do screwing with a hammer.
>
> You're the one that wants to use the hammer to do whatever it is, not
> me. I don't believe in silver bullets. Python is good at what it
> does. If I need a different tool, I use a different tool, rather than
> try and mangle a good tool into something it's not.

Why do you use the word "mangle" here? I'll come to this again later.

> Such attempts are
> pretty much doomed. They nearly inevitably producej a tool that's not
> as good at what the original did as the original, and not as good at
> whatever new task it's being mangledd to do as a tool that was
> designed for that in the first place.
>
>>> Now, I'm not against changing the language per se. But most language
>>> changes have deeper implications than are obvious at first
>>> glance. Even when they don't, I'd prefer that you get cases that make
>>> for significantly cleaner code without having major negative
>>> connotations. The first is why people ask for "use cases": they want
>>> to see a real-world example where the proposed change would make
>>> things cleaner or more readable, or otherwise better in some way. At
>>> the same time, the new feature should provide an abuse that's hard to
>>> read, or lead to code that is easily misinterpreted.
>> I am just curious that if the "should we have ternary" back then
>> creates similar arguments.
>
> By the results of the vote, most people wanted ternary. The use
> cases for it are well know. From what I recall, the debate was over
> which of the many proposals should be adopted.

No it wasn't. From what I have picked up, the ternary operator
was finaly introduced after one of the developers tripped over
the commonly used idiom to simulate a ternary operator, which
can fail in certain cases.

Anyway, when I was arguing for a ternary operator in python,
those who opposed me, certainly gave me the impression that
they thought I wanted to mangle the language, the mere idea
of a ternary operator was against the spirit of python.

When I argued for a more general loop construct similar
objections were made and the proposal was fiercely fought.
Someone even started a PEP, with the intention to bury 
the idea. (That can be from before I argued for it)

Now I have read about both that they will be introduced in
Python 2.5 without a whisper of protest.

>> Based on what I have read for this few period of time on this group, it
>> is actually not people coming in complain loudly that "why can't Python
>> have this" kind of post, it usually was a neutral question because
>> either they come from another background, or they for whatever reason
>> expect things to work certain way, or they enjoy certain style. But
>> many times, the responses are toned in a way of "you dumb, you didn't
>> know that is the wrong way of doing it?", without explain why or with
>> convincing reasons.
>
> The usual response is "That's not the Python way." That's not calling
> someone dumb, just pointing out that they don't yet fully understand
> the Python way.

"That is not the Python way", is just saying "Python doesn't have it"
in other words. So it can't be the answer to why python can't have
something.

> The Python way is not something you're going to grok
> by reading postings on usenet. You can have bits and pieces explained
> to you, and your understanding will increase. And that's the way it is
> for everyone but GvR.

The python way is something that changes continuously. What is the
python way now certainly wasn't the python way with version 1.5
(when I started).

So "That is not the python way" doesn't answer the question why
it couldn't be the python way.

-- 
Antoon Pardon