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

[Wolfgang Maier]

On 07.08.2014 01:55, Andrew Barnert wrote:
> On Aug 6, 2014, at 8:42, Alexander Belopolsky
> <alexander.belopolsky at gmail.com
> <mailto:alexander.belopolsky at gmail.com>>
> wrote:
>
>> Note that if we allow date('2000-01-01'), this may become a more
>> readable and efficient alternative to date(2001, 1, 1).
>
> I'm -0 on this, +1 on Terry's fromstr, +0 on strptime and strftime both
> accept ing no arguments, -1 on only strptime, -0.5 on
> fromisostring/fromisoformat, and -1 on remembering any of the other
> ideas in this thread well enough to comment.
>

So to summarize, the three currently discussed options (in order of 
current votes for) are:

- datetime.fromstr(string)
     classmethod to be used as an alternative constructor

- datetime (string)
     add limited string parsing to the default constructor

- datetime.strptime (string)
     parse datetime.__str__ format when format argument is not specified
     (the OP's original proposal)

A point that has not been discussed yet is that the first two options 
could easily be implemented for datetime.date and datetime.time objects 
as well providing counterparts for date.__str_ and time.__str__ .
With strptime this is not possible since datetime.date and datetime.time 
don't have such a method.


In addition, the first two options, in particular, raise a scope 
question. I can see the following options:

- string has to be of exactly the format generated by datetime.__str__, 
i.e. YYYY-MM-DD HH:MM:SS with optional microseconds and timezone 
information (the original proposal)

- string has to be of a format that can be generated by 
datetime.isoformat, of which the datetime.__str__ format is a subset.
The difference is that with datetime.isoformat the separator between the 
date and time portions of the string can be specified, while with 
datetime.__str__ this is fixed to " ".
Accordingly with this option, you would have either:

     datetime.fromstr(string, sep = " ") or
     datetime(string, sep = " ")

to be able to pass an optional separator. When absent the 
datetime.__str__ format is expected.

- (potentially, but I don't think anyone opted for it:
more powerful parsing of a wider range of formats)


Personally, I'm in favor of the second option here for the following 
reason: the string format returned by datetime.__str__ is not fully ISO 
8601 compatible because it uses " " as the separator instead of "T", 
i.e. if an application has to produce ISO 8601 compliant output it has 
to use datetime.isoformat not __str__, even though the two formats 
differ by just a single character. Hence, allowing the separator to be 
specified makes the new functionality a lot more useful at the expense 
of only a moderate increase in complexity.
Note that this is still fundamentally different from asking for any full 
parsing for ISO 8601 and that it would have no impact on potential 
date.fromstr and time.fromstr methods or their default constructor 
versions since they do not have to deal with a separator.

So my preferred complete version would be something like:

datetime.fromstr (string, sep = ' ')
     Return a datetime object from a string as generated by
     datetime.isoformat(sep).
     With the default value of sep this is also the format generated by
     datetime.__str__().

date.fromstr (string)
     Return a date object from a string as generated by
     date.__str__() and date.isoformat().

time.fromstr (string)
     Return a time object from a string as generated by
     time.__str__() and time.isoformat().

Wolfgang