test_strptime raises a DeprecationWarning

[Eclips4]

Bug 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

• gh-117655: Fix test_strptime raises a DeprecationWarning #117668
• [3.13] gh-117655: Prevent test_strptime from raising a DeprecationWarning (GH-117668) #118956

[nineteendo]

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]

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]

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]

That's caused by the tests of #70647 (resolved):

cpython/Lib/test/datetimetester.py

Lines 2796 to 2807 in 22b25d1

	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]

And we also have these tests that will still raise a DeprecationWarning (resolved):

cpython/Lib/test/test_strptime.py

Lines 500 to 506 in 22b25d1

	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]

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_warnings¹.

Footnotes

1. git grep ignore_warnings Lib/test for inspiration. ↩

[nineteendo]

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]

Could someone review my pull request? I've waited exactly one month. In a week I'll ask on Discourse.

[nineteendo]

@Eclips4 can you review this, or should I ask on Discourse right away? erlend-aasland said he's not going to review this.

[Eclips4]

@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]

Even after waiting one month? But if they decide to review it now, that would be appreciated.

[gpshead]

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.