Skip to content
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

[Bug]: False positive with FURB184 #320

Open
2 tasks done
shaolo1 opened this issue Dec 26, 2023 · 6 comments
Open
2 tasks done

[Bug]: False positive with FURB184 #320

shaolo1 opened this issue Dec 26, 2023 · 6 comments
Assignees
Labels
bug Something isn't working

Comments

@shaolo1
Copy link

shaolo1 commented Dec 26, 2023

Has your issue already been fixed?

  • Have you checked to see if your issue still exists on the master branch? See the docs for instructions on how to setup a local build of Refurb.
  • Have you looked at the open/closed issues to see if anyone has already reported your issue?

The Bug

The following code:

class Foo:
    _path = '/'

    def get_path(self):
        return self._path

    def test(self):
        foo = self
        path = foo.get_path()

Emits the following error:

$ refurb refurb_chain.py
refurb_chain.py:9:9 [FURB184]: Assignment statement should be chained

But it should not be emitting an error instance because...
There is nothing to chain here?

Version Info

Refurb: v1.26.0
Mypy: v1.8.0

Python Version

Python 3.11.3

Config File

# N/A

Extra Info

None

@shaolo1 shaolo1 added the bug Something isn't working label Dec 26, 2023
@dosisod
Copy link
Owner

dosisod commented Dec 26, 2023

@shaolo1 thank you for opening this issue!

I don't think this is a false positive, but perhaps the error message could be improved to better indicate what's going on. Because foo is assigned and then used on the next line to call .get_path() (and never again after that), FURB184 is suggesting you chain foo like so:

    def test(self):
        path = self.get_path()

This might just be a MVP to illustrate the problem, in which case I can imagine this error is a bit misleading/confusing if you're intending to use foo as a placeholder/temp variable. There should probably be a threshold needed to constitute as "chaining", ie, calling and re-assigning the same variable 2+ times instead of just 1.

@blablatdinov
Copy link

Hi! I like this rule, but sometimes it can lead to a false positive.

For example cases with a split definition of a template string and its formatting.

template = '{}'
template.format('User')

@dosisod
Copy link
Owner

dosisod commented Dec 27, 2023

cc @sbrugman what are your thoughts on this?

@shaolo1
Copy link
Author

shaolo1 commented Dec 27, 2023

@shaolo1 thank you for opening this issue!

I don't think this is a false positive, but perhaps the error message could be improved to better indicate what's going on. Because foo is assigned and then used on the next line to call .get_path() (and never again after that), FURB184 is suggesting you chain foo like so:

    def test(self):
        path = self.get_path()

This might just be a MVP to illustrate the problem, in which case I can imagine this error is a bit misleading/confusing if you're intending to use foo as a placeholder/temp variable. There should probably be a threshold needed to constitute as "chaining", ie, calling and re-assigning the same variable 2+ times instead of just 1.

Fair enough. The original code that it was flagged in was a bit weird, and I just focused on the error message not making sense to me. In reality the original code really just needed changing, so perhaps a tweak to the message would be good enough.

@shaolo1
Copy link
Author

shaolo1 commented Dec 27, 2023

@shaolo1 thank you for opening this issue!

I don't think this is a false positive, but perhaps the error message could be improved to better indicate what's going on. Because foo is assigned and then used on the next line to call .get_path() (and never again after that), FURB184 is suggesting you chain foo like so:

    def test(self):
        path = self.get_path()

This might just be a MVP to illustrate the problem, in which case I can imagine this error is a bit misleading/confusing if you're intending to use foo as a placeholder/temp variable. There should probably be a threshold needed to constitute as "chaining", ie, calling and re-assigning the same variable 2+ times instead of just 1.

Fair enough. The original code that it was flagged in was a bit weird, and I just focused on the error message not making sense to me. In reality the original code really just needed changing, so perhaps a tweak to the message would be good enough. The net effect was positive and in the spirit of refurb. It prompted me to make a change to the code for the better.

@gavindsouza
Copy link

I just got this with the following code block after upgrading from v1.22.1 to v1.28.0 :

m = chocolata.get_meta("Component")
+title_field = m.calculate_title()

data = chocolata.find_all(
    "Component",
    filters={
        "target_entity": doc.doctype,
        "is_identifier": True,
    },
+    fields=["name", title_field],
    order_by="creation asc",
)
# Note: order is important ^ to track matches

+notify({f"Component::{x['name']}": x[title_field] for x in data})

I've highlighted the relevant lines as to why this was a false positive

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants