Re: while c = f.read(1)



Op 2005-08-23, Magnus Lycka schreef <lycka@xxxxxxxxx>:
> Antoon Pardon wrote:
>> Following a well defined specification is not contradictory
>> to guessing. It may just mean that the guess was formalized
>> into the specification.
>
> If you want the behaviour of Python to change, you should
> write a PEP.

Such a PEP would have no chance of being accepted, since
it would break to much existing code.

> It always felt natural to me to interpret empty
> as false, but I could be wrong. It's strange that this flaw
> managed to go unnoticed for so long though...

The problem with interpreting empty as false is that empty
just means no data now. But no data now can mean no data
yet or it can mean no more data. The problem is not so
much as having empty interpreted as false but that people
don't seem to think about which false value would be
more appropiate in particular circumstances. IMO reading
'' from network connection is the most natural result
when no data is ready and this should be treated differently
from an EOF which would indicate the connection was closed.

But how can you do this when somewhere else '' is used as
an indication for an EOF.

> If Python is too "wild" for your taste, you might like OCaml.
>
>> Well then I must say people here give beauty too high a priority.
>> Because there seems a tendency to beautify others code when
>> snippets are posted here. Often enough such snippets
>> don't give enough inoformation to know whether "if var is True:"
>> can be replaced by "if var:" or whether other beautifications are
>> appropiate.
>
> You might be right about that. I didn't really notice.
>
> I think the typical comment is to replace "if s != '':" with
> "if s:" in contexts where s is always a string,

And it is IMO this kind of comments that lead to '' being used
as an EOF.

> or to replace
> "if expr != False:" with "if expr": in cases where "expr" is an
> expression that returns True or False etc. In some cases, obvious
> bugs, such as "if (a and b) == True:" where the programmer
> should have written "if (a and b):" are pointed out.

This is not such an obvious bug. Because python allows non boolean
operands with "and" the two don't behave the same. How do you know
which behaviour the other person wants?

> Many of us have a solid mathematical education, and in that world
> it's considered good behaviour to simplify expressions and remove
> redundancy.

I have yet to see a mathematical work where 0, or any kind of
empty sequence is treated as false. In mathematics accuracy
is considered vitaly important and won't be sacrified to
remove redundancy. Boolean expression are always written out
fully.

> If we see things such as redundant pieces in logic expressions,
> functions ending in "return None", returns directly after a raise,
> or other meaningless constructs, it suggests that someone might be
> doing something they don't understand, and then it's helpful to
> try to point that out.

But you don't know if the logic expression are redundant. The
suggestions made are usually not equivallent.

> It's really important to understand what we do when we're
> programming, not just repeat mantras or wave dead chickens.
>
> If people mechanically learn "I shouldn't use '!= False' in
> if-statements in Python", we've failed in trying to help them.
> If people learn what Python considers true and false, what the
> boolean operators return, and understands how to use these
> things in an effective way, we've succeeded.
>
> Another aspect of this particular idiom is that it's often better
> to use the exception system in Python for exceptional situations,
> than to use one variable to carry several different kinds of
> information.

In that case you wouldn't return an empty sequence if you wanted
a false value in a sequence context but would throw an exception.
So this would be fine by me, I just don't understand how this
would support the use of empty sequences as false.

I also don't see how a read from a network connection returning
either:

a bytestring when data is available,
'' when no data is available
None when the connection was closed

As so much different kinds of information.

Besides sometimes different kinds of information is not that
exceptional, so why should I throw an exception in such a
case?

--
Antoon Pardon
.



Relevant Pages

  • Re: decorators tutorials
    ... I am learning python by learning django, ... allow the SystemExit exception to continue to propogate without doing ... # The func argument is a Pythong function object ... trying to get the result of DivXY, ...
    (comp.lang.python)
  • Re: math.nroot [was Re: A brief question.]
    ... >>> wish sometimes that Python would make up it's mind about what it does ... >> exception on overflow, invalid operation, and divide by 0, and "should ... >> not", by default, raise an exception on underflow or inexact. ... you can at least be pretty sure that an infinite result is the ...
    (comp.lang.python)
  • Re: exceptions
    ... How do younger languages like IO make this point more forcefully than lisp, ... deal with *all* errors in an interactive session, ... certainly in python ... > exception handling is hard-coded in syntax. ...
    (comp.lang.python)
  • Re: JSON Strict Mode
    ... Here's one that uses Python and that I've heard praise for: ... How would i go about checking if its in "strict mode" ... an exception is type of object** used to indicate that ... error into a new exception object and then "raises" (using, in Python, ...
    (comp.lang.python)
  • Re: Learning to use decorators with classes
    ... and you could use any legal Python identified instead. ... This kind of "error handling" is more than useless - it's worse than no error handling at all. ... If you cannot handle the problem, just let the exception propagate - you'll get a nice traceback with all the necessary debugging informations. ... Users of your package can always add a top-level "catch-all" exception handler that will log tracebacks, send alert mails to the team, and present the end-user with a nicely formatted error message (and even possibly a way to handle the problem - like providing appropriate connection data (credentials, url, whatever)!-) ...
    (comp.lang.python)