473,325 Members | 2,774 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,325 software developers and data experts.

while c = f.read(1)

I have a Python snippet:

f = open("blah.txt", "r")
while True:
c = f.read(1)
if c == '': break # EOF
# ... work on c

Is some way to make this code more compact and simple? It's a bit
spaghetti.

This is what I would ideally like:

f = open("blah.txt", "r")
while c = f.read(1):
# ... work on c

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:

f = open("blah.txt", "r")
while (c = f.read(1)) != '':
# ... work on c

I get a syntax error also. :(

Is this related to Python's expression vs. statement syntactic
separation? How can I be write this code more nicely?

Thanks

Aug 19 '05
75 5246
Steve Holden wrote:
Robert Kern wrote:

Coincidentally, those are exactly the reasons why I posted it in the
first place. I care not a whit about decluttering the newgroup, an
impossible task.


It's clear that you care not a whit about it. Unfortunately the only way
to preserve bandwidth on this (or any other) chanell is for those with
nothing to say to not say it.


Folks, if you want to preserve bandwidth from being wasted on irrelevant
posts (like this one), delete your newsreader.

USENET *is* clutter. Sometimes useful clutter. Entertaining clutter.
*Shiny* clutter. But clutter. If you care about efficient use of
bandwidth, this is not the place for you.

James asked a question in such a way that I didn't think it would get
answered. Judging from the other non-responses to his post, I was right.
I showed him the way to ask questions such that they *will* get
answered, and he came back, did so, and got his questions answered.

That's worth 5 kb.

--
Robert Kern
rk***@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

Aug 22 '05 #51
> On the other hand, if you've already
planned another pass over the code, that might be the time to look
into this.

Exactly. And when I do that pass I will definitely try buffering the
data 10 or 100 meg at a time before entring the 1 char-at-a-time loop,
or using mmap to similar ends.

Aug 23 '05 #52
>>>>> "Robert" == Robert Kern <rk***@ucsd.edu> writes:

Robert> Greg McIntyre wrote:
The 2nd option has real potential for me. Although the total
amount of code is greater, it factors out some complexity away
from the actual job, so that code is not obscured by
unnecessary compexity. IMHO that's great practice.


Robert> Please quote the message you are replying to. We have no
Robert> idea what "the 2nd option" is.

I think he means the second option you presented

If you must read one character at a time,

def reader(fileobj, blocksize=1):
"""Return an iterator that reads blocks of a given size from a
file object until EOF.
...snip

With a decent threaded news/mail reader, the thread provides
sufficient context, no?

JDH
Aug 23 '05 #53
John Hunter wrote:
>>"Robert" == Robert Kern <rk***@ucsd.edu> writes:
Robert> Greg McIntyre wrote: >> The 2nd option has real potential for me. Although the total
>> amount of code is greater, it factors out some complexity away
>> from the actual job, so that code is not obscured by
>> unnecessary compexity. IMHO that's great practice.


Robert> Please quote the message you are replying to. We have no
Robert> idea what "the 2nd option" is.

I think he means the second option you presented

If you must read one character at a time,

def reader(fileobj, blocksize=1):
"""Return an iterator that reads blocks of a given size from a
file object until EOF.
...snip

With a decent threaded news/mail reader, the thread provides
sufficient context, no?


Not taking into account the python-list gateway or GMane. I see his
message threaded directly under his original one.

And dammit, I'm vain enough that if people are complimenting my code, I
want to be sure about it. ;-)

--
Robert Kern
rk***@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

Aug 23 '05 #54
Op 2005-08-22, Magnus Lycka schreef <ly***@carmen.se>:
Antoon Pardon wrote:
Python doesn't guess. There are a range of values that will be treated,
in a Boolean context (how perlish) as equivalent to False.
Yes it does.


No it doesn't!
Python has no way to know what would be the most
usefull Boolean interpretation of these values in a particular
context.


It's hardly the task of the interpreter to try to do that.


Indeed ir is not, so the interpreter should not pretend it can
by providing a Boolean interpretation.
That it picks one out is guessing.


No, it simply follows a well defined specification.
See http://docs.python.org/ref/Booleans.html
There is no guessing involved in that.


