On Tue, Sep 9, 2014 at 11:12 AM, Martin Teichmann < martin.teichm...@gmail.com> wrote:
> Hi Guido, Hi List, > > And yet having a try/finally around a yield-from is an easy recipe for >> resisting cancellation -- it is all too convenient to put another >> yield-from in the finally clause, and then you are requiring multiple trips >> through the event loop. >> > > This is why I would love to have a well-documented function in the standard > library, where someone thought of all those corner-cases, and the function > either handles those, raises an exception or there is something in the > documentation telling the programmer DON'T DO THAT! > understand where you're coming from, but I want to repeat, with emphasis, that not every pattern deserves to become a library function, and education can take other forms than documentation of existing methods. > >> Where are the finalizers you need called and what do they do? And why do >> you need them called when you're shutting down the process? >> > > I am writing an RPC-like system, along the lines of > > @coroutine > def server(self): > open_database() > try: > yield from getattr(self, yield from read_command())() > finally: > close_database() > > now, there is a command to shut down the server, and I would like > the database to be properly closed for every server. First time I > discovered all of this was actually when I was pressing Ctrl-C > and realized it didn't close the database, something I always > kept for granted in a finalizer... > You realize that if the process crashes (e.g. with a SEGV) or is killed by some other signal, the finalizers aren't called either? I would assume that especially database connections are good at implicitly rolling back any uncommitted transaction regardless of whether any finalization code is run. > I am sure all this can be achieved differently, but nevertheless I think > a well thought out cancel method would still be a very nice thing to > have. > Perhaps, but clearly we're not even scratching the surface of how it should behave. I haven't heard from enough people with other use cases that would actually be helped by the same helper to warrant adding the new API you are proposing. API design generally ought to follow from use cases encountered frequently, otherwise you get a complex hodge-podge that is hard to learn. -- --Guido van Rossum (python.org/~guido)
