On Tue, 19 Nov 2019 at 16:05, Random832 <random832@fastmail.com> wrote:
On Tue, Nov 19, 2019, at 07:03, Paul Moore wrote:
That sounds reasonable, with one proviso. I would *strongly* object to calling context managers that conform to the new expectations "well behaved", and by contrast implying that those that don't are somehow "misbehaving". File objects have been considered as perfectly acceptable context managers since the first introduction of context managers (so have locks, and zipfile objects, which might also fall foul of the new requirements). Suddenly deeming them as "misbehaving" is unreasonable.
The problem is that if this model is perfectly okay, then *there's no reason for __enter__ to exist at all*. Why doesn't *every* context manager just do *everything* in __init__? I think it's clear that something was lost between the design and the implementation.
Because you don't have to create the context manager directly in the with statement - __init__ is called when the object is created,, __enter__ is called when you enter the scope of the with statement. It's often the case that these two events happen at more or less the same time, but not always. I'm not the one suggesting that behaviour that's been around since Python 2.5 should be changed, so I don't think it's down to me to come up with examples where that flexibility is required - if someone's proposing to abolish __enter__ then let them prove that it's OK to do so. And if no-one's suggesting that, then I fail to see your point. Paul.