join()

[Quinn Dunkan]

On Sat, 07 Oct 2000 01:36:19 GMT, Huaiyu Zhu <hzhu at users.sourceforge.net>
wrote:
>What is really needed is an abstraction mechanism, so that we can define the
>abstract form AFTER the special forms.  This way, somebody someday may say:
>Hey, I need a writable file here, and I can use any of open(name,"w") kind
>of objects, or sys.stdout, or MyOutStream, or any other object with a write
>method - and he promptly defines WritableFile, and specifies these cases.

A bit OT, but:

Sounds like supertyping, which you can do in sather.  I.e., you can not only
say which classes your class subtypes from, but also specify its supertypes in
the same place.  It's really intended as a hack to support the situation when
subtyping would be the proper solution, but you're using a library you don't
want to modify.  But sather also tries to be type-safe, and any type-checking
extension to python will have to recognize that if people really wanted
complete type-safety they'd be better off with another language :)

BTW, sather also makes a distinction between subtyping and code inclusion.
You can only subtype from an abstract class (with just a signature, no actual
code).  You can include code from anywhere, but it's mostly just a textual
inclusion (not quite like from blah import *).

This is different again from haskell, in which classes and types are seperated
(a class is a collection of types).  A function can say it wants a type in a
certain class, and at any time you can make any type you want into an instance
of that class by defining the class's signature for your type.

The python approach to interfaces is:

def f(fp):
    # declare that f() expects an object with a 'write' method
    if not hasattr(fp, 'write'):
        raise Attribute, 'write'
    ...

except that the interpreter will do this for you :)  Ok, ok, so it doesn't
express more abstract things about the object, but python programmers seem to
be basically down-to-earth guys :)