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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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*
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,
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
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
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
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
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.
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
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
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
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__
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
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
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,
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
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
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
31 matches
Mail list logo
