Rubic wrote: > Yeah, it's a trivial function that's rewritten for each new project > that passes datetime objects as strings <0.2 wink>. On the basis of it > being a trivial convenience, I could propose removing hundreds of > "redundant" functions from the library. ;-)
I think the big issue is that it solves such a microscopic part of the convert-strings-to-datetimes problem. Believe me, I know, I'm writing parsers for IATA timetable data now. There is a distinct smell of punch cards, telex machines and handwritten forms in this standard... Like writing 112233 instead of 2006- 02-11 22:33, and let the parser guess month and year from context. If I have gotten a time into a datetime object I'll keep it there if I'm in control. If I'm not in control, I'd be very lucky if the string replresentation was in the One True Format. Since I feel that the datetime module largely replaces the older time module, I'd really like to see a strptime in the datetime module though. Then I guess I could often drop use of the old time module. (If it wasn't for the sad fact that we need to support Python 2.2 a little longer...) -- http://mail.python.org/mailman/listinfo/python-list
