This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Suggest third-party cmd2 module as alternative to cmd
Type: Stage:
Components: Documentation Versions: Python 3.8
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: docs@python Nosy List: Catherine.Devlin, barry, catherinedevlin, docs@python, ethan.furman, gvanrossum, lukasz.langa, mcepl, ned.deily, rhettinger, steven.daprano, tleonhardt
Priority: normal Keywords:

Created on 2018-04-05 18:51 by ned.deily, last changed 2022-04-11 14:58 by admin.

Messages (16)
msg315002 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2018-04-05 18:51
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/
msg315035 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2018-04-06 22:04
I've asked on python-dev for comments:

https://mail.python.org/pipermail/python-dev/2018-April/152653.html
msg315040 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2018-04-06 22:51
@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.
msg315041 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2018-04-06 22:56
@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.
msg315047 - (view) Author: Steven D'Aprano (steven.daprano) * (Python committer) Date: 2018-04-07 00:30
(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
msg315048 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2018-04-07 01:26
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.)
msg315050 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2018-04-07 01:35
> 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.
msg315051 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2018-04-07 01:38
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?)
msg315052 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2018-04-07 01:40
FWIW, I've been teaching cmd to my clients for years and it has worked fine for them.
msg315053 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2018-04-07 01:43
> (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.
msg315054 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2018-04-07 01:56
> 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?
msg315059 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2018-04-07 02:17
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.
msg315060 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2018-04-07 02:31
> 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.
msg315061 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2018-04-07 03:04
>  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.
msg315062 - (view) Author: Catherine Devlin (catherinedevlin) * Date: 2018-04-07 03:58
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.
msg315063 - (view) Author: Todd Leonhardt (tleonhardt) Date: 2018-04-07 05:16
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).
History
Date User Action Args
2022-04-11 14:58:59adminsetgithub: 77414
2018-04-09 16:44:19ethan.furmansetnosy: + ethan.furman
2018-04-08 16:08:37mceplsetnosy: + mcepl
2018-04-07 05:16:30tleonhardtsetnosy: + tleonhardt
messages: + msg315063
2018-04-07 03:58:32catherinedevlinsetnosy: + catherinedevlin
messages: + msg315062
2018-04-07 03:04:06rhettingersetmessages: + msg315061
2018-04-07 02:31:49ned.deilysetmessages: + msg315060
2018-04-07 02:17:58gvanrossumsetmessages: + msg315059
2018-04-07 01:56:20ned.deilysetmessages: + msg315054
2018-04-07 01:43:19ned.deilysetmessages: + msg315053
2018-04-07 01:40:34rhettingersetnosy: + rhettinger
messages: + msg315052
2018-04-07 01:38:30gvanrossumsetmessages: + msg315051
2018-04-07 01:35:14ned.deilysetmessages: + msg315050
2018-04-07 01:26:10gvanrossumsetnosy: + gvanrossum
messages: + msg315048
2018-04-07 00:30:59steven.dapranosetnosy: + steven.daprano
messages: + msg315047
2018-04-06 22:56:39ned.deilysetmessages: + msg315041
2018-04-06 22:51:42barrysetnosy: + barry
messages: + msg315040
2018-04-06 22:04:03ned.deilysetmessages: + msg315035
2018-04-05 18:51:29ned.deilycreate