"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 ch
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.
>>
>>Exp
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. :) "Resource" can incl
Fred L. Drake, Jr. wrote:
> Oh, I like this one. "Context manager" / "context protocol" work well for me.
And it means we get to say "decimal.context supports the context
protocol", which sounds perfectly sensible, even obvious. :-)
--
Greg Ewing, Computer Science Dept, +--
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.
__
Raymond Hettinger wrote:
> This is much improved. I think we're getting close. So far, I like
> Nick's most recent version the best, but this is in the ballpark.
I like some of Phillip's suggestions, particularly the 'context' term.
I'll put some thought into combining the two over the next cou
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, a
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 'co
Michael Hudson wrote:
> (I think Raymond has identified the problem I have with resource
> manager more clearly then I did; I certainly don't think I'd realise
> what "decimal.Context() is a resource manager" meant at first
> reading).
I'm also worried that "resource manager" is too narrow
a term
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 t
[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
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
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
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)
>
"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 p
[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 i
IOW, guard is a specific term, not an amorphous metaphor that can be
> accurately applied to the enter/exit or enter/leave pair.
>
>
> Raymond
>
>
>
>
>
> > -Original Message-
> > From: Michael Walter [mailto:[EMAIL PROTECTED]
> > Sent: Sun
> > 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 --
leave pair.
Raymond
> -Original Message-
> From: Michael 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
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 ."
>
> Doesn't "
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 t
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 th
> "Guarding a scope with a decimal.Context() object ."
Doesn't "guard" suggestion conditional execution?
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
Hmm:
"Guarding a scope with a decimal.Context() object ."
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
>
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 d
> > 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
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
"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
[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 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
_
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 ex
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.
Just because not all cars are used as vehicles, does that mean that cars
are not vehicles?
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
ha
"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?
>
> Resource managers.
Thing is, there may b
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 con
Ron Adam wrote:
> So it could be a "Resource Manager Block", which
> uses a "__begin__" and "__end__" method, which is defined in a "Resource
> Manger" object or a "Resource Manager Generator" object, which is called
> by the 'with' key word.
Here's an initial crack at an equivalent of the curr
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
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 i
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 w
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 w
> 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 fro
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
[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
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
[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
http://mail.python.org/mailman/listinf
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++
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.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev ma
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
Pyth
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
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
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
http://mail
"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.Cont
"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,
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 pro
55 matches
Mail list logo
