Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Phillip J. Eby]

At 01:34 PM 4/22/2006 +1000, Nick Coghlan wrote:
Phillip J. Eby wrote:
At 10:51 AM 4/21/2006 -0400, A.M. Kuchling wrote:
On Fri, Apr 21, 2006 at 07:31:35PM +1000, Nick Coghlan wrote:
fit the new definition. So we settled on calling them context managers
instead.
  ...
method. Instead, the new term manageable context (or simply context)
was introduced to mean anything with a __context__ method. This was OK,
Meaning that 'manageable context' objects create and destroy 'context
managers'...  My view is still that 'context manager' is a terrible
name when used alongside objects called 'contexts': the object doesn't
manage anything, and it certainly doesn't manage contexts -- in fact
it's created by 'context' objects.
And that's more or less why I wrote the documentation the way I did.
Nick, as I understand your argument, it's that we were previously using 
the term context manager to mean thing with __enter__ and 
__exit__.  But that was *never* my interpretation.
My understanding of context manager was always, thing that you give to 
a with statement.

Then why didn't you speak up when the discussion was summarised in PEP 343 
for Guido's approval? I said it explicitly:

  This PEP proposes that the protocol used by the with statement be
  known as the context management protocol, and that objects that
  implement that protocol be known as context managers. The term
  context then encompasses all objects with a __context__() method
  that returns a context manager object. (This means that all context
  managers are contexts, but not all contexts are context managers)

I guess a slight ambiguity came in from the fact I didn't spell out that 
the protocol I was referring to was all three methods with __context__ 
returning self (i.e. the moral equivalent of the 'iterator protocol'). But 
the rest of the paragraph doesn't make any sense otherwise.

Because the last time I looked at the PEP, I was trying to make sure that 
the code samples in the PEP worked with Guido's last-minute decision to go 
with the return vs. raise protocol that I originally proposed for __exit__, 
and didn't have the time to sort through the terminology change.

Later, when I wrote up documentation, I mostly did it from memory.  The 
next time I looked at the PEP was when AMK asked for clarification.


That may have been what you personally thought, but it's not what the PEP 
said. If you disagreed with the summarisation in the PEP, you should have 
said so before Guido approved it, or brought it back to python-dev as a 
discussion about changing the standard terminology rather than just the 
PEP's confusing, I want to clear it up (and completely changing the 
meaning in the process).

I changed the PEP because Guido asked me to, right here on Python-Dev, 
after AMK asked the question and I seconded his guess as to the 
interpretation.  I wouldn't have otherwise checked in changes to a PEP that 
doesn't have my name on it:

http://mail.python.org/pipermail/python-dev/2006-April/063856.html

If you have a problem with what I did to the PEP, kindly take it up with 
Guido.  If you have a problem with the documentation I took the time to 
write and contribute, by all means change it.  At this point, I'm getting 
pretty tired of people of accusing me of violating procedures around here, 
and I'm past caring what you do or don't call the bloody objects.  At least 
I've gotten contextlib and test_contextlib to actually work, and arranged 
for there to be *some* documentation for the with statement and the 
contextlib module.

Meanwhile, the iterator-iterable analogy is false.  You have to be able to 
iterate over an iterator, but as AMK pointed out, you don't have to be able 
to pass a [thing having __enter__/__exit__] to a with statement.  So I 
was wrong to apply that analogy myself, as are you now.

That having been said, I don't think either you or I or even Guido should 
be the ones to fix the PEP and the docs at this point, as we've all stared 
at the bloody thing way too long to see it with fresh eyes.  So far, AMK is 
the one who's finding all our screwups, so maybe he should be the one to 
explain it all to *us*.  :)

___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Phillip J. Eby]

At 01:34 PM 4/22/2006 +1000, Nick Coghlan wrote:
Then why didn't you speak up when the discussion was summarised in PEP 343 
for
Guido's approval? I said it explicitly:
...
That may have been what you personally thought, but it's not what the PEP
said.

By the way, Greg Ewing coined the term context manager, combining my 
proposals of resource manager and context listener:

http://mail.python.org/pipermail/python-dev/2005-July/054607.html
http://mail.python.org/pipermail/python-dev/2005-July/054628.html

And from this email, it's clear that other people in the discussion 
interpreted this term to refer to thing given to the 'with' statement:

http://mail.python.org/pipermail/python-dev/2005-July/054615.html

However, you seemed to want to call this a context, even then:

http://mail.python.org/pipermail/python-dev/2005-July/054656.html

So, if anything is clear from all this, it's that nothing has ever been 
particularly clear in all this.  :)

Or more precisely, I think everybody has been perfectly clear, we just 
haven't really gotten on the same page about which words mean what.  ;)

___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Nick Coghlan]

Phillip J. Eby wrote:
 If you have a problem with what I did to the PEP, kindly take it up with 
 Guido.  If you have a problem with the documentation I took the time to 
 write and contribute, by all means change it.  At this point, I'm 
 getting pretty tired of people of accusing me of violating procedures 
 around here, and I'm past caring what you do or don't call the bloody 
 objects.  At least I've gotten contextlib and test_contextlib to 
 actually work, and arranged for there to be *some* documentation for the 
 with statement and the contextlib module.

I'm not trying to diminish the work you've done to make this happen - I *did* 
review those docs after you put them in, and completely missed the discrepancy 
between them and the wording in the PEP. So the current confusion is at least 
as much my fault as anyone else's :)

