Terry Reedy wrote: > "Nick Coghlan" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > >>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@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ncoghlan%40email.com > -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com