Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA).

Recognized GitHub username

We couldn't find a bugs.python.org (b.p.o) account corresponding to the following GitHub usernames:

@dan1994

This might be simply due to a missing "GitHub Name" entry in one's b.p.o account settings. This is necessary for legal reasons before we can look at this contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

You can check yourself to see if the CLA has been received.

Thanks again for the contribution, we look forward to reviewing it!

Where should such a discussion be held, and how would I contact the core developers?
In any case, at least for the time being, I preserve existing APIs, and only partition into functions (although in my opinion there are some changes that will benefit the module).

Meanwhile I'll spill some of my thoughts and questions:

So far I've been adding changes in ways that should not break the existing API (hopefully). I've been careful not to change the behavior, and focused on giving meaningful names and dividing into functions so the module will be more readable.

I do have a few things I would very much like to change, but would love some professional opinion about:

• The Single Responsibility Principle dictates that this class should be split to more classes. The responsibilities I identify and think should have their own classes are:
  • Line parsing
  • Completion
  • Help printing
• Given that I split into classes I'm not sure how and where should I place them.
  • Should they be in separate files to leave the cmd.py file cleaner (this will practically create more modules)?
  • Should they be in the same file but not listed in __all__ (leaving cmd.py pretty bloated)?
  • Should they be inner classes of cmd (again leaving cmd.py pretty bloated)?
• In the current situation, ! is an alias to shell, but there's no default implementation to do_shell. This causes an ugly edge case. I would like to provide a default do_shell implementation that prints that there's no shell implementation.
• In general, a nice feature would be to add aliases to commands, but this should probably be handled in a separate issue.
• I wonder if there's a reason (or if it will make any difference) for variables such as prompt, intro and so forth not to be instantiated in __init__ as members.
• I did not yet refactor the complete function, because I can't test it without readline (that doesn't come with python by default). Even if I installed readline locally, I can't add tests, since the CI (and other people) won't have readline installed. Is there a way around this?