homepage

singledispatch currently doesn't defend against unwanted redefinition of an existing specialization, e.g.:
>>> def f(x): return "default"
... 
>>> f = functools.singledispatch(f)
>>> @f.register(int)
... def _(x): return "1"
... 
>>> @f.register(int)
... def _(x): return "2"
... 
>>> f(42)
'2'
This can be annoying when used as an extension mechanism. It would be nice if at least an option in the singledispatch() constructor could prevent this.

Is it too late to have the default for that option be to not allow the replacement? That would be the safer course.

I don't know. I'm assuming some people actually want to redefine existing specializations.

Sure. I just saying that
@f.register(int, replace=True)
requires opt-in to replacing, whilst
@f.register(int, replace=False) # don't replace if one already exists
is still prone to bugs.

Yes it is too late. You'd have to do a couple of deprecation cycles to change the default.

Ah, but I wasn't suggesting to add an argument to the .register() call, but to the singledispatch() call; i.e. it would be a function-wide parameter.

Ah, I see.
So you say up-front if you are willing to have redefinition occur later.
That doesn't feel like a consenting-adults attitude, and could also make testing harder.
I prefer adding an option to the register method, and move towards making the default be "don't allow".
If we don't want to go that route, would having singledispatch issue a warning on redefinition be sufficient?

Le 09/07/2015 20:30, Ethan Furman a écrit :
> 
> That doesn't feel like a consenting-adults attitude, and could also
make testing harder.
Testing of what? The point is that it's the authority providing the
generic function which decides how lenient extending the generic
function is. That sounds rather reasonable to me...
> I prefer adding an option to the register method, and move towards
> making the default be "don't allow".
But that default won't happen, for the compatibility reasons already
explained.

I agree with Antoine.