GeezerVison is showing github.com — ``test_strptime`` raises a DeprecationWarning · Issue #117655 · python/cpython
test_strptime raises a DeprecationWarning #117655
DescriptionBug report
Bug description:
./python -m test -v test_strptime
== CPython 3.13.0a5+ (heads/main:ac45766673, Apr 8 2024, 23:14:32) [GCC 9.4.0]
== Linux-5.10.16.3-microsoft-standard-WSL2-x86_64-with-glibc2.31 little-endian
== Python build: debug
== cwd: /home/eclips4/CLionProjects/cpython/build/test_python_worker_28987æ
== CPU count: 16
== encodings: locale=UTF-8 FS=utf-8
== resources: all test resources are disabled, use -u option to unskip tests
Using random seed: 3103978630
0:00:00 load avg: 29.90 Run 1 test sequentially
0:00:00 load avg: 29.90 [1/1] test_strptime
test_TimeRE_recreation_locale (test.test_strptime.CacheTests.test_TimeRE_recreation_locale) ... sys:1: DeprecationWarning: Parsing dates involving a day of month without a year specified is ambiguious
and fails to parse leap day. The default behavior will change in Python 3.15
to either always raise an exception or to use a different default year (TBD).
To avoid trouble, add a specific year to the input & format.
See https://github.com/python/cpython/issues/70647.
skipped 'test needs de_DE.UTF8 locale' CPython versions tested on:
CPython main branch
Operating systems tested on:
Linux
Linked PRs
Activitynineteendo commented on Apr 9, 2024 So, we just need to do this? Can I make a pull request for that?
-_strptime._strptime_time("10", "%d")
+_strptime._strptime_time("10 2004", "%d %Y")Eclips4 commented on Apr 9, 2024 Yes, that's looks good to me. I'm dislike the approach of catching DeprecationWarning because in future versions it can raise an exception. Eclips4 commented on Apr 9, 2024 However, there's also a similar warning in the test_datetime:
./python.exe -m test -q test_datetime
Using random seed: 2525252452
0:00:00 load avg: 41.62 Run 1 test sequentially
sys:1: DeprecationWarning: Parsing dates involving a day of month without a year specified is ambiguious
and fails to parse leap day. The default behavior will change in Python 3.15
to either always raise an exception or to use a different default year (TBD).
To avoid trouble, add a specific year to the input & format.
See https://github.com/python/cpython/issues/70647.
sys:1: DeprecationWarning: Parsing dates involving a day of month without a year specified is ambiguious
and fails to parse leap day. The default behavior will change in Python 3.15
to either always raise an exception or to use a different default year (TBD).
To avoid trouble, add a specific year to the input & format.
See https://github.com/python/cpython/issues/70647.
sys:1: DeprecationWarning: Parsing dates involving a day of month without a year specified is ambiguious
and fails to parse leap day. The default behavior will change in Python 3.15
to either always raise an exception or to use a different default year (TBD).
To avoid trouble, add a specific year to the input & format.
See https://github.com/python/cpython/issues/70647.
sys:1: DeprecationWarning: Parsing dates involving a day of month without a year specified is ambiguious
and fails to parse leap day. The default behavior will change in Python 3.15
to either always raise an exception or to use a different default year (TBD).
To avoid trouble, add a specific year to the input & format.
See https://github.com/python/cpython/issues/70647.
sys:1: DeprecationWarning: Parsing dates involving a day of month without a year specified is ambiguious
and fails to parse leap day. The default behavior will change in Python 3.15
to either always raise an exception or to use a different default year (TBD).
To avoid trouble, add a specific year to the input & format.
See https://github.com/python/cpython/issues/70647.
sys:1: DeprecationWarning: Parsing dates involving a day of month without a year specified is ambiguious
and fails to parse leap day. The default behavior will change in Python 3.15
to either always raise an exception or to use a different default year (TBD).
To avoid trouble, add a specific year to the input & format.
See https://github.com/python/cpython/issues/70647.
== Tests result: SUCCESS ==
Total duration: 3.6 sec
Total tests: run=1,012 skipped=28
Total test files: run=1/1
Result: SUCCESS nineteendo commented on Apr 9, 2024 That's caused by the tests of #70647 (resolved):
|
def test_strptime_leap_year(self): |
|
# GH-70647: warns if parsing a format with a day and no year. |
|
with self.assertRaises(ValueError): |
|
# The existing behavior that GH-70647 seeks to change. |
|
self.theclass.strptime('02-29', '%m-%d') |
|
with self.assertWarnsRegex(DeprecationWarning, |
|
r'.*day of month without a year.*'): |
|
self.theclass.strptime('03-14.159265', '%m-%d.%f') |
|
with self._assertNotWarns(DeprecationWarning): |
|
self.theclass.strptime('20-03-14.159265', '%y-%m-%d.%f') |
|
with self._assertNotWarns(DeprecationWarning): |
|
self.theclass.strptime('02-29,2024', '%m-%d,%Y') |
nineteendo commented on Apr 9, 2024 And we also have these tests that will still raise a DeprecationWarning (resolved):
|
def test_feb29_on_leap_year_without_year(self): |
|
time.strptime("Feb 29", "%b %d") |
|
|
|
def test_mar1_comes_after_feb29_even_when_omitting_the_year(self): |
|
self.assertLess( |
|
time.strptime("Feb 29", "%b %d"), |
|
time.strptime("Mar 1", "%b %d")) |
Those will have to be removed in 3.15. erlend-aasland commented on Apr 9, 2024 See commit 33ee5cb. Please follow the existing practice for how to deal with deprecation warnings in tests. See Greg's commit for inspiration. There also test.support.warnings_helper.ignore_warnings1.
Footnotes
-
git grep ignore_warnings Lib/test for inspiration. ↩
Reacted by Gregory P. Smith nineteendo commented on Apr 9, 2024 Yeah, test.support.warnings_helper.ignore_warnings() works here. (It even works on tests checking for deprecation warnings).
I've added it to the functions were necessary, and updated the others to not use the deprecated behaviour. nineteendo commented on May 9, 2024 Could someone review my pull request? I've waited exactly one month. In a week I'll ask on Discourse. nineteendo commented on May 9, 2024 @Eclips4 can you review this, or should I ask on Discourse right away? erlend-aasland said he's not going to review this. Eclips4 commented on May 9, 2024
@Eclips4 can you review this, or should I ask on Discourse right away? erlend-aasland said he's not going to review this.
Will do it later today. Please note that before merging, we should also get a review from Greg or Paul. nineteendo commented on May 9, 2024 Even after waiting one month? But if they decide to review it now, that would be appreciated. gpshead commented on May 11, 2024 thanks for the PR & pings. merged! =)
cpython workflow wise... IIRC we don't have anything in our CI or buildbots treating warnings emitted by the test suite as a hard error so it they can be easily overlooked. I should've tried to do this with my original PR.
There could be an argument made that test coverage of some code paths without the year specified is important to retain, but I believe we've got enough other explicit intentional tests for that behavior already so this issues PR change still the best way forward.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|