Am I missing something with Python not having interfaces?

[jmDesktop]

Studying OOP and noticed that Python does not have Interfaces. Is
that correct? Is my schooling for nought on these OOP concepts if I
use Python. Am I losing something if I don't use the "typical" oop
constructs found in other languages (Java, C# come to mind.) I'm
afraid that if I never use them I'll lose them and when I need them
for something beside Python, I'll be lost. Thank you.

 

[Mike Driscoll]

Studying OOP and noticed that Python does not have Interfaces.  Is
that correct?  Is my schooling for nought on these OOP concepts if I
use Python.  Am I losing something if I don't use the "typical" oop
constructs found in other languages (Java, C# come to mind.)  I'm
afraid that if I never use them I'll lose them and when I need them
for something beside Python, I'll be lost.  Thank you.

In my school, we didn't even discuss the concept of interfaces (except
for CLI and GUI, that is). So I looked it up. I assume you are
referring to something like what's found here:

http://java.sun.com/docs/books/tutorial/java/concepts/interface.html

If so, then it looks like an Interface is a generic class with method
stubs. You can do that with Python just as easily by creating empty
methods with just the "pass" keyword. It also reminds me of
Decorators...so you might want to look at those.

Since it's just a construct to implement polymorphism, I don't think
you'll lose anything. However, Python does not require you to re-
implement every method of the class it is inheriting from. You can
just override those that you want and leave the others alone.

Hopefully I understand this correctly...otherwise, just ignore my
babbling and hand waving.

Mike

 

[Diez B. Roggisch]

Studying OOP and noticed that Python does not have Interfaces. Is
that correct?
Yes.

Is my schooling for nought on these OOP concepts if I
use Python. Am I losing something if I don't use the "typical" oop
constructs found in other languages (Java, C# come to mind.) I'm
afraid that if I never use them I'll lose them and when I need them
for something beside Python, I'll be lost. Thank you.

No. There has been a discussion of interfaces and their value/reason for
existance recently:

http://groups.google.com/group/comp...ad/95e99a5dae495209/647693537ef98068?lnk=raot

Besides, at least for java (didn't do much in C#) you sure will miss on
generators, metaclasses, multiple inheritance, higher-order functions and
such if going there from python. Which I personally consider a much greater
loss and annoyance than a crutch needed in statically typed languages.

Diez

 

[hdante]

Studying OOP and noticed that Python does not have Interfaces.  Is
that correct?  Is my schooling for nought on these OOP concepts if I
use Python.  Am I losing something if I don't use the "typical" oop
constructs found in other languages (Java, C# come to mind.)  I'm
afraid that if I never use them I'll lose them and when I need them
for something beside Python, I'll be lost.  Thank you.

Python supports interfaces. In the example below, "Vehicle" is an
interface.

class Vehicle:
def drive(self, count): raise Exception("I'm only an
interface... :-(")
def number_of_wheels(self): return 0
def fly(self): pass

class Car(Vehicle):
def drive(self, count): print "The car walked %d steps" % count
def number_of_wheels(self): return 4

As you can see, there are a couple of ways you can tell others
"Vehicle" is an interface, like raising exceptions, returning useless
values or doing nothing. You could also raise an exception in
Vehicle.__init__.

 

[Jim Washington]

Studying OOP and noticed that Python does not have Interfaces. Is
that correct? Is my schooling for nought on these OOP concepts if I
use Python. Am I losing something if I don't use the "typical" oop
constructs found in other languages (Java, C# come to mind.) I'm
afraid that if I never use them I'll lose them and when I need them
for something beside Python, I'll be lost. Thank you.

Others have commented that interfaces are not normally important in Python.

However, if you want to do something *with* interfaces like declaring
that an object or class implements a particular interface, or querying
the interfaces implemented by an object, you might look at
zope.interface. Although it is used by and created for Zope,
zope.interface is packaged to be installable and usable outside of zope.
It's available at the Cheese Shop.

If you want to do adaptation from one interface to another or, for
example, register and look-up utilities by interface, zope.component is
also handy.

- Jim Washington

 

[jmDesktop]

Depends on your definition of 'Python does not have Interfaces'. They are not
in the official language, but they do exist. look into zope.interfaces, athttp://www.zope.org/Products/ZopeInterface.


I think you are still thinking with a Java mind-set (no idea about C#, never
programmed with it).

Interfaces mainly exist to formalize TO A COMPILER that an object will provide
certain stuff. In this way, the compiler can catch such errors at compile time.

Python on the other hand does very little at compile time (other than parse
errors). Instead, at run-time it performs the checks that something you want to
use is actually there.
(in the same way that you don't declare variables a priori. You simply use them
and Python creates them for you when needed).

As a result, you get much more light-weight, more dynamic, code, which supports
the RAD nature of Python what makes it so much more productive.

(after a few years Python, you may find the Java way of doing things clunky).


You can continue doing everything exactly in the way you do now. Effectively
you would then be programming Java/C# in Python syntax. I believe you would
gain very little by that move.

If you dare let go of your old habits, and embrace the mindset of a new
language, you can learn a lot more, namely that programming can be done in many
different ways (even if all those ways are called OOP).
If you only have a hammer, the whole world looks like a nail. If you have a
whole toolbox, problems become much more diverse (subtle). You learn to use
the right tools for the right problem, and maybe you find new (better) ways of
approaching old problems.

In the process, you may lose details of how something was done in language X,
but that's why they have invented books.

Sincerely,
Albert

I would imagine this is why I haven't found any schools teaching
Python in their basic programming classes too. On the dynamic typing,
isn't that the same sort of thing that lots of scripting languages
do? VBScript doesn't require you to define your variables, but I
don't really want to use it for anything (used to use it a lot in
Classic ASP.) I believe everyone that Python is great, but some of it
doesn't make sense to me as to why. Thanks.

 

[cokofreedom]

I would imagine this is why I haven't found any schools teaching

Python in their basic programming classes too. On the dynamic typing,
isn't that the same sort of thing that lots of scripting languages
do? VBScript doesn't require you to define your variables, but I
don't really want to use it for anything (used to use it a lot in
Classic ASP.) I believe everyone that Python is great, but some of it
doesn't make sense to me as to why. Thanks.

Well, school-wise we got taught VB because it was easy for the non-
programmers. At university I learnt Java, C++, Haskell, Fortran and
Python. My favourite is obviously Python.

So here is my terrible (likely wrong) view of Python:

Python is a dynamic programming language, different to static ones
like Java or C++, and variables-wise, well you do have types, but it
is up to the interpreter to understand what to do with them. From my
understanding "variables" as you call them can be the following;
Integer 1, String "Hello", Tuple (), List [], Dictionary {} and a
higher level function (you can assign functions as varaible names,
that personally is amazing!).

Python is built to be easy to read, I think Guido (BDFL) said
something about 10% of the time code is written, 90% it is read, or
something to that affect. The point is that anyone who knows Python to
even a small degree should be able to pick up someone elses code and
given a small time understand the idea of it, even with any comments.

That is very powerful and key to the idea of Python, and my main love
for it. The issue I get from University is this idea that OOP is the
way to program, it is one of the ways, not the be all and end all. I
almost died when I got shown Haskell because nothing made sense, but
after using Python and returning, I understood more of the logic
because I had used the same techniques (in a more readable format) in
Python before.

A common bug people suffer from when trying a new language is doing
things how they would in their previous language of choice. Python is
not Java, or C++ or anything else other than Python. So read a few
tutorials on Python, see what people say it is good at and use it for
that purpose. I think it is an advantage to know how to do things
with different languages in different formats, but it is important to
know when to use one method over another. Personally DiveIntoPython
was a great guide for me as to the uses and benefits of Python, at a
basic level. Try googling it and reading the (free) articles and
tutorials online.

And welcome to Python, the grass is greener

 

[Arnaud Delobelle]

Studying OOP and noticed that Python does not have Interfaces. Is
that correct? Is my schooling for nought on these OOP concepts if I
use Python. Am I losing something if I don't use the "typical" oop
constructs found in other languages (Java, C# come to mind.) I'm
afraid that if I never use them I'll lose them and when I need them
for something beside Python, I'll be lost. Thank you.

You're not missing anything. An Interface is the Poor Man's Multiple
Inheritance. But in truth, even without multiple inheritance, Python
wouldn't need java-like interfaces.

 

[Arnaud Delobelle]

Python is built to be easy to read,

And also very easy to *write*. I rarely hear this, but it is the main
reason why I like Python so much. I can't really explain why though.

[...]

(cokofreedom, I found your explanation of the virtues of Python was
excellent!)

 

[hdante]

I would imagine this is why I haven't found any schools teaching
Python in their basic programming classes too.  On the dynamic typing,

No. When teaching problem solving in the basic programming courses,
the language is irrelevant. You don't even need a computer for that.

isn't that the same sort of thing that lots of scripting languages
do?  VBScript doesn't require you to define your variables, but I
don't really want to use it for anything (used to use it a lot in
Classic ASP.)  I believe everyone that Python is great, but some of it
doesn't make sense to me as to why.  Thanks.

If you want to understand the design decisions behind python, read
its history:
http://www.artima.com/intv/python.html

Also, do you have an example of some problem that requires an
interface that you would like to know how it's done in python (or
maybe an explanation of why it's not possible) ?

 

[Matt Nordhoff]

In my school, we didn't even discuss the concept of interfaces (except
for CLI and GUI, that is). So I looked it up. I assume you are
referring to something like what's found here:

http://java.sun.com/docs/books/tutorial/java/concepts/interface.html

If so, then it looks like an Interface is a generic class with method
stubs. You can do that with Python just as easily by creating empty
methods with just the "pass" keyword. It also reminds me of
Decorators...so you might want to look at those.

Instead of just using "pass", you should "raise NotImplementedError".

From the docs: "In user defined base classes, abstract methods should

raise this exception when they require derived classes to override the
method."

Since it's just a construct to implement polymorphism, I don't think
you'll lose anything. However, Python does not require you to re-
implement every method of the class it is inheriting from. You can
just override those that you want and leave the others alone.

Hopefully I understand this correctly...otherwise, just ignore my
babbling and hand waving.

Mike

--

 

[Max M]

Arnaud Delobelle skrev:

You're not missing anything. An Interface is the Poor Man's Multiple
Inheritance. But in truth, even without multiple inheritance, Python
wouldn't need java-like interfaces.

Interfaces are a great concept for many things, and they can cover a few
soft spots in Python.

There is the possibility of using the great zope.interface library
http://pypi.python.org/pypi/zope.interface. Just use:

"easy_install zope.interface"

And you have interfaces.



--

hilsen/regards Max M, Denmark

http://www.mxm.dk/
IT's Mad Science

 

[Bruno Desthuilliers]

jmDesktop a écrit :
(snip)

On the dynamic typing,
isn't that the same sort of thing that lots of scripting languages
do?

This is not restricted to scripting languages - that is, unless you'd
call Smalltalk, Erlang or common lisp "scripting languages".

Also and FWIW, static typing in C is mostly here to help the compiler
optimizing, and it's very common to use void pointers and typecast to
get some genericity (cf the sort() function in C stdlib). And you have
the same pattern in Java with "generic" containers storing only "object"
instances, then you have to cast your objects back to the appropriate
type (which may fails, leading to a runtime error).

VBScript doesn't require you to define your variables,

You mean "to declare the type of your variables" ? Neither OCaml nor
Haskell require this, and they are both statically and strongly typed.

but I
don't really want to use it for anything

Neither do I, but not because of dynamic typing. By experience, dynamic
typing works just fine for most applications. And by experience too,
static typing doesn't magically make your code bullet-proof.

(used to use it a lot in
Classic ASP.) I believe everyone that Python is great, but some of it
doesn't make sense to me as to why.

Quite a lot of Java stopped making sens to me since I learned some other
languages. And most of the "OO" (hem) complexity, patterns madness etc
you'll typically find in Java code only exists because of the language's
arbitrary restrictions and lack of expressivity.

Learn Python, learn Ruby or (preferably) Smalltalk, learn common lisp or
(preferably) Scheme, learn OCaml or (preferably) Haskell, learn Erlang,
and you'll find out that there's much more in programming and languages
than can be dreamt of in Java's philosophy !-)

 

[Bjoern Schliessmann]

Studying OOP and noticed that Python does not have Interfaces.

By "OOP", you mean "Java", right? 8)

Is that correct? Is my schooling for nought on these OOP concepts
if I use Python. Am I losing something if I don't use
the "typical" oop constructs found in other languages (Java, C#
come to mind.)

AFAIK, Interfaces weren't "typical" before Java. CMIIW.

BTW, Zope has interfaces. Not sure if it's exactly the same.

Regards,


Björn

 

[bruno.desthuilliers]

By "OOP", you mean "Java", right? 8)


AFAIK, Interfaces weren't "typical" before Java. CMIIW.

BTW, Zope has interfaces. Not sure if it's exactly the same.

It isn't.

 

[Daniel Marcel Eichler]

Am Dienstag 06 Mai 2008 16:07:01 schrieb Mike Driscoll:

If so, then it looks like an Interface is a generic class with method
stubs. You can do that with Python just as easily by creating empty
methods with just the "pass" keyword.

Well, no. It's a litte different. Interfaces force to implement methods.
Simple inheritance with method-stubs can't garantee that a specific
method is reimplementat in a sub-class. Interfaces work at
compile-time, while method-stubs raise at their first call, so in worst
case, never (when the developer is available).

Since it's just a construct to implement polymorphism, I don't think
you'll lose anything. However, Python does not require you to re-
implement every method of the class it is inheriting from.

That's the point. Interfaces garantee that a duck is a duck, an not only
a chicken that quack.

You can just override those that you want and leave the others alone.

Not always desirable. But often enough

 

[Luis Zarrabeitia]

Am Dienstag 06 Mai 2008 16:07:01 schrieb Mike Driscoll:

Well, no. It's a litte different. Interfaces force to implement methods.
Simple inheritance with method-stubs can't garantee that a specific
method is reimplementat in a sub-class. Interfaces work at
compile-time, while method-stubs raise at their first call, so in worst
case, never (when the developer is available).

<Pseudo-java code>
class MyClass implements MyInterfaceWithPassMethod {
function Pass() {
}
}
</pseudo-java code>

There you have it, interfaces are not enough to ensure that the implementors
actually implement the methods. They are useful for warning at compile time
if there is a missing method, but nothing more. I believe you could achieve a
very similar warning in python using some kind of Interface metaclass (too
lazy right now to hack a proof of concept, but it looks doable).

I actually like the Interface concept... as portrayed by zope.Interfaces and
pyprotocols (not the same thing, but I like them), and the ABCs (these, not
so much). But Java interfaces are barely a replacement for multiple
inheritance+abstract methods.

That's the point. Interfaces garantee that a duck is a duck, an not only
a chicken that quack.

Not really. (See the NotImplementedExceptions in .NET 1.1 and window forms,
and/or their TabbedControl/TabPage background color attribute. Can't find
them now, as I don't have .NET anymore, but I consider that an example of why
the static typing are... overrated)

 

[bruno.desthuilliers]

Am Dienstag 06 Mai 2008 16:07:01 schrieb Mike Driscoll:


Well, no. It's a litte different. Interfaces force to implement methods.
Simple inheritance with method-stubs can't garantee that a specific
method is reimplementat in a sub-class.

And Java's "Interface" wart can't garantee that a specific method is
*appropriately* implemented. One often sees do-nothing methods in Java
code - useless boilerplate code that's only here to satisfy the
compiler. It's just like Java's "checked exception" mechanism : one
very often sees do-nothing catch-all try/catch blocks in Java - which
is way worse than just letting the exception propagate. I find all
this totally pointless, because there's just no way for a compiler to
check if your code is logically correct.

Interfaces work at
compile-time, while method-stubs raise at their first call, so in worst
case, never.

And then ? If it's never called, why bother implementing it ?

Here again, I don't see the point of compile-time checking.
RuntimeError is a well-known Java exception, so the fact is that Java
forces you into either rigid designs or overly complex workarounds
(best knowns as "design patterns"), without even being able to
garantee anything wrt/ correctness nor even safety. Not that static
typing by itself is necessarily bad - as usual, there's a balance
between somewhat conflicting goals -, but Java's type system
definitivly is (bad).

(snip)

That's the point. Interfaces garantee that a duck is a duck, an not only
a chicken that quack.

Who cares if it's a chicken as long as it quacks when you ask her to ?
Now *This* is the whole point of chicken^Mduck typing, isn't it ?-)

 

[Daniel Marcel Eichler]

Am Mittwoch 07 Mai 2008 22:39:30 schrieb Luis Zarrabeitia:

There you have it, interfaces are not enough to ensure that the
implementors actually implement the methods. They are useful for
warning at compile time if there is a missing method, but nothing
more.

It's not the fault of the enviroment, if the coder is to stupid to use
it the right way.

I believe you could achieve a very similar warning in python
using some kind of Interface metaclass (too lazy right now to hack a
proof of concept, but it looks doable).

Of course. And unlike Javas interfaces, it ensure a more dynamic
coding-style, without great tools which check all the time for correct
behaviour.

 

[Daniel Marcel Eichler]

Am Donnerstag 08 Mai 2008 00:12:26 schrieb
(e-mail address removed):

very often sees do-nothing catch-all try/catch blocks in Java - which
is way worse than just letting the exception propagate. I find all
this totally pointless, because there's just no way for a compiler to
check if your code is logically correct.

But it's enough if the called method exists and returns the correct
type. At least it prevents a crash.

And then ? If it's never called, why bother implementing it ?

You never can't say when it's called at least, that's the point.

Who cares if it's a chicken as long as it quacks when you ask her to
? Now *This* is the whole point of chicken^Mduck typing, isn't it ?-)

Ducks can also swim and fly. And if you need a really duck, but have
onyl a chicken while the coder was to bored to make one...

Of course, in the practical world that all doesn't matter. But in the
theoretical world of the big coding farms, called business, that's one
cornerstone of success, in the tinking of managers and so.