On 4/30/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 4/30/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > A few things from the pre-alpha2 context management terminology review have > > had a chance to run around in the back of my head for a while now, and I'd > > like to return to a topic Paul Moore brought up during that discussion. > > I believe the context API design has gotten totally out of hand. > Regardless of the merits of the "with" approach to HTML generation > (which I personally believe to be an abomination), I don't see why the > standard library should support every possible use case with a > custom-made decorator. Let the author of that tag library provide the > decorator. > > I have a counter-proposal: let's drop __context__. Nearly all use > cases have __context__ return self. In the remaining cases, would it > really be such a big deal to let the user make an explicit call to > some appropriately named method? The only example that I know of where > __context__ doesn't return self is the decimal module. So the decimal > users would have to type >
+1. -Brett > with mycontext.some_method() as ctx: # ctx is a clone of mycontext > ctx.prec += 2 > <BODY> > > The implementation of some_method() could be exactly what we currently > have as the __context__ method on the decimal.Context object. Its > return value is a decimal.WithStatementContext() instance, whose > __enter__() method returns a clone of the original context object > which is assigned to the variable in the with-statement (here 'ctx'). > > This even has an additional advantage -- some_method() could have > keyword parameters to set the precision and various other context > parameters, so we could write this: > > with mycontext.some_method(prec=mycontext.prec+2): > <BODY> > > Note that we can drop the variable too now (unless we have another > need to reference it). An API tweak for certain attributes that are > often incremented or decremented could reduce writing: > > with mycontext.some_method(prec_incr=2): > <BODY> > > -- > --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/brett%40python.org > _______________________________________________ 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