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

[Petr Viktorin]

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.

As Wikipedia can tell you, ISO 8601 is a big complicated non-public
specification under which today can be written as:
- 2014-08-05
- 2014-W32-2
- 2014-217
... and by now I can see why there's no ISO 8601 parser in the stdlib.

RFC 3339, on the other hand, specifies one specific variant of ISO
8601: the one we're all used to, and which datetime's isoformat and
__str__ return. (Just about the only exception is that to be
compatible with ISO 8601, it still specifies "T"/"t" for the separator
and graciously lets people agree on space.)