Hi,
On Saturday 02 May 2015 07:20:00 Christopher Adams wrote:
> Hey guys,
>
> Thanks for the great feedback and replies.
>
> Generally agree with everyone that post-commit hooks shouldn't be strictly
> coupled to the signals framework philosophically speaking.
>
> I disagree with Carl's premise that using `connection.on_commit` in your
> signal handler is simpler than adding `after_commit=True` as a kwarg.
I think you're confusing "simple" with "easy", see
http://www.infoq.com/presentations/Simple-Made-Easy
In particular, you are proposing to make one use-case easier, while making the
semantics of the API much more complex (the most glaring point: With your
proposal, adding a keyword argument changes the signal handler invocation from
synchronous to asynchronous, with everything that entails about error
handling). I am -1 on that API, regardless of the "one way to do it" argument.
> [using `connection.on_commit`] involves not only an extra import, but also
> familiarity by developers with the notion of closure and callbacks. Despite
> being a powerful feature of Python, this is not really as familiar a usage
> pattern among developers
It is quite easy to hide the use of connection.on_commit, including the
concepts of callback and closure, behind a small wrapper for handler
registration. I'd hesitate before putting it in core, but you can prove me
wrong by releasing it as a utility (or even a Django Snippet) and making it
popular.
HTH,
Shai.