[Types-sig] Syntax

[Tony Lownds]

On Sat, 18 Dec 1999, Paul Prescod wrote:

> Tim Peters wrote:
> > 
> > [Martijn Faassen]
> > > While my agenda is to kill the syntax discussions for the moment,
> > > ...
> > 
> > Martijn, in that case you should stop feeding the syntax meta-discussion and
> > just view all the other notations as virtual spellings for masses of obscure
> > nested dicts <wink>.
> 
> Let me point out that it was the masses of obscure nested dicts that I
> was objecting to when I told Greg that the syntax cannot be restricted
> to Python (by which I meant Python 1.5). Obviously, by definition any
> syntax that we use for Python 2 becomes "Python". In fact, I don't see a
> lot of difference between the widely embraced Tim-syntax and the syntax
> I posted a few days ago (based on the Tim-syntax). But if putting the
> keyword "decl:" in front makes it feel better then I'm all for that!
> 
> I'm still thinking that it should go in another file because I want to
> be able to experiment with this stuff WITHOUT maintaining a new Python
> interpreter binary.
> 

I think it'd be possible to put type declarations in-line without using a
new binary, at least in the short term:

1. make a module that overloads __import__()

2. when a module is imported it asks the syntax handler to parse the file 
and generate a plain .py file and a .pi (ie "interface") file with
appropriately nested dicts in it.

3. Then it asks the type checker to make sure the .pi and .py match up.
The type checker may need to call __import__() recursively.

4. Then, __import__() should import the generated .py file.


There are a few caveats I can think of:

a. eval/exec/execfile couldnt use type declarations

b. The outputted .py file would basically be stripped of type
declarations, nothing would be added to it. A full-blown system might want
to add runtime type checks.

c. The syntax handler wouldn't get to use Python's parser "for free".


-Tony