At 23:11 11/04/01 -0700, Alex Shindich wrote: >Lately, there has been a lot of talk about PEP 245(Python Interfaces). >Curt and I wrote up a pattern to illustrate how interfaces are dealt >with through the use of generics. I hope that many of you will find this >article interesting, since Python supports generics naturally. >The article can be found at >http://www.shindich.com/sources/patterns/implied.html Nice article, Alex. It summarizes very well a lot of issues that some people (including you) brought up in the past weeks. The fact is that Python already supports interfaces, at least in the format proposed by you. The question is, do we need to add explicit support for interfaces to the language? In your example, interface definitions are handled by the documentation, not by the language. The XML snippet for interface definition was *exactly* the kind of thing that I have proposed in the earliest days of PEP 246 (when it was called __query__). This can be done now, without any changes to the language. At best, we could supply a standard library to handle stuff related to the XML representation of interfaces. For instance, some helper functions to retrieve the documentation, given the URL, and to keep a cache of interface definitions. (A weak ref implementation could be handy for this). On the other hand, interfaces could be handled by the language itself. You don't see any need to make it. There are some sources of concern here, and I would like you to clarify on these issues: 1) Interfaces are not absolutely needed, as you have shown. However, they could be handy, at least on principle. Do you think that code with *explicit* interfaces is going to be worse than "implied interfaces", by the folowing criteria: - readability - clarity 2) There is any functionality that is going to be lost if Python supports interfaces as part of the language? Do you think that it may break older code? 3) There is any new problem that the new interface proposal brings to Python, that is (a) unique to the interface proposal and (b) possible to avoid if we keep the language as is? BTW, I liked the interfaces proposal, mainly because it is a standard way to specify interfaces. My main fear is that, by including interfaces as part of the language, we will be creating a completely new problem: versioning. This is my take for the question number (3) above. We may end up with dozens of 'almost compatible' interfaces for trivial things, with small differences that really dont matter, but that the interface checking *will* catch. Then we will end up (by PEP 246) coding monstrous adapters for endless combinations of interfaces. In some cases, the difference may be negligible for the code that we are running, but interface checking may not allow it to pass. Carlos Ribeiro
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