On 05.08.2014 23:35, Andrew Barnert wrote:
> On Aug 5, 2014, at 14:22, Wolfgang Maier <wolfgang.maier-***@public.gmane.org> 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.
>
Yes, but strftime without format string would then be completely
redundant with __str__ and isoformat with " " separator, which is really
quite against the one and only one way of doing things idea.
Plus again, right now strftime takes an explicit format string and then
generates a datetime string with exactly this and only this format.
In the optional format string scenario, it would have to generate
slightly differently formatted output depending on whether there is
microseconds and/or timezone information. So, like for strptime, this
would change the very clearly defined current behavior into a mix of
things, unnecessarily.
>> 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.
>
Fair enough, it was just the first half-reasonable thing that came to my
mind :)
Being able to parse any valid ISO string would be another nice feature,
but it's really a different story.
Wolfgang