By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,850 Members | 981 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,850 IT Pros & Developers. It's quick & easy.

Am I missing something with Python not having interfaces?

P: n/a
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.
Jun 27 '08 #1
Share this Question
Share on Google+
28 Replies


P: n/a
On May 6, 8:44*am, jmDesktop <needin4mat...@gmail.comwrote:
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/tutor...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
Jun 27 '08 #2

P: n/a
On May 6, 10:44*am, jmDesktop <needin4mat...@gmail.comwrote:
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__.

Jun 27 '08 #3

P: n/a
On 2008-05-06, jmDesktop <ne***********@gmail.comwrote:
Studying OOP and noticed that Python does not have Interfaces. Is
that correct? Is my schooling for nought on these OOP concepts if I
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, at
http://www.zope.org/Products/ZopeInterface .
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
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).

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 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
Jun 27 '08 #4

P: n/a
jmDesktop wrote:
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.
--
http://mail.python.org/mailman/listinfo/python-list
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
Jun 27 '08 #5

P: n/a
On May 6, 10:26*am, "A.T.Hofkamp" <h...@se-162.se.wtb.tue.nlwrote:
On 2008-05-06, jmDesktop <needin4mat...@gmail.comwrote:
Studying OOP and noticed that Python does not have Interfaces. *Is
that correct? *Is my schooling for nought on these OOP concepts if I

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.
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

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 usethem
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).
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 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 inmany
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 languageX,
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.
Jun 27 '08 #6

P: n/a
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 :)
Jun 27 '08 #7

P: n/a
jmDesktop <ne***********@gmail.comwrites:
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
Jun 27 '08 #8

P: n/a
co*********@gmail.com writes:
[...]
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!)

--
Arnaud
Jun 27 '08 #9

P: n/a
Hallöchen!

jmDesktop writes:
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.
See also http://www.python.org/dev/peps/pep-3119/

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: br*****@jabber.org
(See http://ime.webhop.org for further contact info.)
Jun 27 '08 #10

P: n/a
On 2008-05-06, jmDesktop <ne***********@gmail.comwrote:
>
I would imagine this is why I haven't found any schools teaching
Python in their basic programming classes too. On the dynamic typing,
I don't understand your reasoning. What part does 'this' refer to?
Also, you are wrong.
We teach 2nd year Bachelor students about programming (the process of solving a
problem by making a computer program, which is not the same as coding) with
Python.
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
VB was not designed well in that case.

I believe that VB is popular becomes it comes from the same firm that also
sells the OS and the word processor of all school computers. Also, many
teachers make a choice based on what others do or what they know,
rather than what the best possible prog language is for students.

Also, industry wants to have graduates that know the language they use.
It is very easy to give in to that desire, although it is not very useful,
since industry changes its programming language every so many years.

Classic ASP.) I believe everyone that Python is great, but some of it
doesn't make sense to me as to why. Thanks.
That's normal (and healthy, probably).

The thing that should really scare you however is your idea that everything
done in the Java/C# way does make sense (ie you are trying to push Python in
the 'yet another hammer' concept rather than treating it as a shiny newly
invented tool used by many others already).

Unlike what you think, all languages including Java and C# have their
weaknesses. However, you can only see weak points from outside the Java/C#
world (by knowing other languages that handle the same problems in a better
way).
(sorry if I offended you with the last bit, I did not intend to attack you
personally, just trying to provoke you enough to make you wonder about your
implicit assumptions.)

Sincerely,
Albert

Jun 27 '08 #11

P: n/a
On May 6, 12:09*pm, jmDesktop <needin4mat...@gmail.comwrote:
On May 6, 10:26*am, "A.T.Hofkamp" <h...@se-162.se.wtb.tue.nlwrote:
On 2008-05-06, jmDesktop <needin4mat...@gmail.comwrote:
Studying OOP and noticed that Python does not have Interfaces. *Is
that correct? *Is my schooling for nought on these OOP concepts if I
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.
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
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).
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 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,
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) ?
Jun 27 '08 #12

P: n/a
Mike Driscoll wrote:
On May 6, 8:44 am, jmDesktop <needin4mat...@gmail.comwrote:
>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/tutor...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
--
Jun 27 '08 #13

P: n/a
Arnaud Delobelle skrev:
jmDesktop <ne***********@gmail.comwrites:
>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.

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

Jun 27 '08 #14

P: n/a
jmDesktop wrote:
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.
Zope has an implementation of interfaces that Zope 3 and Twisted both use if you
want to take a look.

http://www.zope.org/Products/ZopeInterface

Frankly, I've never missed them.

-Larry

Jun 27 '08 #15

P: n/a
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 !-)
Jun 27 '08 #16

P: n/a
jmDesktop wrote:
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

--
BOFH excuse #424:

operation failed because: there is no message for this error (#1014)

Jun 27 '08 #17

P: n/a
On 7 mai, 18:05, Bjoern Schliessmann <usenet-
mail-0306.20.chr0n...@spamgourmet.comwrote:
jmDesktop wrote:
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.
It isn't.
Jun 27 '08 #18

P: n/a
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 ;)
Jun 27 '08 #19

P: n/a
On Wednesday 07 May 2008 03:19:30 pm Daniel Marcel Eichler wrote:
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 achievea
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)

--
Luis Zarrabeitia (aka Kyrie)
Fac. de Matemática y Computación, UH.
http://profesores.matcom.uh.cu/~kyrie
Jun 27 '08 #20

