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

[Lawrence D'Oliveiro]

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

 

[James Mills]

uggh no!

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

 

[Cong Ma]

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

The "if ... != None" is not necessary... "if PatchDatePat.search(f)" is OK.
And I don't like it...

 

[Harold Fellermann]

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

The "if ... != None" is not necessary...  "if PatchDatePat.search(f)" is OK.
And I don't like it...

Maybe the whole if clause is not necessary? This is how I would try
it:

for Entry in filter(PatchDatePat.search, os.listdir(PatchesDir)) :
fname = os.path(PatchesDir, Entry)
Patch = file(fname) if fname.endswith('.gz') else GzipFile(fname)
# ... read from Patch ...
Patch.close()

 

[Lawrence D'Oliveiro]

Have you ever considered trying to write readable code instead?

(I must admit I haven't checked whether GZipFile works with the 'with'
statement...

That's why I prefer writing _correct_ code instead.

 

[Lawrence D'Oliveiro]

The "if ... != None" is not necessary... "if PatchDatePat.search(f)" is
OK.

I don't do that.

 

[Steven D'Aprano]

I don't do that.

Perhaps you should?

Since the context has been deleted, it's hard to tell whether the code as
written by Lawrence is incorrect or merely bad style. Here's his original
piece of code, with the stupid formatting fixed to a more readable style:

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()


Still pretty obfuscated. The for block could be made considerably more
readable. Here's one way:

opener = gzip.GzipFile if Entry.endswith(".gz") else open
Patch = opener(os.path.join(PatchesDir, Entry), "r")
... read from Patch ...
Patch.close()


Looking at the call to sorted(), Cong Ma suggested that

if PatchDatePat.search(f) != None

should be replaced by the much shorter:

if PatchDatePat.search(f)

The replacement is much more Pythonic style, but it could fail if
PatchDatePat.search() returns a false value (0, empty string, empty list,
etc) which is intended to count as a match. Without knowing what the
search method does, it is impossible to tell whether this is a risk or
not. On the other hand, Lawrence's code can also fail if the search
method returns an object which for some reason tests equal to None
despite being a match.

In other words, *both* techniques are fragile, because they make
assumptions about the sort of object the search method can return. The
best way of doing this test, given *only* the assumption that None
indicates no match, is with:

if PatchDatePat.search(f) is not None


This also happens to be (marginally) faster that either of the others, as
it relies only on an identity test, and doesn't need to make an equality
test or a __nonzero__ test, both of which require method lookups.

 

[Lawrence D'Oliveiro]

Perhaps you should?

I prefer using explicitly Boolean values for conditions.

 

[Lawrence D'Oliveiro]

... stupid formatting ...

withallthedifferenttermsruntogetherintoonelinesoyoudon'tknowwhereoneendsandtheotherbeginsifthat'showyouliketowritecodefinethat'snothowIliketodoit

 

[Lawrence D'Oliveiro]

Since the context has been deleted, it's hard to tell whether the code as
written by Lawrence ...

If you want to reply to my message, reply to my message, don't reply to my
reply to someone else's reply to my message.

 

[Lawrence D'Oliveiro]

... but the mess you posted is going to be virtually untestable ...

The "mess" I posted did actually work as written.

... whereas splitting it up into small testable functions will make it
much easier for you to actually get somewhere near your goal of correct
code.

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...

 

[Steven D'Aprano]

If you want to reply to my message, reply to my message, don't reply to
my reply to someone else's reply to my message.

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.

 

[Steven D'Aprano]

The "mess" I posted did actually work as written.


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...

Gosh Lawrence, do tell, which category do YOU fall into?

I'd probably be able to work it out on my own, if not for me being one of
the plodders incapable of imaginative leaps.

 

[Steven D'Aprano]

I prefer using explicitly Boolean values for conditions.

Perhaps you do, but there's no evidence of such in your post.

bool(PatchDatePat.search(f) != None)

would be an "explicitly Boolean value". What you posted was an
*implicitly* Boolean value, and not even guaranteed to be Boolean, as
__ne__ can return any object it likes.

And yes, such a call to bool would be pointless.

 

[Marco Mariani]

Gosh Lawrence, do tell, which category do YOU fall into?

I suppose a mix-up between a cowbody (or Fonzie) coder and a troll.

His programs have an inner poetry that we're obviously too stupid to
understand.

 

[George Sakkis]

I suppose a mix-up between a cowbody (or Fonzie) coder and a troll.

Naah.. more likely an (ex?) Lisper/Schemer.

 

[Aaron Brady]

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.

There are two types of people. Those who can grasp this distinction,
and those who cannot.

 

[Lawrence D'Oliveiro]

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? 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")

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...

 

[Istvan Albert]

On Dec 3, 8:07 pm, Lawrence D'Oliveiro <l...@geek-
central.gen.new_zealand> wrote:

<snip code>

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.

i.

 

[Steven D'Aprano]

On Dec 3, 8:07 pm, Lawrence D'Oliveiro <l...@geek-
central.gen.new_zealand> wrote:

<snip code>

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

Just like a disfiguring skin disease.

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

It would have been far more concise without the for statement (not the
entire loop) being spread over EIGHT lines... one of which was a lonely
colon, all by itself.