I’m personally more in the “live with the redundancy indefinitely” camp, at least until someone designs and implements an updated context management protocol that meets the goals Serhiy mentioned above:
- passes the return value from the CM entry function to the exit function (to make re-entrant CMs easier to write without having to rely on closures to store state), with the active exception as an optional second argument
- allows the CM exit function to indicate that exceptions should be suppressed and return a value (e.g. by returning a non-empty tuple)
- updates the grammar to allow a 2-tuple of names in the “as” clause of with statements
(Technically, the latter two points could be handled independently from the first, since they don’t affect the method signature - they just tweak the meaning of non-empty tuples when the updated name binding syntax is used)
As Mark pointed out above, we even have __leave__ available as an entirely viable name for the new method.
The derived wrapper function technique can then be used at type construction time to ensure that implementing either version of the CM termination protocol gets you both methods on the resulting class. (at which point, it probably wouldn’t be worth it to deprecate the old method - it could just live on indefinitely, like some of the pickle and copy compatibility APIs)
However, even for proposals that I don’t personally favour, I prefer to see them evaluated in their best possible form, rather than making final decisions based on aspects that are specific to an initial proof of concept implementation (in this case, the fact the introspection could be moved to type definition time means that the runtime impact of the introspection could be minimised even without a specialising interpreter implementation)