[Types-sig] PyDL RFC 0.02

[scott]

On Mon, Dec 27, 1999 at 04:55:08AM -0800, Greg Stein wrote:
> Only a few quick comments for now...
> 
> On Mon, 27 Dec 1999, Paul Prescod wrote:
> > PyDL RFC 0.02
> 
> PyDL ?!
> 
> Don't tell me "Python Definition Language." That is the wrong semantic...
> you're talking about an "inteface file", not a language.
> 
> I'd seriously recommend a new acronym before you confuse people :-)
> 
> .pyi or something.

One thing to consider is that windows/dos users can't have a 4-char
suffix on a file name reliably.  

I like .pyi as greg suggests.  The shorter the suffix, the better IMO.

> 
> >...
> > The Python interpreter invokes the static interface interpreter and
> > optionally the interface checker on a Python file and its associated
> > PyDL file.  Typically a PyDL file is associated with a Python file
> > through placement in the same path with the same base name and a
> > ".pydl"  or ".gpydl" extension. If both are avaiable, the module'sj
> > interface is created by combining the declarations in the ".pydl" and
> > ".gpydl" files.
> 
> The notion of two types of files just adds complexity. There is no reason
> that a generated file would be *any* different in form/syntax than a
> human's file. The human just gets to add funky comments, indentation, etc.
> 
> In other words: design around a single file.

Greg, are you suggesting a single file which gets generated type info
appened automatically?  If so, I don't see it being harmful.  A simple
comment header denoting the beginning of machine generated info would
suffice IMO, and it would facilitate some of the problems with working
with extra files... like permissions denying writes of the interface
file and what not.

> 
> >...
> > Once it interprets the Python code, the interface objects are
> > available to the runtime code through a special namespace called the
> > "interface namespace". This namespace is interposed in the name search
> > order between the module's namespace and the built-in namespace.
> 
> Search *another* namespace? Eek! We're already seeing people avoiding the
> time with things like:
> 
>   def foo(len=len):
>     ...
> 
> Adding another namespace will just exacerbate the situation.
> 
> I don't recommend adding another distinct namespace, but *IF* you are
> going to do so, then I might suggest that it is only available for use
> from withing a typedecl.

I believe greg has a good point here.  But I also think another
namespace gives us a good degree of flexibility in development.
Perhaps the extra namespace could also just be available at runtime
iff python is invoked in such a way as to run type checking and
interface interpretting (not the default).  just another way to
possibly minimize the extra lookup overhead.

Another idea:

Perhaps an additional attribute or set of attributes would achieve a
similar level of modularity of the type checking system?  For example,
maybe each existing namespace could have an __interfaces__ attribute
or __types__ or something that would contain the type information
without affecting lookup time of builtins so much.  Intuitively, this
seems like something which could be extended in the future to work
with local namespace type checking or optimization more easily.

This area could use some more specification before we start anything
too serious, IMO.  I think modularity of this type checking is
important because it seems like it will facilitate making the
necessary changes as time goes on: a potential big efficiency winner
in the ongoing development of type checking.

> 
> >...
> > 5. Declare un-modifiability:
> > 
> > const [const Array( Integer )]
> > 
> > (the semantics of un-modifiability need to be worked out)
> 
> Wasn't the notion of "const" (successfully) argued against inclusion?

Any pointers to this discussion?

scott