[Types-sig] Interface PEP

[Marcin 'Qrczak' Kowalczyk]

Fri, 23 Mar 2001 17:41:07 +0100, Sverker Nilsson <sverker.is@home.se> pis=
ze:

> def f(x:y)
>=20
> The question is: what is the y.
>=20
> 1) 'interface'
> 2) 'type'
> 3)  something else

If you call it 'type', it would be confusing, because the builtin
function called 'type' would no longer return the type of the object
(for the new meaning of the term 'type').

> You may counter now that types are close to classes as you claimed
> before, and I agree classes specify specific implementation. But I
> think I showed in the previous mail how types (that is, what type()
> returns) is likely to stay separate from classes

If types and classes are unified but the 'type' function returns
the same thing as currently, it's clear that it is kept only for
compatibility - it has an irregular behavior.

But this is a problem of the 'type' function, not of the unification.

> it would be no gain making them the same

Of course there would be gains: you could inherit from files, and
the language would be simpler and more consistent.

Look: isinstance works for both types and classes. It's because they
describe essentially the same thing: what defines the behavior of
the object.

> So Python types seem to be free to be generalised.

They cannot be generalized to cover the functionality of interfaces.
They can at most be generalized to cover classes.

--=20
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZAST=CAPCZA
QRCZAK