Python as Guido Intended

[rurpy at yahoo.com]

<rhettinger at gmail.com> wrote in message
news:1132768993.161352.260810 at g49g2000cwa.googlegroups.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 ;-)

I don't disagree with your points and in reality mostly follow
them.  I have found out that it is easier to work with Python
than against it.  And the overall results are on the plus side
of the scale (because I still use it.)  You are describing the
way Python is, and saying a small change in my attitude
will make using Python easier.  I am saying that a small
change in the view of Python's developer's will make Python
a better and more versatile language.

I want two things from a language -
1. Effectiveness - I want to be able to solve my programming
    tasks quickly.  This means good language design, rich and
    powerful datatypes and language features, wide coverage
    library, good documentation, etc.
2. Generality - to be able to use it in a wide range of environments
    and satisfy a wide range of needs: interactive calculator,
    one-off quickie programs, small task programs, large systems,
    gui and command line programs, OS code,... this is a very
    long list.

Python is pretty good at number 1.  It is good, but less
good at #2.  (The biggest limitation in #2 is it's slow runtime
performance but that is a different subject.)

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.  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 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.The sense I have with Python is a little like
I have seen in certain religious or very ideological political
groups -- "our way is the one true way".  I just can't buy
that.

My reaction also results from my belief that supersetting
is good.  A language that allows for writing Pythonic code
and additionally allows for writing in other styles, is better
that one the enforces a Pythonic only style because it
serves the needs of a wider audience.  (Obviously it
is possible to write non-Pythonic code in Python but I see
the Python development community as trying their best to
suppress this ability.)  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.  This
has the benefit of attracting more people to Python.

In practice, as I said, more often than not, I do "swallow the
pill, smile, and be happy", and write my code Pythonically
(or my best approximization of that, given my inexperience
with Python).  Nevertheless, there are times when I have to
sacrifice clarity maintainability, or otherwise write in a way
that has negative costs (in my judgment) in order to do
this.  There are other times when I use another language.
And I continue looking for a better language.

You say, "Pounding a square object into a round hole should
be a cue that you're doing things the hard way".  But I think
that the fact that some things are "recurring theme"s should
also be a cue. :-)

I am under no illusions that I am going to convince you,
GvR, or anyone else to change your views.  But at least I
tried :-)

And thanks for your thoughtful and informative response.