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

[Terry Reedy]

On 8/5/2014 5:35 PM, 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.
>
>> 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?

Probably yes

> 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.

Given that str(dti) (datetime instance) is conceptually dt.tostr(dit), 
name the inverse as dti = dt.fromstr(s).

-- 
Terry Jan Reedy