[Python-ideas] strptime without second argument as an inverse to __str__
Wolfgang Maier
wolfgang.maier at biologie.uni-freiburg.de
Tue Aug 5 23:22:11 CEST 2014
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.
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().
-1 on the specifics of the proposal,
+1 on the general idea.
More information about the Python-ideas
mailing list