[Types-sig] RE: [meta-sig] The Types-SIG is comatose. Let's retire it.

Paul Everitt Paul@digicool.com
Fri, 3 Dec 1999 13:33:35 -0500


Hey folks, isn't this technical discussion better handled on the
types-sig? :^)

--Paul

> -----Original Message-----
> From: Martijn Faassen [mailto:m.faassen@vet.uu.nl]
> Sent: Friday, December 03, 1999 1:17 PM
> Cc: types-sig@python.org; meta-sig@python.org
> Subject: Re: [Types-sig] RE: [meta-sig] The Types-SIG is 
> comatose. Let's
> retire it.
> 
> 
> Jeremy Hylton wrote:
> > 
> > Paul Prescod proposes a new charter for the types-sig:
> > > * the goal is a optional static type system for version 2.
> > > * presume that the type/class dichotomy has been removed in V2
> > > * backwards compatibility with current code is relatively 
> important
> > > * compatibility with the Python 1.x interpreter is NOT important
> > > * interfaces are not an issue
> > > * parameterized (template) types are not available
> > > * names are type checked, not expressions
> > > * got now, only named types (types and classes) can be 
> declared, not
> > >lists and tuples of types
> > 
> > If you're going to develop a static type system to describe Python
> > programs (optional or otherwise), then I think you can't punt on all
> > the things you want to punt on.
> 
> I probably agree with you (at least partially). See my previous post.
> 
> > > * interfaces are not an issue
> > Yes, they are :-).
> 
> Why, exactly?
>  
> > > * parameterized (template) types are not available
> > They need to be.
> 
> Why, exactly? :)
>  
> > > * names are type checked, not expressions
> > Expressions need type checking, too!  I'm thinking of the "the"
> > special form in Common Lisp.  (I don't have much experience with CL,
> > so I'd appreciate input from someone who is.)
> 
> I'm even less familiar with CL than you are, so I don't know...
> 
> > Regardless of these minor quibbles, my largest complaint is:
> > > * the goal is a optional static type system for version 2.
> > 
> > What exactly is the deliverable.  Saying an "optional static type
> > system" is a bit vague.  What is it specifically?  A formal
> > specification of the type system?  A stand-alone utility 
> that reports
> > type errors?  A new compiler?
> 
> Very good question. We need to agree on a deliverable.
> 
> > If this is a type system for Python 2, it seems that the best a SIG
> > can hope for right now is a specification of the type system
> 
> Unfortunately this kind of goal may be too vague to actually involve
> people. Not being able to try things out in some kind of 
> implementation
> may disconnect the discussion from reality.
> 
> > Since
> > Py2 design hasn't even started.
> 
> When will this start, by the way? Anybody know or is this still pure
> speculation? The conference? I started wondering when I saw 
> this in the
> 'A Date with Tim Peters...' post by Guido on comp.lang.python:
> 
> - a developers' day where the feature set of Python 2.0 is 
> worked out. 
> 
> Regards,
> 
> Martijn
> 
> _______________________________________________
> Meta-sig maillist  -  Meta-sig@python.org
> http://www.python.org/mailman/listinfo/meta-sig
>