On Fri, May 10, 2013 at 1:19 PM, Mark Janssen <dreamingforw...@gmail.com> wrote: >> I think where things went pear shaped is when you made the statement: >> >>>> There is no sensible use-case for creating a file OBJECT unless it >>>> initially wraps an open file pointer. >> >> That's a pretty absolute point of view. Life is rarely so absolute. > > In the old days, it was useful to have fine-grained control over the > file object because you didn't know where it might fail, and the OS > didn't necessarily give you give good status codes. So being able to > step through the entire process was the job of the progammers.
I don't know what you mean by the "old days", but a couple of decades ago, there were no such things as "file objects". You call a function to open a file, you get back a number. You explicitly close that by calling another function and passing it that number. In fact, there is no way to have a "file object" that doesn't have an open file associated with it, because it's simply... a number. > Now, with languages so high like python and hardware so common, it > almost is never necessary, so he has some point. A closed file > pointer is useful from a OS-progamming point-of-view though because > you generally never want to leave files open where they'd block other > I/O. I'm beginning to wonder if you and Dihedral are swapping notes. Dihedral's been sounding fairly coherent lately. ChrisA -- http://mail.python.org/mailman/listinfo/python-list