On Tue, 19 Nov 2019 at 19:03, Random832 <random832@fastmail.com> wrote:
On Tue, Nov 19, 2019, at 11:26, Paul Moore wrote:
Because you don't have to create the context manager directly in the with statement
...what? that's *my* argument. that's *precisely* why I consider open to be 'misbehaving'. Because you *should* be able to create a context manager outside the with statement without causing these problems. Because calling open outside the with statement [absent other arrangements like an explicit try/finally] causes problems that wouldn't be there for a proper context manager that has __exit__ as the inverse of __enter__ rather than as the inverse of some other operation that happens before __enter__.
We're just going round in circles here. You *can* call open outside the with statement. It's *perfectly* fine to do so. But if you do, it is *your* responsibility to manage the closing of the file object (which is done using close(), not __exit__()). That's been valid and acceptable for more years than I can recall (at least back to Python 1.4). As a convenience, you can pass the file object to a with statement, to say "i want the file to be closed when control leaves this suite, regardless of how that happens - please handle the admin for me. That convenience ability is provided by file objects making __enter__ do nothing (because there's nothing you need to do on entering the with block to prepare for the tidying up) and making __exit__ act like close (because all you need to do on leaving the scope is close the file). According to the PEP, and established usage since Python 2.5, an object that does this is called a context manager. It's a perfectly acceptable one. Even if it doesn't implement other behaviours that you would like it to have, doesn't mean it's not a context manager. I'm fine with you coining a new term ("enhanced context manager", I don't know, I've already said naming is hard) for context managers with the additional properties you are interested in, but existing context managers are *not* somehow "misbehaving" or "broken", or "problematic" - it's your assumption that context managers have behaviour that isn't required of them by the definition of that term that's wrong.
Because you *should* be able to create a context manager outside the with statement without causing these problems.
Says who? The PEP doesn't say any such thing. If you are saying it, I disagree with you. If you are saying "it's obvious and everyone must surely agree", then sorry, I still disagree with you. Simply asserting the same thing repeatedly is not a particularly effective argument. Demonstrate some benefits. I'll give you "we'd be able to create functions like nested() without worrying about users misusing them" for free. It's not worth a lot (IMO) but hey, you got it for free, what did you expect? ;-) Examine the costs, and explain why they are worth accepting Backward compatibility is a big one here, and you're going to need some serious benefits to offset it, or at least some really good ways to mitigate it - there's masses of code that passes file objects to with statements, as well as plenty of code that uses them independently. I really don't see any new arguments being made here, to be honest. Paul