object.enable() anti-pattern

[Steven D'Aprano]

On Fri, 10 May 2013 17:59:26 +0100, Nobody wrote:

> On Thu, 09 May 2013 05:23:59 +0000, Steven D'Aprano wrote:
> 
>> There is no sensible use-case for creating a file without opening it.
>> What would be the point? Any subsequent calls to just about any method
>> will fail. Since you have to open the file after creating the file
>> object anyway, why make them two different calls?
> 
> As a counterpoint, some OSes (e.g. Plan 9) allow you to get a "handle"
> to a file without opening it. This can then be used for deleting,
> renaming or stat()-type operations without either the risk of race
> conditions (if another process renames files between operations, the
> operations may be performed on different files) or the side-effects of
> actually opening the file (particularly for device files, e.g. opening a
> tape drive may rewind the tape).

Ah, now that's a fantastic counter-example. But I think that says more 
about the primitiveness of the Unix file model than of the idea of 
temporal coupling.


> Python's file model doesn't allow for this, so there isn't really
> anything meaningful that you can do on a file object which isn't open
> (although these actually exist; any file object on which the .close()
> method has been called will be in this state).

Absolutely correct, and I'm amazed it's taken this long for anyone to 
point this out :-)



-- 
Steven