The one thing I wasn't sure of after AMK brought it up was whether or not 
there'd been an offline discussion at PyCon that had made the change on purpose.

 Meanwhile, the iterator-iterable analogy is false.  You have to be able 
 to iterate over an iterator, but as AMK pointed out, you don't have to 
 be able to pass a [thing having __enter__/__exit__] to a with 
 statement.  So I was wrong to apply that analogy myself, as are you now.

This is only true if we're happy for calling ctx.__context__() explicitly to 
produce something unusable.

i.e., just as these are equivalent:

   for x in iterable:
   pass

   itr = iter(iterable)
   for x in itr:
   pass

I believe these should be equivalent:

   with ctx as foo:
   pass

   ctx_mgr = ctx.__context__()
   with ctx_mgr as foo:
   pass

The only way for that to happen is if context managers all have a 
__context__() method that returns self.

 That having been said, I don't think either you or I or even Guido 
 should be the ones to fix the PEP and the docs at this point, as we've 
 all stared at the bloody thing way too long to see it with fresh eyes.  
 So far, AMK is the one who's finding all our screwups, so maybe he 
 should be the one to explain it all to *us*.  :)

Heh. I actually had to go trawling back through the python-dev archives to 
figure out whether or not I was going nuts :)

Alternatively, I could have a go at clearing it up for next week's alpha2, and 
we can ask Anthony to make an explicit request for review of those docs in the 
announcement. . .

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Guido van Rossum]

On 4/22/06, Nick Coghlan [EMAIL PROTECTED] wrote:
 *This* is what Guido approved, not what is currently written up in the PEP on
 python.org.

Nick, please get unstuck on the who said what when and who wasn't
listening thing. I want this to be resolved to use the clearest
terminology possible. As you can clearly tell from my recent posts I'm
not sure what's best myself. So stop beating people over the head with
Guido approved X.

I can't decide this myself -- you and Phillip have to find a way to
agree on one version or the other, that's the only pronouncement you
will get from me.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Nick Coghlan]

Phillip J. Eby wrote:
 So, if anything is clear from all this, it's that nothing has ever been 
 particularly clear in all this.  :)
 
 Or more precisely, I think everybody has been perfectly clear, we just 
 haven't really gotten on the same page about which words mean what.  ;)

+1 QOTT (Quote of the Thread) :)

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 -peps/trunk/pep-0343.txt)

[Fredrik Lundh]

Guido van Rossum wrote:

 Nick, please get unstuck on the who said what when and who wasn't
 listening thing. I want this to be resolved to use the clearest
 terminology possible.

which probably means that the words context and manager shouldn't
be used at all ;-)

space and potato, perhaps?

like in http://tinyurl.com/k5spk ?

/F



___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Paul Moore]

On 4/22/06, Nick Coghlan [EMAIL PROTECTED] wrote:
 Alternatively, I could have a go at clearing it up for next week's alpha2, and
 we can ask Anthony to make an explicit request for review of those docs in the
 announcement. . .

I've just had a *very* quick scan through the 2.5a1 documentation. I
did not look at the PEP, just the official documentation. I've been
reading the messages going round on the subject, but I'm getting
pretty confused, so I'd still count myself as unprejudiced... :-)

My immediate reaction was that the docs make reasonable sense:

- a context is a thing with enter/exit methods (a block of code is
in a context)
- the with statement delimits the block which is in a context
- the with statement asks a context manager for the context in which
the block runs
- context managers have __context__ methods to produce contexts (they
manage the production of explicit context objects)

The contextlib.contextmanager decorator starts off looking fine as well:

@contextmanager
def tag(name):
print %s % name
yield
print /%s % name

Yes, that's a context manager - you pass it to a with statement:

 with tag(h1):
...print foo
...
h1
foo
/h1

But then things go wrong:

class Tag:
def __init__(self, name):
self.name = name

@contextmanager
def __context__(self):
print %s % self.name
yield self
print /%s % self.name

h1 = Tag(h1)

That's bizarre: __context__ isn't the context manager I'm trying to
create - those are the instances of Tag. I think this is where the
terminology comes unstuck, and it's simply because this is an abuse
(a bit strong, that - bear with me) of the contextmanager decorator.

The thing is, __context__ should be *a function which returns a
context*. But we defined it with the decorator as a context manager -
an object whose __context__ method produces a context! It works,
because context managers produced by the decorator return themselves -
that is, they are both context managers and contexts... No, I just
got lost.

BUT - the point is that everything was fine until the point where the
__context__ method got defined using @contextmanager. Maybe all we
need is to have *two* decorators - @context to generate a context
(this would be @contextmanager but without the __context__ method) and
@contextmanager as now (actually, it only needs the __context__ method
- the __enter__ and __exit__ methods are only present to allow the
trick of returning self from __context__).

Then, the definitions are easy:

context manager - has __context__ producing a context
context - has __enter__ and __exit__ methods, used by the with statement

Things with all 3 methods are just a convenience trick to avoid
defining 2 objects - there's no *need* for them (unlike iterators,
where iter(it) is it is an important defining characteristic of an
iterator over an iterable).

So my proposal:

- use the definitions above
- modify contextlib to have 2 decorators - @contextmanager producing a
context manager, and @context producing a context. They can be the
same under the hood, using an object that defines all 3 methods, but
that's just an implementation detail (trick)
- amend the documentation of the Tag example in the contextlib docs to
use the @context decorator.
- tidy up the PEP to reflect this approach

Or alternatively, I'm just confused, like the rest of you :-)

