Python as Guido Intended

[rhettinger at gmail.com]

bonono at gmail.com wrote:
> it seems that quite some people
> don't see the language as the creator or wants them to see it.

Here's my two cents on this recurring theme.

While nothing forces a particular programming style, there is some
merit to swimming with the current rather than against it.  Observing
five years of newsgroup posts, I've observed that many who struggle
with language or get angry about some part of it are fighting the
language rather than using it as intended/designed.

IMO, following designer intent leads to happiness because Guido's
philosophies so thoroughly pervade the language.  So, when you accept
his viewpoints, you'll find that all the parts of the language tend to
fit together neatly and easily.  Conversely, fighting the language
tends to result in one struggle after the next.

For example, there is a person currently working on a new proposal for
a container freezing protocol.  In order to overcome all the
fundamental difficulties (like what to do with mutable values when
freezing a dictionary), the proponent is finding that he has to suggest
pervasive changes to the language (including mutable strings, recursive
freezing protocols, mutation notifications, etc).  I suspect that he is
fighting the language.  It is not so much that his idea is wrong, it is
just that he is effectively creating another language that is not
Python.

My own experience with adapting to Guido's design-view relates to
tuples and lists. To Guido, tuples are for records and lists are for
iteration.  My own inclination is to view tuples as immutable lists.
Accordingly, it seems obvious to me that tuples should have count() and
index() methods for better substitutability.  However, I've learned
that adapting to Guido's world-view leads to happiness because Python's
function signatures tend to reflect his design view.  So, when I'm
thinking the Guido way, my code comes together seamlessly.  When I
persist with a conflicting viewpoint, I find myself having to make
conversions, write work-arounds, or create more helper functions than
otherwise needed.

Keep this in mind when finding yourself madder than heck about
mylist.sort() returning None or zip(it,it) intentionally not
documenting its implementation quirks.  IMO, using the tools as given
leads to easily-written, clean, maintainable, beautiful code.  Learn to
love what makes Python great.  Pounding a square object into a round
hole should be a cue that you're doing things the hard way ;-)

respectfully submitted,


Raymond