Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder4.news.weretis.net!rt.uk.eu.org!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Date: Mon, 13 May 2013 08:15:07 -0500 (CDT)
From: Wayne Werner <wayne@waynewerner.com>
To: Greg Ewing <greg.ewing@canterbury.ac.nz>
Subject: Re: object.enable() anti-pattern
In-Reply-To: <51902332.8090301@canterbury.ac.nz>
References: <518a123c$0$11094$c3e8da3@news.astraweb.com> <mailman.1490.1368098298.3114.python-list@python.org> <av2qleF58afU1@mid.individual.net> <alpine.DEB.2.02.1305121214180.3322@gilgamesh> <51902332.8090301@canterbury.ac.nz>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: python-list@python.org
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1625.1368450946.3114.python-list@python.org>
Lines: 53
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:45237

On Mon, 13 May 2013, Greg Ewing wrote:

> Wayne Werner wrote:
>> On Fri, 10 May 2013, Gregory Ewing wrote:
>>
>>>   f = open("myfile.dat")
>>>   f.close()
>>>   data = f.read()
>> 
>> To clarify - you don't want a class that has functions that need to be 
>> called in a certain order with *valid input* in order to not crash.
>> 
>> Exactly what does happen - a ValueError is raised because you're(*) passing 
>> self into the file.read() function, and that input is invalid
>
> The same argument can be applied to:
>
>   foo = Foo()
>   foo.do_something()
>   foo.enable() # should have done this first
>
> You're passing an invalid input to Foo.do_something,
> namely a Foo that hasn't been enabled yet.

That is the crux of the argument - as designer of the class *you* need to 
ensure that when your constructor is done, your class is in a stable 
state. And that every other state transition (with valid input) results in 
your class then being in a stable state.


If anything, the stronger argument is that `file.close()` is not a well 
designed function because it leaves your object in an unstable state.

Which I would be inclined to agree with, but I couldn't give you the 
answer for what makes it better. Because the answer is the best one you 
can get in computer science: It depends.


The reason that it depends, is because it depends on what you want to do. 
Do you want a program that seems purely functional? Do you want a program 
that's easy to maintain? Do you want a program that more accurately models 
the "real world"?

Personally, I think the file object API in Python is about as good as it 
can get - but that's because it's working with "physical" things (i.e. 
files - bits on a platter, or flash/SSD drive...) which necessarily have a 
temporal nature. And it's much less badness to blow up on a call to `read` 
than it is to remove the `read` function and die with a NameError when the 
underlying file is in a closed state.


At least in my opinion ;)
-W