Re: [Python-Dev] Terminology for PEP 343
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 current 'Iterator Types' in the library reference [1], which explains the iterator and iterable protocols. I'm starting to understand what prompted Raymond's original question, since the continued use of 'exited' sounds rather awkward (the correct English word is actually 'left'). On the other hand 'enter and exit' rolls off the tongue significantly better than 'enter and leave' (the natural pairing for the latter is 'arrive and leave'). All of which just leads me to the conclusion that English is a screwy language, and I already knew that ;) Anyway, I stuck with 'exit' for this - I prefer slightly awkard phrasing in the explanation to awkwardness in the pairing of the names. """ Suite Local Resource Management A frequent need in programming is to ensure a particular resource is released promptly after it is no longer needed. The tool to achieve this in Python is the 'with' statement. 'with' statements can be used to ensure a particular resource is acquired before the contained suite is entered, and released when the suite is exited. The main argument to the 'with' statement must be a resource manager - an object which supports the resource management protocol. This protocol consists of two methods: __enter__(): Called without arguments before execution enters the contained suite. Resource managers will generally acquire the resource in this method, although some resource managers may accept the resource to be managed as an argument to the constructor or acquire it during construction. The value returned from this method is assigned to the target identified in the 'as' clause of the 'with' statement. __exit__(exc_type, exc_value, exc_traceback): Called as execution exits the contained suite. If the suite was exited due to an exception, the details of that exception are passed as arguments. Otherwise, all three arguments are set to None. Resource managers will generally release the resource in this method. If the suite was exited due to an exception, and this method returns without incident, then the original exception continues to propagate. Otherwise, the exception raised by this method will replace the original exception. While the primary purpose of the resource management protocol is to manage simple resources such as files, locks or database connections, more complex uses, such as automatic exception logging or transaction handling, are also possible. Some resources (e.g. thread.Lock) will support the resource management protocol directly, acting as their own managers. In conjunction with the 'resource_manager' decorator, Python's generators provide a convenient way to implement the resource management protocol, and share state between the __enter__ and __exit__ methods. The generator must contain a single yield statement. The generator is executed up to that point as part of the resource manager's __enter__ method, and the value yielded is returned. The remainder of the generator is executed as part of the __exit__ method. Any exceptions that occur in the managed suite will be injected at the location of the yield statement. For example, the following resource manager allows prompt closure of any resource with a 'close' method (e.g. a generator or file): @resource_manager def closing(resource): try: yield resource finally: resource.close() """ Cheers, Nick. [1] http://docs.python.org/lib/typeiter.html -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminology for PEP 343
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 suite. If the suite was > exited due to an exception, the details of that exception are passed > as arguments. Otherwise, all three arguments are set to None. My take is that the primary awkwardness results from all the "ex": "execution", "exits", "exception". If we care, I guess "leave" is okay. Nice work! -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ f u cn rd ths, u cn gt a gd jb n nx prgrmmng. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminology for PEP 343
"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 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 resource? Cheers, mwh -- The meaning of "brunch" is as yet undefined. -- Simon Booth, ucam.chat ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminology for PEP 343
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 have managed to think of (as of yet). - Josiah Michael Hudson <[EMAIL PROTECTED]> 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? > > > > Resource managers. > > 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 resource? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminology for PEP 343
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. The terms __begin__ and __end__, are nearly as general, but they stress better that there are three parts, a beginning, middle and ending. > All of which just leads me to the conclusion that English is a screwy > language, and I already knew that ;) I nowe that tue, but fixxing it issint backward compattibbal. ;-) > Anyway, I stuck with 'exit' for this - I prefer slightly awkard > phrasing in the explanation to awkwardness in the pairing of the names. After reading Michael Hudsun's post: >>I used a with statement to establish and dis-establish an error >>handler -- would you call that a resource? He has a good point, maybe we are confusing what a with-block does, with how it can be used. So something along the lines of ... """ With-Mangager Blocks A With-Manager Block is used to combine related initiation and finalization routines from a Manager object with a local block of code. Python will attempt to execute the finalization routine even if an error occurs which makes With-Manager Blocks useful for writing algorithms which require dependable closure or release of an acquired resource after the code block is executed. etc... """ That's a nice start on the docs Nick. Cheers, Ron ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminology for PEP 343
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 general. They are > frequently used in other places, although __enter__ and __exit__ are > less common, so maybe it's a non issue. > > The terms __begin__ and __end__, are nearly as general, but they stress > better that there are three parts, a beginning, middle and ending. > > > > All of which just leads me to the conclusion that English is a screwy > > language, and I already knew that ;) > > I nowe that tue, but fixxing it issint backward compattibbal. ;-) > > > > Anyway, I stuck with 'exit' for this - I prefer slightly awkard > > phrasing in the explanation to awkwardness in the pairing of the names. > > > After reading Michael Hudsun's post: > > >>I used a with statement to establish and dis-establish an error > >>handler -- would you call that a resource? > > He has a good point, maybe we are confusing what a with-block does, with > how it can be used. > > So something along the lines of ... > > """ > With-Mangager Blocks > > A With-Manager Block is used to combine related initiation and > finalization routines from a Manager object with a local block of code. > Python will attempt to execute the finalization routine even if an error > occurs which makes With-Manager Blocks useful for writing algorithms > which require dependable closure or release of an acquired resource > after the code block is executed. > > etc... """ > > > That's a nice start on the docs Nick. > > Cheers, > Ron > > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/michael.walter%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)
On 6/30/05, Neil Hodgson <[EMAIL PROTECTED]> wrote: >One benefit I see for the path module is that it makes it easier to > write code that behaves correctly with unicode paths on Windows. > Currently, to implement code that may see unicode paths, you must > first understand that unicode paths may be an issue, then write > conditional code that uses either a string or unicode string to hold > paths whenever a new path is created. Then maybe the code that handles Unicode paths in arguments should be fixed rather than adding a module that encapsulates a work-around... -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminology for PEP 343
[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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminology for PEP 343
[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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminology for PEP 343
"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 resource? Yes -- now that you suggested it, given what you had on your slides ;-) An emergency backup resource is different from a normal production resource (opened file for instance), but I can still see it as a resource. Terry J. Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminology for PEP 343
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 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). This is possible. I just wanted to expand everyone's minds :) Cheers, mwh ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminology for PEP 343
> > 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 wanted to expand everyone's minds :) Stick by your guns. 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. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminology for PEP 343
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, "xrange objects are iterable". 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.) -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ f u cn rd ths, u cn gt a gd jb n nx prgrmmng. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminology for PEP 343
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 > 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 > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)
Guido van Rossum: > Then maybe the code that handles Unicode paths in arguments should be > fixed rather than adding a module that encapsulates a work-around... It isn't clear whether you are saying this should be fixed by the user or in the library. For a quick example, say someone wrote some code for counting lines in a directory: import os root = "docs" lines = 0 for p in os.listdir(root): lines += len(file(os.path.join(root,p)).readlines()) print lines, "document lines" Quite common code. Running it now with one file "abc" in the directory yields correct behaviour: >pythonw -u "xlines.py" 1 document lines Now copy the file "Здравствуйте" into the directory and run it again: >pythonw -u "xlines.py" Traceback (most recent call last): File "xlines.py", line 5, in ? lines += len(file(os.path.join(root,p)).readlines()) IOError: [Errno 2] No such file or directory: 'docs\\' Changing line 2 to [root = u"docs"] will make the code work. If this is the correct fix then all file handling code should be written using unicode names. Contrast this to using path: import path root = "docs" lines = 0 for p in path.path(root).files(): lines += len(file(p).readlines()) print lines, "document lines" The obvious code works with only "abc" in the directory and also when "Здравствуйте" is added. Now, if you are saying it is a library failure, then there are multiple ways to fix it. 1) os.listdir should always return unicode. The problem with this is that people will see breakage of existing scripts because of promotion issues. Much existing code assumes a fixed locale, often 8859-1 and combining unicode and accented characters will raise UnicodeDecodeError. 2) os.listdir should not return "???" garbage, instead promoting to unicode whenever it sees garbage. This may also lead to UnicodeDecodeError as in (1). 3) This is an exceptional situation but the exception should be more explicit and raised earlier when os.listdir first encounters name garbage. Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminology for PEP 343
> "Guarding a scope with a decimal.Context() object ." Doesn't "guard" suggestion conditional execution? Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminology for PEP 343
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? > > > > Resource managers. > >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 resource? Yes; an error handling resource is no different than say, a decimal context resource in this respect. A "with" statement defines the scope of use or applicability of some resource; the resource manager is the object that is notified as to when the scope is entered and exited, so that it can appropriately manage the resource. Some resources may be their own default resource manager, but it's always possible to create a different resource management policy by creating a new resource manager. I think this is a clear and straightforward explanation of what "with" does and what you can do with it. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminology for PEP 343
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 of yet). > >[Michael Hudson] > > This is possible. I just wanted to expand everyone's minds :) > >Stick by your guns. 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. 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 maybe you're projecting one particular concept of "resource management" (acquisition/release) and therefore say it's too narrow. But that's like I'm saying "vehicle", and you think that means "car". Should we give mind-expanding examples of "resource"? Yes, sure. But it's easier to say and teach "resource management" first, and then expand the concept, than to start with some more nebulous concept and then say, "but mostly you're going to use it to manage resources of various kinds." :) If you did want to start with something vague, you could always call it "context management", and call the objects "context listeners", saying that the "with" statement defines a context in which its body occurs, and the context listener is notified of the context's entry and exit. But I don't think that this really works as the primary explanation; I think it's better as a mind-expanding "Another way to think of this is..." add-on to the simple resource management explanation. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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?). Not sure. Michael On 7/3/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > "Guarding a scope with a decimal.Context() object ." > > Doesn't "guard" suggestion conditional execution? > > > Raymond > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminology for PEP 343
I'm referring to the specific meaning of "guard" in a computer science context: http://www.computer-dictionary-online.org/guard.htm?q=guard >From David Gries, The Science of Programming, if statement contains two entities of the form B --> S wehere B is a Boolean expression and S a command. B --> S is called a guarded command. I believe that terminology is rooted in Dijkstra's language of guarded commands (used to express and facilitate program proofs). They are essentially the same as conditionally executed statements but may be executed non-deterministically: http://cs-exhibitions.uni-klu.ac.at/contentGuardedCommand.php Also, I believe the pattern matching part of Prolog clauses are called guards; however, the conditional execution is deterministic (the first match is the one that fires) and potentially recursive. This terminology is used consistently among various functional programming languages. From, http://www.cs.ecu.edu/~karl/astarte/glossary.html , "A guard in a case is the condition that is being tested. For example, in case a => b, expression a is the guard." In predicate calculus, the phrase, "strengthening the guard" has a specific meaning with the "guard" part being consistent with the above. One example: http://www.cs.utexas.edu/users/psp/unity/notes/07-89.pdf 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: Sunday, July 03, 2005 10:28 PM > To: Raymond Hettinger > Cc: [EMAIL PROTECTED]; [email protected] > 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?). Not sure. > > Michael > > On 7/3/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > > "Guarding a scope with a decimal.Context() object ." > > > > Doesn't "guard" suggestion conditional execution? > > > > > > Raymond > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminology for PEP 343
> > 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 objects at all. 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) VAR = abc.__enter__() try: try: BLOCK except: exc = sys.exc_info() raise finally: abc.__exit__(*exc) There is nothing in that that says resource managed. The pre/post steps could do almost anything from logging, to changing environments, to translating, launching/joining unrelated threads, to communicating with other processes, etc. Ideally, the phrase needs to fit in a list of all of the other properties of the abc object (i.e. abc objects are callable, iterable, support the buffer interface, and are withable or somesuch). 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 __enter__ and __exit__ or the ability to work with the "with" keyword). The phrase does nothing but suggest a particular application that historically has been implemented without the new mechanism. Of course, what makes this exercise hard is that our two new keywords are prepositions and the process that they apply to is somewhat abstract. Raymond P.S. I would still like to encourage the adoption of __leave__ instead of __exit__. The first suggests part of an enter/leave pair. The latter could too easily be taken as a standalone. If everyone doesn't see the subtle reasons why __leave__ is better, then at least consider __beginwith__ and __endwith__ which say exactly what they mean and are obviously paired with each other and with the new keyword. 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 likely be NO contextual hints). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminology for PEP 343
Oh, I remember. Agreed, it is most probably a bad choice then. One part of my brain likes: "By wrapping a block in/with[*] a decimal.Context, " "xml.Tags used to wrap a block will print '' before the block is entered, and '' after execution has left." What do you think? [*] I'm not sure what's the correct English version, sorry.. if it is "with", it migh be a nice way to place a hyperlink to the language reference. On 7/3/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > I'm referring to the specific meaning of "guard" in a computer science > context: > > http://www.computer-dictionary-online.org/guard.htm?q=guard > > From David Gries, The Science of Programming, if statement contains two > entities of the form B --> S wehere B is a Boolean expression and S a > command. B --> S is called a guarded command. > > I believe that terminology is rooted in Dijkstra's language of guarded > commands (used to express and facilitate program proofs). They are > essentially the same as conditionally executed statements but may be > executed non-deterministically: > > http://cs-exhibitions.uni-klu.ac.at/contentGuardedCommand.php > > Also, I believe the pattern matching part of Prolog clauses are called > guards; however, the conditional execution is deterministic (the first > match is the one that fires) and potentially recursive. > > This terminology is used consistently among various functional > programming languages. From, > http://www.cs.ecu.edu/~karl/astarte/glossary.html , "A guard in a case > is the condition that is being tested. For example, in case a => b, > expression a is the guard." > > In predicate calculus, the phrase, "strengthening the guard" has a > specific meaning with the "guard" part being consistent with the above. > One example: > >http://www.cs.utexas.edu/users/psp/unity/notes/07-89.pdf > > 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: Sunday, July 03, 2005 10:28 PM > > To: Raymond Hettinger > > Cc: [EMAIL PROTECTED]; [email protected] > > 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?). Not sure. > > > > Michael > > > > On 7/3/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > > > "Guarding a scope with a decimal.Context() object effect>." > > > > > > Doesn't "guard" suggestion conditional execution? > > > > > > > > > Raymond > > > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Terminology for PEP 343
[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 certainly a span of action but the scope concept is more closely aligned with namespaces (and we're not creating a new namespace here). For extra credit, any proposed solution ought to also deal with the two kinds of __enter__ methods. One is expected to be used with "as" and the other is not. Neither of the above wordings begin to suggest whether decimal.Context.__enter__ will return a useful value (the PEP has examples of each). Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
