Guido van Rossum wrote:
On 5/1/06, James Y Knight [EMAIL PROTECTED] wrote:
Don't forget that the majority of users will never have heard any of
these discussions nor have used 2.5a1 or 2.5a2. Choose the best term
for them, not for the readers of python-dev.
I couldn't agree more! (Another
On 5/2/06, Nick Coghlan [EMAIL PROTECTED] wrote:
Nick, do you have it in you to fix PEP 343? Or at least come up with a
draft patch? We can take this off-linel with all the +0's and +1's
coming in I'm pretty comfortable with this change now, although we
should probably wait until later
Phillip J. Eby wrote:
At 08:08 PM 4/30/2006 -0700, Guido van Rossum wrote:
If you object against the extra typing, we'll first laugh at you
(proposals that *only* shave a few characters of a common idiom aren't
all that popular in these parts), and then suggest that you can spell
Greg Ewing wrote:
I've been thinking about the terms guarded context
and context guard. We could say that the with-statement
executes its body in a guarded context (an abstract
notion, not a concrete object). To do this, it creates
a context guard (a concrete object) with __enter__
and
Greg Ewing wrote:
Also a thought on terminology. Even though it seems I
may have been the person who thought it up originally,
I'm not sure I like the term manager. It seems rather
wooly, and it's not clear whether a context manager
is supposed to manage just one context or multiple
Nick Coghlan wrote:
the context expression in the with
statement produces a context manager with __enter__ and __exit__ methods
which set up and tear down a managed context for the body of the with
statement. This is very similar to your later suggestion of context
guard and guarded
Nick Coghlan wrote:
Greg Ewing wrote:
Also a thought on terminology. Even though it seems I
may have been the person who thought it up originally,
I'm not sure I like the term manager. It seems rather
wooly, and it's not clear whether a context manager
is supposed to manage just one context
Greg Ewing wrote:
Nick Coghlan wrote:
the context expression in the with statement produces a context
manager with __enter__ and __exit__ methods which set up and tear down
a managed context for the body of the with statement. This is very
similar to your later suggestion of context guard
Fredrik Lundh wrote:
a distinct term for whatever the __enter__ method returns (i.e.
the thing assigned to the target list) would still be nice.
I've called that the context entry value in a few places (I don't think any
of them were in the actual documentation though).
A sample modification
On May 1, 2006, at 8:15 AM, Nick Coghlan wrote:
1. PEP 343, 2.5 alpha 1, 2.5 alpha 2 and the discussions here have
no doubt
seriously confused the meaning of the term 'context manager' for a
lot of
people (you can certainly put me down as one such person). Anyone
not already
On 5/1/06, James Y Knight [EMAIL PROTECTED] wrote:
Don't forget that the majority of users will never have heard any of
these discussions nor have used 2.5a1 or 2.5a2. Choose the best term
for them, not for the readers of python-dev.
I couldn't agree more! (Another thought, occasionally
At 08:29 PM 5/1/2006 +1000, Nick Coghlan wrote:
'localcontext' would probably work as at least an interim name for such a
function.
with decimal.localcontext() as ctx:
# use the new context here
And the as ctx should be unnecessary for most use cases, if localcontext
has an
On Tue, May 02, 2006, Greg Ewing wrote:
Nick Coghlan wrote:
the context expression in the with statement produces a context
manager with __enter__ and __exit__ methods which set up and tear
down a managed context for the body of the with statement. This is
very similar to your later
A few things from the pre-alpha2 context management terminology review have
had a chance to run around in the back of my head for a while now, and I'd
like to return to a topic Paul Moore brought up during that discussion.
Paul had a feeling there should be two generator decorators in
On 4/30/06, Nick Coghlan [EMAIL PROTECTED] wrote:
A few things from the pre-alpha2 context management terminology review have
had a chance to run around in the back of my head for a while now, and I'd
like to return to a topic Paul Moore brought up during that discussion.
I believe the context
At 09:53 AM 4/30/2006 -0700, Guido van Rossum wrote:
I have a counter-proposal: let's drop __context__. Nearly all use
cases have __context__ return self. In the remaining cases, would it
really be such a big deal to let the user make an explicit call to
some appropriately named method? The only
On 4/30/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 4/30/06, Nick Coghlan [EMAIL PROTECTED] wrote:
A few things from the pre-alpha2 context management terminology review have
had a chance to run around in the back of my head for a while now, and I'd
like to return to a topic Paul Moore
Guido van Rossum wrote:
On 4/30/06, Nick Coghlan [EMAIL PROTECTED] wrote:
A few things from the pre-alpha2 context management terminology review
have
had a chance to run around in the back of my head for a while now, and
I'd
like to return to a topic Paul Moore brought up during that
[I'm cutting straight to the chase here]
On 4/30/06, Nick Coghlan [EMAIL PROTECTED] wrote:
The downside of this over the __context__ method is that it is neither nesting
nor thread-safe.
This argument is bogus.
We currently have two types of objects involved in with-statements:
those whose
At 08:08 PM 4/30/2006 -0700, Guido van Rossum wrote:
If you object against the extra typing, we'll first laugh at you
(proposals that *only* shave a few characters of a common idiom aren't
all that popular in these parts), and then suggest that you can spell
foo.some_method() as foo().
Okay,
20 matches
Mail list logo
