> I'm leary of trying to weave some interface taxonomy into the standard > library and types without having a lot of experience in using this for > real world applications. Even then, it's possible <wink> that there > will be a lot of disagreement on the shape of the type hierarchy. That's what I said when I predicted it would be hard to come up with an ontology. :-) > So one strategy would be to not classify the existing types and > classes ahead of time, but to provide a way for an application to > declare conformance to existing types in a way that makes sense for > the application (or library). The downside of this is that it may > lead to a raft of incompatible interface declarations, but I also > think that eventually we'd see convergence as we gain more experience. This is what Zope does. One problem is that it has its own notion of what makes a "sequence", a "mapping", etc. that don't always match the Pythonic convention. > My guess would be that of all the interfaces that get defined and used > in the Python community, on a few that are commonly agreed on or > become ubiquitous idioms will migrate into the core. I don't think we > need to solve this "problem" for the core types right away. Let's > start by providing mechanism and not policy. Sure. But does that mean the mechanism needs to be necessarily separate from the inheritance mechanism? --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4