object.enable() anti-pattern
Steven D'Aprano
steve+comp.lang.python at pearwood.info
Thu May 9 14:21:37 EDT 2013
On Thu, 09 May 2013 09:07:42 -0400, Roy Smith wrote:
> In article <518b32ef$0$11120$c3e8da3 at news.astraweb.com>,
> Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
>
>> There is no sensible use-case for creating a file without opening it.
>
> Sure there is. Sometimes just creating the name in the file system is
> all you want to do. That's why, for example, the unix "touch" command
> exists.
Since I neglected to make it clear above that I was still talking about
file objects, rather than files on disk, I take responsibility for this
misunderstanding. I thought that since I kept talking about file
*objects* and *constructors*, people would understand that I was talking
about in-memory objects rather than on-disk files. Mea culpa.
So, let me rephrase that sentence, and hopefully clear up any further
misunderstandings.
There is no sensible use-case for creating a file OBJECT unless it
initially wraps an open file pointer.
This principle doesn't just apply to OOP languages. The standard C I/O
library doesn't support creating a file descriptor unless it is a file
descriptor to an open file. open() has the semantics:
"It shall create an open file description that refers to a file and a
file descriptor that refers to that open file description."
http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html
and there is no corresponding function to create a *closed* file
description. (Because such a thing would be pointless.)
Of course language designers are free to design their language to work
under whatever anti-patterns they desire. I quote from the Pascal
Language Reference:
"open associates the permanent file file [sic] with a file variable for
reading or writing. open does not actually open the file; you must call
reset or rewrite before reading or writing to that file."
http://www.amath.unc.edu/sysadmin/DOC4.0/pascal/lang_ref/
ref_builtin.doc.html
but since that's not a part of standard Pascal, other Pascals may behave
differently.
--
Steven
More information about the Python-list
mailing list