Paul.
___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 -peps/trunk/pep-0343.txt)

[Nick Coghlan]

Fredrik Lundh wrote:
 Guido van Rossum wrote:
 
 Nick, please get unstuck on the who said what when and who wasn't
 listening thing.

Sorry about that. I was just trying to figure out how we got to where we are. 
I stopped paying close attention to PEP 343 developments a few months back, 
and ended up catching up out loud here on the list. . .

 I want this to be resolved to use the clearest
 terminology possible.

I'm planning to have one go at it before next week's 2nd alpha (making sure 
the source code, library reference, language reference and PEP are all at 
least superficially consistent), and then asking Anthony to include something 
in the 2nd alpha announcement explicitly requesting review of these docs.

As Phillip pointed out, we need input from people that haven't been intimately 
involved in the PEP 343 discussions to see if the final docs actually make 
sense. As I discovered in reviewing the contextlib docs, it turned out to be 
awfully easy for me to see what I expected to see rather than what was 
actually there.

 which probably means that the words context and manager shouldn't
 be used at all ;-)
 
 space and potato, perhaps?
 
 like in http://tinyurl.com/k5spk ?

That's beautiful. It even matches the PEP [1] :)

Cheers,
Nick.

[1] http://tinyurl.com/pc5uq

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Nick Coghlan]

Paul Moore wrote:
 On 4/22/06, Nick Coghlan [EMAIL PROTECTED] wrote:
 Alternatively, I could have a go at clearing it up for next week's alpha2, 
 and
 we can ask Anthony to make an explicit request for review of those docs in 
 the
 announcement. . .
 
 I've just had a *very* quick scan through the 2.5a1 documentation. I
 did not look at the PEP, just the official documentation. I've been
 reading the messages going round on the subject, but I'm getting
 pretty confused, so I'd still count myself as unprejudiced... :-)

Thanks for doing that. I got lost in a maze of twisty contexts all alike 
around the same place you did, so we apparently need to do something different 
somewhere.

So I'm going to express my gratitude by asking you to read the same docs all 
over again in a few days time :)

 My immediate reaction was that the docs make reasonable sense:
 
 - a context is a thing with enter/exit methods (a block of code is
 in a context)
 - the with statement delimits the block which is in a context
 - the with statement asks a context manager for the context in which
 the block runs
 - context managers have __context__ methods to produce contexts (they
 manage the production of explicit context objects)

I'll be making a pass through the docs (and PEP) this weekend using the 
definitions:

   - a context manager is a thing with enter/exit methods
 (it sets up and tears down an execution context for a block of code)
   - the with statement delimits the block which is in an execution context
   - the with statement asks a context object for a context manager to set up
 and tear down an execution context when the block runs
   - context objects have a __context__ method to produce context managers
 (hey, it isn't really that much worse than using the __iter__ method to
  ask an iterable for an iterator. . .)

I'll also add something in which parallels the current Iterator Types 
section in the library reference (only for Context Types).

The big changes from where we are currently are that:
   - execution context will be introduced for the sundry effects that a 
context manager may have on the code in the body of a with statement (like 
affecting how exceptions are handled, redirecting IO, changing the thread's 
active decimal context, affecting thread synchronisation etc)
   - context object will be used where context manager is currently used. 
This is mainly so that decimal.Context can be safely referred to as being a 
context object.
   - context manager will be used where context is currently used. This is 
so that the __context__ method returns context managers, which means 
decorating the generator based ones with @contextlib.contextmanager makes sense.

I was considering producing a patch instead so it could be reviewed before I 
changed anything, but I don't think we'll really understand which is clearer 
until we can review it all together, and documentation patches are difficult 
to review properly without applying them and rebuilding the docs (which a lot 
of people aren't set up to do - just ask the effbot ;).

If the terminology *still* breaks down with those slightly different 
definitions, we'll have to try to come up with a third option after the 2nd 
alpha. I'm really hoping my planned changes actually work out, because if they 
don't I'm out of ideas for how to make these concepts easier to grok. . .

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Paul Moore]

On 4/22/06, Nick Coghlan [EMAIL PROTECTED] wrote:
 So I'm going to express my gratitude by asking you to read the same docs all
 over again in a few days time :)

No problem. Remind me if I forget...

 I'll be making a pass through the docs (and PEP) this weekend using the
 definitions:

- a context manager is a thing with enter/exit methods
  (it sets up and tears down an execution context for a block of code)
- the with statement delimits the block which is in an execution context
- the with statement asks a context object for a context manager to set up
  and tear down an execution context when the block runs
- context objects have a __context__ method to produce context managers
  (hey, it isn't really that much worse than using the __iter__ method to
   ask an iterable for an iterator. . .)

Sorry, but I don't really like this. I find the idea of a context
manager, creating contexts, within which the block in a with statement
runs, much more intuitive. As I said, the only issue I have with it is
the dual use of the contextmanager decorator (and I think that's
fundamental - there are 2 different things going on, and they *should*
have different names).

But I'll do my best to put away my prejudices and read the new docs as
they are written, when they come out.

 If the terminology *still* breaks down with those slightly different
 definitions, we'll have to try to come up with a third option after the 2nd
 alpha. I'm really hoping my planned changes actually work out, because if they
 don't I'm out of ideas for how to make these concepts easier to grok. . .

Presumably, then, my proposal didn't make things clear to you?

I won't comment further on your proposal, as I *want* to avoid
thinking about it before I read the docs...

