ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> types-sig
types-sig
RE: [Types-sig] Re: PRE-PROPOSAL: Python Interfaces
by Tim Peters other posts by this author
Nov 24 1998 9:18PM messages near this date
RE: [Types-sig] Re: PRE-PROPOSAL: Python Interfaces | [Types-sig] Re: PRE-PROPOSAL: Python Interfaces
[Barry A. Warsaw]
>  ...
>  I want a different kind of error to get thrown when a class
>  says it implements a particular interface, but in fact neglects
>  to.  If I have a class List that claims to implement interface
>  Stack, but in fact does not provide an implementation of pop()
>  or push(), I don't want an AttributeError when I call one of
>  those methods on an instance of List.  I want something like
>  NotImplementedError.  I think this important enough to guarantee
>  in language spec.
> 
>  Tim also wants to allow implementation in an interface
>  definition, because some methods can be defined solely in terms
>  of other methods in the interface.  That seems fine to me.

As we discussed on the egroups version of this, if interfaces allow
supplying impementation, then

    from InterfaceSupport import deferred

    class Stack(Interface):
        def push(self, thing): deferred()
        etc

would make everyone who *claims* to implement Stack pick up the (presumably
error-raising) Stack.push "deferred()" implementation if they don't supply
their own (or inherit some other) real implementation of push.

>  ...
>  I think the same approach will have to be taken with the core
>  w.r.t. interfaces.  Keep the set of interfaces defined by the
>  core as shallow and small as possible, but provide enough rich
>  mechanisms so that applications can build higher level stuff
>  easily.

I expect the core will end up with a shallow but large set of interface
tags, because tiny pieces of the implementation get reused in funky ways in
the current folklore interfaces.  Like "for x in thing" requires a
thing.__getitem__ that accepts an integer argument and either returns a
value or raises IndexError, but uses no other properties of "a sequence"
(not even __len__!).  That little piece should be given a name, and the
Sequence interface should specifically say that it implements it.

Similarly. whether a thing supports "len(thing)" is a teensy piece of
behavior that's not unique to Sequence (e.g. Map supports it too, and any
number of user-defined classes that aren't intended to be Sequence or Map).

Maybe we should name these mini-interfaces HasAttr__getitem__ and
HasAttr__len__ <wink> .

healing-the-type/class-split-would-make-it-simpler-ly y'rs  - tim
Thread:
Barry A. Warsaw
Barry A. Warsaw
Jim Fulton
Barry A. Warsaw
Tim Peters
Tim Peters

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved