Correct lint issues exposed with update to pylint-3

[micpap25]

Fixes #1440

Re-enables the following pylint issues which were disabled when bumping to pylint-3.

• abstract-class-instantiated
• deprecated-class
• possibly-used-before-assignment
• used-before-assignment

[mpharrigan]

can we keep this as an elif and add an else clause that raises a ValueError or AssertionError?

[mpharrigan]

Can you revert the changes to remove the different types. The tooling should support us writing good code; we shouldn't let the tooling dictate worse patterns. Unless there's something I'm missing about the original pattern actually being wrong (??)

[micpap25]

@mpharrigan Pushed the reversion. My thought process is that the current state isn't good code since we are using abstraction purely for isinstance checks which seems convoluted and could be handled by one variable.

[mpharrigan]

The distinction shows up in calls to the constructor, with the unique class names helping to make the code more self-documenting.

Should we keep abstract-class-instantiated as a global skip? Am I correct in saying that they were all false-positives? And that now any time someone uses one of these classes they would have to add an additional "skip" comment?

[micpap25]

I can definitely confirm that last part, that a skip would be necessary to use these classes.

Parsing through the code I do think it's all false positives. I don't believe any abstract classes are getting instantiated. It would be nice to be able to keep the warning for real cases, but I'm not sure it's worth it with all the false positives.

[micpap25]

Not sure why anything is failing out now since all that has changed between now and the last succeeding CI was comments after the reversion...?

Oh, I see the notebooks need updating. I'll wait until there's agreement on what to do with abstract-class-instantiated.

[mpharrigan]

Yes, I think we should keep abstract-class-instantiated as a global skip and add a note to the pylint config that it produces too many false positives with our usage of attrs.

If we instantiate an abstract class, it will get caught at runtime (e.g. during a unit test)

[mpharrigan]

There's also a known flaky test at the moment #1657 , which is the pytest failure. I can re-run the CI in that case.

[mpharrigan]

Nice, thanks for getting these three checks fixed and enabled; and investigating the final one to be false-positives