Following a well defined specification is not contradictory
to guessing. It may just mean that the guess was formalized
into the specification.
Lisp imterprets
an empty list as false, scheme interprets it as true. So
both seem usable interpretations.


You might argue that *Guido* was guessing when he decided what
the most useful behaviour of Python would be in this case, and
there's probably some truth in that, just as there is some
guesswork involved in most programming language design decisions,
but that's another thing. That's not Python guessing, it's
Guido using his excellent lanugage design skills. It seems most
Python programmers agree that he "guessed" right here, as usual.


I don't see a big difference. Guessing plays its roles when
different people can have different expectations in cases
where not all the details are known/specified. Whether that
is in the language design or in program design doesn't make
a big difference and I would expect that a language that
discourages guessing in the software that its written in it,
would follow its own rules in its design.
(Perhaps you thought that "Python" was the name of the language
designer. It's not. Python's design is led by Guido van Rossum,
and the name Python comes from a (mostly) British comedy group.)

You might also argue that this behaviour is counter to the
Python dogma of "explicit is better than implicit". Python also
allows you to get a float out of an expression such as "2*3.1"
without forcing an explicit cast, as in "float(2)*3.1".

You should note that the first Python tenet is "Beautiful is
better than ugly" and that's probably what we have to blame here.

There seems to be close to a consensus, that "if users:" is more
beautiful than e.g. "if len(users) > 0:" or
"if (len(users)==0)==False" or for that matter
"if ((len(users)==0)==False)==True" or
"if (((len(users)==0)==False)==True)==True" etc.
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.
What's true and false for Python, belongs to the few things you
actually have to learn, and I can appreciate that it's annoying
for a frequent schemer to remember that it's not the same in
Python, but it seems that very few people argue with the way
Python behaves in this respect.


I care very little for what someone with experience in an other
language can expect. I care about the consistence of the language
and the programs written in it. I just mentioned scheme to show
that [] interpreted as false is not so obvious as a lot of people
seem to think. Since there are situations where using '', (), []
or 0 as false would be not appropiate I advise against using them
as such, because you never know when your software that does has
to cooperate with software that doesn't.

--
Antoon Pardon
Aug 23 '05 #55
Op 2005-08-22, Donn Cave schreef <do**@u.washington.edu>:
Before leaving this topic, I wanted to make a rare visit
to the ruins of Google's USENET archive and pull out this
giant post on the subject of True and False, when they were
being considered for adoption into Python. There is some
stuff to ignore, where she addresses questions that didn't
go anywhere, but she goes on to write a well articulated
case that makes very interesting reading, and possibly has
had some effect on how people think about it around here.

http://groups-beta.google.com/group/...e5e1c8384c0360


Well I guess she and I disagree here. I also don't understand some
of her arguments. e.g. about code like: "if var == True"

| Aaargh!
| I already see too much code like this. It's mostly written by people
| who come from other languages. They define their own True and False so
| they can do this.

I would argue that this would be bad code even in these other languages.
Heck when I was still a student and getting a course in PASCAL, people
with no programming experience whatsoever would write code like that
and PASCAL does have a real BOOLEAN type.

So where she gets the idea that "if var == True" is a symptom of a
language that has no real BOOLEAN type (as python now has IHO) is
beyond me.

--
Antoon Pardon
Aug 23 '05 #56
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. 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...

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, 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.

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

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.

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.

Concerning interfaces between different pieces of code, it's a
good approach to assume as little as possible, but to be clear
about what we assume.
Aug 23 '05 #57
Op 2005-08-23, Magnus Lycka schreef <ly***@carmen.se>:
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
Aug 23 '05 #58
Antoon Pardon wrote:
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


I do not get why returning '' when no data is available? If no data is
available then nothing is returned, the function hangs. (Which is the
cas for receive)

--
rafi

"Imagination is more important than knowledge."
(Albert Einstein)
Aug 23 '05 #59
Op 2005-08-23, rafi schreef <ra**@free.fr>:
Antoon Pardon wrote:
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


I do not get why returning '' when no data is available? If no data is
available then nothing is returned, the function hangs. (Which is the
cas for receive)


