Nick Coghlan wrote:
Raymond Hettinger wrote:
Whatever term is selected, it should be well thought-out and added to the glossary. The choice of words will likely have a great effect on learnability and on how people think about the new tool.
I tried to bring this up on python-list, but I didn't get much of a response. I suggested "witherator" as a too cute alternative, but was hoping to get some alternatives to that.
For 'with' statements, all we really know is that the object may do something before the suite it is entered, and something else as the suite is exited. Other than that, it could be (or do) anything. Hence, 'user defined statement'.
I would say the key attribute is the "and something else as the suite is exited" part. With out that, the "with" statement isn't needed and a regular function or generator would work.
A term which stresses finalizing may be appropriate.
With that piece of terminology in place, the natural outcome was to call objects that supplied __enter__ and __exit__ methods "statement templates".
Will objects be created that can be used with and without "with" statements? I think that this could be a source of confusion.
It seems to me that "with" statements require a "with" object, and that those objects probably shouldn't be used without the "with" statement. Having a clear separation might be a good idea.
Should there be a "with" (different name most likely) type?
Would there be any advantages of a "with" base object that can have constructor methods that can accept either a try-finally generator or two functions to insert into the __enter__ and __exit__ methods as arguments?
For example, call a with object a "manage" object then:
with manage.generator(open_file_gen) as f: BLOCK
with manage.enter_exit(lock_func, unlock_func) as lock: BLOCK
I also used this term to come up with PEP 346's name for the generator to statement template conversion decorator: "stmt_template"
(Like others, the fact that 'with' is a verb makes it very hard for me to interpret "with_template" correctly when I see it as a decorator - I always want to ask "with which template?")
I agree, the decorator adds a layer of complexity to it. I think the with-generator behavior needs to be described without the decorator version first, then the decorator becomes syntactic sugar to make it easier to do the same thing.