[PATCH 1 of 6 events v3] util: add event handling mechanism

Gregory Szorc gregory.szorc at gmail.com
Sun Sep 28 16:14:06 CDT 2014


On 9/28/2014 2:01 PM, Gregory Szorc wrote:
> # HG changeset patch
> # User Gregory Szorc <gregory.szorc at gmail.com>
> # Date 1411933407 25200
> #      Sun Sep 28 12:43:27 2014 -0700
> # Node ID d513c232aeba16137b291456536adee0d88a040f
> # Parent  4109cc16279ef0e04dc70e7f4c9ab7415e6a22d3
> util: add event handling mechanism
> 
> The patch adds a generic event handling mechanism to Mercurial. From a
> high level, you create a class with methods corresponding to event
> names. You can then register functions/callbacks against events that
> get called when that event fires.

I talked with mpm about this feature at the Munich sprint and I believe
this patch series incorporates the improvements he was looking for.
Namely, the .register() bit was replaced by standalone classes holding
event definitions in a more Pythonic way. mpm and I discussed using
decorators. However, I believe __new__ (as implemented) fits the bill
just fine.

There is one feature notably absent from this patch series:
documentation. I'd like to automatically generate documentation for all
available events so extension authors have something that isn't raw
source code to consult. However, I'm not sure where to put this. I don't
think `hg help` is appropriate since events aren't user facing. `hg
debugevents` perhaps?

If incorporated, this patch series could make refactors to facilitate
monkeypatching a thing of the past, as events can satisfy many of the
use cases where monkeypatching was needed. As a recent example, Mike
Hommey's recent refactorings to facilitate additional bundle2 part
handling could likely have been avoided if bundle2 event support were
present. This patch series should thus likely result in less code churn
and thus increased code comprehension.


More information about the Mercurial-devel mailing list