Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
Nick Coghlan [EMAIL PROTECTED] writes: Ron Adam wrote: 3. The with documentation could possibly be grouped with or after the try documentation as it may be easier to understand in that context. I was looking for an appropriate place in the tutorial to put a couple of usage examples - a new subsection immediately after the introduction of try/finally (8.7, IIRC) seemed to make the most sense. However, I figured that bit could wait until I had a chance to play with an actual implementation. http://python.org/sf/1235943 (I have a more recent patch at home, which better implements the __future__ stuff in the compiler package -- not a very big thing). Probably also want to test with Phillip's PEP 342 patch: http://python.org/sf/1223381 (I haven't done this, there are probably conflicts). Cheers, mwh -- Lisp does badly because we refuse to lie. When people ask us if we can solve insoluble problems we say that we can't, and because they expect us to lie to them, they find some other language where the truth is less respected. -- Tim Bradshaw, comp.lang.lisp ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
M.-A. Lemburg [EMAIL PROTECTED] writes: This is exactly what I'm getting at: I can see the potential use for resource management (which is what started out the whole idea IIRC), but fail to see why you'd want to use it for anything more complicated than that. I, as a concrete example, want to be able to write: with output_to_file(f): print stuff function_that_prints_stuff() and have the printed things end up in the file-like object f (in a single-threaded program, foom :) This is only a resource by a tortured defintion. Note that hiding things away in smart objects like what you call context managers will not make programs easier to understand, unless the specific task that such a context manager is simple enough to grasp by just looking at its definition in the with statement... but then you'd not call it a context manager. Of course, but there's no single term to describe all these simple things, and we need a single term to describe the objects designed to be used in the with statement for documentation purposes. Consensus on python-dev has settled on 'context manager', but personally I don't much care what it is so long as it isn't actively misleading (which I contend applies to 'resource manager'), it's just something people can look up in the index. Let's keep things simple and Python nice. Are you arguing against PEP 343 as a whole, here? Cheers, mwh -- CLiki pages can be edited by anybody at any time. Imagine the most fearsomely comprehensive legal disclaimer you have ever seen, and double it-- http://ww.telent.net/cliki/index ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
M.-A. Lemburg wrote: This is exactly what I'm getting at: I can see the potential use for resource management (which is what started out the whole idea IIRC), but fail to see why you'd want to use it for anything more complicated than that. The other suggested uses (redirecting stdout, logging exceptions, inserting fences in markup, switching decimal context) aren't really more complicated. They're just different cases of 'paired code' - code which consists of 'standard setup code', 'the unique bit', 'standard cleanup code'. The longest example context manager in PEP 343 is only 11 lines long. Even the wrapper to turn a generator into a context manager weighs in at only 23 lines. Once you start talking about contexts (which usually refers to a combination of environment, state and location) you have to explain things like nesting, scopes, combination of different contexts, their interaction with each other, etc. etc. Except that context managers combine contexts in a very simple way - each one is almost entirely independent of both its surroundings and its contents. Each context manager takes a specific action to set the context up, and a specific action to tear it down again afterwards. Its behaviour is dependent only on the arguments that are passed to its constructor, and exceptions raised by its contents. The only way to make a context manager depend on its position in the code (rather than the passed in arguments) is to use sys._getframe, and using that is always considered an evil hack :) Note that hiding things away in smart objects like what you call context managers will not make programs easier to understand, unless the specific task that such a context manager is simple enough to grasp by just looking at its definition in the with statement... but then you'd not call it a context manager. Each one on its own may not be called a context manager, but we still need a collective term that covers all of the simple (but different) cases of common setup and cleanup code that we would like to factor out. We tried 'resource managers' (which was too specific to one particular use case), 'block managers' (a bit too close to the related-but-very-different Ruby blocks) and 'suite managers' (which wasn't too bad, but not very intuitive) along the way, but 'context managers' was the first one that really seemed to adequately summarise the nature of the protocol - allowing a programmer to factor out arbitrary setup and cleanup code that would otherwise have to be reproduced inline everywhere they needed it. BTW, the same argument applies to decorators. Programs don't get easier to read or understand if you overload a function with lots and lots of hidden magic... No argument here, but notice that the generic term 'decorator' tells you nothing about what any *specific* decorator does. The obviousness needs to be in the name of the decorator (such as 'classmethod'). The situation is the same for context managers - to make the code easy to read, the method or variable used to denote the context manager in the with statement must be well named. @put_all_the_smart_stuff_here def program(context): return 42 Of course, you *could* do all these things and Python is not preventing you from doing so, but will life get easier ? I doubt it. But what about: for item in put_all_the_smart_stuff_here(): item.value = 42 The other guiding light in the terminology discussion was the existing concept of iterables and iterators. Those can do just about anything you want, and frequently hide a great deal of complexity. However, if they're well named, then it is possible to read a for loop that uses them without batting an eyelid. If the reader decides they need to know the details, they look up the documentation of the iterator, just as they'd look up the details of a decorator they didn't recognise. Once they've looked up the definition once, instead of having to recognise a particular usage pattern in the code (Oh, that's doing 'X' again), the reader simply has to recognise the name (Oh, that's the decorator/iterator/context manager that does 'X') Let's keep things simple and Python nice. Indeed - but I see being able to factor out common code as both simple *and* nice, which is why I like the ideas of functions, iterators, decorators and context managers :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
Michael Hudson wrote: M.-A. Lemburg [EMAIL PROTECTED] writes: This is exactly what I'm getting at: I can see the potential use for resource management (which is what started out the whole idea IIRC), but fail to see why you'd want to use it for anything more complicated than that. I, as a concrete example, want to be able to write: with output_to_file(f): print stuff function_that_prints_stuff() and have the printed things end up in the file-like object f (in a single-threaded program, foom :) I would like it to be that easy also. However, it seems to me that using a context manager within try-except blocks will be a very common practice. try: with some_context() as var: do stuff except: flag, log, and/or handle error else: everything is ok The context manager will handle it's own cleanup, but we will still (in most cases) need to react to the raised exception somehow (and someplace) even if it's with a pass. It makes me think that the 'with' would be better expressed as a variation of a try statement. And the documentation for the 'with' statement would then be grouped and explained along with the try statements. Possibly: try with some_context() as VAR: do stuff with VAR except: # optional except-else? react to error in context else: good to go or just: trywith some_context() as VAR: # May cause an exception do stuff with VAR # that needs to be caught. I guess my point is: Since it's an encapsulated try-finally with a definite chance of generating an exception, Having a stronger association to 'try' in both the syntax and the documentation may be good. Cheers, Ron ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
On 7/15/05, Ron Adam [EMAIL PROTECTED] wrote: [several new syntax proposals] Please stop proposing new syntax. The PEP was accepted after quite enough back-and-forth; there's no point opening this up yet again. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
Guido van Rossum wrote: On 7/15/05, Ron Adam [EMAIL PROTECTED] wrote: [several new syntax proposals] Please stop proposing new syntax. The PEP was accepted after quite enough back-and-forth; there's no point opening this up yet again. My apologies Guido. Subtracting the inappropriate syntax suggestions leaves the following hopefully on-topic documentation suggestions. It may be good to have a stronger association to try in the documentation by: 1. Suggesting to the programmer that in many situations a with can be thought of as 'try with'. 2. Reminding or clarify that a with will handle the object or context cleanup, but the programmer *may still* need to catch exceptions that are generated within the block with a try-except at some point. 3. The with documentation could possibly be grouped with or after the try documentation as it may be easier to understand in that context. Regards, Ron ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
Ron Adam wrote: 3. The with documentation could possibly be grouped with or after the try documentation as it may be easier to understand in that context. I was looking for an appropriate place in the tutorial to put a couple of usage examples - a new subsection immediately after the introduction of try/finally (8.7, IIRC) seemed to make the most sense. However, I figured that bit could wait until I had a chance to play with an actual implementation. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
Nick Coghlan wrote: M.-A. Lemburg wrote: May I suggest that you use a different name than context for this ?! The term context is way to broad for the application scopes that you have in mind here (like e.g. managing a resource in a multi-threaded application). It's actually the broadness of the term 'context' which is appealing - the examples in the draft documentation on SF are: - resource management (synchronisation locks, generic 'closing') - HTML tag matching - Decimal arithmetic context Any earlier version used 'suite managers' (partly to avoid confusing the hell out of anyone ever exposed to Ruby's concept of blocks), but the 'context management' term seems to more clearly describe what the protocol is for. This is exactly what I'm getting at: I can see the potential use for resource management (which is what started out the whole idea IIRC), but fail to see why you'd want to use it for anything more complicated than that. Once you start talking about contexts (which usually refers to a combination of environment, state and location) you have to explain things like nesting, scopes, combination of different contexts, their interaction with each other, etc. etc. Note that hiding things away in smart objects like what you call context managers will not make programs easier to understand, unless the specific task that such a context manager is simple enough to grasp by just looking at its definition in the with statement... but then you'd not call it a context manager. BTW, the same argument applies to decorators. Programs don't get easier to read or understand if you overload a function with lots and lots of hidden magic... @put_all_the_smart_stuff_here def program(context): return 42 Of course, you *could* do all these things and Python is not preventing you from doing so, but will life get easier ? I doubt it. Let's keep things simple and Python nice. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 14 2005) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
{MAL]
This is exactly what I'm getting at: I can see the potential
use for resource management (which is what started out the
whole idea IIRC), but fail to see why you'd want to use it
for anything more complicated than that.
Substitute different for complicated.
'with' is not application specific, it is incredibly general. All it
does is abstract recurring uses of try/finally.
Naming it after a specific class of applications would be a mistake.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
On 7/7/05, Walter Dörwald [EMAIL PROTECTED] wrote: What is still unspecified (or at least not explicitely mentioned) in the PEP is the lifetime of VAR in: with EXPR as VAR: BLOCK It is specified well enough IMO -- you're supposed to take the translation into basic Python seriously. That translation specifies a simple assignment to VAR, and that's what I meant (and what I'm sure most folks understood). IOW VAR lives in the surrounding scope, overwrites a previous value, and survives past the with-statement (unless it is set inside of course). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
Guido van Rossum wrote: On 7/7/05, Walter Dörwald [EMAIL PROTECTED] wrote: What is still unspecified (or at least not explicitely mentioned) in the PEP is the lifetime of VAR in: with EXPR as VAR: BLOCK It is specified well enough IMO -- you're supposed to take the translation into basic Python seriously. That translation specifies a simple assignment to VAR, and that's what I meant (and what I'm sure most folks understood). IOW VAR lives in the surrounding scope, overwrites a previous value, and survives past the with-statement (unless it is set inside of course). Are there use cases for both variants? If VAR would live only until the end of the with block, this would give us a nice way of generating nested data structures: class blist(list): def __init__(self, parent=None): if parent: parent.append(self) list.__init__(self) def __enter__(self): return self def __call__(self, *items): self.extend(items) return self x = blist() x(1) with blist(x) as x: x(2) with blist(x) as x: x(3) x(4) x(5) This would create the list: [1, [2, [3], 4], 5] With the current version of PEP 343, we would either have to use different variable names on each level or use a global stack where __enter__() and __exit__() push and pop values. Bye, Walter Dörwald ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
Walter Dörwald [EMAIL PROTECTED] writes: Am 07.07.2005 um 20:00 schrieb Guido van Rossum: +1 on @contextmanager +1. [__enter__, __exit__] These names should be changed to __beginwith__ and __endwith__. -1. The PEP has had an extensive review period and several alternatives were discussed and rejected. These names are clear, they *do* match, and as Fred says the __*__ namespace has lots of room. Also, the PEP was accepted with these names. Now, if it was accepted with a major flaw or some semantics left unspecified, What is still unspecified (or at least not explicitely mentioned) in the PEP is the lifetime of VAR in: with EXPR as VAR: BLOCK Does VAR overwrite or shadow any previous values of VAR? Yup! Or at least in my half-an-implementation, that's what happens. (PEP 343 is a lot harder to implement then you might think, btw -- the stack discipline around finally: statements is a bit mind-bending). I.e. will VAR still exist after the end of the block with its value the return value of __enter__() or will it revert to the previous value (if any)? Eh, no. Where would you store the old value? I'd prefer the later although interpreting the translation of with EXPR as VAR: BLOCK into abc = EXPR exc = (None, None, None) VAR = abc.__enter__() try: try: BLOCK except: exc = sys.exc_info() raise finally: abc.__exit__(*exc) literally would indicate the former. Please continue to interpret it like that :) Cheers, mwh -- Why are we talking about bricks and concrete in a lisp newsgroup? After long experiment it was found preferable to talking about why Lisp is slower than C++... -- Duane Rettig Tim Bradshaw, comp.lang.lisp ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
Michael Hudson wrote: Walter Dörwald [EMAIL PROTECTED] writes: [...] I.e. will VAR still exist after the end of the block with its value the return value of __enter__() or will it revert to the previous value (if any)? Eh, no. Where would you store the old value? I don't know, where does: x = 42 .join(chr(x) for x in xrange(10)) '\x00\x01\x02\x03\x04\x05\x06\x07\x08\t' x 42 store it? [...] Bye, Walter Dörwald ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
Nick Coghlan [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Phillip J. Eby wrote:
I suggest changing this to something like this:
class tag(object):
def __init__(self,name):
self.name = name
def __enter__(self):
print %s % name
def __exit__(self):
print /%s % name
with tag('html'):
# ... etc.
So that it's obvious where the implementation is coming from.
Otherwise, it looks altogether too magical.
Done - included in the latest version on SF. [1]
Would this also work as a decorated generator?
(If I have understood correctly, something like..)
@contextmanager
def tag(name)
print %s % name
yield None
print /%s % name
If so, I suggest putting in both versions to make the correspondence clear.
To whoever invented this example: thanks. It rang a bell with me so I
could see this as a generally usefully feature rather than a specialized
(though for some, important) 'close resource' feature.
The particularly neat thing is that it converts the indent-dedent method of
showing structure to the alternative matched-fences method. This is
certainly not limited to HTML generation.
Terry J. Reedy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
Nick Coghlan wrote: OK, here's some draft documentation using Phillip's context terminology. I think it works very well. With Statements and Context Management A frequent need in programming is to ensure a particular action is taken after a specific section of code has been executed (such as closing a file or releasing a lock). The tool to achieve this in Python is to use the 'with' statement along with the appropriate context manager. Context managers ensure a particular action is taken to establish the context before the contained suite is entered, and a second action to clean up the context when the suite is exited. The precise behaviour of the 'with' statement is governed by the supplied context manager - an object which supports the context management protocol. This protocol consists of two methods: May I suggest that you use a different name than context for this ?! The term context is way to broad for the application scopes that you have in mind here (like e.g. managing a resource in a multi-threaded application). The PEP talks about blocks, which is a much more precise term for what with is going to implement, so I'd suggest to call these thingies block managers. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 08 2005) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
Barry Warsaw [EMAIL PROTECTED] writes: +1 on @contextmanager On Wed, 2005-07-06 at 19:47, Raymond Hettinger wrote: __enter__(self): __exit__(self, exc_type, exc_value, exc_traceback): These names should be changed to __beginwith__ and __endwith__. -1. -0. My fingers are too hardwired to writing endswith, as in the string method of similar name. ;) Slightly silly alternative: __within__ and __without__ Meh. Otherwise, +0 on __enter__ and __exit__. +1 from me. Cheers, mwh -- 58. Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
+1 on @contextmanager +1. [__enter__, __exit__] These names should be changed to __beginwith__ and __endwith__. -1. The PEP has had an extensive review period and several alternatives were discussed and rejected. These names are clear, they *do* match, and as Fred says the __*__ namespace has lots of room. Also, the PEP was accepted with these names. Now, if it was accepted with a major flaw or some semantics left unspecified, I'd be happy to discuss repairs; but there's nothing broken about this part of the PEP, so I say enough is enough (and none of the proposals sound good to me anyway so I'd be -1 even if the PEP was still under discussion). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
At 09:12 PM 7/6/2005 +1000, Nick Coghlan wrote:
Another example is the use of contexts to handle insertion of the
appropriate tags when generating HTML:
with html:
with body:
with h1:
print Some heading
with p:
print This is paragraph 1
with p:
print This is paragraph 2
with h2:
print Another heading
I suggest changing this to something like this:
class tag(object):
def __init__(self,name):
self.name = name
def __enter__(self):
print %s % name
def __exit__(self):
print /%s % name
with tag('html'):
# ... etc.
So that it's obvious where the implementation is coming from. Otherwise,
it looks altogether too magical.
Also, the posted draft doesn't explain what happens to the __enter__ return
value, either in a literal sense or in the sense of where it fits in the
overall concept of context management.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
Am 07.07.2005 um 20:00 schrieb Guido van Rossum: +1 on @contextmanager +1. [__enter__, __exit__] These names should be changed to __beginwith__ and __endwith__. -1. The PEP has had an extensive review period and several alternatives were discussed and rejected. These names are clear, they *do* match, and as Fred says the __*__ namespace has lots of room. Also, the PEP was accepted with these names. Now, if it was accepted with a major flaw or some semantics left unspecified, What is still unspecified (or at least not explicitely mentioned) in the PEP is the lifetime of VAR in: with EXPR as VAR: BLOCK Does VAR overwrite or shadow any previous values of VAR? I.e. will VAR still exist after the end of the block with its value the return value of __enter__() or will it revert to the previous value (if any)? I'd prefer the later although interpreting the translation of with EXPR as VAR: BLOCK into abc = EXPR exc = (None, None, None) VAR = abc.__enter__() try: try: BLOCK except: exc = sys.exc_info() raise finally: abc.__exit__(*exc) literally would indicate the former. Bye, Walter Dörwald ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
On 7/6/05, Nick Coghlan [EMAIL PROTECTED] wrote: OK, here's some draft documentation using Phillip's context terminology. I think it works very well. I agree. +1 on this terminology, and for this explanation to be included in the docs. I also like the fact that it offers a neat 1-word name for the generator decorator, @context. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
Nick writes sample documentation: For example, the following context manager allows prompt closure of any resource with a 'close' method (e.g. a generator or file): @context def closing(resource): try: yield resource finally: resource.close() Reading this I get the feeling that perhaps the decorator should be named context_manager not context: @context_manager def closing(resource): try: yield resource finally: resource.close() Does anyone else agree? Paul Moore writes: I also like the fact that it offers a neat 1-word name for the generator decorator, @context. Well, ok... does anyone *else* agree? I too saw this and thought neat! a simple one-word name!. But then I started worrying that it's not defining the *context*, but rather the *context manager*. While context manager is a term I could easily imagine associating only with 'with' statements, context is too general a term... even after Python supports 'with' statements I will continue to use context to mean lots of different things (eg: decimal.context). By the way, great job Nick... these docs read quite nicely. -- Michael Chermside ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
Paul Moore wrote: On 7/6/05, Nick Coghlan [EMAIL PROTECTED] wrote: OK, here's some draft documentation using Phillip's context terminology. I think it works very well. I agree. +1 on this terminology, and for this explanation to be included in the docs. I also like the fact that it offers a neat 1-word name for the generator decorator, @context. I liked that too, along with 'ContextManager' as the name for the controlling class that had the highly descriptive name 'Wrapper' in PEP 343. And explaining the operation of specific contexts is generally nice too. Stealing Greg's example: decimal.Context supports the context management protocol, and introduces a new decimal arithmetic context for the duration of the with statement. And the synchronisation example: threading.Lock supports the context management protocol, and acquires the lock for the duration of the with statement. And the generic closing example: closing supports the context management protocol, and closes the supplied resource at the end of the with statement. And the HTML tag examples: The HTML tag objects support the context management protocol, and emit opening and closing tags before and after execution of the body of the with statement. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
On 7/6/05, Michael Chermside [EMAIL PROTECTED] wrote: Paul Moore writes: I also like the fact that it offers a neat 1-word name for the generator decorator, @context. Well, ok... does anyone *else* agree? I too saw this and thought neat! a simple one-word name!. But then I started worrying that it's not defining the *context*, but rather the *context manager*. While context manager is a term I could easily imagine associating only with 'with' statements, context is too general a term... even after Python supports 'with' statements I will continue to use context to mean lots of different things (eg: decimal.context). Actually, you're starting to persuade me... Although I generally prefer decorator names which are single words. Along with the at-sign, underscores make the whole thing look a little too punctuation-heavy for me (and don't suggest camel case, please!). Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
Paul Moore wrote: On 7/6/05, Michael Chermside [EMAIL PROTECTED] wrote: Paul Moore writes: I also like the fact that it offers a neat 1-word name for the generator decorator, @context. Well, ok... does anyone *else* agree? I too saw this and thought neat! a simple one-word name!. But then I started worrying that it's not defining the *context*, but rather the *context manager*. While context manager is a term I could easily imagine associating only with 'with' statements, context is too general a term... even after Python supports 'with' statements I will continue to use context to mean lots of different things (eg: decimal.context). Actually, you're starting to persuade me... Although I generally prefer decorator names which are single words. Along with the at-sign, underscores make the whole thing look a little too punctuation-heavy for me (and don't suggest camel case, please!). Anything against @contextmanager in analogy to @staticmethod ? Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
Well, I'm convinced. My votes go to context management protocol and @contextmanager. Simple, descriptive and specific in meaning yet wide enough to cover pretty much all the cases we care about. I think we should state in the docs that the most common usage is to set up a specific context and restore the context to what it was before the with statement at the end of the with statement. Any other use should contain dire warnings ;) This works for the HTML tags - the original context is being outside the html tag - and the additional explanation is sufficient warning IMO. Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
[Nick Coghlan] OK, here's some draft documentation using Phillip's context terminology. I think it works very well. With Statements and Context Management A frequent need in programming is to ensure a particular action is taken after a specific section of code has been executed (such as closing a file or releasing a lock). The tool to achieve this in Python is to use the 'with' statement along with the appropriate context manager. the tool -- a tool The other tool is, of course, try/finally. What is offered by with and context manager objects is the encapulsation specific try/finally blocks. This enables repeated, common code to be factored-out. There only new magic here is factoring. Context management has always been possible. __enter__(self): __exit__(self, exc_type, exc_value, exc_traceback): These names should be changed to __beginwith__ and __endwith__. The current names are too vague, not obviously paired with each other, not obviously tied to the with-statement, and provide no hint about what calls them. Remember, the methods will appear among a slew of other methods that have nothing to do with with-statements. There will be no surrounding contextual clue as to what these methods are for. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
Fred L. Drake, Jr. wrote: On Wednesday 06 July 2005 19:47, Raymond Hettinger wrote: These names should be changed to __beginwith__ and __endwith__. The current names are too vague, not obviously paired with each other, not obviously tied to the with-statement, and provide no hint about what calls them. Remember, the methods will appear among a slew of other methods that have nothing to do with with-statements. There will be no surrounding contextual clue as to what these methods are for. I don't really like this; what's to say there won't be some other client of the context protocol? Should __iter__ have been __iterfor__? (I don't think so.) Then what about __begincontext__ and __endcontext__? Raymond's points about __enter__ and __exit__ are still good. Regards, Nicolas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
+1 on @contextmanager On Wed, 2005-07-06 at 19:47, Raymond Hettinger wrote: __enter__(self): __exit__(self, exc_type, exc_value, exc_traceback): These names should be changed to __beginwith__ and __endwith__. -0. My fingers are too hardwired to writing endswith, as in the string method of similar name. ;) Slightly silly alternative: __within__ and __without__ Otherwise, +0 on __enter__ and __exit__. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
