On Dec 5, 7:20 pm, Lawrence D'Oliveiro <[EMAIL PROTECTED] central.gen.new_zealand> wrote: > In message <[EMAIL PROTECTED]>, Aaron Brady wrote: > > > On Dec 5, 4:32 am, Lawrence D'Oliveiro <[EMAIL PROTECTED] > > central.gen.new_zealand> wrote: > > >> The code people write is probably a direct reflection of their thinking > >> processes: For example, slow, plodding, one step at a time, incapable of > >> imaginative leaps, versus those who operate directly on larger patterns > >> at once... > > > That distinction operates indirectly on smaller patterns.
Well, I was trying to be funny. But sarcasm is defined as something said in jest that someone else would say seriously; so perhaps it's not the most reliable tone for text. Chalk it up to a failed communication, even though a successful expression. I agree that programming takes imaginative leaps and operates on large patterns. You implied that people's thinking processes vary by "pattern size", which I thought was interesting. But 'leaps' implies carelessness (wrong word, possibly). Is it possible to tackle a large pattern one step at a time? Say, writing a quick sort in assembly? > Do you find this > > (open, gzip.GzipFile)[Entry.endswith(".gz")](os.path.join(PatchesDir, > Entry), "r") > > complicated or hard to understand? It's not easy. I can't understand it at a glance, if that is your question. But it's not obfuscated, that is true. If I can compare programming to chess: I look at a board and you tell me, 'white to play, mate in 5 moves.' If the board is busy (not just Rook and King), it could take a long time to find the mate. It's complicated, but not hard to understand. It requires "holding" (introducing a term) several things in mind at once: first expose the Bishop, then capture the Pawn, etc. But it is not easy in the same way that a 'mate in one' board is, even though the pieces are the same. > It's made up of very simple pieces, > combined according to very simple rules, viz:- > > A tuple of candidate functions: > > (open, gzip.GzipFile) > > A choice from that tuple according to a condition: > > [Entry.endswith(".gz")] > > And finally, arguments to pass to the chosen function: > > (os.path.join(PatchesDir, Entry), "r") As you explain, your program (taking the fragment to be an entire program) is composed of three "very simple pieces". I would say, write them as three very simple pieces. Here's a possible compromise between yours and Arnaud's: if Entry.endswith(".gz"): opener= gzip.GzipFile else: opener= open opener( os.path.join(PatchesDir, Entry), "r" ) It's kind of swampy, I concede. About the same number of characters, 5x the lines. Maybe something in between: opener= (open, gzip.GzipFile)[Entry.endswith(".gz")] path= os.path.join(PatchesDir, Entry) opener( path, "r" ) > See, it's so simple, a child could understand it. A child who isn't burdened > with the preconceptions that seem to afflict some participants in this > noisegroup... 'No preconceptions' is a pretty tall order. The most basic facts about the natural numbers weren't formalized until the 1880s, but people used them successfully for thousands of years before, evidently on preconception alone. To be plodding and slow (as well as meticulous and deliberate, by the way), the child would need 'preconceptions' about tuples, functions, Boolean variables, etc. You might call those plain 'conceptions', and use the other definition, 'bias' for noisegroup participants. Emotions are biased, as are small sample sizes (small-sized samples). I think it's also a tall order to ask a group of people to keep objective for any length of time. Thus, since we're people, and we're interacting, and we can't keep objective forever, we'll be non- objective sometimes, and therefore won't all understand your program. Perhaps you are wanting to write a 'preconception-tolerant' program: a program that is tolerant of (can be read by) readers with preconceptions. But I'll bite: what preconceptions? Favoritism? -- http://mail.python.org/mailman/listinfo/python-list