Paul.
___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Nick Coghlan]

Paul Moore wrote:
 Presumably, then, my proposal didn't make things clear to you?

As Phillip said, I'm probably way too close to this to be a good judge of how 
understandable the terminology is. I just want to make one more attempt before 
admitting defeat. . .

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Nick Coghlan]

Guido van Rossum wrote:
 Sorry Nick, but you've still got it backwards. The name of the
 decorator shouldn't indicate the type of the return value (of calling
 the decorated generator) -- it should indicate how we think about the
 function. Compare @staticmethod and @classmethod -- the return type
 doesn't enter into it. I think of the function/generator itself as the
 context manager; it returns a context.

Let me have another go. . .

One of the proposals when Raymond raised the issue of naming the PEP 343 
protocol was to call objects with __enter__/__exit__ methods contexts. 
This was rejected because there were too many things (like decimal.Context) 
that already used that name but couldn't easily be made to fit the new 
definition. So we settled on calling them context managers instead.

This wasn't changed by the later discussion that introduced the __context__ 
method. Instead, the new term manageable context (or simply context) was 
introduced to mean anything with a __context__ method. This was OK, because 
existing context objects like decimal.Context could easily add a context 
method to return an appropriate context manager.

Notice that in *both* approved versions of PEP 343 (before and after the 
inclusion of the __context__ method) the name of the decorator matched the 
name of the kind of object returned by the decorated generator function.

*THIS ALL CHANGED AT PYCON* (at least, I assume that's where it happened - it 
sure didn't happen on this list, and the timing is about right).

During implementation, the meanings of context and context manager were 
swapped from the meanings in the approved PEP, leading to the current 
situation where decimal.Context is actually not, in fact, a context. These 
meanings were then the ones included in the checked in documentation for 
contextlib, and in PJE's recent update to PEP 343 itself.

However, *despite* the meanings of the two terms being swapped, the decorator 
kept the same name. This means that when using a generator to create a 
context manager like decimal.Context under the revised terminology, you are 
forced to claim that the __context__ method is itself a context manager:

   class Context(object):
  # Actually a context manager, despite the class name

  @contextlib.contextmanager
  def __context__(self):
  # Actually a context, despite the decorator name
  newctx = self.copy()
  oldctx = decimal.getcontext()
  decimal.setcontext(newctx)
  try:
  yield newctx
  finally:
  decimal.setcontext(oldctx)

I also note that the decimal module in 2.5a1 actually uses the originally 
approved PEP 343 terminology, calling the object returned from __context__ a 
ContextManager.

And all of this is why I believe we need to either fix the documentation to 
use the terminology used in the PEP at the time of approval, or else finish 
the job of swapping the two terms and change the name of the decorator. Having 
remembered why we picked context manager over context in the first place, 
my preference is strongly for reverting to the original terminology.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Guido van Rossum]

OK, now I'm confused. I hope that Phillip understands this and will
know what to do.

On 4/21/06, Nick Coghlan [EMAIL PROTECTED] wrote:
 Guido van Rossum wrote:
  Sorry Nick, but you've still got it backwards. The name of the
  decorator shouldn't indicate the type of the return value (of calling
  the decorated generator) -- it should indicate how we think about the
  function. Compare @staticmethod and @classmethod -- the return type
  doesn't enter into it. I think of the function/generator itself as the
  context manager; it returns a context.

 Let me have another go. . .

 One of the proposals when Raymond raised the issue of naming the PEP 343
 protocol was to call objects with __enter__/__exit__ methods contexts.
 This was rejected because there were too many things (like decimal.Context)
 that already used that name but couldn't easily be made to fit the new
 definition. So we settled on calling them context managers instead.

 This wasn't changed by the later discussion that introduced the __context__
 method. Instead, the new term manageable context (or simply context) was
 introduced to mean anything with a __context__ method. This was OK, because
 existing context objects like decimal.Context could easily add a context
 method to return an appropriate context manager.

 Notice that in *both* approved versions of PEP 343 (before and after the
 inclusion of the __context__ method) the name of the decorator matched the
 name of the kind of object returned by the decorated generator function.

 *THIS ALL CHANGED AT PYCON* (at least, I assume that's where it happened - it
 sure didn't happen on this list, and the timing is about right).

 During implementation, the meanings of context and context manager were
 swapped from the meanings in the approved PEP, leading to the current
 situation where decimal.Context is actually not, in fact, a context. These
 meanings were then the ones included in the checked in documentation for
 contextlib, and in PJE's recent update to PEP 343 itself.

 However, *despite* the meanings of the two terms being swapped, the decorator
 kept the same name. This means that when using a generator to create a
 context manager like decimal.Context under the revised terminology, you are
 forced to claim that the __context__ method is itself a context manager:

class Context(object):
   # Actually a context manager, despite the class name

   @contextlib.contextmanager
   def __context__(self):
   # Actually a context, despite the decorator name
   newctx = self.copy()
   oldctx = decimal.getcontext()
   decimal.setcontext(newctx)
   try:
   yield newctx
   finally:
   decimal.setcontext(oldctx)

 I also note that the decimal module in 2.5a1 actually uses the originally
 approved PEP 343 terminology, calling the object returned from __context__ a
 ContextManager.

 And all of this is why I believe we need to either fix the documentation to
 use the terminology used in the PEP at the time of approval, or else finish
 the job of swapping the two terms and change the name of the decorator. Having
 remembered why we picked context manager over context in the first place,
 my preference is strongly for reverting to the original terminology.

 Cheers,
 Nick.

 --
 Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
 ---
  http://www.boredomandlaziness.org



--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Greg Ewing]

