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
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
> platform
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 th
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
Michael Saah added the comment:
Appologies, will do.
--
___
Python tracker
<https://bugs.python.org/issue35066>
___
___
Python-bugs-list mailing list
Unsub
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
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 a
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
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