In article <3ACDB3A1.9B4E3B5A at projtech.com>, Scott Finnie <scott at projtech.com> wrote: > >Hmmm. A question about PEP245: how do interfaces differ from types? > >Both seem to have the same motivation: to declare not what something is, >but what it can do: > > . "An object's type ... determines the operations that an object > supports (e.g., ``does it have a length?)" > - Python Language reference section 3.1 > . "Interfaces try to provide a way for you to ... specify a contractual > obligation for your object" > (PEP245, "The Problem" section). > >There are currently limitations on typing (only covers built-ins, object >can only be of a single type) but neither of these seem justifiable >reasons for introducing a new construct rather than extending the >existing one? What you're talking about here is the type/class split. There have been a lot of suggestions for healing that, but they all require a *lot* of work (plus probably breaking a lot of code). Interfaces are in a lot of ways a gimmick for creating type-like functionality for classes. There are some differences, though: Python currently does not have a mechanism for specifying the interface for a type. It seems rather likely that creating an interface mechanism for classes and then extending it to types will be the easier and simpler route. -- --- Aahz <*> (Copyright 2001 by aahz at pobox.com) Androgynous poly kinky vanilla queer het Pythonista http://www.rahul.net/aahz/ Hugs and backrubs -- I break Rule 6 Why is this newsgroup different from all other newsgroups?
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