I'd also be okay with a docs change, although this wouldn't help avoid late-binding bugs quite so much.
On Mon, Aug 22, 2022 at 1:51 PM Carlton Gibson <carlton.gib...@gmail.com> wrote: > Related ticket from this weekend, suggesting a docs change: > https://code.djangoproject.com/ticket/33939 > > On Mon, 22 Aug 2022 at 14:11, 'Adam Johnson' via Django developers > (Contributions to Django itself) <django-developers@googlegroups.com> > wrote: > >> Hi >> >> I just wrote a blog post on a late-binding bug that can occur with using >> transaction.on_commit() with a function or lambda within a loop. THe post >> shows how using functools.partial() solves this. See the post here: >> https://adamj.eu/tech/2022/08/22/use-partial-with-djangos-transaction-on-commit/ >> >> I propose that transaction.on_commit() be modified to take args and >> kwargs to pass to the callback function. This would mean it effectively >> constructs a partial() "under the hood": >> >> transaction.on_commit(send_mail, subject=f"...", >> recipient_list=[user.email], ...) >> >> I think this would be simpler than asking developers to beware of the >> late-binding problem and use partial(), always or when appropriate. >> >> This change would make transaction.on_commit() similar to Python's >> atexit.register(), which also takes a callback to run at a later point, and >> optional args/kwargs to pass it: >> https://docs.python.org/3.10/library/atexit.html#atexit.register >> >> The only backwards-compatibility concern I can see is the `using` >> argument, which would not be passed to the underlying function. I don't see >> this as a huge concern, since it would be the only argument that isn't >> passed through, and there doesn't seem to be any reason to add further >> arguments. Users who need to pass a kwarg called 'using' could always >> construct a partial() themselves. >> >> Thoughts? >> >> Adam >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-developers+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/CAMyDDM2OQoj3mV4pHuo8OB%2BLM6xpZdLQdSTyaGR%2B1m5oPg-C7Q%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-developers/CAMyDDM2OQoj3mV4pHuo8OB%2BLM6xpZdLQdSTyaGR%2B1m5oPg-C7Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAJwKpyTBmLTR8cLbOMWFmm-y47jH1Jki48BF57cvM%3DKPpjNGHw%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAJwKpyTBmLTR8cLbOMWFmm-y47jH1Jki48BF57cvM%3DKPpjNGHw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM354E0mQg8KAnrmzoJe7nZ7JyHGXgjppGXde-5mMfzqUg%40mail.gmail.com.
