Fix #18: Replace print() with logging

[cmoyates]

Summary

• Add logger = logging.getLogger(__name__) to inference_engine.py and model_transformer.py
• Replace all print() calls with appropriate logger.info() / logger.warning() calls
• 9 print statements replaced across both files

Note: Untested — checkpoint loading paths are mocked in unit tests. Verified lint/format pass.

Closes #18

Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com

[nikopueringer]

print is actually preferred to logging! Thanks for the submission, but I'm going to keep the current function.

[mueslimak3r]

print is actually preferred to logging! Thanks for the submission, but I'm going to keep the current function.

You can both still use print() and write to stdout or stderr (for logging warnings/errors).

import sys
print("my warning or error", file=sys.stderr)

[nikopueringer]

gotcha. perhaps i misunderstood this. Which is likely. Could one of you help clarify the function of this to me?

[cmoyates]

I originally made it as a fix for this issue: #18

[cheesecakegangster]

Could one of you help clarify the function of this to me?

you can use it the same way as a print statement but get more control over the printed output. say you have a status update or a progress bar, that could be a logging.info, and say you want detailed info from what every line in a function is doing, then you would use logging.debug

it can of course also write logs, could be useful if you have a lot of functions that are very verbose and scrolling up in the terminal is a lost cause

in his commit it's more of a future proofing thing to encourage the use of the logging module, he's only replaced print with logging.info in all the files. functionally it will be the same if you commit this

[cheesecakegangster]

unnecessary formatting if you ask me

[shezmic]

Code Review — Community Contribution

Hey @cmoyates, the intent here is solid — print() → logger is a good cleanup. But there's an important consideration about the files being changed:

---

Files touched are in the No-Go Zone

Per the project's CONTRIBUTING.md, CorridorKeyModule/inference_engine.py and CorridorKeyModule/core/model_transformer.py are listed as absolute no-go zones for contributors:

"Changing any layer breaks checkpoint weight loading" (model_transformer.py)
"Resizing, normalisation, and tensor handling are exactly calibrated to the model's training distribution" (inference_engine.py)

Now, these logging changes are technically safe — they don't touch model logic, weight loading, tensor handling, or any functional code. They're purely I/O (print → logger). So the spirit of the no-go rule (don't break model behaviour) isn't violated. But the letter of the rule says these files are off-limits.

This is ultimately a maintainer call. The changes themselves are correct:

• print(f"...") → logger.info("...", args) is proper parameterized logging (avoids string formatting when log level is filtered)
• [Warning] prefixed prints → logger.warning() is appropriate severity routing
• The corridorkey_cli.py whitespace fixes are harmless cleanup

Suggestion

If the maintainer is open to it, this could merge as-is — the changes are safe and improve log hygiene. But the PR description should explicitly acknowledge the no-go zone exception and explain why it's safe (logging-only, no functional changes). That makes it easier for the maintainer to approve.

The --no-verify note in the PR description ("Untested — checkpoint loading paths are mocked in unit tests") is honest, but worth running the full test suite to confirm: uv run pytest -v should pass with zero failures.