while c = f.read(1)

[Steve Holden]

Greg McIntyre wrote:
> 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.
> 
Guido explicitly decided he wanted a clear differentiation between 
expressions and statements, and that assignment was to be a statement. 
The logic behind this design decision is documented in

 
http://www.python.org/doc/faq/general.html#why-can-t-i-use-an-assignment-in-an-expression

which may have already been mentioned in this thread.

> 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.
> 
There are many elegant ways to express iterative solutions in Python, 
and generator expressions are frequently useful in this context as well.

> 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 are likely to be happy with Python, then. Most Python programmers 
are pragmatists.
> 
> 
>>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!
> 
Yes, but it's a common question from newcomers (hence its appearance in 
the FAQ), and there's usually some interesting discussion when it comes 
up. Fortunately c.l.py isn't the kind of place you will usually 
experience "Read the FAQ!" abuse. We try to remember that Python's 
popularity is growing so fast that about a third of readers at any time 
are likely to be newbies to Python (albeit many of them are experienced 
in other programming languages).

> *Greg thumbtacks a note to his forehead*
> 
Ouch!

> 
> 
>>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. ;)
> 
If you *know* that the header is MAX characters maximum you could try

     for c in f.read(MAX):
         ...
> 
> 
>>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. ;)
> 
Good luck.

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC             http://www.holdenweb.com/