In 0.9.3b2 I notice you've added support for the new
builtin datetime module. In my opinion times.py should
import pytimes first, since it avoids reliance on the
third-party mx package.
My logic for this was, since Python-2.3 has it's own
datetime module, then if you've installed mx.DateTime, you
probably prefer to use it over datetime.
Rebuttal?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I might have mx installed for other reasons. For example, with
Python 2.3 and mysql-python 0.9.2, mx.DateTime is still required
if you want more exotic date/time objects. While it works to
upgrade to 0.9.3 with that sort of setup, it's unclear unless you
RTSL that MySQLdb will now support builtin datetime objects, and
you have to twiddle the source to get at them.
Seems like there's no clean way around it. Ask the user during
build?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Would it be possible (I don't see a reason why not) to allow
the user to control this though cursor class, i.e. one class
(or mixin for better control) uses mx, another datetime, and
another dates are strings (which is needed because MySQL
will accept a date of 2004-03-00 but this cannot be used as
a datetime object because it's an invalid date).
The default cursor should use datetime though, since it's
not the python "way".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The standard datetime module (what pytimes uses) will be the
default and only time-handling module used in MySQLdb-1.1
and newer. I will make an announcement about this shortly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=71372
My logic for this was, since Python-2.3 has it's own
datetime module, then if you've installed mx.DateTime, you
probably prefer to use it over datetime.
Rebuttal?
Logged In: YES
user_id=44345
I might have mx installed for other reasons. For example, with
Python 2.3 and mysql-python 0.9.2, mx.DateTime is still required
if you want more exotic date/time objects. While it works to
upgrade to 0.9.3 with that sort of setup, it's unclear unless you
RTSL that MySQLdb will now support builtin datetime objects, and
you have to twiddle the source to get at them.
Seems like there's no clean way around it. Ask the user during
build?
Logged In: YES
user_id=71372
I was thinking about that earlier tonight. Maybe. I'll think
about it some more.
Logged In: YES
user_id=294560
Would it be possible (I don't see a reason why not) to allow
the user to control this though cursor class, i.e. one class
(or mixin for better control) uses mx, another datetime, and
another dates are strings (which is needed because MySQL
will accept a date of 2004-03-00 but this cannot be used as
a datetime object because it's an invalid date).
The default cursor should use datetime though, since it's
not the python "way".
Logged In: YES
user_id=71372
The standard datetime module (what pytimes uses) will be the
default and only time-handling module used in MySQLdb-1.1
and newer. I will make an announcement about this shortly.