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.

Author ned.deily
Recipients Catherine.Devlin, barry, docs@python, gvanrossum, lukasz.langa, ned.deily, rhettinger, steven.daprano
Date 2018-04-07.01:56:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1523066180.1.0.682650639539.issue33233@psf.upfronthosting.co.za>
In-reply-to
Content
> 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?
History
Date User Action Args
2018-04-07 01:56:20ned.deilysetrecipients: + ned.deily, gvanrossum, barry, rhettinger, steven.daprano, docs@python, lukasz.langa, Catherine.Devlin
2018-04-07 01:56:20ned.deilysetmessageid: <1523066180.1.0.682650639539.issue33233@psf.upfronthosting.co.za>
2018-04-07 01:56:20ned.deilylinkissue33233 messages
2018-04-07 01:56:19ned.deilycreate