Nick Coghlan wrote:

 During implementation, the meanings of context and context manager were 
 swapped from the meanings in the approved PEP, leading to the current 
 situation where decimal.Context is actually not, in fact, a context.

That's rather disappointing. I *liked* the way that
decimal.Context was a context. Was there a conscious
choice to swap the terms, or did it happen by accident?

--
Greg
___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Nick Coghlan]

Greg Ewing wrote:
 Nick Coghlan wrote:
 
 During implementation, the meanings of context and context manager were 
 swapped from the meanings in the approved PEP, leading to the current 
 situation where decimal.Context is actually not, in fact, a context.
 
 That's rather disappointing. I *liked* the way that
 decimal.Context was a context. Was there a conscious
 choice to swap the terms, or did it happen by accident?

That's what I'm currently trying to find out - whether or not this was a 
deliberate decision made at PyCon. Conference sprints are great for getting 
things done, but they do occasionally lead to decisions getting made without 
being properly recorded :)

The terminology in the current docs is more natural in some ways than what the 
PEP settled on (mainly due to the __context__ method), so I'm wondering if the 
downside that lead us to pick the slightly more awkward terminology may have 
been forgotten at the time of implementation.

Unfortunately this kind of discussion can take days via email*, even though it 
would probably only take ten minutes or so in person - not getting any 
immediate feedback when your point of view isn't being understood really slows 
things down.

I'm just glad AMK noticed the discrepancy - I completely missed it when I read 
the contextlib docs (I suspect my brain was being 'helpful' and automatically 
filled in what I expected to see rather than what was actually there).

Cheers,
Nick.

* s/can take/already has taken/ ;)

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[A.M. Kuchling]

On Fri, Apr 21, 2006 at 07:31:35PM +1000, Nick Coghlan wrote:
 fit the new definition. So we settled on calling them context managers 
 instead.
 ... 
 method. Instead, the new term manageable context (or simply context) 
 was introduced to mean anything with a __context__ method. This was OK, 

Meaning that 'manageable context' objects create and destroy 'context
managers'...  My view is still that 'context manager' is a terrible
name when used alongside objects called 'contexts': the object doesn't
manage anything, and it certainly doesn't manage contexts -- in fact
it's created by 'context' objects.

Perhaps we need to do some usability tests.  Go to a local user group,
explain the 'with' statement and the necessary objects using __foo__
instead of __context__, provide three or four pairs of names, and then
ask the audience which set of names seems most sensible.

For the What's New, I'm now beginning to think the text should say
'objects that have a __context__() method', and then refer to either
contexts or context managers (whichever way the decision goes) for the
objects with enter/exit, to avoid this confusion.

--amk
___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Phillip J. Eby]

At 10:51 AM 4/21/2006 -0400, A.M. Kuchling wrote:
On Fri, Apr 21, 2006 at 07:31:35PM +1000, Nick Coghlan wrote:
  fit the new definition. So we settled on calling them context managers
  instead.
  ...
  method. Instead, the new term manageable context (or simply context)
  was introduced to mean anything with a __context__ method. This was OK,

Meaning that 'manageable context' objects create and destroy 'context
managers'...  My view is still that 'context manager' is a terrible
name when used alongside objects called 'contexts': the object doesn't
manage anything, and it certainly doesn't manage contexts -- in fact
it's created by 'context' objects.

And that's more or less why I wrote the documentation the way I did.

Nick, as I understand your argument, it's that we were previously using the 
term context manager to mean thing with __enter__ and __exit__.  But 
that was *never* my interpretation.

My understanding of context manager was always, thing that you give to a 
with statement.

So to me, when we added a __context__ method, we were creating a *new 
object* that hadn't existed before, and we moved some methods on to 
it.  Thus, context manager still meant thing you give to the with 
statement -- and that never changed, from my POV.

And that's why I see the argument that we've reversed the terminology as 
bogus: to me it's been consistent all along.  We just added another object 
*besides* the context manager.

Note too that the user of the with statement doesn't know that this other 
object exists, and in fact sometimes it doesn't actually exist, it's the 
same object.  None of this is relevant for the with-statement user, only 
the context manager.  So there's no reason (IMO) to monkey with the 
definition of context manager as thing you use in a with statement.

Now, I get your point about @contextmanager on a __context__ method, and I 
agree that that seems backwards at first.  What I don't see is how to 
change the terminology to handle that subtlety in a way that doesn't muck 
up the basically simple definitions that are in place now.

If it must be explained, however, I'd rather simply document it in 
contextlib that @contextmanager-decorated functions return an object that 
is both a context manager and a context (or whatever name you want for the 
invisible-behind-the-scenes-thing with enter and exit methods).  Since it 
is possible for an object to be both, that seems to do fine for explaining 
why you can use @contextmanager to define a __context__ method.

I'm definitely open to other terminology for the invisible thing besides 
context, but I don't care for managed context or manageable context, 
as these aren't much better.  I'm somewhat tempted by context instance or 
context invocation.  E.g, the __context__ method should return a context 
instance: an object representing a single instance of use of the 
context.  There's a wee hint of suggestion that this means instance of 
type context, but it's more suggestive of one-time use than context object.

___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Guido van Rossum]

