Proof of concept API quality checking

[Jc2k]

Here's something i played around with for a couple of hours, I think there is some potential here but it's probably best to discuss it before going any further.

This proof of concept script looks for the following errors:

• Base driver shouldn't have any ex_ methods
• Base driver shouldn't have any methods with ex_arguments
• Driver implementation shouldn't have methods that aren't defined in the base driver, unless prefixed by ex_
• If a base driver method accepts an argument then a driver implementation should accept that argument
• A driver implementation shouldn't accept any additional arguments that aren't prefixed with ex_

This has 70 matches - though a lot are false positives because create_node uses kwargs for things like image, size, etc. I don't really like that it does that...

But there are real matches - should ec2's list_snapshot be ex_list_snapshot for example.

[Kami]

I really like the idea. It is something I was also thinking a lot in the past and I think it's a step in the right direction.

To put the whole thing into perspective for the other people who might view this pull request. This pull request aims to solve a problem with the "dynamic" nature of Python which makes it hard to enforce interfaces and other things. All of this causes inconsistent API and confusing to the user.

Currently, most of this stuff is enforced manually (during code reviews) which obviously doesn't scale and it's prone to errors.

<off topic>
Waiting for someone to come here and troll and say we should re-write the whole thing in a statically typed language with a better support for interfaces :P
</off topic>

Now some high-level comments about the whole thing:

1. I think this tool should have a concept of rules (or whatever we end up calling it), similar to pep8, pyflakes, pylint and other lint tools. You have already described a couple of good rules in the description.
2. Fixing existing violations will probably be quite painful and take a while. I think a good start would be to make this tool solid and enable and strictly enforce it for all the new contributions.
3. Yes, I hate drivers and methods which (ab)use kwargs. It's an ugly artifact from the first releases which should be fixed.
4. How should we call this thing? It's not really a linter. libcloud-interface-enforcer or something? :)

I also plan to add some more comments about the implementation later on.

[Kami]

I also forgot to add that I would like to see this thing up and running for new contributions asap.

This means that a very simple script should do. We can then extend and make it more generic, robust, etc. later on. I think this would also be a great task for GSoC 2014.