Boolean value of file object?
Just an off-the-wall thought. Is there any reason a file object's boolean value shouldn't be false once it's been closed? This would allow replacing "if f and f.closed:" (to make sure you have a file and it's open) with just "if f:". Is there some use case where you want to verify that an object is a file object instead of None (or another false value), and don't care if it's closed? My own thought is that this is a case where status quo wins, but thought someone else might think the idea has more merit. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On Sun, Jan 8, 2012 at 11:07 AM, Mike Meyer <mwm@mired.org> wrote:
My own thought is that this is a case where status quo wins, but thought someone else might think the idea has more merit.
Unfortunately, there are way too many "file-like objects" in the wild for it to ever be feasible to rely on such a shorthand. Cute idea, though. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Jan 7, 2012, at 5:07 PM, Mike Meyer wrote:
Is there any reason a file object's boolean value shouldn't be false once it's been closed?
Because that would make it harder to learn what things in Python can be False and what that implies. Currently, None is always false, numbers are false when they are zero, and containers are false when they are empty. Files objects don't fit into that model. Some would question whether a file could be considered a container. Even if a file was considered a container, there is still an important distinction between files that are closed versus files that are empty (i.e. they have a length of zero). Lastly, the file API is adopted by many objects, so we would need to change them all. Raymond
On Sun, Jan 8, 2012 at 5:08 AM, Raymond Hettinger < raymond.hettinger@gmail.com> wrote:
there is still an important distinction between files that are closed versus files that are empty (i.e. they have a length of zero).
and `file`s that are None. When you check f.closed explicitly - the None objects throw an exception.
On Sun, Jan 8, 2012 at 11:07 AM, Mike Meyer <mwm@mired.org> wrote:
My own thought is that this is a case where status quo wins, but thought someone else might think the idea has more merit.
Unfortunately, there are way too many "file-like objects" in the wild for it to ever be feasible to rely on such a shorthand. Cute idea, though. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Jan 7, 2012, at 5:07 PM, Mike Meyer wrote:
Is there any reason a file object's boolean value shouldn't be false once it's been closed?
Because that would make it harder to learn what things in Python can be False and what that implies. Currently, None is always false, numbers are false when they are zero, and containers are false when they are empty. Files objects don't fit into that model. Some would question whether a file could be considered a container. Even if a file was considered a container, there is still an important distinction between files that are closed versus files that are empty (i.e. they have a length of zero). Lastly, the file API is adopted by many objects, so we would need to change them all. Raymond
On Sun, Jan 8, 2012 at 5:08 AM, Raymond Hettinger < raymond.hettinger@gmail.com> wrote:
there is still an important distinction between files that are closed versus files that are empty (i.e. they have a length of zero).
and `file`s that are None. When you check f.closed explicitly - the None objects throw an exception.
participants (6)
-
anatoly techtonik -
Antoine Pitrou -
Mike Meyer -
Nick Coghlan -
Raymond Hettinger -
Steven D'Aprano