[Types-sig] Re: [Python-Dev] Revive the types sig?

[Michel Pelletier]

Prelude:

  I've just been digging a bit through the types-sig archives.  Aye carumba,
  we are opening a big-arsed can of worms up here.

  In a way, we may be leading ourselves down the same path of confusion,
  maybe what we need here is a very high level description of vision, scope,
  and goals, perchance a use case or two.  At DC, we like to do these things
  in Wikis so that they don't get lost in the archives.  I'd be happy to
  create a Wiki for this.


On Sun, 11 Mar 2001, Paul Prescod wrote:

> Michel Pelletier wrote:
> >
> > I could be way over my head here, but I'll try to give you my ideas.
>
> You're not over your head and I'd like to invite you to the types-sig.

Just subscribed, thanks!

> I strongly believe that interfaces are a Good Thing. If you DC guys
> weren't working on them I'd spend my own time working on them. But they
> in no way solve the problems of the rest of the types-sig. There are
> many open problems:
>
>  * what is the syntax for describing parameters to an interface?

There isn't one as they ride piggy-back on the syntax of a class.  If they
had their own syntax, that could change.  But the framework *does* support
the notion of tagging any interface element with any kind of data, like
UML.  One of these tagged bits could easily be a parameter description of
any kind, like type, pre/postcondition, unit test, example code, links to
external resources etc.  How this is spelled in syntax is not defined, and
for many things (perhaps other than type) it should not have a syntax.

>  * what is the type hierarchy (or dag) underlying that syntax?

Ya lost me there.

>  * how do we unify the type, class and interface worlds?

These seem like seperate issues to me.

>  * how do we specify the parameters of functions that are NOT on
> classes.

Good point, interfaces don't do that.  But now that I think about it, it
seems possible, I've just never thought about it.  The interface package
defines and object that describes methods/functions.  I don't see why this
object can't be associated with a function now that we have function
attributes.

def foo()
  pass

foo.__impliments__ = FooInterface

>  * how do we specifry the parameters of classes that do NOT have
> associated interfaces?

By associating them with an interface. ;)

> > Also, type checking in general is good, but what about preconditions (this
> > parameter must be an int > 5 < 10) and postconditions and other conditions
> > one does now with assertions.  Would these be more language extensions in
> > your propsal?
>
> One of my governing philosophies about type systems is that you can
> always make them more complex/sophisticated. I don't see that pre and
> post-conditions are so important that they need first-class syntax.
> Assertions are sufficient.

Agreed.  I didn't make my point clear though, interface objects can be
tagged with any kind of data, like UML.  Itamar (a Zope developer) just
sent me code that creates pre/postcondition objects that you can tag on an
interface.  Granted there's no syntax for it, and there shouldn't be, but
the interface framework is extensable in that way.  That's what I *meant*
to say. ;)

> To recap:
>
> How do we do parameter type declarations in scarecrow?

There's no syntax, but an API.  But wait... maybe there can be the same
syntax on both (classes and interfaces), and people can take or leave
interfaces and/or class type checking based on their needs.

We (DC), for example, badly need type checking on many of our methods that
expect input the web.  Some sneaky security attacks (and a whole lot of
bugs) have been discovered based on passing a different kind of object to
a through-the-web method than was expected.  Fixing these with assertions
was laborous.

We would probably go the define-it-in-the-interface type checking because
we're going to create interfaces on all our network-exposed components
anyway.  Others could define their type checking right in the class if
they have no need for an interface.

> How do we do return type declarations in scarecrow?

Same answer as above.

I definitely need to read the four (four!?)  proposals that exist already.
It seems like there are three high level things that were discussed in the
type sig:

  Type Checking

  Interfaces

  Type/Class split

A pandora's box indeed.  Maybe we should take Jim's suggestion and keep
them seperate?

http://mail.python.org/pipermail/types-sig/1999-December/000250.html

-Michel