Brett> The problem I have always had with this proposal is that the Brett> value is worthless, time tuples do not have a slot for fractional Brett> seconds. Yes, it could possibly be changed to return a float for Brett> seconds, but that could possibly break things.
Actually, time.strptime() returns a struct_time object. Would it be possible to extend %S to parse floats then add a microseconds (or whatever) field to struct_time objects that is available by attribute only? In Py3k it could worm its way into the tuple representation somehow (either as a new field or by returning seconds as a float).
Right, it's a struct_time object; just force of habit to call it a time tuple.
And I technically don't see why a fractional second attribute could not be added that is not represented in the tuple. But I personally would like to see struct_tm eliminated in Py3k and replaced with datetime usage. My wish is to have the 'time' module stripped down to only the bare essentials that just don't fit in datetime and push everyone to use datetime for most things.
Brett> My vote is that if something is added it be like %N but without Brett> the optional optional digit count. This allows any separator to Brett> be used while still consuming the digits. It also doesn't Brett> suddenly add optional args which are not supported for any other Brett> directive.
I realize the %4N notation is distasteful, but without it I think you will have trouble parsing something like
13:02:00.704
What would be the format string? %H:%M:%S.%N would be incorrect.
Why is that incorrect?
-Brett _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
