refactor: improve type hints and code organization in streaming_util …

[Dhie-boop]

This addresses Ruff linting violations (I001, UP035, and related rules) in two utility files without changing any runtime behavior.

Fixes #
Before it was like this

• from typing import Optional, Dict — deprecated imports
• Optional[str], Dict[str, Any] — old type annotation syntax
• Imports unsorted (e.g., import json after import requests)
• Functions missing type hints: def set_apollo_port(p):
• Magic numbers in comparisons: if len(parts) >= 2:
• Missing trailing commas in multi-line dicts
• Unused import json in util.py
• Unnecessary global apollo_port in apollo() functioin
• Trailing whitespace on blank lines

These are the new changes

• Use built-in dict and x | None syntax
• Sorted imports per isort
• All functions/methods have type hints
• Named constants Scoped_adaptor_min_parts = 3
• Trailing commas added to all multi-line dicts
• Removed unused imports and dead code
• Clean whitespace, proper EOF newline

Ruff command that help:
ruff check . --fix

All changes are static analysis only, no runtime behavior affected and code logic change.

AI Usage

Please disclose how you've used AI in this work (it's cool, we just want to know!):

• Code generation (copilot but not intellisense)
• Learning or fact checking
• Strategy / design
• Optimisation / refactoring
• Translation / spellchecking / doc gen
• Other
• I have not used AI

You can read more details in our Responsible AI Policy

[Dhie-boop]

@josephjclark Let me know if any changes are needed
happy to adjust.

[Dhie-boop]

Hi, I noticed the PR was closed and just wanted to check if the change isn’t needed at the moment or if there’s something I should adjust. I’m happy to revise based on project preferences. Thanks!

[josephjclark]

Oh that's wierd - it says I closed it too 🤔

Not sure what happened there - maybe an errant mouse click. @hanna-paasivirta is going to get this merged for you today!

[josephjclark]

Fine to accept this but for future reference it's really not necessary. These aren't what I call "magic numbers" and are fine to leave in-situ.

The structure of adaptor specifiers won't change any time soon and I don't particularly think these constants make the code easier to read?

@hanna-paasivirta we can accept this, unless you have a strong opinion, but this isn't a pattern I want to see enforced across the codebase

[josephjclark]

What does this # noqa comment mean?

[Dhie-boop]

This is a Ruff rule suppression comment.
It tells the linter to ignore a specific rule on that line.
So ANN401 is a Ruff rule code.

So the comment tells Ruff Ignore the ANN401 rule for this line.
So that's why it is there.

[josephjclark]

Thanks! And what is it we're ignoring here - the Any return type?

We don't use Ruff as you can tell. I thought were were running Black or Prettier (or both?!) but I'll have to check into that.

Happy to accept code improvements but unless we're going to adopt Ruff as a standard (and I'll speak to the team about this) I don't think we should have Ruff-specific comments in the code.

[Dhie-boop]

Thanks so much for the feedback.

Yeah we are suppressing the Any return type that's why we use that comment there. from the noise it maybe when we run ruff check. However, the project does us both Ruff for linter and Black for python formatter with comprehensive rule set configured in project dependencies in pyproject.toml including ANN (flake8- annotations).

So I may say the # noqa comment are appropriate for this codebase according to modern Python standards.
If it should not be there I'm happy to adjust it.
And I'm also happy and open with what we're going to adopt.