Dispatch model is broken - namespaces #125
Description
At my organization we just discovered a problem where one function price() was using multiple dispatch, and another (unrelated) function in a completely different namespace, also named price() was also using multiple dispatch.
This caused dispatch to pick one or the other function seemingly at random, and chaos ensued. As it happens, there was overlap in the types accepted by the functions, but that didn't raise any errors either, so it silently chose wrong functions.
I was able to write a failing unit test simply by doing assertIsNot(namespace_one.price, namespace_two.price) (the two names were in fact pointing to the same function).
I see in https://multiple-dispatch.readthedocs.io/en/latest/design.html that all multiple-dispatch functions will be put by default into a single global namespace, which seems like it's the root cause of this problem. Why would you want functions to go into this namespace? Why not simply return the decorated function like a normal decorator would, and let it stay in the caller's namespace like normal? What is the benefit of putting everything into a global namespace instead? The docs do say
If several projects use this global namespace unwisely then conflicts may arise...
but TBH I would just consider this a bug in multipledispatch, not the user doing anything unwise. If for some reason the user does want a bunch of functions from different namespace to be placed in the same namespace, this seems like it should be the exception rather than the silent rule.