Network connections can be configured to either block or return
immediatly when no data is available.

--
Antoon Pardon
Aug 23 '05 #60
Antoon Pardon enlightened us with:
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.
By no means can you take all possible future alterations in account.
You have to make assumptions somewhere.
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.
That's called "a protocol". If another protocol is used than the
software is written for, it'll break. This has nothing to do with
accepting something as False or True.
And it is IMO this kind of comments that lead to '' being used as an
EOF.
And who cares if it is? In a blocking environment, it seems pretty
okay to me. A read() call could block, waiting for more data to
arrive. If there is none because the connection is down, for instance,
it could return ''. Of course, raising an exception would be better in
such a case, and it would also remove any ambiguity.
I have yet to see a mathematical work where 0, or any kind of empty
sequence is treated as false.
In that case, properly define your variables to hold either booleans
or numbers, and only test booleans in an "if var:" clause, and only
test numbers in an "if var != 0:" clause.
a bytestring when data is available,
'' when no data is available
None when the connection was closed


Seems pretty nice to me. In such a case, one could do:

data = network.read()
if data:
handleData(data)

if data is None:
handleClosedConnection()

I don't see a problem here.

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa
Aug 23 '05 #61
Op 2005-08-23, Sybren Stuvel schreef <sy*******@YOURthirdtower.com.imagination>:
Antoon Pardon enlightened us with:
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.
By no means can you take all possible future alterations in account.
You have to make assumptions somewhere.


But having to write out a boolean expression fully, would force
one to make his assumptions explicite. My impression is that
people don't actually make assumptions but are happy to just
throw a variable in a conditional context. They only begin
to think about the assumptions this imply when things break.
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.


That's called "a protocol". If another protocol is used than the
software is written for, it'll break. This has nothing to do with
accepting something as False or True.


Yes it has. That empty sequences are treated as false in a conditional
context, influences what kind of protocols are used.
And it is IMO this kind of comments that lead to '' being used as an
EOF.


And who cares if it is? In a blocking environment, it seems pretty
okay to me.


Not all environments are blocking and it seems to be me it is better
to use protocols that are are as much as possible independant from
whether the environment is blocking or not.
A read() call could block, waiting for more data to
arrive. If there is none because the connection is down, for instance,
it could return ''. Of course, raising an exception would be better in
such a case, and it would also remove any ambiguity.
I have yet to see a mathematical work where 0, or any kind of empty
sequence is treated as false.


In that case, properly define your variables to hold either booleans
or numbers, and only test booleans in an "if var:" clause, and only
test numbers in an "if var != 0:" clause.
a bytestring when data is available,
'' when no data is available
None when the connection was closed


Seems pretty nice to me. In such a case, one could do:

data = network.read()
if data:
handleData(data)

if data is None:
handleClosedConnection()

I don't see a problem here.


That is because you are looking at it too much in isolation.
What if you have a function that among things handles bytes
coming from a stream. Whether that stream is a regular file
or a network connection may be irrelevant for the function,
but if regular files return '' for EOF and other streams
don't, you are in trouble. And IMO that '' is treated as
false played its parts in deciding for it as indicating EOF.

--
Antoon Pardon
Aug 23 '05 #62
On Tue, 23 Aug 2005 12:15:36 +0200, Magnus Lycka <ly***@carmen.se>
declaimed the following in comp.lang.python:

If you want the behaviour of Python to change, you should
write a PEP. 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...
Seemed to fit my world view too... So many other languages used the
"non-zero" is True, that it made sense to take "non-empty" is True --
and if "non-empty" is true, then empty must be False.

Of course, there is always VMS -- where status codes were checked in
LSB... odd number => true, even number => false
-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <

Aug 23 '05 #63
Dennis Lee Bieber wrote:
On Tue, 23 Aug 2005 12:15:36 +0200, Magnus Lycka <ly***@carmen.se>
declaimed the following in comp.lang.python:

If you want the behaviour of Python to change, you should
write a PEP. 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...


Seemed to fit my world view too... So many other languages used the
"non-zero" is True, that it made sense to take "non-empty" is True --
and if "non-empty" is true, then empty must be False.

