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
>
Triaged
---
https://code.djangoproject.com/ticket/26183 - PostgreSQL backend: TimeField
is created without time zone (wontfix)
https://code.djangoproject.com/ticket/26184 - Unable to use custom lookups
or transforms in admin `search_fields` (accepted)
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
