Python as Guido Intended

[Mike Meyer]

rurpy at yahoo.com writes:
> Different programming styles are appropriate for different
> tasks, different times and different places, different people.
> And like morality, government, or economics, I do not believe
> that one style of programming fits all situations.

If I read you right, what you're saying is that hammmers aren't good
at driving screws. I don't think anyone would argue about that.

> But I do not think (and reading c.l.p convinces me) that GvR and
> Python's developers know a coding style that works best in all
> situations.

I don't think that GvR believes he knows such a coding style,
either. I certainly don't believe it.

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

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

Adding features makes the language processor bigger. With Pythons
strong commitment to backwards compatibility, these are hard to get
rid of. Further, while those of us who like the Pythonic style may not
have to use them, that won't prevent us from having to maintain code
that uses them.

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.

> This has the benefit of attracting more people to Python.

And why is this a benefit?

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