On Saturday 13 February 2016 12:54:55 Josh Smeaton wrote:
> The iexact lookup shouldn't even be defined for number types should it? I'm
> assuming it is due to backwards compatibility (from 1.7 when custom lookups
> landed), but what would that even mean? If we're not able to remove iexact
> lookup from number types then I would agree that it should also throw an
> error, because there's no reason I can see to ever iexact compare a number
> to an empty string unless there's a problem in the calling code.
>
Right. Any __iexact comparison applied to an integer field is more likely a bug
than some kind of workaround as the OP described. +1 to making it an error.
On the deeper issue:
> On Saturday, 13 February 2016 10:58:11 UTC+11, belorn mandos wrote:
> > ...Python
> > however does permit int and string comparison (1 == "foo") without it
> > throwing a ValueError, so which of the two behaviors is doing the right
> > thing here?
Python allows comparison between ints and strs, but never considers them
equal:
>>> 1=="1"
False
SQL, on the other hand, is weakly typed:
postgres=# select 1 = '1';
?column?
----------
t
(1 row)
And that's on postgres, the best of them, which will let you make things more
type-safe if you ask for it explicitly:
postgres=# select 1::integer = '1'::varchar;
ERROR: operator does not exist: integer = character varying
LINE 1: select 1::integer = '1'::varchar;
^
HINT: No operator matches the given name and argument type(s). You
might
need to add explicit type casts.
(that "^" sign points at the "=" symbol if you use a fixed-size font).
So, I think the current implementation is correct.
> > The question is not purely philosophic, since ignoring type casting
> > makes my current code a simple and short Q query with
> > multiple OR arguments in it.
Strong typing is good for you. I suspect that adding lines that look like
val = int(s) if s else None
will make your code clearer and safer against unexpected inputs than what you
have currently, and certainly cleaner than using __iexact.
Shai.
