[Python-Dev] PEP 343 update (with statement context terminology)

Nick Coghlan ncoghlan at gmail.com
Tue Apr 25 05:22:18 CEST 2006


Paul Moore wrote:
> In the documentation of contextmanager, consider the examples:
> 
>     @contextmanager
>     def tag(name):
>         ...
> 
>     class Tag:
>         ...
>         @contextmanager
>         def __context__(self):
>             ...
> 
> Now, tag should be a function which returns a context manager (a1
> definition - object with a __context__ method) ("with" statement, item
> 1 of the definition). On the other hand, Tag.__context__ is a context
> manager's __context__ method, which according to item 2 of the
> definition of the "with" statement, should be a function which returns
> a context object (a1 definition - object with __enter__ and __exit__
> methods).
> 
> *These are two different types of function*.

Paraphrasing:

   def iterseq(seq):
       for x in range(len(seq)):
           yield x[i]

   class Container:
       ...
       def __iter__(self):
           for x in self.contents:
               yield x

Now, iterseq should be a function which returns an iterable (object with an 
__iter__() method that is passed to for statements). On the other hand, 
Tag.__iter__ is an iterable's __iter__ method, which should be a function 
which returns an iterator (an object with __iter__() and next() methods).

*These are two different types of function*.

Why yes, yes they are. When iterators were introduced, a deliberate design 
decision was taken to make the iterator protocol a superset of the iterable 
protocol, precisely to allow for loops not to care whether they were being 
given an iterable or an iterator.

Iterator's can be standalone, or they can be intended specifically for use as 
a particular iterable's native iterator. The terminology is the same either way.

PEP 343 made a *deliberate, conscious design decision* to copy the semantics 
of iterators by making the context management protocol a superset of the 
context protocol (or rather, the context specification protocol in alpha 2).

What I don't understand is why you and Phillip are so keen on breaking this 
deliberate symmetry with an existing part of the language design. Of course it 
isn't necessary, but then neither was it necessary to make the iterator 
protocol a superset of the iterable protocol.

Cheers,
Nick.

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


More information about the Python-Dev mailing list