[Types-sig] Re: PRE-PROPOSAL: Python Interfaces

Jim Fulton jim@Digicool.com
Sat, 21 Nov 1998 18:17:20 +0000

Note that this discussion should move to the Types SIG:
http://www.python.org/sigs/types-sig/.  I am cross-posting to
types-sig@python.org.  Replies should be made to types-sig and omit

John (Max) Skaller wrote:

>         Next: examine the protocols module in interscript.core.
> [It itself has a documented protocol -- a meta protocol?]
>         It attempts to associate a tag with a documented protocol
> specification, and lets you attach the tag to objects obeying that
> protocol; and thus do run time tests for protocol adherence.
>         This is _not_ the full scale category theory based
> solution for Python: but it is a practical start to experiment
> with protocols that doesn't require any changes to python,
> and can support all the existing objects and protocols ..
> including all third party ones -- without any changes to them.
> [to see how .. look at the module!]
>         Here is an example that conforms to the protocols
> protocol :-)
>         # a 'sink' is an object that support a writeline
>         # method that ......
>         class Sink:
>                 __class_protocols__ = ['sink']
>                 def writeline(self):
>         ...
>         from interscript.core.protocols import has_protocol
>         def writefile(data, output):
>                 if has_protocol(output, 'sink'):
>                         output.writeline(data)
>                 elif has_protocol(output, 'file'):
>                         output.write(data + '\n')
>                 elif has_protocol(output, 'string'):
>                         file = open(output, 'a')
>                         file.write(data + '\n')
>                         file.close()
>                 else:
>                         raise "output must be filename, open file, or sink"
> The 'writefile' function is generic (polymorphic) in the sense that
> it can be called with a sink, an open file, or a filename.
> NOTE: a 'file' is not just a python file object. It is any object
> with a write method -- which claims to be a file.
> Similarly, a 'sink' is not an instance of class Sink:
> it's any object with a suitable writeline() method, that claims
> to be a sink.
> There is a nasty 'case switch' in the module. THIS IS BAD!!!
> But what is good is that it switches on protocol -- not on type.
> So it is 'an order of magnitude' better than type casing,
> even if the technology is still wrong.
> What this example shows is that 'writefile' is in some sense has a protocol,
> related to the 'sink', 'file', and 'string' protocols.
> To get rid of the case switch, what we do we need?
> I think we need protocol categories to define the relationships
> between protocols. I'm working on it. :-)

It looks to me like your protocols idea is pretty close
to the "scarecrow" proposal, which is sketched out in:


I think that, at lease at the start, we are on the same wavelength.

Some differences between the "scarecrow" proposal and your 
protocols idea:

  - in the scarecrow proposal classes need not inherit 
    interface (protocol) conformance from base classes, and

  - interfaces are objects, not just string tags.

Note that interfaces are arranged in a separate hierarchy
(from classes), which perhaps allows them to provide the 
categorization you talk about above.

Jim Fulton           mailto:jim@digicool.com
Technical Director   (540) 371-6909              Python Powered!
Digital Creations    http://www.digicool.com     http://www.python.org

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for

Types-SIG mailing list