[Types-sig] Apologies and proposal

scott scott@chronis.pobox.com
Sun, 27 Feb 2000 19:51:10 -0500

While I'm all for putting in what we can as soon as possible, I have
some reservations about pushing ahead on 20% of the goals.
Specifically, I don't think the remaining 80% have been thought
through well enough to know how we can accomplish 20% without really
damaging the potential of static types.  The issues are subtle and
complex, and, I have found even seemingly innocent assumptions about a
static type system can cause all kinds of problems in an overall

That said, I'm all for 20% now, I just don't want to see any
assumptions about a static type _system_ in that 20%, and I'm not sure
how useful 20% would be if it were really future proof.

Also, I may well be in the minority here, but there's a problem with
releasing software before it's overall design is done -- you have to
support things in a backwards compatible way, and backwards-compatible
is usually patently broken. Even if you say you won't make that
commitment, the temptation is strong.  I don't want static types for
python to end up even harder to do than it needs to be, even if that
means wait for a while.


On Sun, Feb 27, 2000 at 10:55:59AM -0800, Paul Prescod wrote:

> What I would like to ask you participants is whether we our first goal
> should be to push ahead with an end-game proposal or rather push for an
> incremental 20/80 proposal. Arguably, the most pythonic 20% of "ERR" is
> helping people to avoid simple mistakes like passing lists where strings
> are expected and mappings where lists are expected and the most pythonic
> 20% of "OPT" is being able to map integers to C/Java integers, strings
> to C/Java strings and so forth. And I think that "DOC" is similar. And
> of course the point of 20/80 is that we should get a huge amount of
> benefit for the small investment and then worry about the rest of the
> enchilada later.
> If I'm right, then we should consider moving as quickly as possible (1.6
> or 1.7) to providing that 20% and using it as input in our decisions on
> the hard 80%. I hear screams of pain on the mention of 1.6 but I would
> prefer that we didn't rule it out until we think through what the actual
> implementation costs are. Maybe all we do in 1.6 is change the grammar
> so that we have that experimentation with checkers and introspectors is
> possible.
> Here is a minimal proposal:
>  * inline declarations (either using "decl" or really inline in function
> defs)
>  * checked at runtime depending on command line option
>  * there is a syntax for declaring the type objects and methods in an
> extension class
>  * declarations can refer to class objects or "reflected" type objects
>  * declarations can also refer to a finite set of pre-declared
> "protocol" or "interface" objects: mapping, sequence, file/stream,
> number, callable, type.
>  * we adopt VERY conservative rules about what class objects can be
> referred to so that we can later debate about extending them to objects
> that are not trivially available at runtime.
> Among the issues we would not address:
>  * exception declarations
>  * templates
>  * user defined interfaces/protocols
>  * signatures
>  * er, static type checking
> Okay, arguably if we don't do static type checking then we have failed
> to meet our goals. But we could also see the laying down of
> infrastructure TOWARD static type checking as being part of the
> framework. We should explicitly NOT allow anything in our proposal that
> would prevent static type checking but we should also not expect that in
> version 1 we will do the full inter-module, inter-class analysis that is
> required to do static type checking "right".
> I was brought in to do a "minimal proposal" and it was the requirement
> that we work out all details of completely safe static* type checking
> that 
> brought in all of the complexity. Once you say that you need to be able
> to check an "average module" at compile time you invariably bring in
> a huge load of issues because the "average module" does alot of 
> method calls and then we get into issues of subtyping, genericity etc.
> I want to get back to minimalism and to me that means jettisoning 
> compile time safety except (perhaps) for trivial functions/methods
> that work only on simple inputs.
> (still, in terms of 20/80 OPT, there may be a lot you can do with 
> "inner loops" that use only simple types)
> Implementation would require a change to the grammar, some extra
> information attached to method objects (perhaps just a list of parameter
> type pointers), an extra check at runtime (a loop over the args and the
> type pointers, maybe even implemented as a bytecode hack).
> At its heart, the goal of this proposal is to provide a standard syntax
> for static type declarations which can be used by tools *like* static
> type checkers, documentation engines, reflection engines, and runtime
> type checkers. It doesn't matter much whether we use a new syntax, or
> docstrings but I think that the interpreter needs to make that
> information available at runtime and it should probably have optional
> runtime checking as *an inducement* to actually doing the declarations. 
> So the four central goals would be:
>  * syntax for a simple subset
>  * API for reflection
>  * runtime checking based on the API
>  * do not cut off path to external static checking tool
> If someone *writes* a static type checking tool "in time" (whatever that
> means) then it should go in the tools directory. 
> In my opinion, though, any tool built on this basis should be consider 
> "static type checking lint" because we haven't yet said what is or 
> is not legal in terms of dozens of subtle, tricky issues such as 
> runtime instance modification, subclass method overrides 
> (contravariant, covariant), exception handling etc. etc.
> -- 
>  Paul Prescod  - ISOGEN Consulting Engineer speaking for himself
> "The calculus and the rich body of mathematical analysis to which it
> gave rise made modern science possible, but it was the algorithm that
> made possible the modern world." 
>         - from "Advent of the Algorithm" David Berlinski
> 	http://www.opengroup.com/mabooks/015/0151003386.shtml
> _______________________________________________
> Types-SIG mailing list
> Types-SIG@python.org
> http://www.python.org/mailman/listinfo/types-sig