Add guards for spatial conversion assignment warnings

[researchingadi]

Description

Adds targeted guards for a small subset of the Pylint use-before-assignment warnings reported in #512.

This PR focuses only on the spatial conversion helpers in:

• src/vector/_compute/spatial/rotate_quaternion.py
• src/vector/_compute/spatial/cross.py

The changes initialize conditionally assigned conversion callables before the coordinate-system branches and assert that each required callable was resolved before use. This keeps behavior unchanged for supported coordinate-system combinations while giving clearer failures if an unsupported branch reaches the conversion code.

Related issue: Part of #512

Checklist

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't any other open Pull Requests for the required change?
• Does your submission pass pre-commit? ($ pre-commit run --all-files or $ nox -s lint)
• Does your submission pass tests? ($ pytest or $ nox -s tests)
• Does the documentation build with your changes? ($ cd docs; make clean; make html or $ nox -s docs)
• Does your submission pass the doctests? ($ pytest --doctest-plus src/vector/ or $ nox -s doctests)

Before Merging

• Summarize the commit messages into a brief review of the Pull request.

[researchingadi]

Pre-commit passed all hooks except mypy.

The mypy failure appears to come from NumPy’s installed type stubs rather than this PR’s changes:

numpy/__init__.pyi:737: error: Type statement is only supported in Python 3.12 and greater

The rest of the checks in this pre-commit run passed, including ruff check and ruff format. Happy to adjust if there is a preferred way to handle this environment-specific mypy failure.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.74%. Comparing base (735f56c) to head (baab601).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #729      +/-   ##
==========================================
+ Coverage   87.72%   87.74%   +0.01%     
==========================================
  Files          96       96              
  Lines       11194    11212      +18     
==========================================
+ Hits         9820     9838      +18     
  Misses       1374     1374              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[researchingadi]

All project CI checks are passing now, including the Python 3.10–3.14 test matrix, docs build, notebooks, ROOT comparison tests, and Codecov reports 100% coverage on the modified lines.

The only remaining failure is pre-commit.ci, where mypy fails while parsing NumPy’s installed type stub:

numpy/__init__.pyi:737: error: Type statement is only supported in Python 3.12 and greater

Since this appears to be coming from the pre-commit environment / NumPy stub parsing rather than the files changed in this PR, I’ll wait for maintainer guidance before changing anything else.

[Saransh-cpp]

Hi @researchingadi, thanks for opening this!

I have fixed tests upstream. Did you run pylint locally with the checks activated to see if the lines now do not fail?

[Saransh-cpp]

Also, is pylint warning only because we did not initialize the variables outside of if-else blocks? If so, are these assert statements redundant?

[researchingadi]

Yes, the lint warning seems to come from the variables being assigned only inside conditional branches. The assertions were intended as runtime guards / clearer failures, matching the wording in #512, but they are not strictly needed just to silence pylint if the variables are initialized first. I’m happy to adjust based on your preference.

[Saransh-cpp]

It is a good practice to only make changes relevant to the issue. This should not be changed unless pre-commit is flagging and formatting it.

[researchingadi]

Agreed — I’ll revert this formatting-only change and keep the PR focused only on the pylint warning.

[Saransh-cpp]

Ditto with the extra lines.

[researchingadi]

Agreed — I’ll remove the extra blank lines unless formatting tools require them.

[researchingadi]

Thanks for the review!

I’ll clean up the formatting only changes and keep the diff limited to the pylint warning fix. I’ll also rerun pylint locally with the relevant checks enabled against the two touched files and report back with the result.

On the assertions: yes, the warning appears to come from pylint not being able to prove that the conditionally assigned conversion variables are always initialized before use. I added the assertions because #512 mentioned using assertions to give clearer failures on branches where those variables remain unset, but I can simplify/remove them if you prefer the PR to only address the lint warning through initialization.

[researchingadi]

Thanks! I ran pylint locally on the PR branch with the relevant checks enabled against the two touched files:

python -m pylint src/vector/_compute/spatial/cross.py src/vector/_compute/spatial/rotate_quaternion.py --enable=used-before-assignment,possibly-used-before-assignment

The result was:

Your code has been rated at 10.00/10

So the targeted used-before-assignment / possibly-used-before-assignment warnings are no longer reported for these files.

I’ll also clean up the formatting-only diff comments so the PR stays limited to the issue.

[researchingadi]

I pushed a cleanup commit addressing the review feedback.

I reverted the formatting-only dispatch_map change so the PR stays focused on the pylint assignment-warning fix. I also reran pylint locally on the PR branch with the relevant checks enabled:

python -m pylint src/vector/_compute/spatial/cross.py src/vector/_compute/spatial/rotate_quaternion.py --enable=used-before-assignment,possibly-used-before-assignment

Result:

Your code has been rated at 10.00/10

[Saransh-cpp]

Hi @researchingadi. Adding both the initialization and assertion statements sound good.

Your comments above are coming straight out of an LLM. Could you please mention in the PR description how much of this PR is AI generated and in what way was the AI used (full control, assisted development, ...). In any case, I would prefer talking to a human and not act as a mediator between you and your LLM.

I use LLMs very often to write code, and I am not discouraging the broader use. However, I can easily fix this issue with/without LLMs, but that is not the point. The point of these "good first issues" is to onboard people who are new to open-source, such that they can learn how open-source workflows work and how this particular repository works. Using an LLM to fix good first issues defeats the entire point (you, and not the LLM, should be learning open-source development from these issues).

I would be happy to review this further if there is minimal LLM usage . You are very welcome to pick a complex issue and solve that using LLMs, or become a maintainer of this repository (once you have worked on it enough and know your way around it without LLMs) and the use LLMs to fix issues.

PS: This is coming from the fact that I have to read/reply to your three LLM generated paragraphs, which wastes my time and contributes nothing to this repository.