> It is clear to me that either I am the only one who things > that interfaces, at least in the proposed form, are next to > useless in Python, or those who agree with me do not read the > news group, or simply don't care enough to reply. Some mechanism is needed to identify an object as an implementer of a particular protocol, searching for the existance of "getitem" and the like seems like very poor practice. > Indeed, interfaces in a loosely typed language that > supports introspection -- that's a real joke! What is important isn't the function names, but rather the "intent" of the programmer who asserts that his/her class complies with a given set of expectations. There currently isn't a standard way to express this in Python. I think PEP 245 is a good approach. I think most people agree that Python has a "hole" here that needs to be plugged. If you don't like the current proposal, perhaps you should suggest an alternative which provides the required differentiation? Either that or make a convincing argument why searching for function names is indeed acceptable. I think it breaks down quickly. For instance __iter__ has to return self in the iterator proposal to know that a class is an iterator (having the method "next()" is not sufficient). This kind of ad-hock interface negotiotation kinda hurts interoperability, no? Just thinking... Clark
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