You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Before the problematic line df, only has one column (named column), but after the problematic line, df has two columns (column, and new_column); however we currently have no way of knowing that since dfdoes not appear to the left of the assignment operator. This might cause the output of soorgeon refactor to be incorrect.
Unfortunately, there is an infinite way to mutate variables, in fact, any method might mutate them. example:
# this may or may not mutate the inputdf.do_something()
I think for now we should detect instances of:
df[something] =stuff
and display a warning
The text was updated successfully, but these errors were encountered:
Just to clarify but is the issue that since the change for df occurs within a function when the code calls the function, soorgeon cannot see that df has changed which means that df will not be marked as an output when it should? I'm assuming this only applies to function parameters, since for local variables, they wouldn't matter and global variables aren't supported. Also when it says "mutating its inputs" does that mean it applies to any input parameters that are mutable objects or just data frames? Thanks.
Just to clarify but is the issue that since the change for df occurs within a function when the code calls the function, soorgeon cannot see that df has changed which means that df will not be marked as an output when it should?
correct
Also when it says "mutating its inputs" does that mean it applies to any input parameters that are mutable objects or just data frames? Thanks.
it applies to any input parameters
let me sync with Ido, this is low priority so there might be other stuff that will be better use of your time :)
soorgeon detects outputs by looking at the left side of an assignment expression, for example, let's say the section of a notebook looks like this:
In the snippet above, x, y, and z will be detected as outputs, since they are all on the left side of the assignment (
=
) operator.However, non-pure functions mutate their inputs: Say we have the following:
Before the problematic line
df
, only has one column (namedcolumn
), but after the problematic line,df
has two columns (column
, andnew_column
); however we currently have no way of knowing that sincedf
does not appear to the left of the assignment operator. This might cause the output ofsoorgeon refactor
to be incorrect.Unfortunately, there is an infinite way to mutate variables, in fact, any method might mutate them. example:
I think for now we should detect instances of:
and display a warning
The text was updated successfully, but these errors were encountered: