On 11 May 2011 13:45:52 GMT, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: : 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?
Not at all. On both accounts. 1. My concern was not about clueless newbies. They need to learn. My concern is about experienced scientists and engineers who are simply new to python. They will be dealing with a dozen different languages (programming and otherwise), with a need to read more languages than they can possibly learn to master. 2. You should avoid constructs which can /reasonably/ be avoided to /increase/ legibility. Writing if x for if len(x) > 0 when you know that x is of some sort of collection type with len defined does nothing to help legibility. Many of the socalled advanced constructs you mention are used to increase legibility one way or another. Others will simply allow functionality which would otherwise be impossible. I don't object to using if x in a case where x may or may not have len() defined. : 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. Simpler, yes, but it surely depends on more detailed knowledge. One has to remember how the boolean conversion works, for each possible data type. This requires looking up the rules for each data type. E.g. Anyone who has used list/set comprehension in Z, haskell, set theory, or whereever will understand python list comprehension immediately. : 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. Again you miss the point. It is not /too/ complicated. It is /unnecessarily/ complicated. You don't noticeably gain anything by using if x instead of if len(x) > 0, if you know that the latter is defined. If everyone who ever needs to see your program is a python programmer, then your approach works as well as mine. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
