[Python-3000] Traits/roles instead of ABCs

[Bill Janssen]

> [Collin Winter]
> +100 I'm very interested in seeing a lighter weight alternative to abc.py that:
> 
> 1) is dynamic

There's no reason ABC's can't be dynamic.

> 2) doesn't require inheritance to work
> 3) doesn't require mucking with isinstance or other existing mechansims

Using existing mechanisms that work for the issue is always preferable
to adding new ones that *also* work for the issue.

> 4) makes a limited, useful set of assertions rather than broadly covering a whole API.

That's what an API is, isn't it?

> 5) that leaves the notion of duck-typing as the rule rather than the exception

Here we disagree.

> 6) that doesn't freeze all of the key APIs in concrete

After 15 years of experience with the key APIs, we could perhaps freeze some of them?

> IMHO, the ABC approach is using a cannon to shoot a mosquito.  My day-to-day
> problems are much smaller are could be solved by a metadata attribute or a
> role/trait solution:

And then you cite a few symptoms of not having an API-based system:

> * knowing whether a __getitem__ method implements a mapping or a sequence

In other words, what APIs does this value support?

> * knowing whether an object can have more that one iterator (i.e a file has one
>    but a list can have many)

In other words, what APIs does this value support?

> * knowing whether a sequence, file, cursor, etc is writable or just readonly.

In other words, what APIs does this value support?

If we simply had a small standard extensible set of APIs, and a way to
indicate that a value does or doesn't support one or more of them,
we'd be done.  We could either add a new mechanism to do this, or simply
actually use the one we already have, which should work perfectly well for
this purpose.

Bill