On Sunday 14 February 2016 05:52:32 belorn mandos wrote:
> On Saturday, February 13, 2016 at 9:17:34 PM UTC+1, Shai Berger wrote:
> > val = int(s) if s else None
> >
> > will make your code clearer and safer against unexpected inputs than what
> > you
> > have currently, and certainly
On Saturday, February 13, 2016 at 9:17:34 PM UTC+1, Shai Berger wrote:
>
> 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.
>
I was thinking in the line of
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
>
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
When working with QuerySets and IntegerFields, I saw that comparison to
a string with no digits in it throws a ValueError exception when I did
...objects.filter(org_number = criteria)
or
...objects.filter(org_number__exact = criteria)
However, when using iexact, it did not throw an exception,
