Michael Saah <mike.s...@gmail.com> 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 code, where the actual strftime function is called (aliased as format_time). Here's the strange thing. The C datetime module raises a ValueError on a dangling %, while the Python version does not. The C code can be seen here: https://github.com/python/cpython/blob/3df85404d4bf420db3362eeae1345f2cad948a71/Modules/_datetimemodule.c#L1517-L1520 and the python version is here https://github.com/python/cpython/blob/9e95eb0d609cee23e6c9915c0bef243585b8c14b/Lib/datetime.py#L196 So to summarize, it seems unnecessary to throw an error on a dangling % in a higher-order module (_datetimemodule.c) when the lower-order module (timemodule.c) doesn't do the check, and that lower-order module readily accepts external input. This seems to be further corroborated by the fact that the equivalent python version of the high-order module (datetime.py) does not do the check either. Let me know if I'm off base here, or if this is a fair assessment. On Thu, Oct 25, 2018 at 2:35 PM Karthikeyan Singaravelan < rep...@bugs.python.org> wrote: > > Karthikeyan Singaravelan <tir.kar...@gmail.com> 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 with DeprecationWarning for 3.8 and then later > removed on other versions. > > Some more information : > > Further, I looked into timemodule.c in CPython that says that it supports > some common formats and "Other codes may be available on your platform. > See documentation for the C library strftime function." . I looked into > freebsd strftime there is an explicit comment if conversion char is > undefined then the behavior is also undefined and to just print it out. > Related issue that has the patch to an external implementation that refers > to the same comment : https://bugs.python.org/issue3173 > > Meanwhile datetime strftime uses wrap_strftime that defines the custom > error message when format ends with raw % and does some more error > reporting. > > # datetime strftime error : > https://github.com/python/cpython/blob/9e95eb0d609cee23e6c9915c0bef243585b8c14b/Modules/_datetimemodule.c#L1518 > > # Freebsd > https://github.com/freebsd/freebsd/blob/277918494930ec3fb0c7fdbd4d35060a3bc6d181/lib/libc/stdtime/strftime.c#L572 > # Same comment on Apple's source : > https://opensource.apple.com/source/Libc/Libc-166/string.subproj/strftime.c > > > case '%': > /* > * X311J/88-090 (4.12.3.5): if conversion char is > * undefined, behavior is undefined. Print out the > * character itself as printf(3) also does. > */ > default: > break; > > Initially I thought this is the relevant code that is printing the '%' but > looking at the loop itself if the first character is "%" followed by '\0' > indicating that it's just '%' then it breaks out of the loop and just > returns '%' which I hope is happening on my system. I don't think the above > case of printing out the character itself in the comment i.e. "%" is done > here. > > The above are based on my limited knowledge of C though so feel free to > correct me if I am wrong on the above or took it out of context. So maybe > this can be documented that for time.strftime the behavior is undefined > when the conversion char is undefined and is based on the underlying > operating system internals. Also a note that time.strftime with just '%' is > system dependent meanwhile datetime.strftime '%' produces a ValueError. I > think the same is noted in the test that this platform dependent depending > on the implementation of strftime like in Windows. So if we are going to > make '%' as an error from Python like datetime.strftime in time.strftime > too then lies the breakage since Python behaves different from the > underlying OS strftime implementation it uses for time module. > > Hope it helps and maybe someone else with a better understanding of C has > a better explanation. > > ---------- > > _______________________________________ > Python tracker <rep...@bugs.python.org> > <https://bugs.python.org/issue35066> > _______________________________________ > ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue35066> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
