class Node:
    def __init__(self, edges = set()):
        self.edges = edges


def main():
    foo = Node()
    bar = Node()
    quz = Node()

    foo.edges.add(bar)
    bar.edges.add(foo)

    assert(foo is not bar) # assertion succeeds
    assert(foo is not quz) # assertion succeeds
    assert(bar is not quz) # assertion succeeds
    assert(len(quz.edges) == 0) # assertion fails??


main()
spoiler

Mutable default values are shared across objects. The set in this case.

  • FizzyOrange
    link
    fedilink
    arrow-up
    3
    ·
    5 days ago

    Yeah I tried Ruff about a year ago and it only had really trivial lints so it wasn’t a good replacement for Pylint. Is it on par yet?

    • NostraDavid
      link
      fedilink
      arrow-up
      2
      ·
      5 days ago

      It has implemented about half - I would check which the important ones are, and check if it’s been implemented (which is being tracked in issue 970):

      https://github.com/astral-sh/ruff/issues/970

      Astral claims Ruff has more rules total (about 800), but implemented about half of Pylint (which has 400 rules, so 200 implemented).

    • milkisklim@lemm.ee
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      5 days ago

      What do you mean by trivial? I am not necessarily the most experienced coder, but it does a great job yelling at me to keep methods short and simple.

      I’d suggest taking five minutes whenever and look up the ruff ruleset to see if it would be helpful for you.

      Also maybe because I don’t know how to use pylint in vs code, but the only semi useful thing it catches for me is if my venv doesn’t have a library the code imports.

      Edit: For example, Ruff has caught this bug (mutable argument defaults) in my code before.

      • FizzyOrange
        link
        fedilink
        arrow-up
        1
        ·
        5 days ago

        it does a great job yelling at me to keep methods short and simple

        Yes style things like that are what I would consider trivial. I also think those are actively bad lints. Yes methods should be short in general, but making it a hard enforced limit means you end up getting sidetracked by refactoring when you only wanted to add one line to a method.