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