Of course, there is always VMS -- where status codes were checked in
LSB... odd number => true, even number => false


.... and most *nix shells, where a return code of zero implies "success".
Of course, this still leaves wiggle room to discuss whether success is
True or False.

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

Aug 23 '05 #64
On 22 Aug 2005 02:48:24 -0700, Paul Rubin <http://ph****@NOSPAM.invalid> wrote:
"Greg McIntyre" <gr**@puyo.cjb.net> writes:
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).


I often end up doing something like this:

class foo:
def set(self, x):
self.x = x
return x
c = foo()

while c.set(f.read(1)):
# do stuff with c.x

In that file example, it's too much nuisance, but when you're
comparing some input against a series of regexps and you'd otherwise
need a multi-line construction for each one, this method comes in
quite handy.


if you use def __call__ instead of def set, you can also simplify the
subsequent spelling e.g,

while c(f.read(1)):
# do stuff with c.x

though something more menmonic than c might be desirable in that case.

Regards,
Bengt Richter
Aug 23 '05 #65
Greg McIntyre wrote:
John Machin wrote:
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*.


Sigh indeed. If you need to read it a character at a time to parse it,
the design is f***ed.

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 be so sensitive; it has strong Biblical precedent. You can believe
in the one true god but still bow down in the house of Rimmon or Redmond.
Aug 23 '05 #66
Antoon Pardon wrote:
Such a PEP would have no chance of being accepted, since
it would break to much existing code.
What's the point of this thread then?
But how can you do this when somewhere else '' is used as
an indication for an EOF.
If that's your problem, I guess that's what you should attack,
not that Python considers nothing to be nothing even it might
some time become something.

Network programming with Python works pretty well though, so
it seems this is a non-issue too.
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.


Huh? Aren't the Python APIs just mirroring the behaviour of the
underlying C APIs?
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?


I think you misread my text. If the programmer should have written
"if (a and b):", adding "==True" will cause different behaviour
unless True (or 1) is the only non-False value that b can have.
This would not be obvious for someone who expects that the results
of logical operations will return boolean values.
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.
Dear Antoon. The "if" statement interprets the result of an
expression to determine whether or not to execute a block of
code. If "x" is an expression that returns True or False, then
"x==True" is an equivalent expression. It's just not written in
its minimal form.

It's like writing "a / b * 100 %" instead of just "a / b" in a
mathematical equation. The first version contains some kind of
noise that just looks ugly for people who know that 100%==1.
Why multiply with 1? At least in my home town, the MBA students
write stuff like that, but mathematicians and engineers would
just think it was ugly.
But you don't know if the logic expression are redundant. The
suggestions made are usually not equivallent.
I think I know. Please point out if I made some mistake.

It's pretty common that people fail to reduce logical expressions.
I've seen C++ code checking for overlapping periods looking roughly
like this:

if ((start1<=start2 and stop1>=start2 and stop1<=stop2) or
(start1<=start2 and stop1>=stop2) or
(start1>=start2 and stop1<=stop2) or
(start1>=start2 and start1<=stop2 and stop1>stop2))

For that person, his code might actually have been clearer than
the less cluttered version I changed it to:

if (start1<=stop2 and start2<=stop1)

At least he spent a few minutes staring at it before he could
accept that they were equivalent. (Maybe he just gave up.)

Of course, it might well be that different brains work in different
ways, and that different presentations are preferred by different
people. Python seems to fit my brain.

In the overlapping case above it's really a shift of perspective.
He saw overlapping time periods as occuring in four different
cases:
* A starts before B and ends during B
* A starts before B and ends after B
* B starts before A and ends during A
* B starts before A and ends after A.

I guess my first impulse (before I asked what his code did) was
that it looked redundant, but the thing is that my short version
describes overlapping time periods in a different way: Both
periods start before the other period ends. That's all!

The kinds of simplifications in code that we talk about often has
this quality. They show us that things are really simpler than the
coder thought. I'm sure it happens that some people try to over-
simplify things, but most systems can be made simpler, and trying
to do that is a noble cause.
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.
Huh? If I want False I use False. If a sequence is empty, it's empty.
It seems to me that you make things more complicated than they have
to be. Perhaps you're just confused over the C APIs for network
programming. I can understand that, but you seem to be pretty far
away from the real target now.
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?


