builtins-ignorelist for attributes only

[benjamin-kirkbride]

Looking at https://beta.ruff.rs/docs/rules/builtin-attribute-shadowing/#builtin-attribute-shadowing-a003: I agree with the point made here: https://stackoverflow.com/a/60423602/1342874

Specifically, I think that the following is fine, and in fact better than alternatives:

@dataclass
class Row:
    id: int
    input: str

but of course the following is not fine:

id, input = row.id, row.input

My understanding is that the builtins-ignorelist is all or nothing; it makes it so that you can us id everywhere without warning, or nowhere without warning.

My proposal is that there is a builtins-attributes-ignorelist or something similar added for this.

[charliermarsh]

Why not disable the rule entirely? It's intentionally categorized as a separate rule to enable that kind of granular on/off switch.

[benjamin-kirkbride]

Fair question 😅

I think there are some attributes that I would still want to list, like str, or dict or something, but I don't have a good argument for why I think that some things are okay (like id, input, class, etc) but others aren't..

[tylerlaprade]

I ran across this as well. I really don't want type to be used as a Django model attribute because if I accidentally use type instead of self.type, my code will be completely wrong, but I won't get any warnings. But id and filter seem generally harmless for my usecases.

[Olegt0rr]

Just get A003 Class attribute exec is shadowing a python builtin on a method.

class Foo:
    def exec(self):
        ...

It's not a shadowing, cause I still can use builtin exec.

class Foo:
    @staticmethod
    def exec():
        exec("print('it is not a shadowing')")

Foo.exec()

For me, shadowing is when an object covers the original object and confusion can occur when called.

def foo(exec: str):
    print(exec)
    ...
    # and the later you may want to call builtin exec, but you can't
    exec("print('it is a shadowing')")

foo('bar')

Also readers may mistake the attribute for the builtin is a very strange explanation.
My user has an id. And user's class should use it:

class User:
    id: int

id_ - is ugly
user_id - is redundant and ugly, especially on call: user.user_id

What's wrong with reader, who can mess id() and user.id?

[charliermarsh]

@Olegt0rr - That is working as intended but it's a strange rule. You can see an example of what it's intended to catch here:

class C:
    @staticmethod
    def list() -> None:
        pass

    @staticmethod
    def repeat(value: int, times: int) -> list[int]:
        return [value] * times

The issue is that it will be shadowed if you reference the builtin within the class scope.

[charliermarsh]

PR up that should make this rule far more useful by only flagging actual shadowed reads (like in the example above) rather than the method definitions (which will almost always be fine): #9462