Python as Guido Intended

[Mike Meyer]

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

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

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