Currently, there is no way to override the method name when using the
decorator convention. A small change adds the ability to do so.
With this change, the following become possible.
@d.add_method
def one(x):
return x
@d.add_method() # no longer an issue
def one(x):
return x
@d.add_method(name="not.really.x")
def one(x):
return x
Alternate Designs
It is possible to subclass Dispatcher in users codebase, and utilize that as the dispatcher, but it would be nicer to have this upstream (less code required)
Benefits
The ability to override the name used for method lookup. This can be helpful if code in two separate files happens to have the same name, or if you wish to expose a different name (to make api versioning easier).
Possible Drawbacks
Additional complexity of add_method function. functools.partial should be available back to python 2.5, so compatibility /shouldn't/ be an issue. There is a small runtime cost, but only at parse time, not run time.
Description of the Change
Currently, there is no way to override the method name when using the decorator convention. A small change adds the ability to do so.
With this change, the following become possible.
Alternate Designs
It is possible to subclass Dispatcher in users codebase, and utilize that as the dispatcher, but it would be nicer to have this upstream (less code required)
Benefits
The ability to override the name used for method lookup. This can be helpful if code in two separate files happens to have the same name, or if you wish to expose a different name (to make api versioning easier).
Possible Drawbacks
Additional complexity of
add_methodfunction.functools.partialshould be available back to python 2.5, so compatibility /shouldn't/ be an issue. There is a small runtime cost, but only at parse time, not run time.Applicable Issues
None.