On Tue, 19 Nov 2019 at 19:03, Random832 <random...@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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/2E3ULZ3Z75FZWNABSIVQAGN3V6J5QTGS/
Code of Conduct: http://python.org/psf/codeofconduct/
