Python as Guido Intended
apardon at forel.vub.ac.be
Thu Nov 24 12:09:26 CET 2005
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
> 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.
More information about the Python-list