Context manager, atexit processing, and PEP 3143 DaemonContext.close

[MRAB]

Duncan Booth wrote:
> Ben Finney <ben+python at benfinney.id.au> wrote:
> 
>> MRAB <google at mrabarnett.plus.com> writes:
>>
>>> Gunter Henriksen wrote:
>>>> If there is a function which triggers a one-shot switch, I like to
>>>> have a way to find out if it has already been triggered, I prefer
>>>> to have the function tell me if it triggered the switch or not, but
>>>> I would not want that to be by raising an exception.
>>> The 'file' class also has a 'closed' method, so that's a good model
>>> to follow.
>> Yes, I find that convincing as well. (I might prefer it to instead
>> answer the question “is it currently open?”, i.e. an ‘opened’
>> query, but that makes for more awkward English than ‘closed’.)
>>
> In the general case you might have an object which you create then open as 
> an explicit step. Later you close it explicitly before it is discarded. In 
> that case methods 'opened' and 'closed' both make sense but mean different 
> things. For a file object, where construction always opens the file, an 
> opened method (if it existed) should always return true so isn't useful.
> 
> Or in other words, I take the word 'opened' as meaning 'has been opened' 
> which is not the same as 'is currently open'.
> 
Equally you could say that "closed" means "has been closed", which is
not the same as "is currently closed". Unusual, but possible! :-)

Borrowing from the string class, it would be "isopen" (like "isdigit",
probably influenced by C), although these days we would write "is_open".