ENH: don't hide constraints or optional arguments in *args/**kwargs/*constraints etc

[bsipocz]

While their usage seems convenient at first, at the end of the day there are a lot of issues with hiding the details rather then be explicit in an API signature. Just a few of the issues:

• they can swallow arguments without being actually used
• absolute disaster for user facing documentation ( Miscellaneous doc string improvements #215, but there should be other issues about it, too)
• not easy to track the completeness of options, or do any sanity checks (e.g. ENH: Add more text to registry.search docstring for the types of constraints that can be used #426 (comment))

[msdemlei]

Hm – I think I understand your rationale, although I have to say I still like the idea that people can just inherit from Constraint and roll their own sorts of constraints for regtap.py. On the other hand, I think I am resigned into the realisation that the keywords won't disappear as legacy.

Be that as it may: What concrete steps do you have in mind? Scrap the _author thing in rtcons Constraints and make these somehow explicit in regtap.search and regtap.get_RegTAP_query? I have to admit that having to repeat that long list of keyword arguments makes me immediately unhappy...

And as to *constraints... Hm. What would you do instead? The interface rather plainly is "pass in zero or more Constraint objects", and I don't there's not much of a good alternative to that. Of course, we could go all-keyword, but for one the keywords are less expressive, and for a second they won't let me pass in two constraints of the same kind (unless I started to accept both sequences and atoms throughout; again, that feels like a recipe for unhappyness), which seems a bit restrictive to me.

[bsipocz]

This came up again, #490 (comment)