fix: allow None as argument for kbi_msg

[Sevrain1]

This commit addresses the issue of the keyboard interrupt message always printing, even in cases where it's not needed and is explicitly set to an empty string. This allows users to disable/replace said print when needed, while avoiding the redundant newline that's currently being printed when kbi_msg="".

(The commit also introduces the usage of TYPE_CHECKING to improve performance in the changed modules).

What is the problem that this PR addresses?

When kbi_msg="" and a KeyboardInterrupt is encountered, the program still calls the prompt's inner print() , and needlessly prints nothing while adding a redundant newline.
There is essentially no way for the user to disable the kbi_msg and its newline print, even when it's not needed and is breaking the design of the user's program.

...

How did you solve it?

I've added None an optional argument to kbi_msg.
If the user passes any string (even an empty one), it is printed along with a newline.
If the user passes in None, no text or newline will be printed.
This is fully backwards compatible with the current behaviour of kbi_msg, and simply allows users to pass in None to disable this unneeded print.

...

Checklist

• [ x] I have read the Contributor's Guide.
• [ x] I will check that all automated PR checks pass before the PR gets reviewed.

[Sevrain1]

Hi @tmbo,
Could you please review the PR and (if it's acceptable), approve the workflow run?

Thank you.

[kiancross]

Thanks for the PR @Sevrain1 - this fix looks good. Would you be able to add a unit test?

It's probably best to put any TYPE_CHECKING changes in another PR to keep this scoped to a single issue.

[Sevrain1]

@kiancross,
Unit tests added and previous typing imports restored.
Please review when you have time.

Thanks.

[Sevrain1]

@kiancross,
The Python 3.9 instances are failing since late 2024 in all PRs due to e401e8a introducing a Path | str type hint, which isn't supported in Python versions < 3.10.
Since Python 3.9 is already EOL, I think you should consider removing support for it in upcoming versions. Otherwise, I can fix the bug.

Also, I think the black/isort/flake checks can all be replaced by (the much faster) ruff check / ruff format.
poetry can also be replaced by the much simpler and faster uv tool.

[kiancross]

I was just working on the broken CI when you posted your comment. I've removed support for Python 3.9 in #472, and also fixed an issue with the docs build breaking.

Also, I think the black/isort/flake checks can all be replaced by (the much faster) ruff check / ruff format.
poetry can also be replaced by the much simpler and faster uv tool.

Worth creating an issue for this if you think it's something to be persued. Then others e.g., @tmbo can offer thoughts.

[kiancross]

I've rebased this onto latest master so that the CI fixes are incorporated. Assuming they all pass once run (there is a bit of an actions queue at the moment), I'll merge this in.

[kiancross]

Looks like the newly added tests are failing. I'll take a look in the next day or so unless you beat me to it!

[Sevrain1]

Yeah, I had a look at the logs but I still haven't figured out why they pass locally but fail in CI.
I'm using Python 3.14, but I'll install and test with 3.10 shortly. I''m working on a cleaner and more focused PR to replace this one.

BTW, why the formatting change in b72b39f? empty newlines aren't required between docstrings and function code, only between class docstrings and class code (according to black).

[kiancross]

BTW, why the formatting change in b72b39f? empty newlines aren't required between docstrings and function code, only between class docstrings and class code (according to black).

The style test was failing; that was the change output by Black. I'm no expert, but I believe it is expected:

Black won’t insert empty lines after function docstrings unless that empty line is required due to an inner function starting immediately after.

[Sevrain1]

Ah I see, you're absolutely right about newlines before inner functions. Thanks.
I've also reproduced the CI issue locally. Working to resolve it now.

[Sevrain1]

Hi @kiancross,
The root cause of the test failures is the shadowing of the questionary.prompts module by its inner prompt() function.
This prevents patching any of the module's functions for unit testing, as well as completely breaking valid import statements such as from questionary import prompt.

I've submitted the following PR to address the issue: #483