-
-
Save pydanny/6cf5f6344a59a655cf885dd86eefd5b2 to your computer and use it in GitHub Desktop.
def fun_function(name=None): | |
"""Find working ice cream promo""" | |
results = Promo.objects.active() | |
results = results.filter( | |
Q(name__startswith=name) | | |
Q(description__icontains=name) | |
) | |
results = results.exclude(status='melted') | |
results = results.select_related('flavors') | |
return results |
def fun_function(name=None): | |
"""Find working ice cream promo""" | |
return ( | |
Promo.objects.active() | |
.filter( | |
Q(name__startswith=name) | | |
Q(description__icontains=name) | |
) | |
.exclude(status='melted') | |
.select_related('flavors') | |
) |
First example is more clear - the results assignment as the first part of the statement is a useful hint for whats about to happen.
The second example reads a lot like JS - doesn't seem that pythonic.
Maybe somewhere in between?
def fun_function(name=None):
"""Find working ice cream promo"""
results = Promo.objects.active()
results = results.filter(
Q(name__startswith=name) |
Q(description__icontains=name)
)
.exclude(status='melted')
.select_related('flavors')
return results
I like @iokiwi's approach, although I don't like the double assignation to "results" variable, I would use something like:
def fun_function(name=None):
"""Find working ice cream promo"""
promos = Promo.objects.active()
results = promos.filter(
Q(name__startswith=name) |
Q(description__icontains=name)
)
.exclude(status='melted')
.select_related('flavors')
return results
In the versions you posted, method 1 seems to be more legible. However, after formatting them with black, both look the same IMO:
def fun_function(name=None):
"""Find working ice cream promo"""
results = Promo.objects.active()
results = results.filter(Q(name__startswith=name) | Q(description__icontains=name))
results = results.exclude(status="melted")
results = results.select_related("flavors")
return results
def fun_function(name=None):
"""Find working ice cream promo"""
return (
Promo.objects.active()
.filter(Q(name__startswith=name) | Q(description__icontains=name))
.exclude(status="melted")
.select_related("flavors")
)
The first its better for new programmer, more fresh to the eyes
Method 2. From the beginning is clear that I will return the the queryset.
Method 1 makes me think about the state of a variable which is never really important. Puts more effort on me. It keeps me thinking that something is going to happen to the variable but never happens.
@CharlyJazz, may I ask, are you a new programmer? If not, why do you think it is clearer for them?
I ask because It is an opinion on what others might think.
Method 2 by far!
It tells line by line what you're querying. With method 1 I have to see how all variables are assigned, whether result
remains the same thing, and what you're doing with it in between.
I like @iokiwi's approach, although I don't like the double assignation to "results" variable, I would use something like:
Yeah, I second that @angvp! I was contemplating renaming the vars in my example to something a little more descriptive but I didn't want to distract from the main distinction of the number of intermediate assignments I would make.
In terms of variable naming I would personally probably go with active_promos
and filtered_promos
respectively.
The first one! It is easier to debug with breakpoint()
(.set_trace()
), debuggers or even "debug printing".
Method 1