Phillip, I do recomment you look at decimal.py. If we're not reversing
the PEP changes, that module needs to be changed; it has a class
Context (that was always there) with a __context__ method which
returns an instance of a class ContextManager (newly created for the
with-statement). This looks backwards from the PEP's current POV.

--Guido

On 4/21/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
 At 10:51 AM 4/21/2006 -0400, A.M. Kuchling wrote:
 On Fri, Apr 21, 2006 at 07:31:35PM +1000, Nick Coghlan wrote:
   fit the new definition. So we settled on calling them context managers
   instead.
   ...
   method. Instead, the new term manageable context (or simply context)
   was introduced to mean anything with a __context__ method. This was OK,
 
 Meaning that 'manageable context' objects create and destroy 'context
 managers'...  My view is still that 'context manager' is a terrible
 name when used alongside objects called 'contexts': the object doesn't
 manage anything, and it certainly doesn't manage contexts -- in fact
 it's created by 'context' objects.

 And that's more or less why I wrote the documentation the way I did.

 Nick, as I understand your argument, it's that we were previously using the
 term context manager to mean thing with __enter__ and __exit__.  But
 that was *never* my interpretation.

 My understanding of context manager was always, thing that you give to a
 with statement.

 So to me, when we added a __context__ method, we were creating a *new
 object* that hadn't existed before, and we moved some methods on to
 it.  Thus, context manager still meant thing you give to the with
 statement -- and that never changed, from my POV.

 And that's why I see the argument that we've reversed the terminology as
 bogus: to me it's been consistent all along.  We just added another object
 *besides* the context manager.

 Note too that the user of the with statement doesn't know that this other
 object exists, and in fact sometimes it doesn't actually exist, it's the
 same object.  None of this is relevant for the with-statement user, only
 the context manager.  So there's no reason (IMO) to monkey with the
 definition of context manager as thing you use in a with statement.

 Now, I get your point about @contextmanager on a __context__ method, and I
 agree that that seems backwards at first.  What I don't see is how to
 change the terminology to handle that subtlety in a way that doesn't muck
 up the basically simple definitions that are in place now.

 If it must be explained, however, I'd rather simply document it in
 contextlib that @contextmanager-decorated functions return an object that
 is both a context manager and a context (or whatever name you want for the
 invisible-behind-the-scenes-thing with enter and exit methods).  Since it
 is possible for an object to be both, that seems to do fine for explaining
 why you can use @contextmanager to define a __context__ method.

 I'm definitely open to other terminology for the invisible thing besides
 context, but I don't care for managed context or manageable context,
 as these aren't much better.  I'm somewhat tempted by context instance or
 context invocation.  E.g, the __context__ method should return a context
 instance: an object representing a single instance of use of the
 context.  There's a wee hint of suggestion that this means instance of
 type context, but it's more suggestive of one-time use than context object.

 ___
 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/guido%40python.org



--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Greg Ewing]

A.M. Kuchling wrote:

 Does this detail matter to users of the Decimal module, though?  Those
 users may well be thinking using the term 'context'.

Seems to me the most straightforward term should be
applied to the object that users are most likely to
know about and use. The term context is familiar
and understandable, whereas context manager isn't.

I've kind of lost track of why we're having two
separate objects, anyway. Is it really necessary?

As far as I remember, the original 'with' statement
proposal was very simple and quite straightforward
to explain and understand. Somewhere along the way
it seems to have mutated into a monster that I can't
keep in my brain any more. This can't be a good
thing.

--
Greg
___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Nick Coghlan]

Phillip J. Eby wrote:
 At 10:51 AM 4/21/2006 -0400, A.M. Kuchling wrote:
 On Fri, Apr 21, 2006 at 07:31:35PM +1000, Nick Coghlan wrote:
 fit the new definition. So we settled on calling them context managers
 instead.
  ...
 method. Instead, the new term manageable context (or simply context)
 was introduced to mean anything with a __context__ method. This was OK,
 Meaning that 'manageable context' objects create and destroy 'context
 managers'...  My view is still that 'context manager' is a terrible
 name when used alongside objects called 'contexts': the object doesn't
 manage anything, and it certainly doesn't manage contexts -- in fact
 it's created by 'context' objects.
 
 And that's more or less why I wrote the documentation the way I did.
 
 Nick, as I understand your argument, it's that we were previously using the 
 term context manager to mean thing with __enter__ and __exit__.  But 
 that was *never* my interpretation.
 
 My understanding of context manager was always, thing that you give to a 
 with statement.

Then why didn't you speak up when the discussion was summarised in PEP 343 for 
Guido's approval? I said it explicitly:

  This PEP proposes that the protocol used by the with statement be
  known as the context management protocol, and that objects that
  implement that protocol be known as context managers. The term
  context then encompasses all objects with a __context__() method
  that returns a context manager object. (This means that all context
  managers are contexts, but not all contexts are context managers)

I guess a slight ambiguity came in from the fact I didn't spell out that the 
protocol I was referring to was all three methods with __context__ returning 
self (i.e. the moral equivalent of the 'iterator protocol'). But the rest of 
the paragraph doesn't make any sense otherwise.

Under Resolved Issues, before the recent changes, it said this:

  3. After this PEP was originally approved, a subsequent discussion
on python-dev [4] settled on the term context manager for
objects which provide __enter__ and __exit__ methods, and
context management protocol for the protocol itself. With the
addition of the __context__ method to the protocol, the natural
adjustment is to call all objects which provide a __context__
method contexts (or manageable contexts in situations where the
general term context would be ambiguous).
This is now documented in the Standard Terminology section.

