Draft

Querysets

Description
Loading description...
Fundamentals
View
AllIssues7QuestionsSuggestionsShow Resolved
  • Please sign in or sign up to leave a comment.
  • Voile Avatar

    filter most definitely shouldn't be named filter since it collides with built-in method.

  • Blind4Basics Avatar
    • the arguments are not "optional", they are keyword arguments, actually (well, only for the filter lethod... x. See FArekkusu issue below)
    • some of the most important requirements are given in the notes at the bottom of the description... The whole thing should actually be rewritten.
    • the contract for the parent class must be given somewhere
    • the overall design is rather bad, since a simple base class is used while the actual implementation is calling like hell for extending the list class. But with the inheritance system, that's not compatible with the current setup (or at least, I didn't find how to do it... especially with a hidden contract... x/ )
    • needs random tests
    • it's not specified/tested if the filtering should be done by mutation or by returning a fresh instance
    • iteration isn't tested on the instance itself.
    • FArekkusu Avatar

      the overall design is rather bad

      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.

  • FArekkusu Avatar

    Description is inconsistent with the task.

    • Blind4Basics Avatar

      it IS consistent. But it IS pretty bad...

    • FArekkusu Avatar

      "filter should accept the following optional arguments"

      filter is never actually called with positional arguments

      ?

    • Blind4Basics Avatar

      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)

      Issue marked resolved by Blind4Basics 5 years ago
  • FArekkusu Avatar

    get should accept arguments the same was as filter does.

  • FArekkusu Avatar

    It's not mentioned what parameters get takes.

    • Blind4Basics Avatar

      The filter() and get() methods should accept the following optional arguments: first_name last_name age

      it's rather that the info isn't at the correct/best place in the description...

    • FArekkusu Avatar

      Oh well, the kata is such a mess I didn't even notice this. I assumed get should use kwargs like filter does. Now there's an issue that filter is never actually called with positional arguments...

      Issue marked resolved by FArekkusu 5 years ago
  • Blind4Basics Avatar
  • zellerede Avatar

    Really nice kata!

    One miscrepancy: in the trainer window, the inherited attribute of DBResultSet is referred as records in the code comment, though in reality it is called results -- I had to print dir(DBResultSet) to identify the real name.