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

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

get should accept arguments the same was as filter does.