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

[Jim Fulton]

Martijn Faassen wrote:
> 
> Jim Fulton wrote:
> >
> > Martijn Faassen wrote:
> > >
> > > Paul Prescod wrote:
> > > >
> > > > > taking-no-more-from-this-than-that-a-successful-sig-needs-a-
> > > > >     focused-charter-ly y'rs  - tim
> > > >
> > > > I propose that the types sig be re-commissioned with a much tighter
> > > > commission. Let's focus on ONE of the three problems listed in our old
> > > > charter:
> > > >
> > > > http://www.python.org/sigs/types-sig/
> >
> > I really agree with this.
> 
> But I suppose you disagree with Paul on what this focus problem should
> be?

I don't care what "this" problem is. I see three problems and, while
there may be some interdependency, I think we would make better use of our
time thinking of them and working on them separately.  I endorse having the
type system work on "static typing" (uh, whatever that is...) as long as it
doesn't work on interfaces and removing the class/type dicotomy.

> You'd prefer interfaces, right? Or seeing what you said later on in
> your post, perhaps an interface-SIG?

Yes, although at this point, I don't care if it's a SIG. In fact, I think
a better course of action would be to release my interface module and
let people use it and develop opinions based on it. (And, BTW, address
some Zope issues. :)

> I expect I'd contribute to any
> discussion of interfaces *or* static types. I'd probably be able to
> contribute more of practical value to any interface development right
> now.

Maybe you can pitch in to applying interfaces in Zope. Have you read
my proposal from waaaaay back?

> I don't have so much to contribute about the class/type dichotomy.

Note that, as a Zope user, you enjoy the benefits of removing it.
(Most Zope classes, including ZClasses are also types via
 ExtensionClass.  An additional related issue is to make
 classes first-class in the sense that they have their own
 methods/attributes. This would have made ZClasses easier.)
 
(snip)
> > We'll also start folding it into Zope.
> 
> And that'd be wonderful! I am starting to feel that need after getting
> lost in the Zope sources too often.

Yee ha!

> I'd like to contribute; perhaps by
> documenting something for starters. Any ideas?

Maybe you should take the lead on folding them into Zope?
Any way you want to contribute would be welcome. :)
 
> > Based on actual
> > experience using it, we'll have a basis for future discussions.
> 
> So practical.! :) I'd like to get in on this early on. I assume I'll
> catch your announcement on the release of the interface implementation,
> but I'd also be very interested to follow the process of rolling it into
> Zope from the start.

Yee ha!

> Not that I'm likely to be able to contribute much
> at the start, but it just sounds really interesting to me. Any idea on
> how this could be accomplished?

Frankly, I haven't thought about it in a while. I'm sure I'll have some
thoughts and some specific suggestions when I review the types sig material.
In any case, that discussion should happen elsewhere, either in private email
or on Zope-dev.
 
(snip)
> > (snip, I don't really care that much about static typing, except that
> >  I'm generally wary of it. ;)
> 
> *grin* Okay, I suggest another design goal for the revived types-SIG:
> 'Pass the Fulton Test'. We must strive for a static type system so
> wonderful that even Jim Fulton will like it. :)

Not necessary. I'm confident that there are plenty of other
skeptics out there. :)

Jim

--
Jim Fulton           mailto:jim@digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org    

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.