[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 ;-) respectfully submitted, Raymond -- http://mail.python.org/mailman/listinfo/python-list
