从第三方模块重写方法有多糟糕? [英] How bad is it to override a method from a third-party module?
问题描述
在Python中从另一个第三方模块重新定义类方法有多糟?
How bad is it to redefine a class method from another, third-party module, in Python?
实际上，用户可以创建NumPy矩阵，其中包含具有不确定性的数字；理想情况下，我希望它们的代码能够不修改地运行(与之相比，该代码何时处理浮点矩阵)；特别是，即使m.I必须用我自己的代码计算(原始的I方法不起作用，一般).
In fact, users can create NumPy matrices that contain numbers with uncertainty; ideally, I would like their code to run unmodified (compared to when the code manipulates float matrices); in particular, it would be great if the inverse of matrix m could still be obtained with m.I, despite the fact that m.I has to be calculated with my own code (the original I method does not work, in general).
重新定义numpy.matrix.I有多严重?一方面，它会篡改我不喜欢的第三方代码，因为它可能不够健壮(如果其他模块也能做到这一点呢?……).另一个问题是，新的numpy.matrix.I是包装器，而实际上可以应用原始的numpy.matrix.I以获得逆矩阵时，其包装开销很小.
How bad is it to redefine numpy.matrix.I? For one thing, it does tamper with third-party code, which I don't like, as it may not be robust (what if other modules do the same?…). Another problem is that the new numpy.matrix.I is a wrapper that involves a small overhead when the original numpy.matrix.I can actually be applied in order to obtain the inverse matrix.
子类化NumPy矩阵并仅更改其I方法更好吗?这将迫使用户更新其代码并使用m = matrix_with_uncert(…)创建具有不确定性的数字矩阵(而不是像浮点数矩阵那样继续使用numpy.matrix(…))，但这可能是不便之处，因此健壮性?矩阵求逆仍然可以使用m.I执行，这很好.另一方面，如果用户可以直接使用numpy.matrix()构建所有矩阵(浮点数或具有不确定性的数)，而不必费心检查数据类型.
Is subclassing NumPy matrices and only changing their I method better? this would force users to update their code and create matrices of numbers with uncertainty with m = matrix_with_uncert(…) (instead of keeping using numpy.matrix(…), as for a matrix of floats), but maybe this is an inconvenience that should be accepted for the sake of robustness? Matrix inversions could still be performed with m.I, which is good… On the other hand, it would be nice if users could build all their matrices (of floats or of numbers with uncertainties) with numpy.matrix() directly, without having to bother checking for data types.
任何评论或欢迎其他方式！
Any comment, or additional approach would be welcome!
推荐答案
与猴子补丁"(将更改的方法填充到现有的类或模块中)相比，子类化(确实涉及覆盖，正如通常使用的术语)通常更可取. )，即使后者可用(内置类型，即用C实现的类型也可以保护自己免受猴子补丁攻击，而且大多数都可以).
Subclassing (which does involve overriding, as the term is generally used) is generally much preferable to "monkey-patching" (stuffing altered methods into existing classes or modules), even when the latter is available (built-in types, meaning ones implemented in C, can protect themselves against monkey-patching, and most of them do).
例如，如果您的功能依赖于猴子修补程序，则在任何时候将您要进行猴子修补程序的类升级为用C实现(以提高速度或专门防御猴子修补程序)，它将中断并停止升级. .第三方软件包的维护者讨厌猴子补丁，因为这意味着不幸的用户会收到虚假的错误报告，这些用户(他们不知道)实际上使用的是错误的猴子修补程序，该补丁会破坏第三方软件包，除非第三方软件包(除非破碎的猴子-明智的做法)是完美无缺的.您已经对可能的性能下降发表了评论.
For example, if your functionality relies on monkey-patching, it will break and stop upgrades if at any time the class you're monkey patching gets upgraded to be implemented in C (for speed or specifically to defend against monkey patching). Maintainers of third party packages hate monkey-patching because it means they get bogus bug reports from hapless users who (unbeknownst to them) are in fact using a buggy monkey-patch which breaks the third party package, where the latter (unless broken monkey-wise) is flawless. You've already remarked on the possible performance hit.
从概念上讲，具有不确定性的数字矩阵"与数字矩阵"是不同的概念.子类化清晰地表达了这一点，猴子修补试图将其隐藏.这实际上是猴子修补普遍存在的问题的根源:秘密渠道通过全局，隐藏的手段运作，没有清晰和透明.从某种意义上说，所有实际问题都源于这个根本的概念问题.
Conceptually, a "matrix of numbers with uncertainty" is a different concept from a "matrix of numbers". Subclassing expresses this cleanly, monkey-patching tries to hide it. That's really the root of what's wrong with monkey-patching in general: a covert channel operating through global, hidden means, without clarity and transparency. All the many practical problems descend in a sense from this root conceptual problem.
我强烈，敦促您拒绝使用猴子补丁，而希望使用干净的解决方案，例如子类化.
I strongly urge you to reject monkey-patching in favor of clean solutions such as subclassing.
这篇关于从第三方模块重写方法有多糟糕?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
