Michael Hudson [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Guard? Monitor? Don't really like either of these.
I know I am late, but since guard means something else, 'sentinel' (in the
line of __enter__ and __exit__ interpretation) could be an alternative.
Tongue in cheek.
Probably late in the game, esp. for an outsider, but I read the
terminology discussion with interest.
FWIW, I do like Philip's use of context, though I feel that it is a
very generic word that may clash with many application-level
classes... For that reason, I also liked scope a lot, though
Michael Sparks wrote:
On Monday 04 Jul 2005 03:10, Phillip J. Eby wrote:
At 03:41 PM 7/3/2005 -0400, Raymond Hettinger wrote:
[Michael Hudson]
This is possible. I just wanted to expand everyone's minds :)
The mechanism is more general than resourcemanagement.
Expand your mind. :)
Phillip J. Eby wrote:
At 11:48 PM 7/3/2005 -0400, Raymond Hettinger wrote:
with context_expression as variable:
# perform actions within a context
The with statement establishes a context in which some operations are to
be performed.
I like this.
The object produced by
Raymond Hettinger wrote:
With Statements and Suite Management
This is nicely done :-)
Nit: Replace e.g. with such as.
BTW, do you support changing __exit__ to __leave__? I think it provides
a small but useful gain in usability.
I was initially -0 on the idea, and I've moved to a
On Tuesday 05 July 2005 02:57, Greg Ewing wrote:
I'm thinking about something like context manager,
or at least something with context in it.
Oh, I like this one. Context manager / context protocol work well for me.
-Fred
--
Fred L. Drake, Jr. fdrake at acm.org
[Aahz]
How about decimal.Context() objects are managed resources or
...have
guarded scopes? (I'm not terribly wild about either, but they are
fairly simple and direct.)
See my other posts which bag on both managed resources and guarded.
The part about scopes is less clear -- there is
Raymond Hettinger [EMAIL PROTECTED] writes:
Another trouble with resource managed is that it makes little sense
even when describing something that is clearly a resource (for instance,
locking objects are resource managed, what the heck could that mean,
there is no hint about the presence of
Raymond Hettinger wrote:
There is no value in expanding a concept to the point of being
meaningless (i.e. meaning whatever you want it to or nothing at all).
Instead, we need a phrase that expresses the essence of the following:
abc = EXPR
exc = (None, None, None)
Take II on some draft docs (accuracy of specific examples obviously
depends on other PEP 343 and PEP 342 related updates).
Based on the various discussions, the following suggests the term
suite managers. That focuses on the fact that we're doing something
before and after the contained suite.
At 11:48 PM 7/3/2005 -0400, Raymond Hettinger wrote:
Remember,
these methods are going to show up in objects such as Context which are
not primarily about 343. All of the other methods names will have
nothing to do with 343, so our choice of magic names needs to be really
good (as there will
[Phillip J. Eby]
with context_expression as variable:
# perform actions within a context
The with statement establishes a context in which some operations
are to
be performed. Often, this is a resource management context, wherein
some
resource is allocated when the context is
Phillip J. Eby wrote:
Expand your mind. :) Resource can include whatever objects you
want it
to -- or no objects at all. A resource can be conceptual - like for
example the user's attention, or the contents of a status bar or log
message, or the timing/profiling of an activity. I think
On Sun, Jul 03, 2005, Nick Coghlan wrote:
[...]
Anyway, I stuck with 'exit' for this - I prefer slightly awkard
phrasing in the explanation to awkwardness in the pairing of the names.
[...]
__exit__(exc_type, exc_value, exc_traceback):
Called as execution exits the contained
Nick Coghlan wrote:
On the other hand 'enter and exit' rolls off the tongue
significantly better than 'enter and leave'
My only concern is enter and exit may be too general. They are
frequently used in other places, although __enter__ and __exit__ are
less common, so maybe it's a non issue.
How about simply with block or guarded scope or something like that?
Michael
On 7/3/05, Ron Adam [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
On the other hand 'enter and exit' rolls off the tongue
significantly better than 'enter and leave'
My only concern is enter and exit may be too
[Michael Walter]
How about simply with block or guarded scope or something like
that?
How would you use that to describe decimal.Context() objects after Nick
adds the __enter__ and __exit__ magic methods? We want something as
direct as, xrange objects are iterable.
Raymond
[Ron Adam]
The terms __begin__ and __end__, are nearly as general, but they
stress
better that there are three parts, a beginning, middle and ending.
-1 Those are too generic to communicate anything. You would be better
off using beginwith and endwith or somesuch.
Raymond
Michael Hudson [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Thing is, there may be no resource; in my talk at EuroPython:
http://starship.python.net/crew/mwh/recexc.pdf
I used a with statement to establish and dis-establish an error
handler -- would you call that a
On 3 Jul 2005, at 18:25, Josiah Carlson wrote:
Just because not all cars are used as vehicles, does that mean that
cars
are not vehicles?
No, but it means calling all vehicles cars is dumb.
There may be cases where the object being managed is not a resource
per-se, but that doesn't mean
There may be cases where the object being managed is not a resource
per-se, but that doesn't mean that the mechanism is misnamed as a
'resource manager'; it's just the most common use case that any of
us
have managed to think of (as of yet).
[Michael Hudson]
This is possible. I just
On Sun, Jul 03, 2005, Raymond Hettinger wrote:
[Michael Walter]
How about simply with block or guarded scope or something like
that?
How would you use that to describe decimal.Context() objects after
Nick adds the __enter__ and __exit__ magic methods? We want something
as direct as,
Hmm:
Guarding a scope with a decimal.Context() object explain effect.
What do you think? (I'm not sure myself, but we even got a with in there :-)
Michael
On 7/3/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
[Michael Walter]
How about simply with block or guarded scope or something like
At 03:04 PM 7/3/2005 +0100, Michael Hudson wrote:
Phillip J. Eby [EMAIL PROTECTED] writes:
At 05:41 PM 6/30/2005 -0400, Raymond Hettinger wrote:
With 343 accepted, we can now add __enter__() and __exit__() methods to
objects.
What term should describe those objects in the documentation?
At 03:41 PM 7/3/2005 -0400, Raymond Hettinger wrote:
There may be cases where the object being managed is not a resource
per-se, but that doesn't mean that the mechanism is misnamed as a
'resource manager'; it's just the most common use case that any of
us
have managed to think of (as
Hmm, I think I'm seeing mostly the (guarded) entry/exit part of
guard metaphor, but I see what you mean (not allowing entry, so to
say, right?). Not sure.
Michael
On 7/3/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
Guarding a scope with a decimal.Context() object explain effect.
Walter [mailto:[EMAIL PROTECTED]
Sent: Sunday, July 03, 2005 10:28 PM
To: Raymond Hettinger
Cc: [EMAIL PROTECTED]; python-dev@python.org
Subject: Re: [Python-Dev] Terminology for PEP 343
Hmm, I think I'm seeing mostly the (guarded) entry/exit part of
guard metaphor, but I see what you mean
The mechanism is more general than resource
management. Like decorators, the encapsulation of a try/finally
wrapper
is completely generic and not married to the resource management
context.
[Phillip]
Expand your mind. :) Resource can include whatever objects you want
it
to -- or no
, July 03, 2005 10:28 PM
To: Raymond Hettinger
Cc: [EMAIL PROTECTED]; python-dev@python.org
Subject: Re: [Python-Dev] Terminology for PEP 343
Hmm, I think I'm seeing mostly the (guarded) entry/exit part of
guard metaphor, but I see what you mean (not allowing entry, so to
say, right
On Friday 01 July 2005 10:45 am, Fred L. Drake, Jr. wrote:
On Friday 01 July 2005 11:44, Phillip J. Eby wrote:
Resource managers.
Yeah, I was thinking that, but was somewhat ambivalent. But I definately
like it better than anything else proposed so far.
I like that as well. My hat in the
Raymond Hettinger wrote:
Hmm, that got me to thinking a bit more. Here's another subjective two
cents worth. exit seems to be a more global concept and leave seems
more local. For instance, I leave a room but exit a building. In
Python, sys.exit and os._exit are grand exits rather than
Raymond Hettinger wrote:
With 343 accepted, we can now add __enter__() and __exit__() methods to
objects.
What term should describe those objects in the documentation?
Witty objects?
___
Python-Dev mailing list
Python-Dev@python.org
Raymond Hettinger wrote:
Whatever term is selected, it should be well thought-out and added to
the glossary. The choice of words will likely have a great effect on
learnability and on how people think about the new tool.
When writing PEP 346, I ended up choosing user defined statement as
a
On Thu, 2005-06-30 at 22:41, Raymond Hettinger wrote:
With 343 accepted, we can now add __enter__() and __exit__() methods to
objects.
What term should describe those objects in the documentation?
Their raison d'etre is to bracket user code with setup and teardown
methods, so how about the
At 05:41 PM 6/30/2005 -0400, Raymond Hettinger wrote:
With 343 accepted, we can now add __enter__() and __exit__() methods to
objects.
What term should describe those objects in the documentation?
Resource managers.
___
Python-Dev mailing list
On 7/1/05, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote:
On Friday 01 July 2005 11:44, Phillip J. Eby wrote:
Resource managers.
Yeah, I was thinking that, but was somewhat ambivalent. But I definately like
it better than anything else proposed so far.
I say we steal from the C++ and the
[Brett Cannon]
I say we steal from the C++ and the RAII paradigm and go with RMUW
(Resource Management Using 'with'
Or the-keyword-formerly-known-as-do
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
Nick Coghlan wrote:
Raymond Hettinger wrote:
Whatever term is selected, it should be well thought-out and added to
the glossary. The choice of words will likely have a great effect on
learnability and on how people think about the new tool.
I tried to bring this up on python-list, but I
[Raymond]
Whatever term is selected, it should be well thought-out and added
to
the glossary. The choice of words will likely have a great effect
on
learnability and on how people think about the new tool.
[Ron Adam]
I tried to bring this up on python-list, but I didn't get much of a
Raymond writes:
On a separate note, I also propose that __exit__() be renamed to
__leave__(). The enter/leave word pairing are a better fit in standard
English:
I don't feel strongly about it, but I tend to disagree. Certainly you
will admit that enter-exit IS a gramatically correct pairing
I would use She left the ballpark. for someone walking into the
dugout, climbing up into the stands, or walking out of the stadium,
and might refer to the entire process. Using She exited the
ballpark.
to me suggests the exact moment that she went through the door
dividing outside from
Michael Chermside wrote:
In favor of exit over leave I have only two arguments. First, I
just like exit better. Hmm... didn't find that compelling? I was
afraid of that.
I have a pretty simple reason for liking the enter/exit pair over the
enter/leave pair.
In the former case, both words
Raymond Hettinger wrote:
On a separate note, I also propose that __exit__() be renamed to
__leave__(). The enter/leave word pairing are a better fit in standard
English:
I tend to associate leave with leaving, and leaving with arriving.
I didn't even think the __enter__ / __exit__ names
With 343 accepted, we can now add __enter__() and __exit__() methods to
objects.
What term should describe those objects in the documentation?
For instance, if the new magic methods are added to decimal.Context(),
do we then describe Context objects as withable ;-)
The PEP itself doesn't
Raymond Hettinger [EMAIL PROTECTED] writes:
With 343 accepted, we can now add __enter__() and __exit__() methods to
objects.
What term should describe those objects in the documentation?
Hmm, don't know.
I talked about an object 'that conformed to the with protocol' at
EuroPython, which
Resource managed?
On 6/30/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
With 343 accepted, we can now add __enter__() and __exit__() methods to
objects.
What term should describe those objects in the documentation?
For instance, if the new magic methods are added to decimal.Context(),
46 matches
Mail list logo
