[Types-sig] minimal or major change? (was: RFC 0.1)

[Martijn Faassen]

Tim Peters wrote:
> 
> [Martijn Faassen, reasonably demands ...]
> > So that's where I'm coming from. It's important for our proposal
> > to actually come up with a workable development plan, because
> > adding type checking to Python is rather involved. So I've been
> > pushing one course of implementation towards a testable/hackable
> > system that seems to give us the minimal amount of development
> > complexities. I haven't seen clear development paths from others
> > yet; most proposals seem to involve both run-time and compile-
> > time developments at the same time.
> >
> > So I'm interested to see other development proposals; possibly
> > there's a simpler approach or equally complex approach with more
> > payoff, that I'm missing.
> 
> I haven't given a lick of thought to development, beyond sketching "the
> usual" approach to type inference for Guido, and having a hard-won intuition
> about what is and isn't reasonably parseable.  This SIG has been "alive
> again" for on the order of just one week:  design precedes implementation,
> and I won't bemoan the lack of implementation details even if they're
> delayed for *another* whole week <wink>.

Of course I can wait a couple of weeks longer. :)

Now I'll add some buts:

But implementation possibilities do influence design. I wasn't asking
for actual implementation proposals, I was thinking about how to go
about development. What brings us early payoffs. What is most effective
and least complex. What development difficulties may appear that we
simply can't avoid (so we can brace ourselves :). 

> At that point, it's fine by me if the first cut is *spelled* using plain
> dicts and docstrings etc to ease development.  But before that point, we
> don't even know what we want it to *do*.

remember-there-something-called-'prototyping'-ly yours,

Martijn