John Machin wrote: > > Is some way to make this code more compact and simple? It's a bit > > spaghetti. > > Not at all, IMHO. This is a simple forward-branching exit from a loop in > explicable circumstances (EOF). It is a common-enough idiom that doesn't > detract from readability & understandability. Spaghetti is like a GOTO > that jumps backwards into the middle of a loop for no discernable reason.
While that is true, I had high hopes that I could do this: while c = f.read(1): # ... And relative to that, it is more complex. And although I am nit-picking to try to simplify this code, I wanted to understand why Python works in this way (even if that's just "historical reasons"), and check to see if there was not some shorter more modern Pythonic alternative. I did actually like Robert Kern's suggestion which used an iterator and a function to factor out the complexity of setting it up. I think that is actually better code than the original. It matches my philosophy in programming of pushing complexity *out* of the code which does the actual job, even if it means writing a few support functions/classes/whatever. I know they can be re-used and refined and I know that it is the code that does the actual job that is most likely to be rewritten in future revisions of the code with shifts in requirements. > You have a bit of a misunderstanding here that needs correcting: > > In "if <blah>" and "while <blah>", <blah> is NOT restricted to being in > (True, False). See section 5.10 of the Python Reference Manual: I'm sorry! I realise that now and I'm sorry to have caused the traffic I did. Thank you for pointing it out to me though - it's pretty fundamental Python! *Greg thumbtacks a note to his forehead* > How about > for c in f.read(): > ? > Note that this reads the whole file into memory (changing \r\n to \n on > Windows) ... performance-wise for large files you've spent some memory > but clawed back the rather large CPU time spent doing f.read(1) once per > character. The "more nicely" factor improves outasight, IMHO. I would if only I had any kind of guarrantee on the file size but I don't - this code is for reading a header out of a binary file which uses delimiters and escape characters to mark out its fields. I didn't design the format, but after cleaning up the code that deals with it, I may *re*design it. ;) > Mild curiosity: what are you doing processing one character at a time > that can't be done with a built-in function, a standard module, or a > 3rd-party module? Our company is designing a new file type. *sigh*. Confidentiality prevents me from saying any more, too. If that bugs you because it's not open source, sorry I need a job. Don't worry though, I'm developing an open source remote GUI for the code management system we're using called Aegis (http://aegis.sf.net). It's not sufficiently implemented yet to warrant posting publically (I'd describe its current state as "framework") but if anybody reading this is interested then give me a yell and it'll have a public project page or something overnight. ;) -- http://mail.python.org/mailman/listinfo/python-list
