On Wed, 11 May 2011 15:34:28 +0100, Hans Georg Schaathun wrote: > 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.
Which makes them clueless newbies *about Python*. I don't care how experienced they are in astrophysics or biology or calculating the average airspeed of an unladen swallow. > 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. Yeah, life is hard and then you die, and scientists don't even get paid that much. So what? Do physicists write their scientific papers about string theory with the thought "What if some Python programmer who knows nothing about string theory is reading this? I better dumb it down." Of course not. A ridiculous idea. They use their tools the way they are designed to be used, and outsiders have to learn the language and the jargon to make sense of it. This is not a problem that needs solving. It's one thing to simplify code that you are explicitly using as a teaching aid. That's a good thing, I approve of that. But it's a completely different thing to dumb down production code because you think some non-programmer might have to read it. > 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. Of course it does. It means you don't have to care about implementation details of what emptiness means for a list. It means you don't force the reader to read, parse and understand three extraneous terms. It means you don't force the reader to wonder why you bothered to use a long-winded test when a short test would do, or be concerned that maybe > 0 is a typo and you actually meant > 10. [...] > 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. No. You have that exactly backwards. The point of "if x" is that you DON'T have to care about how the boolean conversion works, because the object itself encapsulates that behaviour. This is basic object-oriented principles. When you call len(x) you don't care about the details of how to calculate the length of x. The object itself knows so that you don't have to. The same applies to truth testing. I have a data type that is an array of lists. When you call "if len(x) > 0" on it, it will blow up in your face, because len(x) returns a list of lengths like [12, 0, 2, 5]. But if you say "if x", it will do the right thing. You don't need to care how to truth-test my data type, because it does it for you. By ignoring my type's interface, and insisting on doing the truth-test by hand, you shoot yourself in the foot. > E.g. Anyone who has used list/set comprehension in Z, haskell, set > theory, or whereever will understand python list comprehension > immediately. Yes. And anyone who hasn't, probably won't. But they will learn. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
