Misc. fixes
1 unresolved thread
1 unresolved thread
Compare changes
+ 27
− 27
@@ -35,7 +35,7 @@ class Constant(AbstractOperation):
@@ -59,7 +59,7 @@ class Addition(AbstractOperation):
@@ -82,11 +82,11 @@ class Subtraction(AbstractOperation):
@@ -105,11 +105,11 @@ class Multiplication(AbstractOperation):
@@ -128,11 +128,11 @@ class Division(AbstractOperation):
@@ -150,11 +150,11 @@ class SquareRoot(AbstractOperation):
@@ -172,11 +172,11 @@ class ComplexConjugate(AbstractOperation):
@@ -195,13 +195,13 @@ class Max(AbstractOperation):
@@ -220,13 +220,13 @@ class Min(AbstractOperation):
@@ -244,11 +244,11 @@ class Absolute(AbstractOperation):
@@ -266,7 +266,7 @@ class ConstantMultiplication(AbstractOperation):
@@ -288,11 +288,11 @@ class ConstantAddition(AbstractOperation):
@@ -310,11 +310,11 @@ class ConstantSubtraction(AbstractOperation):
@@ -332,9 +332,9 @@ class ConstantDivision(AbstractOperation):
What is the reason for removing "-> Any"?
It is superfluous since Any is the default return type annotation. In most cases, it would have made sense to keep it anyway for clarity, but in this case I believe it makes the user code cleaner if they don't have to add "Any" to everything since the signature for the evaluate method is completely generic (generic number of arguments, generic types of arguments and generic return type).
In other words, I would rather have the user manual say something like "overload evaluate by writing def evaluate(a, b): return a + b" instead of "overload evaluate by writing def evaluate(a: Any, b: Any) -> Any: return a + b", since I believe the latter would only be more confusing.
If we don't type "Any" then there is no clear way to distinguish if the type is meant to be "Any" or if the developer forgot the typing, which I am sure will happen many times in this project considering that we are 8 developers. Don't you agree?
Also, don't we require 2 approvals to merge to develop? I can only see that Kevin approved this. You also merged the branch before waiting for a response on the comment / it being resolved which is not the type of code reviews that we want to have. I know this is a very minor issue but there are good reasons to keep these practices in place.