<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> [EMAIL PROTECTED] 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.
--
http://mail.python.org/mailman/listinfo/python-list
