Python as Guido Intended

rurpy at yahoo.com rurpy at yahoo.com
Thu Nov 24 15:14:33 EST 2005


"Mike Meyer" <mwm at mired.org> writes:
> 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.

No, the analogy is more like this.  Python is hammer that comes
in green or blue.  The hammer's developers say (perhaps with
some reason) that cool colors like green and blue are the best
colors because they promote calm when used.  Calm hammerers
are more productive and less violent.  My work is
repairing the inside of dark water tanks.  It is hard to see blue
and green hammers, and to find them if I put them down.
I suggest that Python have the option of red hammers.  The
Python people respond with horror, pointing out the problems
with red hammers.  I say that I am a calm person already,
that I know how to use red hammers safely, but of course
the Python people don't want anything to do with the idea.
"What will happen if your red hammer falls into the hands of
a beginner?" they ask.  (I note that although the hammer does
have a lot of safety features, it is still easy to poke an eye out
with the nail remover if one is not careful.)  They also point
out that adding a third color will cost time and effort.  And
the problems of deciding if the hammer should really be
red, or maybe orange would be better.  So they tell me to go
use a red screwdriver.

Regarding the differences between hammers and screwdrivers...
When a screwdriver is appropriate I use a screwdriver.  If I
need to write code that does a large amount of CPU intensive
number crunching, I use C, not Python.

But suppose someone came up with a Python compiler.  It
would compile any Python program but there would be no
speed benefit unless you carefully wrote the code to not use
many of Python's dynamic features, so that either by type
inferencing or programmer supplied static declarations, the
compiler could generate efficient native machine code
that executes at near C speeds.
Obviously this would require changes (mostly additions?)
to the Python language, though these changes would still
allow today's style dynamic code to be written and run
(though just as slow as today's runs).
The payout would be that things written as C-extensions
today, would be writable in (a restricted form of) Python.
Would the Python orthodoxy favor such a development?
Or would that be turning Python into a screwdriver?

To me, it would be better because I can now do with a
hammer, many of the things I used to do with a screw-
driver.  I can spend more time becoming a better hammerer,
and less time learning the intricacies of screwdrivers.
My life is better.

> > This has the benefit of attracting more people to Python.
> And why is this a benefit?

More eyeballs to find bugs.  More hands to make improvements.
More minds to make suggestions.  More hearts to share the joy. :-)




More information about the Python-list mailing list