[Types-sig] type declaration syntax

[Tim Peters]

For whatever reason, "xxx" sent the attached to me in email, but not to the
SIG.  Since it's relevent, I'm passing it on.

yes-their-name-really-is-xxx<wink>-ly y'rs  - tim


-----Original Message-----
From: xxx
Sent: Sunday, December 19, 1999 12:53 AM
To: Tim Peters
Subject: Re: [Types-sig] type declaration syntax

On Sat, Dec 18, 1999 at 03:56:44PM -0500, Tim Peters wrote:
> [John Skaller]
> > ...
> > But the _return_ type doesn't need to be annotated as much.
> > Why? Because the inferencer can usually deduce it:
> > it's an output, the argument types are inputs.
> >
> > If the inferencer _cannot_ deduce the return type,
> > it _also_ cannot check that the function is returning
> > the correct type.
>
> "The" correct type (as opposed to "a type consistent with the
> operations") is impossible for an inferencer to determine, but
> this is addressed more to the SIG than to John <wink>:
>
> My bet is that the vast majority of Python people asking for
> "static typing" have in mind a conventional explicit system of
> the Algol/Pascal/C (APC) ilk, and that decisions based on what
> *inference* schemes can do are going to leave them very unhappy.

If this is so, I am a member of the majority.

> Inference schemes commit two kinds of gross errors that the APC
> camp won't abide:
>
> 1) Inferring types that aren't general enough.
> 2) Inferring types that are too general.

I always had more trouble following the inferencer in ml than simply
declaring everything as in C.  I think we should aim at one thing, a way to
declare types, and what the different types will be.  Once there is a
standard for this in core python, a myriad of tools from optimizers to code
checkers to cross-language compilers will become much more feasible.  A type
inferencer is one of those things, and it could be built for those who
wished to have their types inferenced from a minimal set of type
declarations.

xxx