[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

miss-islington added the comment: New changeset 0553369b9827bb5497bb7a65f64dd259781ae792 by Miss Islington (bot) in branch '3.7': bpo-35066: Make trailing percent test more portable. (GH-15907) https://github.com/python/cpython/commit/0553369b9827bb5497bb7a65f64dd259781ae792 --

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

miss-islington added the comment: New changeset f3e430b07975c84cf34c927851df234d04d5753f by Miss Islington (bot) in branch '3.8': bpo-35066: Make trailing percent test more portable. (GH-15907) https://github.com/python/cpython/commit/f3e430b07975c84cf34c927851df234d04d5753f --

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Change by Benjamin Peterson : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Change by miss-islington : -- pull_requests: +15557 pull_request: https://github.com/python/cpython/pull/15916 ___ Python tracker ___

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Change by miss-islington : -- pull_requests: +15556 pull_request: https://github.com/python/cpython/pull/15915 ___ Python tracker ___

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Benjamin Peterson added the comment: New changeset f2173ae38fa49235c3cdc28ae2ca2e19a375a596 by Benjamin Peterson in branch 'master': bpo-35066: Make trailing percent test more portable. (GH-15907) https://github.com/python/cpython/commit/f2173ae38fa49235c3cdc28ae2ca2e19a375a596 --

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Change by Benjamin Peterson : -- pull_requests: +15548 pull_request: https://github.com/python/cpython/pull/15907 ___ Python tracker ___

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Erik Bray added the comment: FWIW (unsurprisingly) the new test added here is broken on Cygwin, whose libc's (newlib) behavior in this undefined case. So I get: >>> from datetime import date >>> t = date(2005, 1, 1) >>> t.strftime("%Y") # ok '2005' >>> t.strftime("%%") # ok '%' >>>

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Paul Ganssle added the comment: > No please, don't do that :-( Interesting, I don't feel terribly strongly about it, but I would have thought that you'd be more in favor of that solution, maybe we have a different definition of "expected failure"? Usually in my projects, I use xfail if I

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

STINNER Victor added the comment: > or we can mark the test as an expected failure on Android No please, don't do that :-( -- ___ Python tracker ___

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Paul Ganssle added the comment: I think the proposed change to the test will work, or we can mark the test as an expected failure on Android (on the theory that the test *should* work because we want the behavior normalized, but we are not living up to that). In either case, I think a

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Michael Saah added the comment: While I agree with Victor that reworking time.strftime to be more portable is a great idea, this issue was never about that; it was about making exception throwing behavior consistent across datetime's two strftime implementations (python and C), and also

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

STINNER Victor added the comment: Xavier de Gaye: That's why I asked to stop relying on the exact behavior of strftime() of the libc to get portable behavior :-/ See my previous comments. IMHO the correct fix is to strip trailing % from the format string, call strftime() and then

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Xavier de Gaye added the comment: The new test added by changeset 454b3d4ea246e8751534e105548d141ed7b0b032 fails on Android: == FAIL: test_strftime_trailing_percent (test.datetimetester.TestDate_Pure)

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

STINNER Victor added the comment: I proposed two different implementations to make time.strftime() more portable, so it seems like it's more complex than what I expected. I merged the datetime change since this one is self-sufficient, so someone can work on a time change on top of it.

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

miss-islington added the comment: New changeset 26122de1a80d1618ee80862cf3b8f73f8ec7d9cf by Miss Islington (bot) in branch '3.7': bpo-35066: _dateime.datetime.strftime copies trailing '%' (GH-10692) https://github.com/python/cpython/commit/26122de1a80d1618ee80862cf3b8f73f8ec7d9cf

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Change by miss-islington : -- pull_requests: +11175, 11176, 11177 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Change by miss-islington : -- pull_requests: +11175, 11176 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

STINNER Victor added the comment: New changeset 454b3d4ea246e8751534e105548d141ed7b0b032 by Victor Stinner (MichaelSaah) in branch 'master': bpo-35066: _dateime.datetime.strftime copies trailing '%' (GH-10692) https://github.com/python/cpython/commit/454b3d4ea246e8751534e105548d141ed7b0b032

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Change by miss-islington : -- pull_requests: +11175 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

STINNER Victor added the comment: The behavior of strftime() with non-ASCII is not portable: bpo-34512. A solution to make time.strftime() more portable would be to split the format string, format each "%xxx" substring separately but don't pass substrings between "%xxx" to strftime().

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Michael Saah added the comment: > Michael - do you think you can / would you like to add the functionality that > Victor mentioned to your existing PR? If not, I recommend we merge the > current PR and open a new issue for "Lone trailing % not supported on all > platforms". I'd be happy to

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Paul Ganssle added the comment: I agree with Victor on this. In the future, I'd really like to see us do our best to add cross-platform uniformity to Python's strftime and strptime support. If there really is a platform out there that doesn't support a trailing `%`, I like the idea of

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Michael Saah added the comment: Hi Victor, thanks for taking a look. > Would why datetime have the same behavior on all platforms, but > time.strftime('%') may or may not raise an exception depending on the libc? If I understand the call stack correctly, datetime does not have the same

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

STINNER Victor added the comment: Paul Ganssle asked me to look at PR 10692. This issue is about consistency, so I don't understand this part of the change: try: _time.strftime('%') except ValueError: self.skipTest('time module does not support trailing %') Would

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Michael Saah added the comment: Summary to accompany my patch: Modules/_datetimemodule.c and Lib/datetime.py do not behave identically. Specifically, the strftime functions do not match when passed a format string terminated with a '%'. The C function performs an explicit check for this

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Change by Roundup Robot : -- keywords: +patch pull_requests: +9944 stage: -> patch review ___ Python tracker ___ ___

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Change by Pablo Galindo Salgado : -- nosy: +pablogsal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Karthikeyan Singaravelan added the comment: Thanks for the details. The C implementation should be same as Python implementation which in this case differs as per your analysis if I am understanding it right and IIRC there is a PEP (PEP 399 I think) to enforce that C and Python

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Michael Saah added the comment: Appologies, will do. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Terry J. Reedy added the comment: Michael Saah, when you reply by email, *please* delete the quoted post you are replying to (except possibly for a relevant line or two.). The quotation duplicates what is already on the web page and makes it harder to scroll through posts on the web page.

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Michael Saah added the comment: Did a little digging. Seems that there are two versions of the datetime module, a C version (looks like an accelerator module) and a Py version. Both define a wrap_strftime function that replace %z, %Z and %f format codes before handing off to the timemodule.c

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Karthikeyan Singaravelan added the comment: Michael: I understand the inconsistency but since there is a test that says ValueError is platform dependent then making it as an intentional error there might be breakage. I am not against changing this but if it's done then it should be done

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Change by Srinivas Reddy Thatiparthy(శ్రీనివాస్ రెడ్డి తాటిపర్తి) : -- nosy: +thatiparthy ___ Python tracker ___ ___

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Michael Saah added the comment: >From a pure usability standpoint I'd prefer for datetime to match the time behavior you're demonstrating, that is to not fail on a dangling %. Of course I defer to the dev team on this, but I want to make clear where I'm coming from. On Thu, Oct 25, 2018 at

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Eric V. Smith added the comment: After a little more thinking: maybe we should just document this behavior, make it official, and not change it. -- ___ Python tracker ___

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Eric V. Smith added the comment: Hmm, if there's a test for this, then that does complicate the decision. Is this behavior documented anywhere? If so, then we shouldn't change it. If we do decide to go forward with a change, it should be in the master branch, which will become 3.8.

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Karthikeyan Singaravelan added the comment: I am not sure time.strftime("%") should raise an error. There is an explicit test case and it's mentioned as platform dependent in the comment to raise a ValueError or succeed. So I don't know if it should be changed despite the inconsistency and

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Michael Saah added the comment: Ok, seems reasonable. What branch would I submit a PR against? On Thu, Oct 25, 2018 at 1:11 PM Eric V. Smith wrote: > > Eric V. Smith added the comment: > > I think it would be a good idea to make this more consistent. We should > run through a multi-release

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Eric V. Smith added the comment: I think it would be a good idea to make this more consistent. We should run through a multi-release deprecation cycle, since it might break existing, working code. And we could only start that in 3.8. -- nosy: +eric.smith versions: +Python 3.8

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Stéphane Wirtel added the comment: for me, yep normally we should provide the same behavior. now, if you want, you can submit a PR but before your PR, you have to sign the CLA. thanks -- nosy: +matrixise ___ Python tracker

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

New submission from Michael Saah : A call to time.strftime('%') returns '%' A similar call to datetime.utcfromtimestamp(int(time.time()).strftime('%') raises ValueError: strftime format ends with raw % Similar inputs like '%D %' behave similarly. I might take a crack at fixing this, but