I don't know what you are trying to say. If you want more
Pythonic network API, I'd rather use an iterator. Just make
it return StopIterator when the connection closes. You would
use it like this:

for chunk in NetworkReader(ip, port):
if chunk: print chunk

This could be blocking, or use a timer and return '' on
timeout. Thus the if-statement. chunk would always be a
string. As you suggested, an empty string would then mean
no data yet. When the connection is closed, the for loop
simply ends.

In this context, writing "if chunk != '':" instead of simply
"if chunk:" is just a waste of resources.
Aug 24 '05 #67
Op 2005-08-24, Magnus Lycka schreef <ly***@carmen.se>:
Antoon Pardon wrote:
Such a PEP would have no chance of being accepted, since
it would break to much existing code.
What's the point of this thread then?


I only hope to impress people that the way python
treats 'nothing' in a condional context is not
so obvious as seems to be accepted here.
But how can you do this when somewhere else '' is used as
an indication for an EOF.


If that's your problem, I guess that's what you should attack,
not that Python considers nothing to be nothing even it might
some time become something.


IMO the two are linked. People use '' as an EOF because the
call they are working with returns strings and they need a
way to end a loop. Since "if var:" is considered beautifull
they search for a nothing value and since they were working
with strings, '' gets chosen.
Network programming with Python works pretty well though, so
it seems this is a non-issue too.
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.


Huh? Aren't the Python APIs just mirroring the behaviour of the
underlying C APIs?


That may depend on how strict the meaning of mirroring is, you
are using. I would say no. Even if the answer is yes I would
say that chosing such values on that basis was a bad design
choice.
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?


I think you misread my text. If the programmer should have written
"if (a and b):", adding "==True" will cause different behaviour
unless True (or 1) is the only non-False value that b can have.
This would not be obvious for someone who expects that the results
of logical operations will return boolean values.


So? How do you know what the writer of the code expects. You
originaly wrote it was an obvious bug, how do you come to
that conclusion.
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.


Dear Antoon. The "if" statement interprets the result of an
expression to determine whether or not to execute a block of
code. If "x" is an expression that returns True or False, then
"x==True" is an equivalent expression. It's just not written in
its minimal form.


But we were talking about interpreting 0, '', (), [], and {}
directly in a conditional context. No mathematical text
will just contain a line like

a => b > 10

when what is meant is:

a != 0 => b > 10
It's like writing "a / b * 100 %" instead of just "a / b" in a
mathematical equation. The first version contains some kind of
noise that just looks ugly for people who know that 100%==1.
Why multiply with 1? At least in my home town, the MBA students
write stuff like that, but mathematicians and engineers would
just think it was ugly.


But you can't transfer this situation to python, because python
allows non Boolean values to be interpreted in a conditional
context. I have code somewhere that looks like this:

if var is True:

and that is exactly how it should be. The if branch should not
be taken if var would be 5. I even have code that looks like:

if var is not False:

And although in a logical context those two would be equivallent
to each other and to just "if var:", they are not equivallent
in a python context.

Yet I see a lot of suggestions here to change logical expressions
in python code, seemingly based on the fact that they would
be equivallent in a logical context.
But you don't know if the logic expression are redundant. The
suggestions made are usually not equivallent.


I think I know. Please point out if I made some mistake.

It's pretty common that people fail to reduce logical expressions.
I've seen C++ code checking for overlapping periods looking roughly
like this:

if ((start1<=start2 and stop1>=start2 and stop1<=stop2) or
(start1<=start2 and stop1>=stop2) or
(start1>=start2 and stop1<=stop2) or
(start1>=start2 and start1<=stop2 and stop1>stop2))

For that person, his code might actually have been clearer than
the less cluttered version I changed it to:

if (start1<=stop2 and start2<=stop1)

At least he spent a few minutes staring at it before he could
accept that they were equivalent. (Maybe he just gave up.)


I think he did, because both expression are not equivallent
unless some implicite constraints make them so. Values where
both expressions differ are:

start1=67, stop1=9, start2=10, stop2=29
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.


