Draft
Querysets
13samupl
Loading description...
Fundamentals
View
This comment has been reported as {{ abuseKindText }}.
Show
This comment has been hidden. You can view it now .
This comment can not be viewed.
- |
- Reply
- Edit
- View Solution
- Expand 1 Reply Expand {{ comments?.length }} replies
- Collapse
- Spoiler
- Remove
- Remove comment & replies
- Report
{{ fetchSolutionsError }}
-
-
Your rendered github-flavored markdown will appear here.
-
Label this discussion...
-
No Label
Keep the comment unlabeled if none of the below applies.
-
Issue
Use the issue label when reporting problems with the kata.
Be sure to explain the problem clearly and include the steps to reproduce. -
Suggestion
Use the suggestion label if you have feedback on how this kata can be improved.
-
Question
Use the question label if you have questions and/or need help solving the kata.
Don't forget to mention the language you're using, and mark as having spoiler if you include your solution.
-
No Label
- Cancel
Commenting is not allowed on this discussion
You cannot view this solution
There is no solution to show
Please sign in or sign up to leave a comment.
filter
most definitely shouldn't be namedfilter
since it collides with built-in method.How does
Person.objects.filter
collide withfilter
? This is exactly how it is in Django too :\Well, the CodeMirror syntax highlighting breaks, so...
IMO, if this kata gets fixed, the whole thing should be rewritten because as of now it's total crap (especially the way the circular dependency is "fixed" to make it work with the new runner). I've made a fork with what I believe to be more sensibly designed (you'll have to fork it to see the Preloaded section). I don't really care what happens to this kata, so if you have any better ideas (and really want to waste your time on reworking this), you can just fix it yourself.
Description is inconsistent with the task.
it IS consistent. But it IS pretty bad...
?
consistent as long as you understand that the calls are made with keywords, so we're talking about keyword args, here. Thing is, positional with default has the same syntax than keyword args.
Closing here, since more precisely told about in the one above (moreover, "the description is inconsistent with the task" is a useless issue. Totally unspecific)
get
should accept arguments the same was asfilter
does.It's not mentioned what parameters
get
takes.it's rather that the info isn't at the correct/best place in the description...
Oh well, the kata is such a mess I didn't even notice this. I assumed
get
should use kwargs likefilter
does. Now there's an issue thatfilter
is never actually called with positional arguments...kata broken (python) by the new runner. Need corrections
Fixed.
Really nice kata!
One miscrepancy: in the trainer window, the inherited attribute of
DBResultSet
is referred asrecords
in the code comment, though in reality it is calledresults
-- I had to printdir(DBResultSet)
to identify the real name.Thanks for feedback. It was a typo indeed, I already fixed it.