while c = f.read(1)

[Greg McIntyre]

Donn Cave wrote:
> Actually I'd make it a little less compact -- put the "break"
> on its own line -- but in any case this is fine.  It's a natural
> and ordinary way to express this in Python.
>
> ...
> | But I get a syntax error.
> |
> |     while c = f.read(1):
> |            ^
> | SyntaxError: invalid syntax
> |
> | And read() doesn't work that way anyway because it returns '' on EOF
> | and '' != False. If I try:
>
> This is the part I really wanted to respond to.  Python managed
> without a False for years (and of course without a True), and if
> the introduction of this superfluous boolean type really has led
> to much of this kind of confusion, then it was a bad idea for sure.

Sorry that was patently untrue - as far as the while loop is concerned
'' and False both cause the loop to exit so for all intents and
purposes, in that context, '' may as well equal False.

I think True and False constants are a good idea. And I like the way it
worked. The reason I got confused though was because I cannot do this:

  while c = f.read(1):
    # ...


> The condition that we're looking at here, and this is often the
> way to look at conditional expressions in Python, is basically
> something vs. nothing.  In this and most IO reads, the return
> value will be something, until at end of file it's nothing.
> Any type of nothing -- '', {}, [], 0, None - will test "false",
> and everything else is "true".  Of course True is true too, and
> False is false, but as far as I know they're never really needed.

I'm all in favour of logic that looks like:

  if '' or 0 or {} or None:
     # never gets done
  else:
     # always gets done

My confusion stems from the syntax error not from Python's boolean
logic. Sorry, my statement at the end regarding '' != False was a bit
of a red herring. :\

I'm also in the habit of doing things like this:

  def f(dict=None):
    dict = dict or {}
    # ...


> You are no doubt wondering when I'm going to get to the part where
> you can exploit this to save you those 3 lines of code.  Sorry,
> it won't help with that.

Ah but if it helps me to understand why Python forces me to do it then
although it won't save 3 lines it will stop me from complaining and
posting naff newbie questions. ;)


> | Is this related to Python's expression vs. statement syntactic
> | separation? How can I be write this code more nicely?
>
> Yes, exactly.  Don't worry, it's nice as can be.  If this is
> the worst problem in your code, you're far better off than most
> of us.

Okay well that is reassuring but a little disappointing.

Are there any plans (PEPs?) in the distant future to unify statements
and expressions in the Python syntax so I can generally do things like
this:

  x = if aboolean:
          <expression1>
      else:
          <expression2>

and

  while c = f.read(1):
      # ...

I couldn't find any general PEPs along these lines, only specific ones
(e.g. 308 re. an if-then-else expression). It does seem quirky given
Python's indentation syntax. :( However I notice I can already do some
things I wouldn't expect given a strict statement/expression
separation, such as:

  x = y = z = 0

I suppose I have to learn these as special cases. (?)