Huh? If I want False I use False. If a sequence is empty, it's empty.
It seems to me that you make things more complicated than they have
to be.


You can't just decide to use False if you want False. What if
you depend on a library that returns '', because '' behaves
as false in a conditional context. So returning it was good
enough for those who wrote it.

--
Antoon Pardon
Aug 24 '05 #68
Antoon Pardon wrote:
I think he did, because both expression are not equivallent
unless some implicite constraints make them so. Values where
both expressions differ are:

start1=67, stop1=9, start2=10, stop2=29


Ouch! That didn't occur to me. How sloppy to just assume that
time periods can't end before they start. I'll shut up now.
You win, I'm obviously the idiot here, and Python's must be
redesigned from ground up. Pyrdon maybe?
Aug 24 '05 #69
John Machin wrote:
Sigh indeed. If you need to read it a character at a time to parse it,
the design is f***ed.


There is always the potential to do 2k buffered reads and once in
memory pick the contents apart character-wise.

I assume something similar would happen for tokenising XML and HTML
which would presumably often 'read until "<"'.

Aug 25 '05 #70
Robert Kern wrote:
Robert> Please quote the message you are replying to. We have no
Robert> idea what "the 2nd option" is.

I think he means the second option you presented

If you must read one character at a time,

def reader(fileobj, blocksize=1):
"""Return an iterator that reads blocks of a given size from a
file object until EOF.
...snip

With a decent threaded news/mail reader, the thread provides
sufficient context, no?


Not taking into account the python-list gateway or GMane. I see his
message threaded directly under his original one.

And dammit, I'm vain enough that if people are complimenting my code, I
want to be sure about it. ;-)


Sorry Robert, I'm using Google Groups until I figure out the news
settings for our ISP at work (which is most unhelpful). I'm not used to
using it and the default 'Reply' option doesn't quote. :\ Not a good
excuse, I know.

Let's see... to summarise the responses I got, I liked yours the best,
Robert. It was:

def reader(fileobj, blocksize=1):
"""Return an iterator that reads blocks of a given size from a
file object until EOF.
"""
# Note that iter() can take a function to call repeatedly until
it
# receives a given sentinel value, here ''.
return iter(lambda: fileobj.read(blocksize), '')
f = open('blah.txt', 'r')
try:
for c in reader(f):
# ...
finally:
f.close()

I like it because I can make 'reader' a stock library function I can
potentially re-use and it removes complexity from the area where I want
to place the domain-specific logic (where I call reader()), which I
have a personal preference for.

Potentially the added comlexity of buffering larger chunks at a time
for efficiency could also be put into the reader() function to keep the
rest of the code super clean and neat.

Aug 25 '05 #71
Greg McIntyre wrote:
Robert Kern wrote:
Robert> Please quote the message you are replying to. We have no
Robert> idea what "the 2nd option" is.

I think he means the second option you presented

If you must read one character at a time,

def reader(fileobj, blocksize=1):
"""Return an iterator that reads blocks of a given size from a
file object until EOF.
...snip

With a decent threaded news/mail reader, the thread provides
sufficient context, no?


Not taking into account the python-list gateway or GMane. I see his
message threaded directly under his original one.

And dammit, I'm vain enough that if people are complimenting my code, I
want to be sure about it. ;-)

Sorry Robert, I'm using Google Groups until I figure out the news
settings for our ISP at work (which is most unhelpful). I'm not used to
using it and the default 'Reply' option doesn't quote. :\ Not a good
excuse, I know.


[...]

Well you could do worse than use the gmane.comp.python.general newsgroup
if you want to use an NNTP newsreader. I recently left the ISP who had
provided me with news services for years, and I am very happy with the
gmane service (though heaven only knows why they chose to use a name
other than comp.lang.python for the group: perhaps they were only aware
of the list it gateways when they established the service).

Anyway, ther price is certainly right.

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

Aug 25 '05 #72
Steve Holden wrote:
Well you could do worse than use the gmane.comp.python.general newsgroup
if you want to use an NNTP newsreader. I recently left the ISP who had
provided me with news services for years, and I am very happy with the
gmane service (though heaven only knows why they chose to use a name
other than comp.lang.python for the group: perhaps they were only aware
of the list it gateways when they established the service).


