[flake8-boolean-trap] Add setting for user defined allowed boolean trap

[augustelalande]

Summary

Add a setting extend-allowed-calls to allow users to define their own list of calls which allow boolean traps.

Resolves #10485.
Resolves #10356.

Test Plan

Extended text fixture and added setting test.

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

[9128305]

Is it possible to also check the import path like it should check "django.db.models.Value" and not just "Value" usage?

[charliermarsh]

It's not clear to me if these should be function names, or symbol paths (like ["pydantic", "BaseModel"]).

[augustelalande]

Do you mean it's not clear in the documentation/implementation? Or are you saying you're not sure how we should implement it?

[charliermarsh]

The latter!

[augustelalande]

I think symbol path gives finer control, and is less prone to false negatives. The only downside is that it is less intuitive to users, and may lead to confusion. But I think this should be ok with good documentation.

[augustelalande]

I will change it to symbol paths if everyone agrees.

[q0w]

is it hard to support both?

[charliermarsh]

Symbol path is a little problematic because it doesn't support methods (e.g., there's no way to identify y in x = pydantic.BaseModel(); x.y()), and methods are a common use-case here.

[augustelalande]

@charliermarsh I'm moving the discussion to the main thread.

Given your comment I think you do not want to drop support for simple function calls.

Then there are three options:

1. Keep things as is with users only defining functions to ignore.
2. Implement both function names and symbol paths using a single setting. It is then up to us to determine whether the given pattern should be interpreted as a function or symbol path (I think it's not that hard?).
3. Implement both with two settings, one for symbol path, one for functions.

[augustelalande]

I lean more towards 2, but not strongly

[charliermarsh]

Let me quickly cross-reference with some other settings.

[charliermarsh]

The two linked examples, at least, seem like they would work with symbol paths. So let's start with that. (extend_immutable_calls works with symbol paths, so symbol paths are more consistent with existing settings.)

[augustelalande]

Done