Kalle Anke wrote: > Better (in this case) = > > + Being "pythonic" > > + Avoiding going through a second representation (the tuple) > if there is some way to create a date object directly.
I think the plainest and simplest approach would be to create a well-named function which does the necessary steps (_not_ in a single line of code but with nice readable temporary variables) and call that whenever you need it. Simple utility functions that call a few standard library functions to do a job like this are very "pythonic", and trying to avoid a second representation when (as in this case) there's no obvious way to do it is not pythonic. :-) I'd say if you've checked datetime.date() and not found a factory function or whatever which knows how to parse a string (as many of us have), and if you don't want to download, install, and depend on a third-party extension such as mxDateTime which do this already, then a function to wrap the ugly details is a very nice way to proceed. If you need to do this often, then you've got the beginnings of your own utility module or package, and having those around is pretty "pythonic" too. (An alternative would be to contribute a patch to add something like this to the datetime module. I don't know if it would be accepted, but at least it would be the true arbiters of "pythonicism" who would be judging the matter, not you or I. :-) ) -Peter -- http://mail.python.org/mailman/listinfo/python-list