Their service is *only* about gatewaying mailing lists to their NNTP
server. I'm certain they were aware of comp.lang.python and how it is
gatewayed to python-list, but they aren't a general USENET node and
don't get USENET feeds from other nodes. gmane.comp.python.general
articles come only from python-list. I imagine that it would be impolite
to name any of their newsgroups using one of the controlled Big Eight
hierarchies.

But I agree that it is quite nice and is what I use to access
c.l.py/python-list so that I can use the same server both at home and at
work.

http://gmane.org

--
Robert Kern
rk***@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

Aug 25 '05 #73
Op 2005-08-24, Magnus Lycka schreef <ly***@carmen.se>:
Antoon Pardon wrote:
I think he did, because both expression are not equivallent
unless some implicite constraints make them so. Values where
both expressions differ are:

start1=67, stop1=9, start2=10, stop2=29
Ouch! That didn't occur to me. How sloppy to just assume that
time periods can't end before they start.


I have no trouble that you assume a time period starts before
it ends.

But two pieces of code that only give the same result under
particular assumptions are not equivallent. For all I know
his code might work without this assumption and thus be
usefull in circumstances where yours is not.

Maybe someone uses a convention where time intervals that
stop before they start can have some meaning.

Equivallent code IMO always gives the same results, not
only under the particular constraints you are working with.
I'll shut up now. You win,
I'm obviously the idiot here, and Python's must be
redesigned from ground up. Pyrdon maybe?


If I ever design a language it'll be called: 'Queny'

--
Antoon Pardon
Aug 25 '05 #74
Antoon Pardon wrote:
Op 2005-08-24, Magnus Lycka schreef <ly***@carmen.se>:
Antoon Pardon wrote:
I think he did, because both expression are not equivallent
unless some implicite constraints make them so. Values where
both expressions differ are:

start1=67, stop1=9, start2=10, stop2=29

This is just too fatuous to ignore, sorry.
Ouch! That didn't occur to me. How sloppy to just assume that
time periods can't end before they start.

I have no trouble that you assume a time period starts before
it ends.

But two pieces of code that only give the same result under
particular assumptions are not equivallent. For all I know
his code might work without this assumption and thus be
usefull in circumstances where yours is not.

Maybe someone uses a convention where time intervals that
stop before they start can have some meaning.

Equivallent code IMO always gives the same results, not
only under the particular constraints you are working with.

I'll shut up now. You win,
I'm obviously the idiot here, and Python's must be
redesigned from ground up. Pyrdon maybe?

If I ever design a language it'll be called: 'Queny'

....and you will regard it as perfect and be completely unable to
understand why nobody likes it.

Could we possibly reduce the number of arguments about ridiculous
postulates such as , and try to remember that most people on this list
are dealing with real life?

Magnus gave you a perfectly reasonable example of some code that could
be simplified. You say the two pieces of code aren't equivalent. While
you may be (strictly) correct, your assertion signally fails to add
enlightenment to the discussion.

I continue to look forward to the first post in which you actually
accept someone else's point of view without wriggling and squirming to
justify your increasingly tenuous attempts to justify every opinion
you've ever uttered on this group :-)

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

Aug 25 '05 #75
Op 2005-08-25, Steve Holden schreef <st***@holdenweb.com>:
Antoon Pardon wrote:
Op 2005-08-24, Magnus Lycka schreef <ly***@carmen.se>:
Antoon Pardon wrote:

I think he did, because both expression are not equivallent
unless some implicite constraints make them so. Values where
both expressions differ are:

start1=67, stop1=9, start2=10, stop2=29
This is just too fatuous to ignore, sorry.
You mean you can't think of circumstances where this
could be valid data.
Ouch! That didn't occur to me. How sloppy to just assume that
time periods can't end before they start.

I have no trouble that you assume a time period starts before
it ends.

But two pieces of code that only give the same result under
particular assumptions are not equivallent. For all I know
his code might work without this assumption and thus be
usefull in circumstances where yours is not.

Maybe someone uses a convention where time intervals that
stop before they start can have some meaning.

