[Types-sig] Shadow File Opinions?

Martijn Faassen m.faassen@vet.uu.nl
Wed, 15 Dec 1999 10:39:34 +0100

Paul Prescod wrote:
> Martijn Faassen wrote:
> >
> > ...
> > While my agenda is to kill the syntax discussions for the moment, I'd
> > propose a seperate declaration syntax before all others, because this is
> > the most syntactically compatible with Python. And easier on the
> > programmer.
> I'm considering your argument carefully. If we make separate interface
> files then we get Python 1.5 (hell, Python 1.0) compatibility "for free"
> and we can experiment with different syntaxes without breaking Python
> code. Plus we could use IDL and type libraries for type analysis
> *already*.
> I think the final product must allow inline declarations but I am
> starting to think that in the short term, "interface definition" files
> are the way to go not just for builtin modules but for all modules.
> Do others agree?

I agree. I'm not sure I'm others, though. :)
> > Imagine you have a module. Now you want to make it fully statically
> > typed. With most syntax proposals I've seen you'd have to go through the
> > code and add type declarations here and there, mix it with the current
> > code.
> I think that any proposal that requires you to keep two separate files
> "in sync" is bound to fail in the long term. I left that crap behind in
> C++. But in the short term...okay.

Right - in the longer term we'll have a nice syntax, but it's too soon
for syntax right now.

> > With either a Python based system as I'm proposing (ugly but powerful
> > and fairly simple), or a seperate type declaration system, you have your
> > type declarations separated from the code itself. This means you easily
> > add and remove type information and switch between a statically typed
> > module and a dynamically typed module easily.
> But there is not going to be alot of "switching". You add declarations
> and you leave them there. You update them when they get out of sync with
> the code. Why would you want to take a nice, safe, optimized module that
> you have gone to the effort of type annotating and hide the annotations?

Hiding the annotations may be useful (on the short term, at least). You
can use existing the Python interpreter to test your module even if you
have added type annotations. That's nice for development/debugging,
including the development and debugging of the type annotation system.
You can say 'hey, Python does this to my code when I only pass strings
in, but our static type checker/compiler/asserter barfs at it'. If you
have Python code already sprinkled with annotations you need two source
files for the same module, one with annotations, one without. You can
automate this but it's not as nice.