On Wed, 20 Nov 2019 at 02:36, Richard Damon <rich...@damon-family.org> wrote: > > On 11/19/19 8:57 PM, Oscar Benjamin wrote: > > On Tue, 19 Nov 2019 at 12:03, Paul Moore <p.f.mo...@gmail.com> wrote: > >> On Tue, 19 Nov 2019 at 11:34, Oscar Benjamin <oscar.j.benja...@gmail.com> > >> wrote: > >> > >>> If I was to propose anything here it would not be to disallow anything > >>> that you can currently do with context managers. Rather the suggestion > >>> would be to: > >>> 1. Clearly define what a well-behaved context manager is. > >>> 2. Add convenient utilities for working with well behaved context > >>> managers. > >>> 3. Add well-behaved alternatives for open and maybe others. > >>> 4. Add Random832's utility for adapting misbehaving context managers. > >> 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. > > Perhaps a less emotive way of distinguishing these classes of context > > managers would be as "eager" vs "lazy". An eager context manager jumps > > the gun and does whatever needs undoing or following up before its > > __enter__ method is called. A lazy context manager waits until > > __enter__ is called before committing itself. > > > > I don't really want to give a sense of equality between eager and lazy > > though. To me it is clear that lazy context managers are preferable. > > You say it's unreasonable to claim now that some long-existing context > > managers are "misbehaving". Perhaps there is a better word but an > > alternative that implies that all existing context managers are > > "perfectly acceptable" will not convey the useful point that some ways > > of doing things are better than others. > > > > -- > > Oscar > > If I understand it right, an eager context manager (like open currently > is) allows itself to be used somewhat optionally, and not need to be in > a with statement. A lazy context manager on the other hand, seems to be > assuming that it will be used in a with statement (or something > similar), as it is putting off some important work until it sees it is > in there. > > It impetus for this seems to be to make a cleaner syntax for a with > statement managing multiple resources through context managers, if we > only need simple recovery (the built in provided by the context > manager). It may be at the cost of making more complex (and explicit) > handling of conditions for current (or possible future) 'eager' > managers. For example, if open doesn't actually open the file, but only > prepares to open, then the use of a file outside a with becomes more > complicated if we want somewhat precise control over the file.
The idea would be (or rather would have been) that open still does the same thing it did before and returns a file object with the usual methods. However that file object would *not* be a context manager. If you wanted a context manager for the file then you would have used opened (from PEP 343) rather than open and opened would give a context manager whose __enter__ would return the same file object that open otherwise returns. So it doesn't make other uses of the file object more complicated except that you choose whether to call open or opened depending on how you want to use the file. -- Oscar _______________________________________________ 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/GY5XMGGHHBFQXW277V7PBKSJZO7FGL4K/ Code of Conduct: http://python.org/psf/codeofconduct/
