classification
Title: ISO date errors in _strptime are jumbled
Type: Stage: patch review
Components: Library (Lib), Tests Versions: Python 3.8
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: gphemsley, p-ganssle
Priority: normal Keywords: patch

Created on 2019-05-18 19:46 by gphemsley, last changed 2019-05-19 01:10 by gphemsley.

Pull Requests
URL Status Linked Edit
PR 13408 open gphemsley, 2019-05-18 19:52
Messages (5)
msg342810 - (view) Author: Gordon P. Hemsley (gphemsley) * Date: 2019-05-18 19:46
This has not been apparent because the tests for this code are not testing what they think they're testing.
msg342811 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2019-05-18 19:50
@gphelmsley Can you clarify what you mean by this?

Do you have a minimal reproducing example that shows what's happening and what you are expecting?
msg342812 - (view) Author: Gordon P. Hemsley (gphemsley) * Date: 2019-05-18 19:55
I've created a PR that fixes the issue, which I discovered while evaluating the test coverage for _strptime.

Certain scenarios of error messages were never being hit because the cascade was out of order, and the tests were not showing that because they were throwing a different ValueError than the one they were expecting to throw.
msg342816 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2019-05-18 21:01
Hm, I was a bit confused by your wording here, because I am able to trigger all the errors just fine even before this PR, but I do think that even though this isn't necessarily fixing inaccurate error messages (all the error messages *are* accurate), you're right that the text of the messages does seem to indicate that the original authors intended a cascade ordering more like the one you've proposed.

I'll give this a more thorough review a bit later, thanks for working on this!
msg342828 - (view) Author: Gordon P. Hemsley (gphemsley) * Date: 2019-05-19 01:10
Ah yes, to be clear, I wasn't trying to suggest that the error messages themselves were wrong—just that they weren't triggering when the tests were expecting them to.

Some of the existing tests currently trigger the "unconverted data remains" ValueError from earlier in the method, but because the messages are not checked, that is not immediately obvious. I've also added new tests for additional scenarios that would presumably also be considered invalid, based on the existing ones.
History
Date User Action Args
2019-05-19 01:10:45gphemsleysetmessages: + msg342828
2019-05-18 21:01:05p-gansslesetmessages: + msg342816
2019-05-18 19:55:24gphemsleysetmessages: + msg342812
2019-05-18 19:52:09gphemsleysetkeywords: + patch
stage: patch review
pull_requests: + pull_request13319
2019-05-18 19:50:45p-gansslesetmessages: + msg342811
2019-05-18 19:48:37xtreaksetnosy: + p-ganssle
2019-05-18 19:46:43gphemsleycreate