Updated linter configs

[ammar92]

Changes

Enabled and fixed these ruff plugins:

• PLC
• A

More to enable and fix soon.

Issue link

#784

---

Code Checklist

• This PR only contains functionality relevant to the issue; tickets have been created for newly discovered issues.
• I have written unit tests for the changes or fixes I made.
• For any non-trivial functionality, I have added integration and/or end-to-end tests.
• I have performed a self-review of my code and refactored it to the best of my abilities.

Communication

• I have informed others of any required .env changes files if required and changed the .env-dist accordingly.
• I have made corresponding changes to the documentation, if necessary.

---

Checklist for code reviewers:

Copy-paste the checklist from the docs/source/templates folder.

---

Checklist for QA:

Copy-paste the checklist from the docs/source/templates folder.

[github-actions]

File	Coverage
All files	66%	❌
bits/definitions.py	65%	❌
bits/runner.py	56%	❌
bits/https_availability/https_availability.py	93%	✅
bits/oois_in_headers/oois_in_headers.py	57%	❌
bits/spf_discovery/internetnl_spf_parser.py	55%	❌
bits/spf_discovery/spf_discovery.py	72%	❌
octopoes/api/api.py	58%	❌
octopoes/api/models.py	75%	✅
octopoes/api/router.py	47%	❌
octopoes/core/app.py	80%	✅
octopoes/core/service.py	44%	❌
octopoes/events/events.py	96%	✅
octopoes/events/manager.py	65%	❌
octopoes/models/__init__.py	86%	✅
octopoes/models/datetime.py	66%	❌
octopoes/models/exception.py	83%	✅
octopoes/models/origin.py	70%	❌
octopoes/models/path.py	99%	✅
octopoes/models/types.py	95%	✅
octopoes/models/ooi/certificate.py	96%	✅
octopoes/models/ooi/config.py	89%	✅
octopoes/models/ooi/email_security.py	95%	✅
octopoes/models/ooi/findings.py	94%	✅
octopoes/models/ooi/network.py	97%	✅
octopoes/models/ooi/service.py	91%	✅
octopoes/models/ooi/software.py	71%	❌
octopoes/models/ooi/web.py	81%	✅
octopoes/models/ooi/dns/records.py	95%	✅
octopoes/models/ooi/dns/zone.py	77%	✅
octopoes/repositories/ooi_repository.py	39%	❌
octopoes/repositories/origin_parameter_repository.py	53%	❌
octopoes/repositories/origin_repository.py	53%	❌
octopoes/repositories/scan_profile_repository.py	45%	❌
octopoes/xtdb/client.py	49%	❌
octopoes/xtdb/query_builder.py	69%	❌
octopoes/xtdb/related_field_generator.py	71%	❌
tests/conftest.py	88%	✅
tests/integration/test_xtdb_client.py	34%	❌

Minimum allowed coverage is 75%

Generated by 🐒 cobertura-action against 19ba63c

[dekkers]

What is the problem with shadowing builtins? The flake8-builtins example would be caught by both CI and code review. There are a lot of generic named python builtins and adding a trailing _ to them is just ugly, so we should only do that if there realy is a benefit, which I currently fail to see.

[ammar92]

What is the problem with shadowing builtins? The flake8-builtins example would be caught by both CI and code review. There are a lot of generic named python builtins and adding a trailing _ to them is just ugly, so we should only do that if there realy is a benefit, which I currently fail to see.

I guess the real benefit is avoiding confusion and spreading consistency.

Shadowing builtins is even worse than shadowing outer scoped variables. It's confusing, linters and static analysis of proper IDEs and other languages nag about it for good reasons. There are about 158 builtins (Python 3.11), I'm sure there's a magnitude of other variable names one can think of. For example, some function arguments named type could've also been object_type or plugin_type. Also, it doesn't make sense, for example, to only add an underscore to that type argument if we wish to use type (as a function) in the function body, why not be consistent everywhere?