On Fri, 01 Jul 2005 13:42:10 -0400, Mike Meyer wrote: > "iK" <[EMAIL PROTECTED]> writes: > >> Seems like he wants python programmers to solve their problems all in the >> same way. While that is great for corporate slaves it is terrible for the >> creative programmer. > > No, he wants Python to be Pythonic. TMTOWTDI is not Pythonic.
Too Many T--- Only Way To Do It? There Might Tangle One Way To Do It? T--- M--- Two Obvious Ways To Do It? Nope, sorry, still not getting it. >> Python is quickly becoming the visual basic of the 21 century. If you want >> to have fun while getting some work done you need to look elsewhere. It's a >> shame... > > If you'd rather spend your time figuring out which of multiple ways to > do things is the best for the job at hand than producing code, there's > a language that makes TMTOWTDI a way of life. Figuring out which of multiple ways to do things is the best for the job at hand _is_ part of producing code. There will always be multiple ways to do the job. For starters, there is the choice, which language should I use? Top-Down or Bottom-Up design? Test-driven or not? For loop or list comprehension or generator? Procedural programming or object-oriented or a mixture of both? Singleton or Borg design pattern? Test your data first or deal with the exceptions when they happen? And so on. Only One Obvious Way makes a nice slogan, but it is easy to turn a flexible language like Python into a straight-jacket where there is Only One Way To Do It Regards Of Whether It Is The Best For The Job On Hand Or Not. Not such a short and concise slogan. Now that Python has list comps, should for loops be removed from the language? Why did Python bother introducing list comps when there is nothing they can do that a for loop can't? Functional programming using map etc does require a slightly different way of thinking about programming than does procedural programming, just as object-oriented needs a different way of thinking than spaghetti-coding using GOTOs. Different ways of thinking about programming should be encouraged, not discouraged. Even the much-maligned GOTO has its modern usage case: the Exception. If map/filter/reduce have to be removed from the built-ins, and I don't think they should, I'd prefer for them to be moved into a module rather than dropped altogether. Provided list comps are made as fast as map and filter, then at the cost of readability they can be replaced by list comps. But reduce can't be written as a list comp, only as a relatively complex for loop at a HUGE loss of readability -- and I've never used Lisp or Scheme in my life. I'm surely not the only one. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
