On 2011-11-09, at 22:10 , Jeremy Sanders wrote:
That makes no sense.
I think it does.
No, you're objecting to a local, scoped and type-based customization of operations (something already common in Python) by asking for a global functional reimplementation in user code instead.
I could write code relying on the math.XXX failing for types other than the built in numeric types, or for particular exceptions for particular calls.
I fail to see how that's an argument against local customization and for global reimplementation.
Also, if you override a standard module as a quick way to get existing code working, you can get lots of existing code paths which might fail in interesting ways, especially if there weren't unit tests for these cases. It would make more sense if the possibility was documented in the math documentation.
If you go and change the behaviour of built-in functions just by importing a module it could lead to some weird bugs. I know monkey patching can do this currently, but doing it by default seems dangerous to me.
Nothing in these two paragraphs makes any sense in the context of the current discussion. *Nobody* (but you) argues for "changing the behavior of built-in functions just by importing a module", or for "overriding a standard module".
I think you have misunderstood what Case Van Horsen is suggesting.