Repository navigation
optparse module does not emit DeprecationWarning #69707
Description
| BPO | 25521 |
|---|---|
| Nosy | @bitdancer, @vadmium, @serhiy-storchaka, @matrixise, @johnthagen |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2015-10-30.23:22:34.136>
labels = ['type-bug', 'library']
title = 'optparse module does not emit DeprecationWarning'
updated_at = <Date 2020-04-29.15:12:36.841>
user = 'https://github.com/johnthagen'bugs.python.org fields:
activity = <Date 2020-04-29.15:12:36.841>
actor = 'John Hagen'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2015-10-30.23:22:34.136>
creator = 'John Hagen'
dependencies = []
files = ['40921']
hgrepos = []
issue_num = 25521
keywords = ['patch']
message_count = 21.0
messages = ['253768', '253779', '253788', '253808', '253838', '253841', '253842', '253857', '253858', '253869', '253874', '253881', '253884', '253889', '253890', '254051', '254059', '254061', '254063', '265061', '367655']
nosy_count = 6.0
nosy_names = ['r.david.murray', 'SilentGhost', 'martin.panter', 'serhiy.storchaka', 'matrixise', 'John Hagen']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue25521'
versions = ['Python 3.4', 'Python 3.5', 'Python 3.6']
Activity
johnthagen commentedon Oct 30, 2015
According to the Python docs, optparse has been deprecated since Python 3.2, but it does not emit a DeprecationWarning when imported Python 3.2+.
https://docs.python.org/3/library/optparse.html
PyCharm can uses these DeprecationWarnings to provide helpful alerts the user: https://youtrack.jetbrains.com/issue/PY-16589
vadmium commentedon Oct 31, 2015
Under <https://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse\> it says “Importing optparse will issue a PendingDeprecationWarning” (not DeprecationWarning!), however even this does not appear to be the case. Maybe somebody forgot to do this, or maybe somebody decided not to do this; I dunno.
bitdancer commentedon Oct 31, 2015
Whether someone decided not to do it originally or not, it is probably a good idea to do it (as a DeprecationWarning, IMO), if someone wants to propose a patch. The module isn't receiving maintenance any longer. (Not that it couldn't, but no one is motivated to do so.)
johnthagen commentedon Oct 31, 2015
First time trying to contribute to the Python standard library.
I attached a patch that is modeled off the deprecated imp module. The DeprecationWarning message is taken from the Python docs: https://docs.python.org/3/library/optparse.html
vadmium commentedon Nov 1, 2015
I don’t have an opinion on pending vs non-pending warning.
I think there are quite a few standard library modules that use “optparse” that will emit a warning as a result of this change. And the test suite probably needs patching to suppress the warning while testing the “optparse” module. Perhaps you could look at the code touched by revisions 5877c191b76e (imp warning upgrade) and 3f924cb4c3eb (test suite update) for inspiration.
SilentGhost commentedon Nov 1, 2015
Modules that use optparse: calendar (bpo-18973 has patch), uu (seems trivial to change), test_decimal (trivial too), profile, cprofile
Tools: strginbench, ccbench, iobench
Neither of the changes are particularly tricky it seems.
matrixise commentedon Nov 1, 2015
Already proposed to move to argparse for the existing modules, see this issue: http://bugs.python.org/issue25475
For the calendar module, there are two issues with two patches. http://bugs.python.org/issue25499 and http://bugs.python.org/issue18973
I can write a patch to use argparse instead of optparse.
serhiy-storchaka commentedon Nov 1, 2015
There is a difference between optparse and other deprecated module. Other modules are deprecated if they are too buggy or bad-designed to be fixed and there are stable standard or third-party modules that provides similar functionality. But looking on a number of open issues for argparse it seems that optparse is more stable and has less bugs than more powerful argparse.
Having experience with converting many modules from optparse to argparse or reviewing converting patches, I can say that not always the conversion can be done without loss. For example there is a difference in formatting descriptions.
I think that optparse should be supported in the stdlib for very long time. -1 for non-pending warning. Don’t have an opinion about pending warning.
serhiy-storchaka commentedon Nov 1, 2015
And it looks there was a special decision to not deprecate optparse.
bitdancer commentedon Nov 1, 2015
My sense is that most of the open argparse bugs are *because* of the increased power (that is, they aren't, with a few exceptions, in the fundamental bits that optparse does as well). And the issues are open because no one is maintaining that module, either :(. There is one non-committer who has done a lot of work on the patches, we should probably evaluate offering him commit privileges.
That said, I don't have a strong opinion on the deprecation-or-not myself.
johnthagen commentedon Nov 1, 2015
@martin.panter My new patch fixes Lib/test_optparse.py by suppressing the warning like test_imp does as you suggested.
@serhiy.storchaka I don't have a strong preference that it be a DeprecationWarning vs. PendingDeprecationWarning since to me, both get the point across to the end-user to avoid it. I do, however, feel that it is important raise some kind of warning since it seems clear from the docs that is deprecated.
In my new patch I changed the type of warning to a PendingDeprecationWarning, as there seems to be at least some notion that optparse is a special case. I don't have a strong opinion about which type of deprecation warning is used.
My new patch works when test_optparse.py is run with -Werror on 3.6.0a0.
vadmium commentedon Nov 1, 2015
Serhiy, do you have a link or more information about this decision? Looking around at previous discussions, this is what I found: limiting to pending deprecation: <https://www.marc.info/?l=python-dev&m=126676001222439&w=2\>; not bothering with any code warning: <https://www.marc.info/?l=python-dev&m=130113240102821&w=2\>. But the PEP was never updated as suggested in that last thread.
FWIW I have never used optparse. I do find argparse useful, but having bugs due to being “powerful” is not necessarily a good thing.
serhiy-storchaka commentedon Nov 1, 2015
No, I have not more information. My supposition is based on indirect evidence in msg225052. I suppose there was more recent discussion in 2014.
bitdancer commentedon Nov 2, 2015
I can't remember the timing...was that PEP accepted before we made DeprecationWarnings off by default? It sounds like it probably was, based on the phrasing.
bitdancer commentedon Nov 2, 2015
Oh, and as far as bugs because it is powerful...optparse has had time to have its bugs fixed, so having bugs in the newer features of argparse is not surprising, really. We just need to get the fixes committed.
johnthagen commentedon Nov 4, 2015
Is there any consensus on how to move forward with this? I feel there are at least 4 options:
Do nothing.
Pro: No work.
Con: It feels misleading to the user since the docs clearly state it's deprecated. Some users (especially new ones) may miss the fact they should really be using argparse.
Throw PendingDeprecationWarning from optparse, and simply suppress it where it's used.
Pro: Not as much work. Users of optparse are properly notified.
Con: Kicks the can down the road for someone else to have to eventually port off of optparse.
Throw PendingDeprecationWarning from optparse and port stdlib modules to argparse.
Pro: Seems like the "purest" solution at least from what is indicated in docs that it will no longer be supported. Users of optparse are properly notified.
Con: Most amount of work. argparse has some bugs that need to be patched.
Some combination of 2) and 3) where some modules are suppressed and others are ported.
bitdancer commentedon Nov 4, 2015
I vote for (4): (2) with a helping of (3). That is, add the warning, but don't try to port all the stdlib modules to argparse beforehand. Those should be addressed one by one, as I mentioned in another issue.
serhiy-storchaka commentedon Nov 4, 2015
I vote for gradual porting stdlib modules and scripts to argparse and fixing found problems, but doesn't touch optparse right now. We have enough time before 3.6 feature freezing.
matrixise commentedon Nov 4, 2015
+1 with @serhiy.storchaka
johnthagen commentedon May 7, 2016
With 3.6.0a1 scheduled just around the corner, is there consensus about how to begin this? I just signed the contributor agreement, so I should be able to try to help if we have a plan on how to divide the work.
johnthagen commentedon Apr 29, 2020
With PEP-594 (https://www.python.org/dev/peps/pep-0594/) in the pipeline, is it time that optparse correctly emits DeprecationWarnings?
gpshead commentedon Feb 16, 2023
optparseis under "Modules to keep" in PEP-594. It is not going away.