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

[Andrew Barnert]

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?

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.

> 
> -1 on the specifics of the proposal,
> +1 on the general idea.
> 
> _______________________________________________
> 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/