-
-
Notifications
You must be signed in to change notification settings - Fork 321
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve Strict Equality To Account For Named Closures #852
Comments
Alternatively, for function defs we can check if their code is equal using string equality |
I think we could probably skip the qualname check and allow lambda comparisons by, as you say, just checking byte code equivalence. |
I would think the same applies to named closures as well. This would make the implementation for all function types the same. But to be bullet proof, would need to also check if the |
True. Though technically, all we really care about is whether, given the same inputs, the output is the same (assuming the function is pure). The file name then, only matters in so far as there might be different globals that the function is referencing. |
Current Situation
Right now,
strictly_equal
does not understand how to check if named closures are the same. Here's an example of such a closure:Here, while
add(1) is not add(1)
both produce the same behavior, IDOM won't recognize that they're the same.Proposed Actions
It turns out that we can fairly reliable look at a function's
__qualname__
,__closure__
, and__defaults__
to determine whether it's the same function. The logic to check this would look like:The catch here is that technically, a user could do the following:
This will fail because both functions, while they may implement different logic, have the same qualname. This is basically the same reason that we cannot compare lambdas. Since they all have the same name.
There may be ways to work around this. For example,
f1
andf1
were defined on different lines. You could check this using__code__.co_firstlineno
.The text was updated successfully, but these errors were encountered: