Am I missing something with Python not having interfaces?

[J. Clifford Dyer]

Am Mittwoch 07 Mai 2008 21:48:56 schrieben Sie:


I didn't said that interfaces are a kind of duck-typing. In fact it was
the exact opposite.


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.

 

[J. Cliff Dyer]

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.


Then what were you trying to say?

 

[Bruno Desthuilliers]

Daniel Marcel Eichler a écrit :

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


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.

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.

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

 

[Daniel Marcel Eichler]

Am Freitag 09 Mai 2008 10:19:45 schrieb Bruno Desthuilliers:

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.

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.

Sorry, I live in a very practical world - and we're by no mean
running out of business here...

Like i said.

 

[Rhamphoryncus]

Am Freitag 09 Mai 2008 10:19:45 schrieb Bruno Desthuilliers:

The application has already failed. You'd prefer it silently do the
wrong thing than get an explicit error message and stop?

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.

 

[Pete Forman]

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.