Michael Saah <mike.s...@gmail.com> 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 condition, and raises a ValueError on it. The Py version does not perform this check. Both pass the format string (after doing substitutions for %z, %Z, and %f tags) to the system strftime or wcfstime, depending on platform. These live within the python time module. The time module wrapper function does not perform this check. This situation leads to a scenario in which, for example, "%D %" passed to datetime.strftime (with the C extension included) raises a value error. The same string passed to time.strftime returns "mm/dd/yy %", at least on OSX. Furthermore, if Python is built without the C module, "mm/dd/yy %" is returned when datetime.strftime is called. To summarise, there are two problems: (1) datetime does not comply with PEP-399, and (2) a higher-order module raises an exception on a case that the (exposed) lower-order module has no problem with, causing a mismatch in behavior between datetime.strftime and time.strftime. This PR attempts to fix this problem by removing the case check from the datetime C module. This solves both (1) and (2). There was much talk on the issue thread about there existing a test case for time.strftime that documented a platform-dependent failure on a dangling '%'. I wish to note that my patch does not touch the time module at all, it only removes a seemingly unnecessary check in the datetime C module. ---------- _______________________________________ 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