P: n/a
On 7 mai, 21:19, Daniel Marcel Eichler <onsen-n...@gmx.netwrote:
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.
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 ?-)

Jun 27 '08 #21

P: n/a
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.
Jun 27 '08 #22

P: n/a
Am Donnerstag 08 Mai 2008 00:12:26 schrieb
br*****************@gmail.com:
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.
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 ?
You never can't say when it's called at least, that's the point.
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 ?-)
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.
Jun 27 '08 #23

P: n/a
On Thu, 2008-05-08 at 09:12 +0200, Daniel Marcel Eichler wrote:
Am Mittwoch 07 Mai 2008 21:48:56 schrieben Sie:
That's the point. Interfaces garantee that a duck is a duck, an not
only a chicken that quack.
Which, in spite of your rhetorical flourish, is the exact opposite of
duck typing. Duck typing means that if you're looking for quacking
behavior, and you find a quacking chicken, it's close enough.

I didn't said that interfaces are a kind of duck-typing. In fact it was
the exact opposite.
Sometimes you need that kind of rigor, and you can get it as easily
as

And sometimes you need more. So what?
More rigor than Zope's interfaces offer? That's new information to me.
Perhaps you should stop being argumentative for a moment, and explain
exactly what it is you're looking for and why Zope interfaces don't fit
the bill.

Jun 27 '08 #24

P: n/a
On Thu, 2008-05-08 at 13:25 -0400, J. Cliff Dyer wrote:
On Thu, 2008-05-08 at 19:11 +0200, Daniel Marcel Eichler wrote:
Am Donnerstag 08 Mai 2008 13:02:52 schrieb J. Clifford Dyer:
I didn't said that interfaces are a kind of duck-typing. In fact it
was the exact opposite.

Sometimes you need that kind of rigor, and you can get it as
easily as

And sometimes you need more. So what?
>
More rigor than Zope's interfaces offer?
Did i say that? I only explained why interfaces are not 'simple method
stubs'.

Um. Yes. I said "sometimes you need that kind of rigor," and proceeded
to explain how zope interfaces offer it. (which you snipped from your
quotation), and you said "sometimes you need more." If you were
actually responding to what I said, then "sometimes you need more" must
mean more than zope interfaces.
That's new information to
me. Perhaps you should stop being argumentative for a moment, and
explain exactly what it is you're looking for and why Zope interfaces
don't fit the bill.
Perhaps you should read more accurate. It's not my thread and i'm not
looking for anything here.

Then what were you trying to say?
--
Oook,
J. Cliff Dyer
Carolina Digital Library and Archives
UNC Chapel Hill

Jun 27 '08 #25

P: n/a
Daniel Marcel Eichler a écrit :
Am Donnerstag 08 Mai 2008 00:12:26 schrieb
br*****************@gmail.com:
>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.
Then providing an appropriate default in the base class is enough too.
>>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 ?

You never can't say when it's called at least, that's the point.
Either the method is actually called somewhere and you'll now it pretty
soon, or it isn't and you don't care.
>>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 ?-)

Ducks can also swim and fly. And if you need a really duck,
If you're code expects something that quacks, swims and flies, anything
that quacks, swims and flies is ok. You just don't care if it's a duck
or a flying whale with a quacking device tied to it.
but have
onyl a chicken while the coder was to bored to make one...
Then the coder have a nice traceback, and it's not *your* problem - as
long as the expectations are clearly documented, it's the user's (ie:
coder) duty to provide something that fullfil the expectations.
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.
Sorry, I live in a very practical world - and we're by no mean running
out of business here...

Jun 27 '08 #26

P: n/a
Am Freitag 09 Mai 2008 10:19:45 schrieb Bruno Desthuilliers:
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.

Then providing an appropriate default in the base class is enough
too.
Only working *if* there is a base-class, and not only convention for
should-have-methods.
>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 ?-)
Ducks can also swim and fly. And if you need a really duck,

If you're code expects something that quacks, swims and flies,
anything that quacks, swims and flies is ok. You just don't care if
it's a duck or a flying whale with a quacking device tied to it.
Not the point.
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.

Sorry, I live in a very practical world - and we're by no mean
running out of business here...
Like i said.
Jun 27 '08 #27

P: n/a
On May 9, 1:53 pm, Daniel Marcel Eichler <onsen-n...@gmx.netwrote:
Am Freitag 09 Mai 2008 10:19:45 schrieb Bruno Desthuilliers:
>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.
The application has already failed. You'd prefer it silently do the
wrong thing than get an explicit error message and stop?

>>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 ?-)
Ducks can also swim and fly. And if you need a really duck,
If you're code expects something that quacks, swims and flies,
anything that quacks, swims and flies is ok. You just don't care if
it's a duck or a flying whale with a quacking device tied to it.

Not the point.
It really is. They're only going to give you something they expect to
work. They might occasionally make a mistake and give you garbage,
but it's not worth the effort of trying to catch it early.

Jun 27 '08 #28

P: n/a
I would suggest that using an interface at compile time is not the
only approach. Unit tests can be run on classes to check that they do
indeed quack.
--
Pete Forman -./\.- Disclaimer: This post is originated
WesternGeco -./\.- by myself and does not represent
pe*********@westerngeco.com -./\.- the opinion of Schlumberger or
http://petef.22web.net -./\.- WesternGeco.
Jun 27 '08 #29

This discussion thread is closed

Replies have been disabled for this discussion.