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.
