Eri*_*got 9 python overriding numpy
在Python中从另一个第三方模块重新定义类方法有多糟糕？
事实上,用户可以创建包含不确定数字的 NumPy矩阵; 理想情况下,我希望他们的代码运行不变(与代码操作浮点矩阵时相比); 特别是,如果m仍然可以使用矩阵的逆来获得,那将是很好的m.I,尽管m.I必须用我自己的代码计算(原始I方法通常不起作用).
重新定义numpy.matrix.I有多糟糕？首先,它确实篡改了我不喜欢的第三方代码,因为它可能不健壮(如果其他模块做同样的话会怎么样？...).另一个问题是新的numpy.matrix.I是一个包装器,当实际上可以应用原始的numpy.matrix.I以获得逆矩阵时,它涉及很小的开销.
是否继承了NumPy矩阵并且只更改了它们的I方法？这将迫使用户更新他们的代码并创建具有不确定性的数字矩阵 m = matrix_with_uncert(…)(而不是保持使用numpy.matrix(…),如浮点数矩阵),但这可能是为了鲁棒性而应该被接受的不便之处？矩阵求逆仍然可以与执行m.I,这是很好的.......另一方面,这将是很好,如果用户可以建立自己的(浮点或数字与不确定性的)所有矩阵与numpy.matrix()直接,而不必费心检查数据类型.
欢迎任何评论或其他方法!
Ale*_*lli 11
子类(它涉及重写,如该术语在通常使用的)通常更优选地将"猴子补丁"(馅改变的方法到现有的类或模块),即使当后者是可用的(内置类型,这意味着那些实施在C中,可以保护自己免受猴子修补,而且大部分都可以.)
例如,如果你的功能依赖于猴子补丁,它会破坏并停止升级,如果在任何时候你是猴子修补被升级类在C语言中实现(速度或专门抵御猴子补丁).第三方软件包的维护者恨猴修补,因为这意味着他们从倒霉的用户使用马车猴子补丁,它打破了第三方软件包,后者(除非打破monkey-其中虚假的bug报告谁(不知情的他们)实际上明智的)是完美的.您已经评论过可能的性能影响.
从概念上讲,"具有不确定性的数字矩阵"是与"数字矩阵"不同的概念.子类化表达这种干净,猴子修补尝试隐藏它.这实际上是一般情况下修补猴子的错误的根源:一个隐蔽的渠道通过全球隐藏的手段运作,没有清晰度和透明度.从根本上的概念问题来看,所有许多实际问题都在某种意义上下降.
我强烈建议你拒绝猴子修补,转而采用子类化等清洁解决方案.