Don't you just love writing this sort of thing :)

[Lawrence D'Oliveiro]

I did reply to your message. It was your message that was missing all the
context necessary to tell what you were rabbiting on about.

If you wanted the context for your reply, you should have replied to the
message with the context. That way you automatically get the context when
you hit reply, no need to go out of your way to dig it up from a different
posting.

Does that make any sense to you, or should I start drawing simple diagrams?

 

[Lawrence D'Oliveiro]

It would have been far more concise ...

Gee, I thought people were complaining it was too cryptic, now it turns out
they were actually complaining because it was too verbose.

 

[Lawrence D'Oliveiro]

In message

Originally, like many others here I said YIKES! but on a second read,
it is not that bad. It actually grows on you.

After looking at it one more time I found it neat, very concise
without being unreadable.

The key thing is, it's functional, not procedural. Instead of a sequence of
statements performing actions, it uses expressions that compute values.

Here's another one (from <http://github.com/ldo/linear2d/tree>):

def MapRect(SrcRect, DstRect) :
"""returns a Matrix that does appropriate scaling and translation
to map the corners of SrcRect to DstRect."""
return \
(
Matrix.translation(- SrcRect.topleft())
*
Matrix.scaling(DstRect.dimensions() / SrcRect.dimensions())
*
Matrix.translation(DstRect.topleft())
)
#end MapRect

 

[Arnaud Delobelle]

That distinction operates indirectly on smaller patterns.

Do you find this

(open, gzip.GzipFile)[Entry.endswith(".gz")](os.path.join(PatchesDir, Entry), "r")

complicated or hard to understand?

(aside: it's funny that someone asks Aaron this quesion as he is the one
who used to post code that almost nobody understood! (although I had a
feeling there was often something interesting in it)).


in Python it is a convention only to capitalize classes, so unless Entry
and PatchesDir are classes it would be better to write them as entry and
patches_dir for example.

Why use (open, gzp.GzipFile)[Entry.endswith(".gz")] when we have had
contitional expressions for a few years now? Instead, you can write

(gzip.GzipFile if entry.endswidth(".gz") else open).

I think it will be faster (as it doesn't require the construction of a
tuple and then the retrieval of one of its elements) and clearer.


It's good to be able to understand (and I guess, to write) such code.
But to assume that others dislike it because they don't understand it
sends several wrong signals:

* you give the impression of being arrogant;

* many people will understand this code snippet perfectly easily but
they won't like it because they think that Python offers much better
ways to express the same thing.

* you seem to disregard the fact that in 'programming language' there
is the word 'language'. A language is a way to _communicate_
information, in the case of a programming language you communicate
it to the computer but also to other human beings.


To come back to your code, you could define a function like the one
below (untested). It'll allow you to add support for different
compression formats easily in the future. This is a 'pattern' which can
be useful to keep in mind and requires *some* imagination.

open_methods = { 'gz': gzip.GzipFile, 'bz2': bz2.BZ2File }

def open_by_ext(path, *args):
ext = os.path.splitext(path)[1]
return open_methods.get(ext, open)(path, *args)

Then your code snippet becomes:

open_by_ext(os.path.join(patches_dir, entry), "r")

 

[Andreas Waldenburger]

Does that make any sense to you, or should I start drawing simple
diagrams?

People, please! Is some civility too much to ask?

/W

 

[Aaron Brady]

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?

 

[Rhodri James]

Do you find this
(open, gzip.GzipFile)[Entry.endswith(".gz")](os.path.join(PatchesDir,
Entry), "r")
complicated or hard to understand? It's made up of very simple pieces,
combined according to very simple rules, viz:-

Yes, it's very pretty, and you're terribly clever. In six months' time
when you come back to make some engineering change and have to sit down and
break it back down into those simple pieces to remind yourself what it's
doing, "pretty" and "clever" will not be the words you are using. Trust
me on this one.

 

[Lawrence D'Oliveiro]

Yes, it's very pretty, and you're terribly clever. In six months' time
when you come back to make some engineering change and have to sit down
and break it back down into those simple pieces to remind yourself what
it's doing, "pretty" and "clever" will not be the words you are using.
Trust me on this one.

Considering I've been writing and maintaining and debugging code for about
30 years now, I figure I have the hard-earned right to judge what I will be
able to understand in six months and what I won't...

 

[Lawrence D'Oliveiro]

* you seem to disregard the fact that in 'programming language' there
is the word 'language'. A language is a way to _communicate_
information, in the case of a programming language you communicate
it to the computer but also to other human beings.

It was Niklaus Wirth, I think who pointed out that programming languages are
not properly "languages" but are actually "notations". Like mathematics is
a notation.

And mathematics, too, is a predominantly functional, not a procedural,
notation. Could that be why so many people are frightened of functional
constructs, like my code example and things like lambdas? Because they look
too much like mathematics?

 

[Lawrence D'Oliveiro]

* you give the impression of being arrogant;

Oddly enough, I wasn't the one who started by criticizing other people's
code. I have no ego about my code; I gladly accept criticisms. But perhaps
some other people are not so thick-skinned and do not like getting as they
give...

 

[Stefan Behnel]

It was Niklaus Wirth, I think who pointed out that programming languages are
not properly "languages" but are actually "notations". Like mathematics is
a notation.

And mathematics, too, is a predominantly functional, not a procedural,
notation. Could that be why so many people are frightened of functional
constructs, like my code example and things like lambdas? Because they look
too much like mathematics?

That's not the impression I got from reading this thread.

Stefan

 

[Arnaud Delobelle]

It was Niklaus Wirth, I think who pointed out that programming languages are
not properly "languages" but are actually "notations". Like mathematics is
a notation.

I suppose anyone could call them what they want. The fact is that they
are languages with grammars. Anyway, replace 'language' with 'notation'
in my point and it is still meaningful.

And mathematics, too, is a predominantly functional, not a procedural,
notation.

Well, mathematics is seldom concerned with procedures, that's true. But
mathematics is more preoccupied with relations than functions.

Could that be why so many people are frightened of functional
constructs, like my code example and things like lambdas? Because they
look too much like mathematics?

I don't think that people have been frightened by it. They don't think
it's expressed elegantly as Python is designed to be used as an
imperative language.

 

[Rhodri James]

Considering I've been writing and maintaining and debugging code for
about
30 years now, I figure I have the hard-earned right to judge what I will
be
able to understand in six months and what I won't...

Huh. I can only claim 25 years, but I would still strongly discourage
people
from playing that sort of game.

 

[Gabriel Genellina]

En Sun, 07 Dec 2008 05:34:39 -0200, Lawrence D'Oliveiro

Oddly enough, I wasn't the one who started by criticizing other people's
code. I have no ego about my code; I gladly accept criticisms. But
perhaps
some other people are not so thick-skinned and do not like getting as
they
give...

May I ask then *why* did you chose to post your code fragment? Did I miss
something?

 

[Jorgen Grahn]

....

Why use (open, gzp.GzipFile)[Entry.endswith(".gz")] when we have had
contitional expressions for a few years now? Instead, you can write

(gzip.GzipFile if entry.endswidth(".gz") else open).

I think it will be faster (as it doesn't require the construction of a
tuple and then the retrieval of one of its elements) and clearer.

Even clearer would be if gzip.Gzipfile could (optionally) read
non-gzipped files and file-like objects, like the gzip Unix commands
zcat -f, zgrep and so on.

Also, making a decision based on the .gz part of the name isn't
always correct -- you miss files named foo.Z and similar.

/Jorgen

 

[Gabriel Genellina]

En Sun, 07 Dec 2008 05:34:39 -0200, Lawrence D'Oliveiro

Oddly enough, I wasn't the one who started by criticizing other people's
code. I have no ego about my code; I gladly accept criticisms. But
perhaps
some other people are not so thick-skinned and do not like getting as
they
give...

May I ask then *why* did you chose to post your code fragment? Did I miss
something?

 

[Bruno Desthuilliers]

Jorgen Grahn a écrit :
(snip)

Also, making a decision based on the .gz part of the name isn't
always correct -- you miss files named foo.Z and similar.

..tgz anyone ?

 

[MRAB]

...

Why use (open, gzp.GzipFile)[Entry.endswith(".gz")] when we have had
contitional expressions for a few years now? Instead, you can write

(gzip.GzipFile if entry.endswidth(".gz") else open).

I think it will be faster (as it doesn't require the construction of a
tuple and then the retrieval of one of its elements) and clearer.

Even clearer would be if gzip.Gzipfile could (optionally) read
non-gzipped files and file-like objects, like the gzip Unix commands
zcat -f, zgrep and so on.

Also, making a decision based on the .gz part of the name isn't
always correct -- you miss files named foo.Z and similar.

gzip is for reading gzipped files. IMHO it would be better to have a
de-archive module which uses the gzip, tarfile, etc, modules as necessary.

 

[Jorgen Grahn]

...

Why use (open, gzp.GzipFile)[Entry.endswith(".gz")] when we have had
contitional expressions for a few years now? Instead, you can write

(gzip.GzipFile if entry.endswidth(".gz") else open).

I think it will be faster (as it doesn't require the construction of a
tuple and then the retrieval of one of its elements) and clearer.

Even clearer would be if gzip.Gzipfile could (optionally) read
non-gzipped files and file-like objects, like the gzip Unix commands
zcat -f, zgrep and so on.

....

gzip is for reading gzipped files. IMHO it would be better to have a
de-archive module which uses the gzip, tarfile, etc, modules as necessary.

Not tarfile, since that's usually a container for many files.

But ok, maybe you are right about placing it in a different module
-- even though it's fairly common for Unix application to accept plain
files, gzipped files and nothing else.

Note that such a module should handle reading sys.stdin and other
non-disk files. That's a bit tricky, because when you realize that you
guessed wrong on the format, you have already consumed and discarded
some of the data.

I started looking at such a module a year ago, but never finished it.

/Jorgen

 

[Ethan Furman]

for \
Entry \
in \
sorted \
(
f for f in os.listdir(PatchesDir) if PatchDatePat.search(f) != None
) \
:
Patch = (open, gzip.GzipFile)[Entry.endswith(".gz")](os.path.join(PatchesDir, Entry), "r")
... read from Patch ...
Patch.close()
#end for

Not all code has to be written for everyone. Not all code will be read
by the masses. Some code you write for yourself... an expression of who
you are, how you think...

While my own quirks are not as visually entertaining, I think it's
another mark in Python's favor that such self-expression is possible,
and functional.

Yes, Lawrence, I do love writing fun code.

~ethan~