On 03/07/12 05:27, Maxime Haineault wrote:
> One of the common pitfall I come across way to often with novices is
> something like this:
>
> def getFirstUser():
> return User.objects.all()[0]
>
> It looks innocuous and often wont raise any exceptions in dev because
> you develop and
Shouldn’t it make sense to make it:
User.objects.first() ?
I assume first() is just a custom method on the objects manager, which would
mean you could chain them, and so have objects.all().first(); this also makes
the code more readable in a template:
{{ users.first }} as opposed to {{
Hi all,
On Tue, 3 Jul 2012, Łukasz Rekucki wrote:
On 3 July 2012 06:27, Maxime Haineault wrote:
One of the common pitfall I come across way to often with novices is
something like this:
def getFirstUser():
return User.objects.all()[0]
It looks innocuous and
We shouldn't bloat the API. Obviously there are nice looking approaches and
not to mention the different behaviour in some of them.
-1 on this proposal from me.
On Tuesday, July 3, 2012 8:22:59 AM UTC+3, Łukasz Rekucki wrote:
>
> On 3 July 2012 06:27, Maxime Haineault
On 3 July 2012 06:27, Maxime Haineault wrote:
> One of the common pitfall I come across way to often with novices is
> something like this:
>
> def getFirstUser():
> return User.objects.all()[0]
>
> It looks innocuous and often wont raise any exceptions in dev
On Mon, Jul 2, 2012 at 9:27 PM, Maxime Haineault wrote:
> One of the common pitfall I come across way to often with novices is
> something like this:
>
> def getFirstUser():
> return User.objects.all()[0]
>
> It looks innocuous and often wont raise any exceptions
One of the common pitfall I come across way to often with novices is
something like this:
def getFirstUser():
return User.objects.all()[0]
It looks innocuous and often wont raise any exceptions in dev because you
develop and test with data,
so they slip easily in production.