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

[Petr Viktorin]

On Thu, Aug 7, 2014 at 11:57 AM, Wolfgang Maier
<wolfgang.maier at biologie.uni-freiburg.de> wrote:
> 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.

According to Wikipedia's quote of the standard: "the character [T] may
be omitted in applications where there is no risk of confusing a date
and time of day representation with others defined in this
International Standard."

If you give the string to a deatetime constructor, there is obviously
no such confusion.
I'm not sure if replacing by space counts as omitting, but it's the
de-facto standard :)

Anyway, i'd prefer not taking sep as an argument, but accepting both '
' and 'T', since other separators aren't widely used.

Also, note that we while a full ISO parser may not be feasible, we can
(and IMO should) implement a complete RFC 3339 parser (with optional
space separator), and document that both __str__ and fromstr (or
whatever it ends up to be) is indeed is compatible with RFC 3339.