The cmd module in the standard library has languished for many years.  In the mean time, third-party replacements for it have arisen.  Perhaps the most popular is cmd2 which seems to be actively maintained, provides upward compatibility from cmd along with many desirable new features, and is permissively licensed.

I suggest we consider at a minimum adding a "See also:" note referencing cmd2 to the cmd documentation in the Standard Library document, similar to what we do for the third-party "requests" module in the "urllib.request" documentation.

We could be even bolder and officially deprecate "cmd" and consider closing open enhancement issues for it on b.p.o.




https://pypi.org/project/cmd2/
https://cmd2.readthedocs.io/

I've asked on python-dev for comments:

https://mail.python.org/pipermail/python-dev/2018-April/152653.html

@ned.deily - are you proposing to officially deprecate it for 3.7?  If we're going to do it, let's do it now so we can remove it for 3.9.  It seems like a reasonable strategy to push folks toward cmd2 and clean up our stdlib.

@barry, I was thinking more of 3.8 but, sure, if there seems to be a consensus prior to 3.7.0b4 that deprecation is the right thing, we could do it in 3.7.

(Previously posted on Python-Dev.)

I think the documentation note is a good idea.

But I disagree with deprecating "cmd" unless it is actively falling
apart and no longer working, not just languishing with no feature
improvements. Just in the last week, I've been reminded twice that many
people using Python do so where they cannot just arbitrarily pip install
<whatever>, and if a library isn't in the std lib, they can't use it
without a lot of pain:

https://mail.python.org/pipermail/tutor/2018-April/112817.html

https://mail.python.org/pipermail/tutor/2018-April/112818.html

But cmd is used by pdb. Do you recommend we deprecate that too? (There are countless 3rd party alternatives, but I sure prefer to have it in the stdlib, so I can start debugging without first having to install a dependency.)

> cmd is used by pdb

Well, that's a pretty good reason for not removing cmd!  I really wasn't advocating its removal, just gently pushing users to use cmd2.  So perhaps we should only add a "See Also" like we do for urllib.request and close any new feature request issues?

>  See also: The Requests package is recommended for a higher-level
>  HTTP client interface.

I'm fine with linking to cmd2, we do that for some other modules too.
(Though I think it's somewhat arbitrary. E.g. do we link to requests
anywhere? Or to all the "better pdb" modules?)

FWIW, I've been teaching cmd to my clients for years and it has worked fine for them.

> (Though I think it's somewhat arbitrary.

Yes, it is.

> E.g. do we link to requests anywhere?

Yes:
https://docs.python.org/3/library/urllib.request.html

> Or to all the "better pdb" modules?)

Not that I'm aware of.

> FWIW, I've been teaching cmd to my clients for years and it has worked fine for them.

I'm not saying that cmd is bad; it's just that there have been suggested improvements over the years and many of those are already implemented in cmd2, which is supposed to be generally upward compatible from cmd.  (I don't know how accurate that is in practice.)  The main reason for bringing this up is that it seems to me that, rather than trying to duplicate effort by re-implementing new features for cmd that are already in cmd2, we should point at cmd2 for new users who want those features.  So, as Guido pointed out, with a customer of cmd in the std library (e.g. pdb), we shouldn't remove it.  But we can still set expectations that there aren't going to be new features in cmd.  Does that sound reasonable to everyone?

Well, is cmd2 stabilizing, or is it still changing at a rate too fast for inclusion in the stdlib? Does it perhaps have a mix of desirable and wacky features? Or could we just copy much of it into the stdlib as 'cmd'?

I'm a bit concerned about the idea that we should not upgrade stdlib modules because a better 3rd party alternative exists -- and I'm kind of assuming that those 3rd party module authors are also somewhat disappointed that their modules are not used to improve the stdlib. (PyPI not withstanding.)

Often (like in this case) there's just no chance of getting rid of the stdlib module, so we're just stuck with a duplication of functionality.

Note that every case is a bit different. But I'm not ready to give up on the idea that Python comes with batteries included. We should not let those batteries corrode and leak.

> But I'm not ready to give up on the idea that Python comes with batteries included. We should not let those batteries corrode and leak.

I totally agree with you.  And it would be great if cmd2 could be incorporated into the std lib as an updated cmd.  cmd seems to be largely abandoned in the std lib: looking at the commit history for it shows few changes in the past decade or so and I'm not aware that any current core developer feels ownership of it: I might be wrong.  But it certainly is true that cmd2 has seen much more activity recently than cmd has.  So I would think that the ideal solution would be for the cmd2 project to take ownership of cmd in the std library.  OTOH, it seems like we haven't always had good long-term results in the past when trying to bring existing third-party packages into the std lib.  But it could be worth trying again, if someone were willing to shepherd it.

>  cmd seems to be largely abandoned in the std lib: 

I'm not sure why the absence of bugs indicates abandonment.  We almost never touch defaultdict, in part because the code is straight-forward, tested, and not buggy.  If a bug were reported for cmd, I would be happy to work on it.

Hi, everybody!  I really appreciate the kind words about cmd2.

For several years now, Todd Leonhardt has been cmd2's primary maintainer, so I may be speaking out of turn.  But, before I wanted to let it get within screaming distance of the standard library, I would want to refactor it like mad; maybe even remove some features that were created more in a spirit of gee-whiz-I-can-do-this than real need.  Todd and I have worked a little on such a refactor, but even once we make time to actually complete it, that would make cmd2 by definition too unstable until the refactored version itself had earned some grey hair.

Also, cmd2 depends on pyparsing, which is itself unlikely to be in the standard library.

I think a "see also" list attached to standard library module docs would be great, and if this helps nucleate a decision about whether/how to do that for a bunch of modules, that would be great.

The cmd2 project is in the process of rapidly stabilizing, but it isn't quite there yet.

The other cmd2 core maintainers and I do have a bunch of refactoring planned over the next 6 to 8 months or so.  Right now @kotfu (Jared Crapo) is working on replacing pyparsing with shlex.  Since shlex is built into Python, that removes one 3rd party dependency.   In early September we plan on abandoning support for Python 2.7 for future releases which will enable us to remove dependencies on most of the other 3rd party libraries we currently depend upon and to dramatically clean the code up in numerous other ways.  The one third party dependency which will be left is pyperclip, but honestly that isn't very well maintained and I've been thinking about removing the functionality we use it for (clipboard copy/paste).

Another core cmd2 maintainer, @kmvanbrunt (Kevin Van Brunt) has been toying with the idea of forking it and creating a lighter and simpler version with a reduced feature set.  If it is something the core developers view as desirable, I think it would perhaps be a viable path forward to have the cmd2 maintainers take over maintenance of cmd and to move towards that becoming the lightweight reduced feature set version and cmd2 living on as the heavier weight more full featured extension of cmd (but many of the current features of cmd2 could be merged into cmd).