This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Guido.van.Rossum
Recipients Guido.van.Rossum, Richard.Kiss, giampaolo.rodola, gvanrossum, mpaolini, pitrou, python-dev, richard.kiss, vstinner, yselivanov
Date 2014-08-18.16:22:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAP7+vJLFKMOvTA+hNHMMuuqXXzZvVUaVMYLK+h8ALBd=sey1Sg@mail.gmail.com>
In-reply-to <1408378670.22.0.55774757462.issue21163@psf.upfronthosting.co.za>
Content
So you are changing your mind and withdrawing your option #1.

I don't have the time to really dig deeply into the example app and what's
going on. If you want to help, you can try to come up with a patch (and it
should have good unit tests).

I'll be on vacation most of this week.

On Mon, Aug 18, 2014 at 9:17 AM, Marco Paolini <report@bugs.python.org>
wrote:

>
> Marco Paolini added the comment:
>
> Asking the user to manage strong refs is just passing the potential
> leak issue outside of the standard library. It doesn't really solve
> anything.
>
> If the user gets the strong refs wrong he can either lose tasks or
> leak memory.
>
> If the standard library gets it right, both issues are avoided.
>
> > I'm all in favor of documenting that you must keep a strong reference to
> a
> > task that you want to keep alive. I'm not keen on automatically keep all
> > tasks alive, that might exacerbate leaks (which are by definition hard to
> find) in existing programs.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue21163>
> _______________________________________
>
History
Date User Action Args
2014-08-18 16:22:12Guido.van.Rossumsetrecipients: + Guido.van.Rossum, gvanrossum, pitrou, vstinner, giampaolo.rodola, python-dev, yselivanov, richard.kiss, Richard.Kiss, mpaolini
2014-08-18 16:22:12Guido.van.Rossumlinkissue21163 messages
2014-08-18 16:22:12Guido.van.Rossumcreate