parsing a date

Peter Hansen peter at
Sun Sep 25 00:03:50 CEST 2005

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 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. :-) )


More information about the Python-list mailing list