Re: [Python-Dev] Soliciting comments on the future of the cmdmodule (bpo-33233)

2018-04-08 Thread Steven D'Aprano 
On Sat, Apr 07, 2018 at 06:53:44PM +, Brett Cannon wrote:

> > Raymond has stated that he is happy to work on it if there are any bugs
> > reported on it, and if he's not available, I'm sure somebody will.
> 
> Actually Raymond said he *teaches* the module, not that he wanted to
> maintain it. And I definitely would not assume that someone will pick up to
> help maintain any module in the stdlib.

Raymond said:

"If a bug were reported for cmd, I would be happy to work on it."

https://bugs.python.org/issue33233#msg315061


-- 
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Soliciting comments on the future of the cmdmodule (bpo-33233)

2018-04-07 Thread Brett Cannon 
On Sat, 7 Apr 2018 at 02:09 Steven D'Aprano  wrote:

> On Sat, Apr 07, 2018 at 09:30:05AM +0100, Paul Moore wrote:
> > On 7 April 2018 at 04:13, Steve Dower  wrote:
> > > Better to deprecate it before it becomes broken, in my opinion.
>
> That argument could be applied to everything in the std lib.
>

Sure, but we all know none of this is as black-and-white as it's being
portrayed either.


>
>
> > > Having someone willing and able to review and merge changes is the best
> > > criteria for whether a module is still supported or not.
>
> I don't think "best" is justified -- and certainly it is not the *only*
> criteria.
>

But you have to admit it is an important one.


>
> Modules can become stable simply because they have no known bugs and no
> new feature requests. Stable doesn't mean useless, and the urge to
> consider anything that isn't being regularly fiddled with as "obsolete"
> is a tendency to be resisted.
>
> If the module isn't broken, there's no need to fix it. That's a GOOD
> thing, not a reason to dump a perfectly good, useful, working module.
>

I think part of the question is whether the module is also used enough to
justify putting in scarce core dev time to maintain it.


>
> Raymond has stated that he is happy to work on it if there are any bugs
> reported on it, and if he's not available, I'm sure somebody will.


Actually Raymond said he *teaches* the module, not that he wanted to
maintain it. And I definitely would not assume that someone will pick up to
help maintain any module in the stdlib.


> And
> if not, well, we don't have any sort of performance guarantees on fixes:
> sooner or later, *somebody* will provide a patch.


Assuming someone does, do we really want to say, "eh, it's buggy but we can
wait over 7 years for a fix" (the oldest open issue on b.p.o is from August
2009: https://bugs.python.org/issue6686). And even if they do, that doesn't
mean someone will have the time or inclination to review it and eventually
see it through to being merged.


> That's the beauty of
> the Open Source model. There are plenty of potential upstream
> contributors who could contribute a patch.
>

But potential does not necessarily translate to action.


>
>
> > I think there's a difference between not being willing to add
> > enhancements, and not fixing bugs. The issue that originally triggered
> > this discussion was an enhancement request, and I don't think it's
> > unreasonable to declare cmd as "stable - no further enhancements will
> > be made or accepted" while still considering it as supported for
> > bugfixes.
>
> Its not an unreasonable position to take, but I don't think it is
> justified in this case. The cmd module is not something so arcane or
> complicated that it requires a specialist to maintain it. Its about 400
> lines, including blank lines and doc strings, with a single class and
> around twenty methods.
>
> Wasn't one of the major reasons for moving to git and Github to
> make it easier for non-core devs to contribute?


Actually the major reason was to make it easier for core devs to review
contributions. Easing the workflow for outside contributors was a side
benefit.


> A module as stable and
> simple as cmd seems to me to be the ideal place for people to begin
> contributing, whether it is fixing bugs or contributing any
> (hypothetical) feature enhancements.
>

Perhaps, but that assumes someone wants that job. ;)


>
> I don't think we need do anything here: so long as there is a core
> developer willing to review any PRs, and so long as new enhancements go
> through the same approval process on the bug tracker and/or Python-
> Ideas, I don't think we need to single cmd out as deprecated or "no new
> features".
>

Those two "so long as" parts are I think the key reason Ned brought this up.


>
> This isn't gopher, or something with serious unfixable security
> vulnerabilities. It works. What more needs to be said?
>

I think this all ties back to the usual discussion we have when it comes to
the stdlib: what  is the bar for what should be in there because nothing is
maintenance-free?

The cmd module itself has plenty of commits that were just standard code
maintenance changes:
https://github.com/python/cpython/commits/master/Lib/cmd.py . All of that
eats up time over the 26 years of the module's existence. And feature
enhancements are not free either even if you don't review the PR because
even if you don't review them you still have to peruse the PR title to make
the decision not to review it, which once again is a small amount of time
in isolation but adds up at a macro level.

