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

[Andrew Barnert]

On Aug 5, 2014, at 14:46, Petr Viktorin <encukou at gmail.com> wrote:

> On Tue, Aug 5, 2014 at 11:35 PM, Andrew Barnert
> <abarnert at yahoo.com.dmarc.invalid> 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.
> 
> +1
> 
>> 
>>> 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.
> 
> Let me just note this, since it hasn't been said here yet:
> 
> When people say "iso" in the context of datestimes, they usually mean RFC 3339.

RFC 3339 is still more complicated than just reversing Python's str or isoformat. IIRC (it's hard to check on my phone), it mandates that parsers should accept 2-digit years (including 3-digit or semicolon-and-two-digit years), lowercase T and Z, missing "-", and other things that you shouldn't generate but some code might.

That being said, it's still obviously easier to write an RFC 3339 parser than a full ISO 8601 parser, and as long as someone is willing to write it (with sufficient tests) I don't see any problem with the stdlib having one. But I don't know that it should be called "fromisostring". 

"fromisoformat" isn't quite as bad, since at least it implies that it's the inverse of the same type's "isoformat", but it still seems misleading.