Enforce clearer usage of IsList() etc. with no arguments

[alexmojaki]

IsList() with no arguments is equivalent to an empty list, but the user probably just wants to check for a list with any number of items. It should throw an error suggesting that the user write IsList(length=0) or IsList(length=...) to prevent ambiguity. Similar for IsTuple(). Maybe even IsListOrTuple().

[samuelcolvin]

Yes true, and IsDict, PR welcome.

[FBruzzesi]

Hey there! I am taking a look at this and coming up short due to the following: by raising an error during the initialization, then

[] == IsListOrTuple

would also raise as is falls back to ln24-25 in DirtyEqualsMeta:

try:
    return self() == other
...

While I agree that IsListOrTuple() is ambiguous, I would argue that something == IsListOrTuple should still be allowed.

Any tips?

[alexmojaki]

@samuelcolvin will need to confirm, but in my opinion it's fine to just not allow something == IsListOrTuple. That's also still ambiguous, exactly as much as something == IsListOrTuple(). IsListOrTuple is a bit murkier than IsList because at least it allows two possibilities. something == IsList is pointless to allow with its current behaviour because it could just be written as something == [] so that's probably not what the user intends when they write it.