We all have a limited amount of time to contribute, especially when we are
almost all spending personal time on this project. And no matter how
trivial a module is to keep around, it is not a non-zero amount of time for
the group all-up, even if we all collectively choose to ignore it in hopes
someone comes forward to help out.

And I would

Re: [Python-Dev] Soliciting comments on the future of the cmdmodule (bpo-33233)

2018-04-07 Thread Steven D'Aprano 
On Sat, Apr 07, 2018 at 09:30:05AM +0100, Paul Moore wrote:
> On 7 April 2018 at 04:13, Steve Dower  wrote:
> > Better to deprecate it before it becomes broken, in my opinion.

That argument could be applied to everything in the std lib.


> > Having someone willing and able to review and merge changes is the best
> > criteria for whether a module is still supported or not.

I don't think "best" is justified -- and certainly it is not the *only* 
criteria.

Modules can become stable simply because they have no known bugs and no 
new feature requests. Stable doesn't mean useless, and the urge to 
consider anything that isn't being regularly fiddled with as "obsolete" 
is a tendency to be resisted.

If the module isn't broken, there's no need to fix it. That's a GOOD 
thing, not a reason to dump a perfectly good, useful, working module.

Raymond has stated that he is happy to work on it if there are any bugs 
reported on it, and if he's not available, I'm sure somebody will. And 
if not, well, we don't have any sort of performance guarantees on fixes: 
sooner or later, *somebody* will provide a patch. That's the beauty of 
the Open Source model. There are plenty of potential upstream 
contributors who could contribute a patch.


> I think there's a difference between not being willing to add
> enhancements, and not fixing bugs. The issue that originally triggered
> this discussion was an enhancement request, and I don't think it's
> unreasonable to declare cmd as "stable - no further enhancements will
> be made or accepted" while still considering it as supported for
> bugfixes.

Its not an unreasonable position to take, but I don't think it is 
justified in this case. The cmd module is not something so arcane or 
complicated that it requires a specialist to maintain it. Its about 400 
lines, including blank lines and doc strings, with a single class and 
around twenty methods.

Wasn't one of the major reasons for moving to git and Github to 
make it easier for non-core devs to contribute? A module as stable and 
simple as cmd seems to me to be the ideal place for people to begin 
contributing, whether it is fixing bugs or contributing any 
(hypothetical) feature enhancements.

I don't think we need do anything here: so long as there is a core 
developer willing to review any PRs, and so long as new enhancements go 
through the same approval process on the bug tracker and/or Python- 
Ideas, I don't think we need to single cmd out as deprecated or "no new 
features".

This isn't gopher, or something with serious unfixable security 
vulnerabilities. It works. What more needs to be said?



-- 
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Soliciting comments on the future of the cmdmodule (bpo-33233)

2018-04-07 Thread Paul Moore 
On 7 April 2018 at 04:13, Steve Dower  wrote:
> Better to deprecate it before it becomes broken, in my opinion.
>
> Having someone willing and able to review and merge changes is the best
> criteria for whether a module is still supported or not.

I think there's a difference between not being willing to add
enhancements, and not fixing bugs. The issue that originally triggered
this discussion was an enhancement request, and I don't think it's
unreasonable to declare cmd as "stable - no further enhancements will
be made or accepted" while still considering it as supported for
bugfixes. If significant bugs in cmd are remaining unfixed, then
that's a somewhat different matter.

The fact that pdb uses it, and the advantage of having something in
the stdlib for users without easy access to "pip install", *plus* the
general principle of "if it isn't broken, don't fix it" make me feel
that the best solution would be to document that extended replacements
such as cmd2 exist in PyPI, but retain cmd as supported but not (in
principle) accepting further enhancements (leaving the door open for
interested core devs to merge enhancements on a case by case basis if
they have a personal interest in doing so).

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Soliciting comments on the future of the cmdmodule (bpo-33233)

2018-04-06 Thread Steve Dower 
Better to deprecate it before it becomes broken, in my opinion.

Having someone willing and able to review and merge changes is the best 
criteria for whether a module is still supported or not.

Top-posted from my Windows phone

From: Raymond Hettinger
Sent: Friday, April 6, 2018 18:55
To: Ned Deily
Cc: Python-Dev@Python. Org
Subject: Re: [Python-Dev] Soliciting comments on the future of the cmdmodule 
(bpo-33233)



> On Apr 6, 2018, at 3:02 PM, Ned Deily  wrote:
> 
> We could be even bolder and officially deprecate "cmd" and consider closing 
> open enhancement issues for it on b.p.o."

FWIW, the pdb module depends on the cmd module.

Also, I still teach people how to use cmd and I think it still serves a useful 
purpose.  So, unless it is considered broken, I don't think it should be 
deprecated.


Raymond




___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/steve.dower%40python.org

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com