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

[Andrew Barnert]

On Aug 6, 2014, at 17:32, Steven D'Aprano <steve at pearwood.info> wrote:

> On Wed, Aug 06, 2014 at 06:48:44AM -0700, Andrew Barnert wrote:
> 
>> The purpose of strftime and strptime is to be inverses of each 
>> other--to generate and parse datetime strings in a specified way. If 
>> one of those ways is "the default Python string representation" for 
>> one function, it should be true for the other.
> 
> As of Python 3.3, neither strftime nor strptime take a default format. 
> It's only __str__ which has an implicit default format.

Exactly my point. They're currently balanced. Adding a default format to strptime only would mean they can no longer be used as inverses of each other.

One solution is to also add a default format to strftime.

The other solution is to recognize that if the desire is an inverse for str, strptime is not the best way to write that. (I didn't have a good alternative suggestion, but Terry's later fromstr seems perfect to me.)

>> (Doesn't gnu strf/ptime 
>> have an extension that gives you % codes for "default" date and time 
>> representations, which don't guarantee anything other than that they 
>> be reasonable for the locale and reversible?)
> 
> I worry about something like that. Unless the default is guaranteed to 
> be a particular format, what counts as "reasonable" when the string is 
> written out and when read back in may not be the same.

I share that worry. Is it guaranteed that str on any Python anywhere can be parsed back to the same value on a different Python somewhere else?

The docs for str (and the presumed docs got the new function) can make that guarantee, but most of the people in this thread didn't know that, or weren't confident in it. That's why I don't really like the idea of the inverse functions being __str__ and the constructor--it isn't obvious or explicit to the reader, and it's not quite as easy to look up. (That wasn't the initial proposal, but it came up later in the thread, so it was worth responding to.)