Re: Don't you just love writing this sort of thing :)
2008/12/9 Ethan Furman [EMAIL PROTECTED]: 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. I did once get into a rivalry with a Perl programmer over obfusticating a coding exercise. I knew from the start that I had no chance, but I was impressed with how close-run I could make it with Python. Fun, yes, but no way anything I would consider for code that is actually going to be /used/ in any way whatsoever! -- Tim Rowe -- http://mail.python.org/mailman/listinfo/python-list
Re: gzip.GzipFile (was Re: Don't you just love writing this sort of thing :))
On Mon, 08 Dec 2008 14:21:40 +, MRAB [EMAIL PROTECTED] wrote: Jorgen Grahn wrote: On Sat, 06 Dec 2008 10:01:10 +, Arnaud Delobelle [EMAIL PROTECTED] wrote: ... 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 -- // Jorgen Grahn grahn@Ph'nglui mglw'nafh Cthulhu \X/ snipabacken.se R'lyeh wgah'nagl fhtagn! -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
Lawrence D'Oliveiro wrote: 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~ -- http://mail.python.org/mailman/listinfo/python-list
gzip.GzipFile (was Re: Don't you just love writing this sort of thing :))
On Sat, 06 Dec 2008 10:01:10 +, Arnaud Delobelle [EMAIL PROTECTED] wrote: ... 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 -- // Jorgen Grahn grahn@Ph'nglui mglw'nafh Cthulhu \X/ snipabacken.se R'lyeh wgah'nagl fhtagn! -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
En Sun, 07 Dec 2008 05:34:39 -0200, Lawrence D'Oliveiro [EMAIL PROTECTED] escribió: In message [EMAIL PROTECTED], Arnaud Delobelle wrote: * 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... May I ask then *why* did you chose to post your code fragment? Did I miss something? -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: gzip.GzipFile (was Re: Don't you just love writing this sort of thing :))
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 ? /Jorgen -- http://mail.python.org/mailman/listinfo/python-list
Re: gzip.GzipFile (was Re: Don't you just love writing this sort of thing :))
Jorgen Grahn wrote: On Sat, 06 Dec 2008 10:01:10 +, Arnaud Delobelle [EMAIL PROTECTED] wrote: ... 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
En Sun, 07 Dec 2008 05:34:39 -0200, Lawrence D'Oliveiro [EMAIL PROTECTED] escribió: In message [EMAIL PROTECTED], Arnaud Delobelle wrote: * 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... May I ask then *why* did you chose to post your code fragment? Did I miss something? -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
Lawrence D'Oliveiro [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED], Arnaud Delobelle wrote: * 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. 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. -- Arnaud -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
On Sun, 07 Dec 2008 07:27:51 -, Lawrence D'Oliveiro [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Rhodri James wrote: 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... Huh. I can only claim 25 years, but I would still strongly discourage people from playing that sort of game. -- Rhodri James *-* Wildebeeste Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
Lawrence D'Oliveiro [EMAIL PROTECTED] writes:
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.
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)
--
Arnaud
--
http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
On Sat, 06 Dec 2008 20:28:17 +1300 Lawrence D'Oliveiro [EMAIL PROTECTED] wrote: Does that make any sense to you, or should I start drawing simple diagrams? People, please! Is some civility too much to ask? /W -- My real email address is constructed by swapping the domain with the recipient (local part). -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
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
Re: Don't you just love writing this sort of thing :)
On Sat, 06 Dec 2008 01:20:55 -, Lawrence D'Oliveiro [EMAIL PROTECTED] wrote: 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. -- Rhodri James *-* Wildebeeste Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
In message [EMAIL PROTECTED], Rhodri James wrote: 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 Been There, Done That D'Oliveiro -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
In message [EMAIL PROTECTED], Arnaud Delobelle wrote: * 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? -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
In message [EMAIL PROTECTED], Arnaud Delobelle wrote: * 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... -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
Lawrence D'Oliveiro wrote: In message [EMAIL PROTECTED], Arnaud Delobelle wrote: * 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? That's not the impression I got from reading this thread. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
Lawrence D'Oliveiro [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Duncan Booth wrote: 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. Good idea, but the mess you posted is going to be virtually untestable 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. BTW, by trimming half of my sentence you changed its meaning significantly. You implied that I gave an example without caring whether it could work whereas the other half of the sentence pointed out that if GZipFile requires it you may need to add a single function call to my code. -- Duncan Booth http://kupuguy.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
In message [EMAIL PROTECTED], Steven D'Aprano wrote: On Fri, 05 Dec 2008 13:27:35 +1300, Lawrence D'Oliveiro wrote: In message [EMAIL PROTECTED], Cong Ma wrote: The if ... != None is not necessary... if PatchDatePat.search(f) is OK. I don't do that. Perhaps you should? I prefer using explicitly Boolean values for conditions. -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
In message [EMAIL PROTECTED], Steven D'Aprano wrote: ... stupid formatting ... withallthedifferenttermsruntogetherintoonelinesoyoudon'tknowwhereoneendsandtheotherbeginsifthat'showyouliketowritecodefinethat'snothowIliketodoit -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
In message [EMAIL PROTECTED], Steven D'Aprano wrote: 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
In message [EMAIL PROTECTED], Duncan Booth wrote: ... 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... -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
On Fri, 05 Dec 2008 23:28:48 +1300, Lawrence D'Oliveiro wrote: In message [EMAIL PROTECTED], Steven D'Aprano wrote: 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. 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
On Fri, 05 Dec 2008 23:32:49 +1300, Lawrence D'Oliveiro wrote: In message [EMAIL PROTECTED], Duncan Booth wrote: ... 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... 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
On Fri, 05 Dec 2008 23:16:08 +1300, Lawrence D'Oliveiro wrote: In message [EMAIL PROTECTED], Steven D'Aprano wrote: On Fri, 05 Dec 2008 13:27:35 +1300, Lawrence D'Oliveiro wrote: In message [EMAIL PROTECTED], Cong Ma wrote: The if ... != None is not necessary... if PatchDatePat.search(f) is OK. I don't do that. Perhaps you should? 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. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
Steven D'Aprano wrote: 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
On Dec 5, 8:06 am, Marco Mariani [EMAIL PROTECTED] wrote: Steven D'Aprano wrote: Gosh Lawrence, do tell, which category do YOU fall into? I suppose a mix-up between a cowbody (or Fonzie) coder and a troll. Naah.. more likely an (ex?) Lisper/Schemer. -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
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. There are two types of people. Those who can grasp this distinction, and those who cannot. -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
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. 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... -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
On Dec 3, 8:07 pm, Lawrence D'Oliveiro [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
On Fri, 05 Dec 2008 20:19:22 -0800, Istvan Albert wrote: On Dec 3, 8:07 pm, Lawrence D'Oliveiro [EMAIL PROTECTED] 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. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
In message [EMAIL PROTECTED], Steven D'Aprano wrote: On Fri, 05 Dec 2008 23:28:48 +1300, Lawrence D'Oliveiro wrote: In message [EMAIL PROTECTED], Steven D'Aprano wrote: 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. 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? -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
In message [EMAIL PROTECTED], Steven D'Aprano wrote: 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
In message [EMAIL PROTECTED], Istvan Albert wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
Lawrence D'Oliveiro [EMAIL PROTECTED] wrote: 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 Have you ever considered trying to write readable code instead? Something like (untested): def patchfiles(dir, pattern): for f in os.listdir(dir): if pat.search(f) is not None: yield os.path.join(dir, f) def openpatch(name): if name.endswith(.gz): return gzip.GzipFile(name, r) return open(name, r) for entry in sorted(patchfiles(PatchesDir, PatchDatePat): with openpatch(entry) as patch: ... read from patch ... (I must admit I haven't checked whether GZipFile works with the 'with' statement, but if it doesn't you just wrap it in contextlib.closing). -- Duncan Booth http://kupuguy.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
Lawrence D'Oliveiro wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list The if ... != None is not necessary... if PatchDatePat.search(f) is OK. And I don't like it... -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
On Dec 4, 10:39 am, Cong Ma [EMAIL PROTECTED] wrote:
Lawrence D'Oliveiro wrote:
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()
--
http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
In message [EMAIL PROTECTED], Duncan Booth wrote: 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
In message [EMAIL PROTECTED], Cong Ma wrote: The if ... != None is not necessary... if PatchDatePat.search(f) is OK. I don't do that. -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
On Fri, 05 Dec 2008 13:27:35 +1300, Lawrence D'Oliveiro wrote: In message [EMAIL PROTECTED], Cong Ma wrote: The if ... != None is not necessary... if PatchDatePat.search(f) is OK. 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. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Don't you just love writing this sort of thing :)
uggh no! On Thu, Dec 4, 2008 at 11:07 AM, Lawrence D'Oliveiro [EMAIL PROTECTED] wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list -- -- -- Problems are solved by method -- http://mail.python.org/mailman/listinfo/python-list
