[Python-Dev] type categories

[Alex Martelli]

On Sunday 25 August 2002 00:14, Oren Tirosh wrote:
> On Sat, Aug 24, 2002 at 11:33:38PM +0200, Alex Martelli wrote:
> > > I am not talking about situations where the object does not meet your
> > > expectations and needs to be adapted - I'm talking about situations
> > > where it actually does and the only problem is how to describe that
> > > fact properly.
> >
> > Adaptation IS one way to "describe that fact properly", given that
> > checks are anyway constrained to happen at runtime.  You just install
> > an adapter from objects x of class X to protocol Y that receives x as
> > an argument and whose body is just "return x" -- that's all.
>
> I don't take it as given that "checks are anyway constrain to happen at
> runtime". I prefer a system that is future-proof enough to evolve into
> something that the compiler can use to do type inference. That is one

A compiler able to do type inference had better be smart enough to
recognize the special-case pattern:

def noadapt(obj, proto): return obj
install_adapter(noadapt, someclass, someprotocol)

If that hypothetical compiler is unable to recognize this pattern (with
whatever change of names except for a built-in install_adapter), its
hypothetical type inference is FAR too puny for me to be happy to
pay any substantial price for it.

In particular, defining multiple mechanisms that partially overlap for
the same tasks, for the sole purpose of making it hypothetically and
marginally easier to draw the sole distinction of compile time versus
runtime, IS a substantial price to pay in term of language complication.

Conceptual distinctions between compile time and runtime are already
"a price".  One that may be worth paying, in general, for performance and 
in order to get error messages earlier.  But, I think, one we should be
quite wary to _extend_ -- particularly to extend to areas where we might
well get away WITHOUT paying it.


> time or at module load time. Renaming and reordering really does have to
> be done at runtime in a dynamically typed language.

Not necessarily, given _decent_ (hypothetical) type inference.  The
hypothetical decent type-inferring compiler would know about the
install_adapter builtin.  It could then hypothetically special-case
method renaming by recognizing in the adapter pure-renaming
patterns such as:

    def interfacemethod(self, *args): return self.obj.objmethod(*args)

and generate code suitably when it recognizes that a given adapter
does nothing but renaming.  Blue-sky to some extent, but that sort
of thing IS a good part of what type *inference* is about.


Alex