Equivallent code IMO always gives the same results, not
only under the particular constraints you are working with.

I'll shut up now. You win,
I'm obviously the idiot here, and Python's must be
redesigned from ground up. Pyrdon maybe?

If I ever design a language it'll be called: 'Queny'

...and you will regard it as perfect


I doubt that. I've looked at the problem of designing a language
and IMO it is a very complex matter, that is difficult to do
good, let alone perfect. At this moment I think very highly
about the designers of Python, because I think they have
done a very good job and Python is for the moment my language
of choice. Sure Python has its warts, but I can live with
them. I just don't like it if I get the impression that
people want to deny the warts.
and be completely unable to
understand why nobody likes it.

Could we possibly reduce the number of arguments about ridiculous
postulates such as , and try to remember that most people on this list
are dealing with real life?
So? Real life is full of thinss that could be better. If people just
want deal with that, fine. But arguing that there is nothing wrong
with how python treats conditional context is not dealing with
real life. AFAIAC writing articles in newsgroups isn't dealing
with real life, unless maybe if you have a question you need an
answer for. I deal plenty with real life myself, during working
hours that consists partly in writing python software, with all
the good and the few bad python brings.
Magnus gave you a perfectly reasonable example of some code that could
be simplified. You say the two pieces of code aren't equivalent. While
you may be (strictly) correct, your assertion signally fails to add
enlightenment to the discussion.
No, my assertion pointed out, that his code would only work under
specific constraints. Constraints that may have been very natural
in the context the program was written, but that doesn't mean
all programs work with such a constraint. He was also talking
about logical equivallence and his expression was not logical
equivallent with the one that was replaced.
I continue to look forward to the first post in which you actually
accept someone else's point of view without wriggling and squirming to
justify your increasingly tenuous attempts to justify every opinion
you've ever uttered on this group :-)


I don't post me too's. There have been plenty of posts here, I have no
problem with. I read them, give a slight nod and go on. And if I have
an opinion I was to express here, I certainly will to justify it.

--
Antoon Pardon
Aug 26 '05 #76

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: Carlo Filippini | last post by:
Hi I try to measure how fast an ftp download is going on the fly. I do something like: $|=1; my $count =0; open (CMD, "ftp.script 2>&1 |") or die "Can't execute: $!"; while (<CMD>){ print...
0
by: sstark | last post by:
Hi, I have a web/cgi script that allows users to upload a file to the web server. I want to only allow files up to a certain size, which is stored in $imageFileMaxSize (typically 75K). That part...
2
by: Gunnar | last post by:
Hello, I've just written a CPP program that reads integers from a binary file, and used this code while (my_ifstram.read( (char* ) &number, sizeof(int)) { // do something with number } My...
18
by: jas | last post by:
Hi, I would like to start a new process and be able to read/write from/to it. I have tried things like... import subprocess as sp p = sp.Popen("cmd.exe", stdout=sp.PIPE)...
4
by: yo_mismo | last post by:
Hi everyone, I'm trying to read the first line of a file this way: .... .... .... .... new_line=0; while((read=read(fd, &info, sizeof(info))) > 0 && !new_line){ if (strcmp(&info, "\n") !=...
4
by: Ollie Cook | last post by:
Hi, I am having some difficulty with read(2) and interrupting signals. I expect I am misunderstanding how the two work together, so would appreciate some guidance. I am trying to 'time out' a...
4
by: Dave | last post by:
I'm using a datareader to get data from an sql table. The line that gives the error is as follow, dtrReceivers.ToString() which gives the error, Invalid attempt to read when no data is...
2
by: Tiger | last post by:
I try to write a struct into a brut file but I can't write all var in this struct when I try to add user I have that : > testmachine:/usr/share/my_passwd# ./my_passwd -a users.db > Ajout d'une...
2
by: Saran | last post by:
Hi, Below is my scenario... I want to restrict my clients to access one of my class property in ReadOnly mode. At the same time as an author of the component i would like to have read-write...
1
by: DannyMc | last post by:
Hi all, I am in the progress of consolidating my 2 NIS databases into 1. My first step is to get the NIS record for particular department. I have software.csv which contain list of name in. ...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.