On 4/24/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: [...] > The __iter__ method isn't called __iterator__, so why would the __context__ > method need to be called "__contextmgr__"?
Because......... Hmm, Oleg already responded to this, and to be honest, I think the whole issue is a nitpick. Apologies for bringing it up, it doesn't help. > However, I'm definitely starting to agree with Just & Terry and whoever else > said it that the basic object needs to be called something other than "context > object". "context specifier" or something like that. (in fact, I might make a > pass through the PEP & documentation to see how that looks. . .) [...] > > (Oh, and by the way, writing this sentence > > reinforced the reason I perfer the old terminology - "context manager" > > feels like the name of something more concrete than "context", and yet > > under your new terminology, the "context" is more concrete than the > > "context manager"!) > > This is why I'm starting to think Terry and Just are right - the name of that > type needs to be something other than "context object" in order to reduce the > current ambiguity. Right. I'll still do as I promised, and have a better look through the latest documentation, but my gut feel is that this whole thing is getting way out of proportion. Naming and terminology is important, but we've now on our 3rd version of the docuentation. My instinct is STILL that the original version of the docs were fine. I can't express this in analytical terms, for which I apologise, but I'm not sure it's an analytical issue. So if the following sounds wooly, it's the best I can do :-) The terms "context" (an abstract thingy relating to the environment in which a block of code executes) and "context manager" (a concrete object that manages contexts) seem natural to me. The fact that you pass "context managers" to the "with" statement emphasizes the idea that they are the concrete one of the pair. Your version swaps the terms around, and so messes up my intuition. I concede that your version is self-consistent, but it doesn't match my intuition. And in my view, intuition matters here, so I have to prefer the variant that matches my intuition. Your point about the objects in the stdlib doesn't persuade me, I'm afraid. All the threading examples have __context__ return self, so they are, in some sense, both contexts and context managers (contexts which are their own managers, if you like). Only decimal.Context is a genuine context manager which creates independent context objects - I concede that the name doesn't match my theory here, but I'm afraid *I don't care*. I emphasize this, because it's an intuition thing again - I know my terminology is (slightly) inconsistent with respect to the decimal.Context class, but it doesn't disrupt my understanding. Worse (in terms of explaining myself!) it still feels natural to stick with decimal.Context even though I *know* that in my terms, it is formally a context manager. (The best explanation I can give is that it sits happily alongside the other places where I don't mind ignoring the difference between "function returning X" and "X" when describing things). OK, I really can't explain that any better, but the library object naming issue doesn't sway me. Right, this is my final position: I'm happy with the alpha-1 terminology. I would strongly prefer that we go back to that. I'd like to see the @contextmanager decorator split (conceptually, if not actually) into 2 parts, one for use with generator functions which are to be context managers, and one for use with __context__ functions (generator functions which are to be functions returning contexts). I'm willing to write up a patch doing the code changes for this, but I don't hold out much hope of being able to write docs any better than you or anyone else can! I won't argue against any self-consistent terminology. But that's because I'm not convinced of the value of having another round of change/review on the docs - it doesn't mean I support it over the alpha-1 version (and I'll probably still think in alpha-1 terms, whatever ends up being agreed). I think I've now read enough on the subject that my value as an unbiased reader is being lost... Paul. PS Is anyone else arguing with Nick on this? Now that I'm reduced to intuitive "well, I prefer it" arguments, it would be nice to hear what people's gut feelings are - "contexts create context managers", "context managers create contexts", "so confused I don't know"... :-) ? _______________________________________________ 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
