Additional allowed magic attributes; consider 'blocklist' over 'allowlist' approach (WPS609)

[ariebovenberg]

I'd like to suggest some exceptions to rule WPS609 (disallow accessing magic attributes/methods):

• __bases__ (the base classes of a class)
• __path__ (present in Python packages)
• __dict__ (present in all non-slots classes)
• __module__ (present on all Python classes, functions)

These methods are part of established Python standards and are explicitly documented as being readable (and sometimes even settable!).

I could add these to _allowed_magic_attributes, but... I'd like to go one step further and suggest only generating errors for magic methods which have a possible alternative. For a few reasons:

1. Currently we force people to noqa without offering a workaround (e.g. how do you get a class bases without using __bases__?)
2. Some modules define their own (documented) magic attributes (like enum defining __members__) . This style guide cannot predict what the allowed/disallowed behavior is for all other libraries (current and future).
3. By keeping a 'blocklist' we still prevent all known egregious violations, like calling __eq__, __iter__, __delitem__, etc. directly. We can add more as we encounter them.

Also: If forbidding introspection is what we're after, it would perhaps be better to create a separate violation (so that it can be toggled more easily for introspection-heavy projects)

related:

• False positive DirectMagicAttributeAccessViolation with __subclasses__ #1314
• Think about direct magic method invocation #494

[ariebovenberg]

@sobolevn I'm happy you gave your blessing to add extra allowed attributes (dry-python/returns#1147 (review)) 🙏 . How do you feel about maintaining a list of 'forbidden attributes' instead of a list of 'allowed' ones? Valid ones are easily missed (and more could be added in modules/libraries without WPS knowledge), while we can find all 'forbidden' ones here.

[sobolevn]

forbidden attributes

Yes, this actually looks like a great idea! Because there might be extra magic attributes that are exposed as 1-party API members. This seems like being too strict for no valid reason.

We can safe forbig all magic methods that have other ways to be called. Possibly, some extra ones.

Thanks a lot for another great feature request! 👍