Re: [Python-Dev] More on contextlib - adding back a contextmanager decorator
At 09:53 AM 4/30/2006 -0700, Guido van Rossum wrote:
But what's an appropriate name for some_method? Given that documentation is the sore spot that keeps us circling around this point, doesn't this just push the problem to finding a name to use in place of __context__? And not only for this use case, but for others? After all, for any library that has a notion of "the current X", it seems reasonable to want to be able to say "with some_X" to mean "use some_X as the current X for this block". And it thus seems to me that people will want to have something like: def using(obj): if hasattr(obj,'__context__'): obj = obj.__context__() return obj so they can do "with using(some_X)", because "with some_X.using()" or "with some_X.as_current()" is awkward. If you can solve the naming issue for these use cases (and I notice you punted on that issue by calling it "some_method"), then +1 on removing __context__. Otherwise, I'm -0; we're just fixing one documentation/explanation problem (that only people writing contexts will care about) by creating others (that will affect the people *using* contexts too).
On 4/30/06, Phillip J. Eby <pje@telecommunity.com> wrote:
But what's an appropriate name for some_method?
Let's leave that up to the decimal lovers. You could call it push() or stack() or establish() or some other non-descript word. Or manage() or manager(). The method name can't involve the word "context" since the object is already called a context. But that still leaves an infinite number of possible names. :-)
To the contrary. Even if we never come up with a perfect name for decimal.Context.some_method(), then we've still solved a documentation problem for 9 out of 10 cases where __context__ is just empty ballast. But I'm sure that if we require that folks come up with a name, they will. Things should be as simple as possible but no simpler. It's pretty clear to me that dropping __context__ approaches this ideal. I'm sorry I didn't push back harder when __context__ was first proposed -- in retrospect, the first 5 months of PEP 343's life, before __context__ (or __with__, as it was originally called) was invented, were by far its happiest times. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
I've posted two versions of the "with" page from the language reference: http://pyref.infogami.com/with (current) http://pyref.infogami.com/with-alt (simplified) (the original is a slightly tweaked version of the current development docs) </F>
On 4/30/06, Phillip J. Eby <pje@telecommunity.com> wrote:
But what's an appropriate name for some_method?
Let's leave that up to the decimal lovers. You could call it push() or stack() or establish() or some other non-descript word. Or manage() or manager(). The method name can't involve the word "context" since the object is already called a context. But that still leaves an infinite number of possible names. :-)
To the contrary. Even if we never come up with a perfect name for decimal.Context.some_method(), then we've still solved a documentation problem for 9 out of 10 cases where __context__ is just empty ballast. But I'm sure that if we require that folks come up with a name, they will. Things should be as simple as possible but no simpler. It's pretty clear to me that dropping __context__ approaches this ideal. I'm sorry I didn't push back harder when __context__ was first proposed -- in retrospect, the first 5 months of PEP 343's life, before __context__ (or __with__, as it was originally called) was invented, were by far its happiest times. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
I've posted two versions of the "with" page from the language reference: http://pyref.infogami.com/with (current) http://pyref.infogami.com/with-alt (simplified) (the original is a slightly tweaked version of the current development docs) </F>
participants (3)
-
Fredrik Lundh -
Guido van Rossum -
Phillip J. Eby