[Python-ideas] "While" suggestion

Stavros Korokithakis stavros at korokithakis.net
Thu Jul 3 17:09:13 CEST 2008


This was apparently resuggested in PEP 315 but they couldn't get the 
syntax right: http://www.python.org/dev/peps/pep-0315/

I believe that my proposal deals with that issue by keeping the syntax 
coherent with the rest of Python (especially with the "with" keyword) 
and has all the advantages of the restructured code.

There are also some use cases in that PEP.

Stavros

Thomas Lee wrote:
> Stavros Korokithakis wrote:
>> I don't think they do, if I'm not mistaken the only way is to call 
>> read() and see if it returns the empty string. I agree that this would 
>> be better, but the use case I mentioned is not the only one this would 
>> be useful in... Unfortunately I can't think of any right now, 
> :)
>> but there have been a few times when I had to initialise things 
>> outside the loop and it always strikes me as ugly.
>>
> Well that depends, on the situation really. The only use case I can 
> think of is exactly the one you mentioned. And since you can't think of 
> any other scenarios where such a thing might be handy, I've got no 
> better suggestion to offer.
> 
> If you can conjure up another scenario, post it back here and we'll see 
> if we can generalize the pattern a little.
> 
> In the meantime, I'd love a way to check if a file is at its end without 
> having to read data out of it ...
> 
> Cheers,
> T
> 
> P.S. you might be interested in using something like the following to 
> hide the ugliness in a function:
> 
> def reader(stream, size):
>  data = stream.read(size)
>  while data:
>    yield data
>    data = stream.read(size)
> 
> Then you could use it as follows:
> 
> for block in reader(my_file, 1024):
>  do_something(block)
>> Thomas Lee wrote:
>>> It's not currently possible to determine if a file/stream is at its 
>>> end, is it?
>>>
>>> If that were the case you could easily do the read before your 
>>> do_something call. Something like:
>>>
>>> while not my_file.eof:
>>>  data = my_file.read(1024)
>>>  do_something(data)
>>>
>>> Can anyone explain why file objects don't support some sort of eof 
>>> check? Something gives me the impression that it was an intentional 
>>> decision.
>>>
>>> IMO something like this would be better than more syntax.
>>>
>>> Cheers,
>>> T
>>>
>>> Stavros Korokithakis wrote:
>>>> Hello all,
>>>> I have noticed that sometimes "while" loops produce "unpythonic" 
>>>> patterns, such as the following:
>>>>
>>>> data = my_file.read(1024)
>>>> while data:
>>>>     do_something(data)
>>>>     data = my_file.read(1024)
>>>>
>>>> The assignment is repeated, which is less than optimal. Since we 
>>>> don't have a while statement that does the check in the end, would 
>>>> it not be better if the syntax of while could be amended to  include 
>>>> something like this (in the spirit of the new "with" keyword)?:
>>>>
>>>> while my_file.read(1024) as data:
>>>>    do_something(data)
>>>>
>>>> This would terminate the loop when myfile.read() evaluated to False, 
>>>> and it is more pythonic than repeating onesself.
>>>>
>>>> I contacted GvR about this, and he replied that this syntax would 
>>>> have to be part of the expression than part of the while, which I 
>>>> agree would be less than ideal. However, I don't see why it would 
>>>> have to be part of the expression, since the "while" could easily 
>>>> assign the value of the expression to the variable and break if it 
>>>> evaluates to False.
>>>>
>>>> I would appreciate any thoughts on this,
>>>> Stavros Korokithakis
>>>> ------------------------------------------------------------------------ 
>>>>
>>>>
>>>> _______________________________________________
>>>> Python-ideas mailing list
>>>> Python-ideas at python.org
>>>> http://mail.python.org/mailman/listinfo/python-ideas
>>>>   
>>>
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stavros.vcf
Type: text/x-vcard
Size: 143 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20080703/d2922a98/attachment.vcf>


More information about the Python-ideas mailing list