[Python-ideas] strptime without second argument as an inverse to __str__

[Andrew Barnert]

On Aug 6, 2014, at 1:35, Wolfgang Maier <wolfgang.maier at biologie.uni-freiburg.de> wrote:

> On 05.08.2014 23:35, Andrew Barnert wrote:
>> On Aug 5, 2014, at 14:22, Wolfgang Maier <wolfgang.maier at biologie.uni-freiburg.de> wrote:
>> 
>>> On 05.08.2014 03:39, Steven D'Aprano wrote:
>>>> 
>>>> Since str(d) is documented to use a well-defined format, then I agree
>>>> that it makes sense to make the second argument to d.strptime optional,
>>>> and default to that same format. The concern I had was the sort of
>>>> scenario Skip suggested: I might write out a datetime object as a string
>>>> on one machine, where the format is X, and read it back elsewhere, where
>>>> the format is Y, leading to at best an exception and at worse incorrect
>>>> data.
>>>> 
>>>> +1 on the suggestion.
>>> 
>>> After looking a bit into the code of the datetime module, I am not convinced anymore that strptime() is the right place for the functionality for the following reasons:
>>> 
>>> 1) strptime already has a clear counterpart and that's strftime.
>>> 
>>> 2) strftime/strptime use explicit format strings, not any more sophisticated parsing (as would be required to parse the different formats that datetime.__str__ can produce) and they try, intentionally, to mimick the behavior of their C equivalents.
>>> 
>>> In other words, strftime/strptime have a very clear underlying concept, which IMO should not be given up just because we are trying to stuff some extra-functionality into them.
>> 
>> What if strftime _also_ allowed the format string to be omitted, in which case it would produce the same format as str? Then they would remain perfect inverses.
> 
> Yes, but strftime without format string would then be completely redundant with __str__ and isoformat with " " separator, which is really quite against the one and only one way of doing things idea.

They're not redundant. str provides gives you some human-readable, ideally but not necessarily parseable, representation. isoformat gives you a specific format that you know is parseable by many other libraries and languages, and sorts in date order. strftime lets you specify a format to be parsed by specific code or problem-specific human expectations. Is the fact that they happen to overlap (which is already true, since you can always specify the same format explicitly if you want) any worse than the fact that str(3) and format(3, 'd') give you the same result?

> Plus again, right now strftime takes an explicit format string and then generates a datetime string with exactly this and only this format.
> In the optional format string scenario, it would have to generate slightly differently formatted output depending on whether there is microseconds and/or timezone information. So, like for strptime, this would change the very clearly defined current behavior into a mix of things, unnecessarily.

The purpose of strftime and strptime is to be inverses of each other--to generate and parse datetime strings in a specified way. If one of those ways is "the default Python string representation" for one function, it should be true for the other. (Doesn't gnu strf/ptime have an extension that gives you % codes for "default" date and time representations, which don't guarantee anything other than that they be reasonable for the locale and reversible?)

>>> That said, I still think that the basic idea - being able to reverse-parse the output of datetime.__str__ - is right.
>>> 
>>> I would suggest that a better place for this is an additional classmethod constructor (the datetime class already has quite a number of them). Maybe fromisostring() could be a suitable name ?
>>> With this you could even pass an extra-argument for the date-time separator just like with the current isoformat.
>>> This constructor would then be more like a counterpart to datetime.isoformat(), but it could simply be documented that calling it with fromisostring(datestring, sep=" ") can be used to parse strings written with datetime.str().
>> 
>> Wouldn't you expect a method called fromisostring to be able to parse any valid ISO string, especially given that there are third-party libs with functions named fromisoformat that do exactly that, and people suggest adding one of them to the stdlib every few months?
>> 
>> What you want to get across is that this function parses the default Python representation of datetimes; the fact that it happens to be a subset of ISO format doesn't seem as relevant here. I like the idea of a new alternate constructor, I'm just not crazy about the name.
> 
> Fair enough, it was just the first half-reasonable thing that came to my mind :)
> Being able to parse any valid ISO string would be another nice feature, but it's really a different story.
> 
> Wolfgang
> 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/