*This* is what Guido approved, not what is currently written up in the PEP on 
python.org.

 So to me, when we added a __context__ method, we were creating a *new 
 object* that hadn't existed before, and we moved some methods on to 
 it.  Thus, context manager still meant thing you give to the with 
 statement -- and that never changed, from my POV.

That may have been what you personally thought, but it's not what the PEP 
said. If you disagreed with the summarisation in the PEP, you should have said 
so before Guido approved it, or brought it back to python-dev as a discussion 
about changing the standard terminology rather than just the PEP's confusing, 
I want to clear it up (and completely changing the meaning in the process).

 And that's why I see the argument that we've reversed the terminology as 
 bogus: to me it's been consistent all along.  We just added another object 
 *besides* the context manager.

I agree with the second part, but not the first part. Originally we only had 
context managers (objects that managed their own state in their 
__enter__/__exit__ methods). Jason brought up the point that this excluded 
decimal.Context objects because it was extremely difficult to produce a 
thread-safe and nesting-safe __enter__/__exit__ pair to manipulate the decimal 
context. Without a __context__ method, the decimal module would have had to 
provide a separate object for use as a context manager.

So we added contexts to the PEP - objects that could produce a context manager 
to work in conjunction with the with statement to manage the state of the 
context object. Context managers created in this fashion, instead of operating 
on their own state, actually operate on the state of the context that created 
them.

This is what got reversed in the contextlib docs - the PEP said that context 
managers work on contexts the same way that iterators work on iterables.The 
contextlib docs (and the latest version of the PEP) say that contexts 
manipulate context managers.

This is just plain bad English. context is a passive noun like iterable - 
it doesn't imply any sort of active operation. context manager on the other 
hand describes an actor doing something, just like iterator does.

 
 Note too that the user of the with statement doesn't know that this other 
 object exists, and in fact sometimes it doesn't actually exist, it's the 
 same object.  None of this is relevant for the with-statement user, 

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Nick Coghlan]

Phillip J. Eby wrote:
 At 11:41 PM 4/19/2006 +1000, Nick Coghlan wrote:
 Given that naming though, I think contextlib.contextmanager should be 
 renamed
 to contextlib.context.
 
 The name is actually correct under this terminology arrangement.  
 @contextmanager *returns* a context manager.

That's like saying we should describe the result of calling a generator 
function as a generator-iterable because it has an __iter__ method.

The longer name made sense when context manager was the term for the object 
with __enter__ and __exit__ methods (the way I originally wrote it when 
updating the PEP after the addition of the __context__ method).

While I agree that flipping the terminology the other way around makes sense, 
it *also* flips the effect of calling a decorated generator function so that 
what it returns is now appropriately termed a generator-context (since it 
provides __enter__ and __exit__ methods directly).

These contexts are context managers only in the same sense that iterators are 
also iterables. We shouldn't break the parallels between iterable-iterator and 
context manager-context without a good reason - and so far I haven't heard one.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Nick Coghlan]

A.M. Kuchling wrote:
 On Tue, Apr 18, 2006 at 03:37:37PM -0400, Phillip J. Eby wrote:
 I was going to say, so they can be context managers, but I suppose you 
 have a point.  There is no need for a context to have a __context__ method, 
 unless it is also a context manager.  Ugh.
 
 It would be easy to just remove the parenthetical comment from the PEP
 and forget about it, if in fact the statement is now purposeless.  But
 these are murky waters, and maybe there's still some deeper reason for
 it.  Nick, do you have any comments?

Aside from wondering Did I even pretend to proofread that paragraph??

The second occurrence of context manager is meant to say context:

 This PEP proposes that the protocol used by the with statement be
 known as the context management protocol, and that objects that
 implement that protocol be known as context managers. The term
 context then encompasses all objects with a __context__()
 method that returns a context object.

And the parenthetical comment was completely backwards and should have read:

   (This means that all context managers are contexts, but not all contexts are
context managers).

The reason for recommending that context managers should be contexts is 
similar to the reason that iterators should be iterables - so that doing the 
__context__() call manually will still give you something that can be used in 
a with statement.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[A.M. Kuchling]

On Wed, Apr 19, 2006 at 10:00:21PM +1000, Nick Coghlan wrote:
 And the parenthetical comment was completely backwards and should have read:
 
   (This means that all context managers are contexts, but not all contexts 
   are
context managers).
 
 The reason for recommending that context managers should be contexts is 
 similar to the reason that iterators should be iterables - so that doing 
 the __context__() call manually will still give you something that can be 
 used in a with statement.

So the intention is to enable something like:

ctx = lock.__context__()
with ctx:
...

Which works as long as people don't try to use the context in two
nested 'with' statements.  Fair enough.  I don't think I'll suggest
doing this in the What's New, though.  :)

--amk
___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Nick Coghlan]

Nick Coghlan wrote:
 The second occurrence of context manager is meant to say context:
 
  This PEP proposes that the protocol used by the with statement be
  known as the context management protocol, and that objects that
  implement that protocol be known as context managers. The term
  context then encompasses all objects with a __context__()
  method that returns a context object.
 
 And the parenthetical comment was completely backwards and should have read:
 
(This means that all context managers are contexts, but not all contexts 
 are
 context managers).
 
 The reason for recommending that context managers should be contexts is 
 similar to the reason that iterators should be iterables - so that doing the 
 __context__() call manually will still give you something that can be used in 
 a with statement.

Ah, all is explained by svn blame, with a little help from svn log.

