[Python-3000] Traits/roles instead of ABCs (original) (raw)

Bill Janssen janssen at parc.com
Mon Apr 30 18:08:40 CEST 2007

[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

More information about the Python-3000 mailing list