Using FutureWarning for last version before deletion.
Hi, folks. Now Python 3.11 development is open and I am removing some deprecated stuffs carefully. I am considering `configparser.ParseError.filename` property that is deprecated since Python 3.2. https://github.com/python/cpython/blob/8e8307d70bb9dc18cfeeed3277c076309b275... My random thoughts about it: * It has been deprecated long enough. * But the maintenance burden is low enough. * If we don't remove long deprecated stuff like this, Python 4.0 will be a big breaking change. My proposal: * Change DeprecationWarning to FutureWarning and wait one more version. * DeprecationWarning is suppressed by default to hide noise from end users. * But sudden breaking change is more annoying to end users. I am not proposing to change PEP 387 "Backwards Compatibility Policy". This is just a new convention. Another idea: * Stop suppressing DeprecationWarning by default * Use at least one PendingDeprecationWarning and one DeprecationWarning. * More than two PendingDeprecationWarning periods is preferred. How do you think? -- Inada Naoki <songofacandy@gmail.com>
On 10. 05. 21 10:53, Inada Naoki wrote:
Test tools should treat DeprecationWarning as error by default [0][1]. So even if end users don't really see it, I don't consider it "hidden". Waiting one more release sounds reasonable to me, but for a slightly different reason: the warning should list the version the feature will be removed in: "3.12" rather than "future versions". Another idea: would it be worth it to create "What's new" pages for 3.12 and 3.13 already and fill them with planned removals? (Of course they'd need to be de-emphasized in the table of contents.) [0]: https://www.python.org/dev/peps/pep-0565/#recommended-filter-settings-for-te... [1]: https://docs.pytest.org/en/latest/how-to/capture-warnings.html#deprecationwa...
On Tue, May 11, 2021 at 5:30 PM Petr Viktorin <encukou@gmail.com> wrote:
Test tools should treat DeprecationWarning as error by default [0][1]. So even if end users don't really see it, I don't consider it "hidden".
*should* is not *do*. For example, nosetests don't show DeprecationWarning. And there are many scripts without tests. So it is hidden for some people. -- Inada Naoki <songofacandy@gmail.com>
On 11. 05. 21 11:08, Inada Naoki wrote:
Sadly, there's not much we can do for users of nose. Nose itself is only tested with Python 3.5 and below. I'm aware that there are scripts without tests. But maybe letting them suddenly break is the right balance between letting people know and annyoing everyone with unactionable warnings. If DeprecationWarning is not enough, then we should be having a wider discussion, and PEP 387 should change. This particular issue should not be an exception to the process.
On Tue, 11 May 2021, 7:57 pm Petr Viktorin, <encukou@gmail.com> wrote:
Scripts (with or without tests) have gone back to showing deprecation warnings by default since 3.7: https://www.python.org/dev/peps/pep-0565/ If DeprecationWarning is not enough, then we should be having a wider
discussion, and PEP 387 should change. This particular issue should not be an exception to the process.
The limitations section of PEP 565 covers several known problems even with the 3.7+ status quo: https://www.python.org/dev/peps/pep-0565/#limitations-on-pep-scope Most notably, unit test doesn't catch import time or compile time deprecation warnings, and it doesn't catch deprecations in subprocesses. Another case that came up in this thread was support libraries that are tested with warnings treated as errors, but: * the test runner still doesn't enable all warnings (e.g. nose projects that never migrated to nose2) * the project isn't covered as a dependency by any *other* project's test suites that are stricter about avoiding deprecation warnings in their code and the code they use And, of course, projects that don't treat warnings as errors in their tests will get a green tick from CI systems no matter how many warnings they emit. If we wanted to go back to enabling DeprecationWarning by default across the board, I think we could only reasonably do that if we provided an easier to use "hide all warnings except the ones I specifically opt in to seeing" API like the one mentioned at the end of PEP 565: https://bugs.python.org/issue32229 As currently written, that API proposal would flip the ergonomics problem though - while ensuring the warnings system was configured early enough to capture compile time and import time warnings would be up to the application, being able to easily propagate the config change to subprocesses would need to be part of the new API design. Cheers, Nick.
On 10. 05. 21 10:53, Inada Naoki wrote:
Test tools should treat DeprecationWarning as error by default [0][1]. So even if end users don't really see it, I don't consider it "hidden". Waiting one more release sounds reasonable to me, but for a slightly different reason: the warning should list the version the feature will be removed in: "3.12" rather than "future versions". Another idea: would it be worth it to create "What's new" pages for 3.12 and 3.13 already and fill them with planned removals? (Of course they'd need to be de-emphasized in the table of contents.) [0]: https://www.python.org/dev/peps/pep-0565/#recommended-filter-settings-for-te... [1]: https://docs.pytest.org/en/latest/how-to/capture-warnings.html#deprecationwa...
On Tue, May 11, 2021 at 5:30 PM Petr Viktorin <encukou@gmail.com> wrote:
Test tools should treat DeprecationWarning as error by default [0][1]. So even if end users don't really see it, I don't consider it "hidden".
*should* is not *do*. For example, nosetests don't show DeprecationWarning. And there are many scripts without tests. So it is hidden for some people. -- Inada Naoki <songofacandy@gmail.com>
On 11. 05. 21 11:08, Inada Naoki wrote:
Sadly, there's not much we can do for users of nose. Nose itself is only tested with Python 3.5 and below. I'm aware that there are scripts without tests. But maybe letting them suddenly break is the right balance between letting people know and annyoing everyone with unactionable warnings. If DeprecationWarning is not enough, then we should be having a wider discussion, and PEP 387 should change. This particular issue should not be an exception to the process.
On Tue, 11 May 2021, 7:57 pm Petr Viktorin, <encukou@gmail.com> wrote:
Scripts (with or without tests) have gone back to showing deprecation warnings by default since 3.7: https://www.python.org/dev/peps/pep-0565/ If DeprecationWarning is not enough, then we should be having a wider
discussion, and PEP 387 should change. This particular issue should not be an exception to the process.
The limitations section of PEP 565 covers several known problems even with the 3.7+ status quo: https://www.python.org/dev/peps/pep-0565/#limitations-on-pep-scope Most notably, unit test doesn't catch import time or compile time deprecation warnings, and it doesn't catch deprecations in subprocesses. Another case that came up in this thread was support libraries that are tested with warnings treated as errors, but: * the test runner still doesn't enable all warnings (e.g. nose projects that never migrated to nose2) * the project isn't covered as a dependency by any *other* project's test suites that are stricter about avoiding deprecation warnings in their code and the code they use And, of course, projects that don't treat warnings as errors in their tests will get a green tick from CI systems no matter how many warnings they emit. If we wanted to go back to enabling DeprecationWarning by default across the board, I think we could only reasonably do that if we provided an easier to use "hide all warnings except the ones I specifically opt in to seeing" API like the one mentioned at the end of PEP 565: https://bugs.python.org/issue32229 As currently written, that API proposal would flip the ergonomics problem though - while ensuring the warnings system was configured early enough to capture compile time and import time warnings would be up to the application, being able to easily propagate the config change to subprocesses would need to be part of the new API design. Cheers, Nick.
participants (4)
-
Antoine Pitrou -
Inada Naoki -
Nick Coghlan -
Petr Viktorin