[Python-Dev] Possible context managers in stdlib

[Nick Coghlan]

Terry Reedy wrote:
> "Nick Coghlan" <ncoghlan at gmail.com> wrote in message 
> news:42D3A766.90705 at gmail.com...
> 
>>The main outcome of the PEP 343 terminology discussion was some proposed
>>documentation I put on the Sourceforge patch tracker ([1]).
> 
> Is this a proposal for the Language Reference manual?

No - it's for an entry in the Library reference under 'built-in types', as a 
sibling to the current documentation of the iteration protocol.

The 'with' statement itself would have to be documented along with the rest of 
the grammar.

>>A simpler way to achieve this in Python is to use the 'with' statement
>>along with the appropriate context manager.
> 
> Somewhere about here we need the syntax itself.

I'm not sure. We don't reproduce the 'for' loop syntax in the documentation of 
iterators, so should we reproduce the 'with' statement syntax in the 
documentation of context managers?

Again, modelling on the existing documentation of the iteration protocol, I 
would expect the statement syntax to be introduced in the tutorial (e.g. as 
part of Section 8.6, where try/finally is introduced).

>>Context managers define an...
>>     the contained suite starts. If the 'as' clause of the 'with'
> 
> 
> Else this does not mean much.
> ...
> 
>>The simplest use of context management is to strictly control the
>>handling of key resources (such as files, generators, database
>>connections, synchronisation locks).
> 
> I have a little trouble seeing generators (as opposed to iterables) as 
> resources needing management.

PEP 342 adds this, in order to allow 'yield' inside tyr/finally blocks.
> 
> 
>>For example, the following context manager allows prompt closure of
>>any resource with a 'close' method (e.g. a generator or file):
> 
> 
> And I was not aware that they had close methods.  You mean a iterable (not 
> just a file) with both an associated generator and a close?  Or are 
> generators gaining close methods (which make no sense to me).  Or are you 
> using 'generator' in a different sense?

Sorry - these docs assume PEP 342 has been implemented, so generator's have 
close() methods. I was trying to steer clear of files, since we don't know yet 
whether there is going to be an "opening" or "closing" implementation in the 
standard library, or whether files will become context managers. The latter is 
my preference, but Guido didn't seem too keen on the idea last time it was 
brought up.

> 
> 
>>     class closing(object):
>>         def __init__(self, resource):
>>             self.resource = resource
>>
>>         def __enter__(self):
>>             return self.resource
>>
>>         def __exit__(self, *exc_info):
>>             self.resource.close()
>>
>>
>>    with closing(my_generator()) as g:
>>        # my_generator() is assigned to g via call to __enter__()
>>        for item in g:
>>            print item
>>    # g is closed as the with statement ends
> 
> 
> To me, this should be with closing(my_iterable())... with 'for' calling 
> g.__iter__ to get the iterator that is possibly a generator.  Otherwise, I 
> don't understand it.
> 
> The rest is pretty clear.
> 
> Terry J. Reedy
> 
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ncoghlan%40email.com
> 


-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com