> [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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