When Phillip went through to make the terminology consistent he actually 
swapped the meanings of context (which meant 'has a __context__ method' in 
the original PEP) and context manager (which meant 'has __enter__ and 
__exit__ methods and a __context__ method that returns self' in the original 
PEP).

I clearly wasn't paying attention when that diff went past on the checkins 
list, but I'd humbly request that we change it back :)

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[A.M. Kuchling]

On Wed, Apr 19, 2006 at 11:10:55PM +1000, Nick Coghlan wrote:
 When Phillip went through to make the terminology consistent he actually 
 swapped the meanings of context (which meant 'has a __context__ method' 
 in the original PEP) and context manager (which meant 'has __enter__ and 
 __exit__ methods and a __context__ method that returns self' in the 
 original PEP).

Yes, that was exactly what he set out to do.  I noted that the terms
context and context manager seemed to be exactly reversed from
what's intuitive, and from how the user-facing documentation is
written; the post at
http://mail.python.org/pipermail/python-dev/2006-April/063842.html
contains my argument.  GvR approved, and Phillip went ahead and made
the change.

--amk
___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Nick Coghlan]

A.M. Kuchling wrote:
 On Wed, Apr 19, 2006 at 11:10:55PM +1000, Nick Coghlan wrote:
 When Phillip went through to make the terminology consistent he actually 
 swapped the meanings of context (which meant 'has a __context__ method' 
 in the original PEP) and context manager (which meant 'has __enter__ and 
 __exit__ methods and a __context__ method that returns self' in the 
 original PEP).
 
 Yes, that was exactly what he set out to do.  I noted that the terms
 context and context manager seemed to be exactly reversed from
 what's intuitive, and from how the user-facing documentation is
 written; the post at
 http://mail.python.org/pipermail/python-dev/2006-April/063842.html
 contains my argument.  GvR approved, and Phillip went ahead and made
 the change.

I'm a little behind on python-dev *and* python-checkins, so I'd missed the 
first half of this discussion.

It'll take me a while to swap the two in my head, but I'll get used to it 
eventually. Phillip's point that calling __context__ should give you a context 
as the result is a good one, and context manager makes sense as an object 
that can generate new contexts.

Given that naming though, I think contextlib.contextmanager should be renamed 
to contextlib.context. The current name was assigned when objects with all 3 
methods were the one's being called context managers. With the terms being 
swapped, the name of the decorator should probably change, too. Chopping 7 
characters off the name doesn't hurt, either :)

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Phillip J. Eby]

At 11:10 PM 4/19/2006 +1000, Nick Coghlan wrote:
Ah, all is explained by svn blame, with a little help from svn log.

When Phillip went through to make the terminology consistent he actually
swapped the meanings of context (which meant 'has a __context__ method' in
the original PEP)

At least AMK and I thought that it was obvious that context manager means 
has a context method, and it's the only way to have the PEP read 
consistently.

Note that the decorator is called @contextmanager, not @context, for example.


  and context manager (which meant 'has __enter__ and
__exit__ methods and a __context__ method that returns self' in the 
original PEP).

That's true - *before* there was a __context__ method.  Now that there *is* 
a context method, it makes more sense to say that the thing that has it is 
the context manager, and the thing with the __enter__/__exit__ methods is 
the context.


I clearly wasn't paying attention when that diff went past on the checkins
list, but I'd humbly request that we change it back :)

The change made the PEP self-consistent in its terminology, if you are 
encountering it for the first time, and don't already have it in your head 
that it's one way or the other.  If we change it the other way, we'll have 
to rename @contextmanager.

___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Phillip J. Eby]

At 11:41 PM 4/19/2006 +1000, Nick Coghlan wrote:
Given that naming though, I think contextlib.contextmanager should be renamed
to contextlib.context.

The name is actually correct under this terminology 
arrangement.  @contextmanager *returns* a context manager.  It happens to 
also be a context, but that's not important.  With takes a context 
manager expression.

___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[Phillip J. Eby]

At 04:18 PM 4/18/2006 -0400, A.M. Kuchling wrote:
On Tue, Apr 18, 2006 at 08:55:18PM +0200, phillip.eby wrote:
  Modified:
 peps/trunk/pep-0343.txt
 
  +context manager then encompasses all objects with a __context__()
  +method that returns a context object.  (This means that all contexts
  +are context managers, but not all context managers are contexts).

This change reminds of another question I had about the parenthetical
statement: all contexts are context managers (= 'has a __context__'
method).  Why?  The context object isn't necessarily available to the
Python programmer, so they can't write:

with context_mgr as context:
  with context:  # uses the same context
  ...

Why do contexts need to have a __context__() method?

I was going to say, so they can be context managers, but I suppose you 
have a point.  There is no need for a context to have a __context__ method, 
unless it is also a context manager.  Ugh.


___
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

Re: [Python-Dev] Why are contexts also managers? (was r45544 - peps/trunk/pep-0343.txt)

[A.M. Kuchling]

On Tue, Apr 18, 2006 at 03:37:37PM -0400, Phillip J. Eby wrote:
 I was going to say, so they can be context managers, but I suppose you 
 have a point.  There is no need for a context to have a __context__ method, 
 unless it is also a context manager.  Ugh.

It would be easy to just remove the parenthetical comment from the PEP
and forget about it, if in fact the statement is now purposeless.  But
these are murky waters, and maybe there's still some deeper reason for
it.  Nick, do you have any comments?

--amk

___
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