[Python-ideas] with expression

Andrew Barnert abarnert at yahoo.com
Thu Feb 20 23:07:06 CET 2014


On Feb 20, 2014, at 13:46, Jan Kaliszewski <zuo at chopin.edu.pl> wrote:

> 20.02.2014 22:33, Yann Kaiser wrote:
> 
>> The first one could be accomplished like:
>> 
>>    x = [line.split() for line in f] with open(thisfile) as f
>> 
>> It would keep f opened while the listcomp is being evaluated. This
>> makes me think however of a likely accident:
>> 
>>    x = (line.split() for line in f) with open('name') as f
>>    next(x) # ValueError: I/O operation on closed file.
>> 
>> This does mirror this mistake though:
>> 
>>    with open('name') as f:
>>        return (line.split() for line in f)
>> 
>> When what was meant was:
>> 
>>    with open('name') as f:
>>        for line in f:
>>            yield line.split()
>> 
>> (Which is, unfortunately, a __del__ in disguise, which is frowned upon.)
> 
> Why 'unfortunately'?

Relying on __del__ to clean up your files (and other expensive resources) is a bad idea if you only use CPython, and a terrible idea if your code might ever be run on other implementations: it means you don't get deterministic cleanup.

And writing something using a with statement--which was explicitly designed to solve that problem--that still relies on __del__ would be dangerously misleading.

However, as I pointed out in my other message, this is not really a __del__ in disguise, because if you use this in cases where the returned iterator is fully consumed in normal circumstances (e.g., a chain of iterator transformations that feeds into a final listcomp or writerows or executemany or the like), you _do_ get deterministic cleanup.

> 
> Cheers.
> *j
> 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/


More information about the Python-ideas mailing list