On 02/12/2016 02:29 AM, immerrr again wrote:
On Thu, Feb 11, 2016 at 8:48 PM, Mike Bayer wrote:
Good point, but this may not be an option. Currently we return NULLTYPE
for such ambigious comparisons but it's not known what side effects would
occur if we across the board assumed the other s
On Thu, Feb 11, 2016 at 8:48 PM, Mike Bayer wrote:
>
> Good point, but this may not be an option. Currently we return NULLTYPE
> for such ambigious comparisons but it's not known what side effects would
> occur if we across the board assumed the other side should operate (plus the
> other side n
On 02/11/2016 01:16 PM, immerrr again wrote:
> well Python only allows one side's operator override to be called, so
> when DateTime is on the left, its own operate() method is called and not
> yours.
Excuse me for barging in, but the operator function can return a
"NotImplemented" singleto
> well Python only allows one side's operator override to be called, so
> when DateTime is on the left, its own operate() method is called and not
> yours.
Excuse me for barging in, but the operator function can return a
"NotImplemented" singleton and Python will retry the operation reflected o
On 02/09/2016 12:30 AM, Rudolf Cardinal wrote:
Dear all,
I've been trying to implement a datetime-style field in SQL Alchemy
that, in the database backend, uses a specific ISO-8601 format (e.g.
"2013-04-30T00:26:03.000+05:00"), and is a datetime at the Python end.
The primary database engine
Dear all,
I've been trying to implement a datetime-style field in SQL Alchemy that,
in the database backend, uses a specific ISO-8601 format (e.g. "
2013-04-30T00:26:03.000+05:00"), and is a datetime at the Python end. The
primary database engine is MySQL.
I don't want to implement this as a
