On Wed, 11 May 2011 11:47:42 +0100, Hans Georg Schaathun wrote: > On Sat, 07 May 2011 21:57:13 -0700, Ethan Furman > <et...@stoneleaf.us> wrote: > : If you're going to use a language, and use it well, you have to learn > : how that language works. > > And if the world evolves around the compiler and you, that advice > suffices. > > However, programming is often as much about developing ideas in a large > and complex community, where perfect universal mastery of one language > is not an option, because half the community do not normally use that > language or aren't really programmers at all. The less you assume about > the skill of the reader, the better it is.
Do you think that we should avoid chained comparisons, class methods, closures, co-routines, decorators, default values to functions, delegation, doc tests, exceptions, factory functions, generator expressions, inheritance, iterators, list comprehensions, operator overloading, properties, regular expressions, tuple unpacking, or unit tests, to say nothing of *advanced* techniques like descriptors or metaclasses, just in case the person reading your code is a clueless n00b? We routinely and uncontroversially use all of these techniques (well, sometimes metaclasses get a few raised eyebrows). Truth testing is MUCH simpler than any of those. It is extremely patronizing to say that we should avoid truth-testing arbitrary objects because it is too complicated for other people. It's not hard, and they can learn. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
