Enable more ruff rules including A, DTZ, PGH and more

[DanielYang59]

Summary

• Enable more ruff rules
• Revert an accidental change in tests for io.lobster.inputs in Simplify case handling in lobster.inputs #3848 (comment)
• Other format tweaks

Enable more ruff rules

The following requires code change:

• rule family PGH for stricter typing
• rule family A to avoid shadowing of builtins

Caution

b1aa5bb and 50e9b7d changed multiple ValueError to more semantic TypeError to fix TRY004. this is breaking. however, downstream repercussions are expected to be small.

pinging @mkhorton @shyuep for approval

Future PR

• 7fac0b4 need to fix [Dev] datetime.datetime.utcnow() deprecated and replacement breaks strptime #3791
• Enable rule family S and NPY

Other format tweaks

• Replace match.group(x) with match[x]
• Replace array[0:x] slicing with array[:x]
• Replace already multi-lined dict() constructor with {} for speed (almost 2x-4x speedup).

[JaGeo]

@DanielYang59 could you trigger the atomate2 tests?

[DanielYang59]

@JaGeo Thanks for commenting. Can you let me how to achieve that? It should only be possible when pushing to master I guess?

pymatgen/.github/workflows/test.yml

Line 94 in 624e6eb

if: github.ref == 'refs/heads/master'

This PR is still a type annotation improvement, and I don't expect much code functionality change :)

[JaGeo]

@DanielYang59 ah okay. Then, we will see after merging! Thanks!

[DanielYang59]

@janosh I replaced some already multi-lined dictionary constructor dict() with {} for speed in 47d72f3, I know you don't want to introduce extra line, so I just replaced those that wouldn't do so.

From my side, the speed up is something I really want to have (2x - 4x, though being in the nanosecond level) :)

[DanielYang59]

@shyuep Can I have your approval on the following potentially breaking change/fix (change some ValueError to TypeError where the type doesn't match)? Thanks!

b1aa5bb and 50e9b7d changed multiple ValueError to more semantic TypeError to fix TRY004. this is breaking. however, downstream repercussions are expected to be small.

[shyuep]

If the errors are not the type that are meant to be caught, it is fine to change the error type. What I mean is that if the error is something that happens because of a bad use of code. Rather than something like catching an expected exception case and then handling it in some way.

[DanielYang59]

Thanks for your reply!

Yes I could confirm those are exceptions we raise instead of catch (try...except...), see b1aa5bb and 50e9b7d.

Mostly in the following pattern:

if not isinstance(variable, expected_type):
-    raise ValueError("variable should be in {expected_type}")
+    raise TypeError("variable should be in {expected_type}")

Still it could be breaking if any downstream operation replies on catching a ValueError, but I would consider this a fix as the wrong type of exception was raised in the first place.

[shyuep]

Thanks I have merged them,.

[DanielYang59]

Thanks!