Interfaces.

[davisn90210 at gmail.com]

On Nov 15, 7:55 pm, "PeterBrad... at googlemail.com"
<PeterBrad... at googlemail.com> wrote:
> I would argue that interfaces/(similar feature) are necessary in any
> modern language because they provide a way of separating the
> specification from the implementation of a module.
>

First of all, being a newbie, let me welcome you to python.  I get the
feeling that you, like me, are coming from a strong background in
statically typed languages.  Personally I have found that, while some
python ideology takes some time to get used to, once you get used to
the "python way", it is even more difficult going back.  And it
provides a very rich set of features (overloading attribute access,
attribute descriptors, and function decorators come to mind) that are
simply unrivaled in any other language I have tried, combined with a
simple, clean, and clear syntax.  Much of the reason why python does
certain things in certain ways has to do with a combination of power
and simplicity.  Pythons dealings with interfaces are no exception.

Iterfaces are, and have always been, a part of every language.  Even
before OO, there were interfaces.  They may have been informally
defined (via documentation, word-of-mouth, etc.).

I know you are talking about "interfaces" in an OO sense, but in
understanding why python does not (yet) support the notion of a formal
"interface", it is important to realize that an "interface" is simply
a formal codification of an interface using the syntax of a language.

(Note that I will use "interfaces" to refer the formal interfaces,
while unquoted interface will refer to the broader meaning.)

In a statically-typed language, "interfaces" are very important.  They
define what can, and can't, be done to an object.  In dynamically-
typed languages, "interfaces" are less important.  This is because
interfaces are not enforced at the language level.  Instead,
interfaces are "enforced" through communication and documentation.

For example, at the language level, Python variables are simply
typeless "blobs" with attributes.  Only when the code is actually
executed is there enough information to determine the type of a
variable.  (It is possible to infer the type of a variable through
static analysis, but only in certain cases.)

Statically-typed languages, such as C++ or Java, rely on type
information in order to perform static checks that "ensure" all uses
of a variable within a program are "valid" to a point.  For example,
you it should not be possible to obtain an "AttributeError" running
Java code that has successfully passed all the compile-time semantic
checking.

While it could be argued that statically-typed languages are better
than dynamically-typed languages, it is interesting to note that there
seems to be a fair amount of "working around" the type system in
Java.  After all, there was a reason introspection capabilities were
added to Java.  While static type-checking can catch a certain class
of errors, it is certainly not a panacea.

IMHO, one of python's greatest strengths is that it is dynamically
typed.  I like to think of python having the power of C/C++ with the
ease and flexibility of scripting.

For example, one case where "interfaces" would get in the way is
overloading the [] (subscript) operator.  In python, I just overload
it and run.  I can pass those objects to *any* code which expect to
operate on objects through the [] operator and it just works.

In C++, I would have the following options:
1) Use templates.  Templates are great, but they create their own
problems.  For instance, they require a separate copy for every type
they are applied to.
2) Have all objects I would ever want to pass to the functions inherit
from a common class.  Depending on the degree of flexibility I want,
this may range from sensible to arguably silly.  In the extreme case,
I suppose, you would find yourself inheriting from some sort of a
"Subscriptable" class which merely flags that the class implements an
overloaded[].  IMHO, that is silly -- even more so when you consider
that various types could be used as the "index" ("IntSubscriptable",
"CharStarSubscriptable" anyone?).
And, of course, these work only if you wrote or can modify the code.
If you're using a library, your options for integrating it into your
framework is substantially limited.

Java, of course, doesn't support overloaded operators (much to its
loss, IMHO).  However, you could easily come up with similar example
for it.

If I have digressed from the original discussion, I apologize.
However, I hope that the above gives you some insight into *why*
python doesn't (yet) have "interfaces".  To summarize, there just
aren't that many usecases where they would provide much benefit
because the type model as a whole plays a lesser role in defining
interfaces.  (And, as other posters have pointed out, "interfaces" can
be emulated using classes -- C++ doesn't have "interfaces" in the
sense that Java does either, although it does provide for pure virtual
methods.)

Hope this is helpful,

--Nathan Davis