Well, the CodeMirror syntax highlighting breaks, so...

How does Person.objects.filter collide with filter? This is exactly how it is in Django too :\

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

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.

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)

• 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.

"filter should accept the following optional arguments"

filter is never actually called with positional arguments

?

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

Description is inconsistent with the task.

get should accept arguments the same was as filter does.

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...

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...

It's not mentioned what parameters get takes.

Fixed.

kata broken (python) by the new runner. Need corrections