[Types-sig] check.py (was: PyDL RFC 0.02)

[scott]

On Tue, Dec 28, 1999 at 10:52:56PM -0800, Greg Stein wrote:
> On Wed, 29 Dec 1999, scott wrote:
> >...
> > While there may be a lot of value in walking the parse tree as your
> > checker does, it doesn't seem to do much in terms of what I expect out
> > of a type checker.  
> 
> It isn't done. I thought that I made that very clear. It provides a

I was just working under the assumption that if it was a complete
framework -- filled in or not, there'd be a way to do things like
declare types.  Then I threw a couple of off-the-cuff basic things at
it, and it didn't do well, so I figured it wasn't done enough to
warrant a basic framework to develop on.

While I still sortof feel that way, your message has made a lot of
what's going on in check.py more clear -- and shows some really cool
things about one approach to it all.

So we all know that exactly how .pyi info and embedded declarations
maps runtime namespaces is a touchy issue -- we can't really account
for exec, and there are lots of things which may act odd, such as
get/set-attr hooks and global and del what not that can cause some
real issues.

We also know that whatever inaccuries or mismatches there might be
between the picture of runtime namespaces available at compile time
and how they work at runtime will probably become a royal pain in the
ass down the road.

So check.py uses the parser module to gain a pretty darn accurate
picture of runtime name spaces via the parse tree.  That's a *very*
good thing when compared to some half-assed namespace picture that
sortof works like you expect, but is bound to blow up in way too many
cases and create reams of new faqs down the road.

It also has some drawbacks:  it's a little awkward to have compile
time activity depend so heavily on a module that is optional.  Also,
compile-time activity IMO is rightly done in C (or Java or whatever)
and not in the language that is being interpretted, though prototyping
can of course be anything.  The module seems to be built primarily for
availability from within python, and not so much from the interpreter
itself; while the end product seems like it should be (mostly atleast)
in the interpreter itself.  

The list of drawbacks goes on a bit, but all the points rest on one
question that I'm not sure of:  Does the framework presented in
check.py actually depend on the parser module, or is this just a
functional relationship that can be met by some reasonable alternative
means in the interpreter itself? 

scott