Op 2005-08-25, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-08-24, Magnus Lycka schreef <[EMAIL PROTECTED]>:
>>
>>>Antoon Pardon wrote:
>>>
I think he did, because both expression are not equivallent
unless some implicite constraints make them so. Values wher
Antoon Pardon wrote:
> Op 2005-08-24, Magnus Lycka schreef <[EMAIL PROTECTED]>:
>
>>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, st
Op 2005-08-24, Magnus Lycka schreef <[EMAIL PROTECTED]>:
> 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! T
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 cho
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(fileob
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):
> >
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
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
Op 2005-08-24, Magnus Lycka schreef <[EMAIL PROTECTED]>:
> 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 con
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 sh
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)
On 22 Aug 2005 02:48:24 -0700, Paul Rubin <http://[EMAIL PROTECTED]> wrote:
>"Greg McIntyre" <[EMAIL PROTECTED]> writes:
>> while c = f.read(1):
>> # ...
>>
>> I couldn't find any general PEPs along these lines, only specific ones
&g
Dennis Lee Bieber wrote:
> On Tue, 23 Aug 2005 12:15:36 +0200, Magnus Lycka <[EMAIL PROTECTED]>
> 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
Op 2005-08-23, Sybren Stuvel schreef <[EMAIL PROTECTED]>:
> 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
>>
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 w
Op 2005-08-23, rafi schreef <[EMAIL PROTECTED]>:
> 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 us
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
Op 2005-08-23, Magnus Lycka schreef <[EMAIL PROTECTED]>:
> 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
> wr
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
Op 2005-08-22, Donn Cave schreef <[EMAIL PROTECTED]>:
> 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
> st
Op 2005-08-22, Magnus Lycka schreef <[EMAIL PROTECTED]>:
> 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
Robert Kern wrote:
> 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 answer
Donn Cave wrote:
> 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 q
> 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.
--
http:
John Hunter wrote:
>>"Robert" == Robert Kern <[EMAIL PROTECTED]> 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
> "Robert" == Robert Kern <[EMAIL PROTECTED]> 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
>> un
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 ban
Robert Kern wrote:
> Paul Rubin wrote:
>
>>Robert Kern <[EMAIL PROTECTED]> writes:
>>
>>
>http://www.catb.org/~esr/faqs/smart-questions.html
Is it a *smart* way or *necessary* way?
>>>
>>>It's the polite way. And probably the only way you're going to get
>>>your questions actually ans
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 anyw
"Greg McIntyre" <[EMAIL PROTECTED]> writes:
> My files are large, hence 1 character at a time, not f.read().
There are alternatives between the two. You could read in a chunk of
reasonable size for your platform. Say 10meg on a recent workstation,
or 100meg on a current workstation.
> This is cod
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 p
Op 2005-08-22, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-08-19, Donn Cave schreef <[EMAIL PROTECTED]>:
>>
>>>In article <[EMAIL PROTECTED]>,
>>> Antoon Pardon <[EMAIL PROTECTED]> wrote:
>>>...
>>>
But '', {}, [] and () are not nothing. They are empty container
le 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 r
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
Antoon Pardon wrote:
> Op 2005-08-19, Donn Cave schreef <[EMAIL PROTECTED]>:
>
>>In article <[EMAIL PROTECTED]>,
>> Antoon Pardon <[EMAIL PROTECTED]> wrote:
>>...
>>
>>>But '', {}, [] and () are not nothing. They are empty containers.
>>
>>Oh come on, "empty" is all about nothing.
>
>
> No it is
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.
Please quote the message you are replying
That is both clever and useful! I never would have thought of doing
that.
This seems to me like a general way to "workaround" the Python
statement/expression separation woes I've been having, in cases where I
really really want it.
Now, where can I copy this out to so I will be able to find it wh
27;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
"Greg McIntyre" <[EMAIL PROTECTED]> 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:
I've always accepted the None vs. 0 as a cavaet of the added
convenience but I think it's ultimately worth it.
Sorry, I didn't want to start a
"nothing values evaluate to false" argument.
I'll go read python-dev archives a bit and see if there's anything
useful for me to know.
Thanks
--
http:/
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 =
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.
I like it! Thank you! The assurance that the code was clear was good
t
Okay, the 1st option seems more complicated and the 2nd option, while
simpler to my eye makes me worry about file descriptors, resource
management and memory running out.
My files are large, hence 1 character at a time, not f.read().
This is code from another employee and I'm just in the stages o
Op 2005-08-19, Donn Cave schreef <[EMAIL PROTECTED]>:
> In article <[EMAIL PROTECTED]>,
> Antoon Pardon <[EMAIL PROTECTED]> wrote:
> ...
>> But '', {}, [] and () are not nothing. They are empty containers.
>
> Oh come on, "empty" is all about nothing.
No it is not. There are situation where False
Paul Rubin wrote:
> Reinhold Birkenfeld <[EMAIL PROTECTED]> writes:
>
>>Don't forget
>>
>>for line in f:
>>for c in line:
>># do stuff
>
>
> As mentioned before, that's careless programming, since it can read
> the whole file into memory if the file contains no newlines.
I agree tha
Reinhold Birkenfeld wrote:
> John Machin wrote:
>
>
>>... AND it's about time that list is updated to include False explicitly
>> -- save nitpicking arguments about whether False is covered by
>>"numeric zero of all types" :-)
>
>
> Done.
Thanks -- those of us who actually read manuals salu
Reinhold Birkenfeld <[EMAIL PROTECTED]> writes:
> Don't forget
>
> for line in f:
> for c in line:
> # do stuff
As mentioned before, that's careless programming, since it can read
the whole file into memory if the file contains no newlines.
--
http://mail.python.org/mailman/listinfo/
John Machin wrote:
> ... AND it's about time that list is updated to include False explicitly
> -- save nitpicking arguments about whether False is covered by
> "numeric zero of all types" :-)
Done.
>> If I try:
>>
>> f = open
sing lambda and iter that way was considered a bad answer
to "how do you write something like 'while c = f.read(1)'".
Anyway, quick explanation of lambda: it's a way of creating functions
without having to give then names. Example:
lambda x: x*x
is a function tha
Robert Kern 쓴 글:
>
> Now go read the documentation.
>
Thanks to your comments, I read the corresponding helps searched by
Google. (Sorry to say a specific search engine here, but I must say that
it is really convinient.)
Now I realized that Command 'lambda' is a similar to Command 'inline' in
On 19 Aug 2005 23:13:44 -0700, "James" <[EMAIL PROTECTED]> wrote:
>> for data in iter(lambda:f.read(1024), ''):
>> for c in data:
>
>What are the meanings of Commands 'iter' and 'lambda', respectively? I
>do not want you to indicate merely the related help pages. Just your
>ituitive and short
Paul Rubin wrote:
> Robert Kern <[EMAIL PROTECTED]> writes:
>
http://www.catb.org/~esr/faqs/smart-questions.html
>>>
>>>Is it a *smart* way or *necessary* way?
>>
>>It's the polite way. And probably the only way you're going to get
>>your questions actually answered.
>
> I wonder if there's a
On 2005-08-20, James <[EMAIL PROTECTED]> wrote:
>> for data in iter(lambda:f.read(1024), ''):
>> for c in data:
>
> What are the meanings of Commands 'iter' and 'lambda', respectively? I
> do not want you to indicate merely the related help pages.
Rude much?
If somebody is kind enough to poin
Robert Kern <[EMAIL PROTECTED]> writes:
> >>http://www.catb.org/~esr/faqs/smart-questions.html
> > Is it a *smart* way or *necessary* way?
>
> It's the polite way. And probably the only way you're going to get
> your questions actually answered.
I wonder if there's a way to killfile posts that co
James Kim wrote:
> Robert Kern wrote:
>
>>http://www.catb.org/~esr/faqs/smart-questions.html
>
> Is it a *smart* way or *necessary* way?
It's the polite way. And probably the only way you're going to get your
questions actually answered.
Read the documentation. If you still don't understand so
James Kim wrote:
>Robert Kern wrote:
>
>
>>http://www.catb.org/~esr/faqs/smart-questions.html
>>
>>
>
>Is it a *smart* way or *necessary* way?
>
>
Of course it's not *necessary*. I mean, the world isn't going to come
to an end if it doesn't happen. There is no logical contingency making
Robert Kern wrote:
> http://www.catb.org/~esr/faqs/smart-questions.html
Is it a *smart* way or *necessary* way?
Plus, my question was not for the detail description but for the
intuitive guide leading the beginner's further study.
I understand that too many repeated talks make cyberian tired. H
James wrote:
>>for data in iter(lambda:f.read(1024), ''):
>>for c in data:
>
> What are the meanings of Commands 'iter' and 'lambda', respectively? I
> do not want you to indicate merely the related help pages. Just your
> ituitive and short explanations would be enough since I'm really newbie
> for data in iter(lambda:f.read(1024), ''):
> for c in data:
What are the meanings of Commands 'iter' and 'lambda', respectively? I
do not want you to indicate merely the related help pages. Just your
ituitive and short explanations would be enough since I'm really newbie
to Python.
-James
bit
> spaghetti.
>
> This is what I would ideally like:
>
> f = open("blah.txt", "r")
> while c = f.read(1):
> # ... work on c
for data in iter(lambda:f.read(1024), ''):
for c in data:
# ... work on c
--
jk
--
http://mail.python.org/mailman/listinfo/python-list
[EMAIL PROTECTED] wrote:
> Alright, everyone seems to have gone off on a tangent here, so I'll try
> to stick to your code...
> """
> This is what I would ideally like:
>
>
> f = open("blah.txt", "r")
> while c = f.r
en("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.
>
On 2005-08-19, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Alright, everyone seems to have gone off on a tangent here, so I'll try
> to stick to your code...
> """
> This is what I would ideally like:
>
>
> f = open("blah.txt", "
Alright, everyone seems to have gone off on a tangent here, so I'll try
to stick to your code...
"""
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
In article <[EMAIL PROTECTED]>,
Antoon Pardon <[EMAIL PROTECTED]> wrote:
...
> But '', {}, [] and () are not nothing. They are empty containers.
Oh come on, "empty" is all about nothing.
> And 0 is not nothing either it is a number. Suppose I have
> a variable that is either None if I'm not regi
Antoon Pardon wrote:
> But '', {}, [] and () are not nothing. They are empty containers.
> And 0 is not nothing either it is a number. Suppose I have
> a variable that is either None if I'm not registered and a
> registration number if I am. In this case 0 should be treated
> as any other number.
break # EOF
>| # ... work on c
>|
>| Is some way to make this code more compact and simple? It's a bit
>| spaghetti.
>
> 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
On 19 Aug 2005 03:43:31 -0700
Paul Rubin wrote:
> <[EMAIL PROTECTED]> writes:
> > import itertools
> > f = open("blah.txt", "r")
> > for c in itertools.chain(*f):
>
> But that can burn an unlimited amount of memory if there are long
> stretches of the file with no newlines. There's no real good
[EMAIL PROTECTED] wrote:
> import itertools
> f = open("blah.txt", "r")
> for c in itertools.chain(*f):
> print c
> # ...
>
> The "f" is iterable itself, yielding a new line from the file every time.
> Lines are iterable as well, so the itertools.chain iterates through each
> line and y
<[EMAIL PROTECTED]> writes:
> import itertools
> f = open("blah.txt", "r")
> for c in itertools.chain(*f):
> print c
> # ...
>
> The "f" is iterable itself, yielding a new line from the file every time.
> Lines are iterable as well, so the itertools.chain iterates through each
> line and
On 18 Aug 2005 22:21:53 -0700
Greg McIntyre wrote:
> 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.
import i
== '': 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.r
ty & understandability. Spaghetti is like a GOTO
that jumps backwards into the middle of a loop for no discernable reason.
>
> This is what I would ideally like:
>
> f = open("blah.txt", "r")
> while c = f.read(1):
> # ... work on c
>
&
le? It's a bit
| spaghetti.
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):
|
Greg McIntyre wrote:
> 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.
That's not spaghetti. Not even close.
gt;
>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
>
How about (untested):
for c in iter((lambda f=ope
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:
77 matches
Mail list logo
