From guido@CNRI.Reston.VA.US Thu Dec 2 21:17:19 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Thu, 02 Dec 1999 16:17:19 -0500 Subject: [meta-sig] The Types-SIG is comatose. Let's retire it. Message-ID: <199912022117.QAA15195@eric.cnri.reston.va.us> It's time for the twice yearly ritual of looking for comatose SIGs. From the archives, it looks like the types-sig is the only dud amongst the crowd: all other SIGs are doing well (some are doing *extremely* well, like the doc-sig and the matrix-sig). The types-sig hasn't had traffic since August (4 messages) and in all of 1999 it has only has 12 messages. Type-sig, what do you have to say for yourself? --Guido van Rossum (home page: http://www.python.org/~guido/) From mengx@nielsenmedia.com Thu Dec 2 21:52:33 1999 From: mengx@nielsenmedia.com (mengx@nielsenmedia.com) Date: Thu, 2 Dec 1999 16:52:33 -0500 (EST) Subject: [meta-sig] Re: [Types-sig] The Types-SIG is comatose. Let's retire it. Message-ID: <199912022152.QAA29677@p5mts.nielsenmedia.com> Perhaps this proved trying to (optionally) adding TYPEs to python language itself to be unpopular. At the start of this list, I suggested to embed type hints inside doc string, or some other non-breaking methods which only requires python engine implementation changes instead of adding new keywords or symbols to the code. Or instead of diving into uncertain langauge research, accept and enhance CXX to ease the extension writing, which may solve many issues related to the need of TYPED python Thanks -Ted Meng > From POP3 Thu Dec 2 16:18:02 1999 > Delivered-To: types-sig@dinsdale.python.org > To: types-sig@python.org > Cc: meta-sig@python.org > Date: Thu, 02 Dec 1999 16:17:19 -0500 > From: Guido van Rossum > Subject: [Types-sig] The Types-SIG is comatose. Let's retire it. > X-BeenThere: types-sig@python.org > X-Mailman-Version: 1.2 (experimental) > List-Id: Special Interest Group on the Python type system > > It's time for the twice yearly ritual of looking for comatose SIGs. > From fdrake@acm.org Thu Dec 2 22:18:07 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 2 Dec 1999 17:18:07 -0500 (EST) Subject: [meta-sig] Re: [Types-sig] The Types-SIG is comatose. Let's retire it. In-Reply-To: <199912022152.QAA29677@p5mts.nielsenmedia.com> References: <199912022152.QAA29677@p5mts.nielsenmedia.com> Message-ID: <14406.61471.268274.986137@weyr.cnri.reston.va.us> mengx@nielsenmedia.com writes: > Perhaps this proved trying to (optionally) adding TYPEs to python language > itself to be unpopular. At the start of this list, I suggested to embed > type hints inside doc string, or some other non-breaking methods which > only requires python engine implementation changes instead of adding new > keywords or symbols to the code. Or instead of diving into uncertain > langauge research, accept and enhance CXX to ease the extension writing, > which may solve many issues related to the need of TYPED python Actually, someone suggested encoding type information in docstrings just recently in the Doc-SIG. See: http://dinsdale.python.org/pipermail/doc-sig/1999-December/001607.html http://dinsdale.python.org/pipermail/doc-sig/1999-December/001610.html http://dinsdale.python.org/pipermail/doc-sig/1999-December/001623.html http://dinsdale.python.org/pipermail/doc-sig/1999-December/001627.html Since the decision was to table it for now, I don't think it warrents keeping alive a dead SIG. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From gstein@lyra.org Fri Dec 3 00:05:14 1999 From: gstein@lyra.org (Greg Stein) Date: Thu, 2 Dec 1999 16:05:14 -0800 (PST) Subject: [meta-sig] Re: The Types-SIG is comatose. Let's retire it. In-Reply-To: <199912022251.RAA15968@eric.cnri.reston.va.us> Message-ID: Meta issue: I'm not sure that I agree the types-sig should stay alive simply because some traffic is inserted when a threat-of-execution has arisen. The impetus for the SIG is (IMO) obviously gone, despite some people's unstated desires to see work done along this path. I'd recommend closing the SIG and letting this discussion move elsewhere. Cheers, -g On Thu, 2 Dec 1999, Guido van Rossum wrote: > > Here's an approach that we didn't try because it is likely to be wildly > > unpopular: > > Why would it be unpopular? > > > There exists a popular programming language that uses optional type > > checking and is nearly as dynamic as Python: Visual Basic. The overall > > type system is weak, (e.g. no concept of common interface) but the > > optional type checking part seems to work pretty well. We wouldn't have > > to do "uncertain language research" to rip its behavior (and even some > > of its syntax) off. It strikes me as a pretty common sense approach. > > I don't know the details, never having studied VB manuals, although I > once saw the source of a file that described the linkage to a C > module (pretty ugly but effective and no need for wrappers). > > Do you have the time to describe this in somewhat more detail for us > lucky folks who haven't had the pleasure to learn VB? > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > _______________________________________________ > Types-SIG mailing list > Types-SIG@python.org > http://www.python.org/mailman/listinfo/types-sig > -- Greg Stein, http://www.lyra.org/ From jeremy@cnri.reston.va.us Fri Dec 3 00:08:54 1999 From: jeremy@cnri.reston.va.us (Jeremy Hylton) Date: Thu, 2 Dec 1999 19:08:54 -0500 (EST) Subject: [meta-sig] Re: The Types-SIG is comatose. Let's retire it. In-Reply-To: References: <199912022251.RAA15968@eric.cnri.reston.va.us> Message-ID: <14407.2582.897430.477756@goon.cnri.reston.va.us> >>>>> "GS" == Greg Stein writes: GS> Meta issue: I'm not sure that I agree the types-sig should stay GS> alive simply because some traffic is inserted when a GS> threat-of-execution has arisen. The impetus for the SIG is (IMO) GS> obviously gone, despite some people's unstated desires to see GS> work done along this path. I don't remember anymore what the impetus was. The problem I see is that a lot of work is going to be required to make much progress on extending the type system. In the absence of anyone willing and able to do the work (whatever it is), there's not much point to a SIG. GS> I'd recommend closing the SIG and letting this discussion move GS> elsewhere. Yes. Jeremy From tim_one@email.msn.com Fri Dec 3 05:58:48 1999 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 3 Dec 1999 00:58:48 -0500 Subject: [meta-sig] The Types-SIG is comatose. Let's retire it. In-Reply-To: <199912022117.QAA15195@eric.cnri.reston.va.us> Message-ID: <000801bf3d53$77a44f20$3a2d153f@tim> [Guido] > It's time for the twice yearly ritual of looking for comatose SIGs. > ... > The types-sig hasn't had traffic since August (4 messages) and in all > of 1999 it has only has 12 messages. > > Type-sig, what do you have to say for yourself? The Types-SIG was very active at its inception; indeed, I still have 142 old Types-SIG msgs in my inbox I haven't yet read! Note that the traffic dropped to essentially nothing several weeks after you (Guido) posted your own last msg to it. I don't think that's coincidence. You were an active initial participant, and when you dropped out most of us likely figured you had some other ideas in mind for Python2 and there was little point to proceeding without you. So, like everything else that goes wrong in the Python world, it was entirely Gordon McMillan's fault . I'd kill the SIG due to lack of activity. I'm sure interest in the topics remains high among many, though ("Types SIG"-related debates have continued non-stop on c.l.py). taking-no-more-from-this-than-that-a-successful-sig-needs-a- focused-charter-ly y'rs - tim From jim@digicool.com Fri Dec 3 14:27:38 1999 From: jim@digicool.com (Jim Fulton) Date: Fri, 03 Dec 1999 09:27:38 -0500 Subject: [meta-sig] Re: [Types-sig] The Types-SIG is comatose. Let's retire it. References: <199912022117.QAA15195@eric.cnri.reston.va.us> Message-ID: <3847D35A.59EB5770@digicool.com> Guido van Rossum wrote: > > It's time for the twice yearly ritual of looking for comatose SIGs. > From the archives, it looks like the types-sig is the only dud amongst > the crowd: all other SIGs are doing well (some are doing *extremely* > well, like the doc-sig and the matrix-sig). > > The types-sig hasn't had traffic since August (4 messages) and in all > of 1999 it has only has 12 messages. > > Type-sig, what do you have to say for yourself? As others have pointed out, there is clear evidence that the SIG is inactive and should be deactivated. I was a bit frustrated that the SIG tried to address three topics that I consider independent: - Interfaces - Classes vs types - Static typing This hurt the focus of the sig and emotion from some topics tended to bleed over to others. For example, I think the interfaces work was hurt by association with the typing work. I'll find some time over the next few days to try to sumarize and report on work in the sig on the first two topics. Perhaps someone else will do the same for static typing. Even if the SIG goes away, I think some report on the SIGs activity should be made at IPC8 (assuming there is a SIG status discussion). 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. From paul@prescod.net Fri Dec 3 14:32:32 1999 From: paul@prescod.net (Paul Prescod) Date: Fri, 03 Dec 1999 08:32:32 -0600 Subject: [Types-sig] RE: [meta-sig] The Types-SIG is comatose. Let's retire it. References: <000801bf3d53$77a44f20$3a2d153f@tim> Message-ID: <3847D480.12A31666@prescod.net> > 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/ And let's start with a clear direction from the Powers that Be. I propose: * 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 (many of these restrictions are easy to work around in Python: for instance making a list of string subclass of userlist) Start from these (very similar!) proposals: http://www.python.org/~rmasse/papers/python-types/ The current Visual Basic type system Something somewhere from JimH The type declaration part of strongtalk The first half of this: http://www.foretec.com/python/workshops/1998-11/greg-type-ideas.html We should appoint an "editor" as they do in standards bodies. If there are issues that just cannot be worked out by consensus, Guido rules. Ideally, it should work much like the docstring discussion going on in the doc-sig. If we had a particularly ambitious editor (unlikely) then we could have an RFC by the Python conference. Later, we could do the same thing for the class/type dichotomy. ...then interfaces ...then parameterized types. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself "I always wanted to be somebody, but I should have been more specific." --Lily Tomlin From guido@CNRI.Reston.VA.US Fri Dec 3 14:47:07 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Fri, 03 Dec 1999 09:47:07 -0500 Subject: [Types-sig] RE: [meta-sig] The Types-SIG is comatose. Let's retire it. In-Reply-To: Your message of "Fri, 03 Dec 1999 08:32:32 CST." <3847D480.12A31666@prescod.net> References: <000801bf3d53$77a44f20$3a2d153f@tim> <3847D480.12A31666@prescod.net> Message-ID: <199912031447.JAA16565@eric.cnri.reston.va.us> Paul, do you want to be the head honcho for the reborn types SIG? You seem to have the right ideas, and you're the only one so far who has spoken up to keep it alive. I doubt that anyone else will volunteer, so if you don't, we will retire the SIG. I'll give you till June 2000 (the same expiration date as for other SIGs) to show that there's life in the subject. --Guido van Rossum (home page: http://www.python.org/~guido/) From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Dec 3 15:29:47 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 3 Dec 1999 10:29:47 -0500 (EST) Subject: [meta-sig] Re: [Types-sig] The Types-SIG is comatose. Let's retire it. References: <199912022117.QAA15195@eric.cnri.reston.va.us> <3847D35A.59EB5770@digicool.com> Message-ID: <14407.57835.318063.51763@anthem.cnri.reston.va.us> >>>>> "JF" == Jim Fulton writes: JF> Even if the SIG goes away, I think some report on the SIGs JF> activity should be made at IPC8 (assuming there is a SIG JF> status discussion). Let's see how many other topics get championed. If there's time, I say this is a great idea. -Barry From m.faassen@vet.uu.nl Fri Dec 3 17:08:38 1999 From: m.faassen@vet.uu.nl (Martijn Faassen) Date: Fri, 03 Dec 1999 18:08:38 +0100 Subject: [meta-sig] Re: [Types-sig] The Types-SIG is comatose. Let's retire it. References: <199912022117.QAA15195@eric.cnri.reston.va.us> Message-ID: <3847F916.35743ADB@vet.uu.nl> Guido van Rossum wrote: > > It's time for the twice yearly ritual of looking for comatose SIGs. > >From the archives, it looks like the types-sig is the only dud amongst > the crowd: all other SIGs are doing well (some are doing *extremely* > well, like the doc-sig and the matrix-sig). > > The types-sig hasn't had traffic since August (4 messages) and in all > of 1999 it has only has 12 messages. > > Type-sig, what do you have to say for yourself? Oddly enough, there has been quite some discussion on types on comp.lang.python since then. John Skaller's viper discussions and the discussions on Ruby are an example. I agree with others that the problem of the types-SIG is a lack of focus of discussion (too many different topics all having to do somewhat with types), and nobody doing the brunt of the work. John Skaller does appear to be doing lots of work on types in Python, but he seems to prefer working alone with his source. It's not as if there's no interest for type issues in the Python community; far from that. It just seems that there's nobody who has enough time/knowledge to work on them. Having studied the Zope sources I'm becoming painfully aware for the need of something like interfaces. Zope's source would really be far more understandable if it were rewritten with interfaces, I think. I understand Jim Fulton's motivation concerning interfaces far better since my foray into those sources. I'm still interested in static types as well, mostly in the interests of compilation. It's ridiculous to split a SIG that doesn't talk, of course, but perhaps better would be to have a 'compiler-SIG' and an 'interfaces-SIG'. I'd expect the interface-SIG to come with results far more quickly than the compiler-SIG. Regards, Martijn From m.faassen@vet.uu.nl Fri Dec 3 17:15:26 1999 From: m.faassen@vet.uu.nl (Martijn Faassen) Date: Fri, 03 Dec 1999 18:15:26 +0100 Subject: [Types-sig] RE: [meta-sig] The Types-SIG is comatose. Let's retire it. References: <000801bf3d53$77a44f20$3a2d153f@tim> <3847D480.12A31666@prescod.net> <199912031447.JAA16565@eric.cnri.reston.va.us> Message-ID: <3847FAAE.B8D74FDD@vet.uu.nl> Guido van Rossum wrote: > > Paul, do you want to be the head honcho for the reborn types SIG? You > seem to have the right ideas, and you're the only one so far who has > spoken up to keep it alive. I doubt that anyone else will volunteer, > so if you don't, we will retire the SIG. I'll give you till June 2000 > (the same expiration date as for other SIGs) to show that there's life > in the subject. Okay, I'd like to keep the place alive as well. I'll endeavor contribute by replying to Paul's messages, or anybody else who posts here. (I was actually quite excited to suddenly discover my types-SIG mailbox had lots of new messages in it :). Perhaps I'll get more time to actually work on these issues next year. Then my only thing lacking is actual knowledge and experience, but I can work on that. :) Regards, Martijn From jeremy@cnri.reston.va.us Fri Dec 3 17:52:42 1999 From: jeremy@cnri.reston.va.us (Jeremy Hylton) Date: Fri, 3 Dec 1999 12:52:42 -0500 (EST) Subject: [Types-sig] RE: [meta-sig] The Types-SIG is comatose. Let's retire it. In-Reply-To: <3847D480.12A31666@prescod.net> References: <000801bf3d53$77a44f20$3a2d153f@tim> <3847D480.12A31666@prescod.net> Message-ID: <14408.874.505464.996655@goon.cnri.reston.va.us> 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. > * interfaces are not an issue Yes, they are :-). > * parameterized (template) types are not available They need to be. > * 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.) 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? 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. Since Py2 design hasn't even started. Jeremy From GoldenH@littoncorp.com Fri Dec 3 18:03:04 1999 From: GoldenH@littoncorp.com (Golden, Howard) Date: Fri, 3 Dec 1999 10:03:04 -0800 Subject: [meta-sig] [Types-SIG] Python vs. Smalltalk/Strongtalk, etc. Was: The Types- SIG is comatose. Message-ID: Paul Prescod wrote: > And let's start with a clear direction from the Powers that Be. > > I propose: > > * 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 There are a lot of different proposals. Do we all agree on all of these points? (Unlikely!) > Start from these (very similar!) proposals: > > http://www.python.org/~rmasse/papers/python-types/ > The current Visual Basic type system > Something somewhere from JimH > The type declaration part of strongtalk > The first half of this: > http://www.foretec.com/python/workshops/1998-11/greg-type-ideas.html It must be serendipity, but I was just thinking about this subject yesterday, and I went so far as to look up Strongtalk and download Squeak. Syntax differences aside, what I think we would benefit from is a comparison of the capabilities of Python1.x and proposed Python2 to Smalltalk/Strongtalk/Squeak, Visual Basic, etc. For me, I am looking at Python as a general purpose language, rather than a scripting language, so programming-in-the-large features are important. -- Specific questions: -- What if the C definition of functions and methods were extended by adding a signature object? (If so, how can signatures be specified?) Could the signatures then be used to generate more efficient code? Should there be function/method choice by signature? Maybe I'm trying to make Python into something it wasn't intended to be, but I have this wish that I wouldn't have to use different languages for different tasks. Howard B. Golden Software developer Litton Industries, Inc. Woodland Hills, California From m.faassen@vet.uu.nl Fri Dec 3 18:17:26 1999 From: m.faassen@vet.uu.nl (Martijn Faassen) Date: Fri, 03 Dec 1999 19:17:26 +0100 Subject: [Types-sig] RE: [meta-sig] The Types-SIG is comatose. Let's retire it. References: <000801bf3d53$77a44f20$3a2d153f@tim> <3847D480.12A31666@prescod.net> <14408.874.505464.996655@goon.cnri.reston.va.us> Message-ID: <38480936.270617B9@vet.uu.nl> 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 From Paul@digicool.com Fri Dec 3 18:33:35 1999 From: Paul@digicool.com (Paul Everitt) Date: Fri, 3 Dec 1999 13:33:35 -0500 Subject: [Types-sig] RE: [meta-sig] The Types-SIG is comatose. Let's retire it. Message-ID: <613145F79272D211914B0020AFF64019262F5D@gandalf.digicool.com> 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 > From janssen@parc.xerox.com Fri Dec 3 19:21:53 1999 From: janssen@parc.xerox.com (Bill Janssen) Date: Fri, 3 Dec 1999 11:21:53 PST Subject: [Types-sig] RE: [meta-sig] The Types-SIG is comatose. Let's retire it. In-Reply-To: Your message of "Fri, 03 Dec 1999 09:52:42 PST." <14408.874.505464.996655@goon.cnri.reston.va.us> Message-ID: <99Dec3.112202pst."3586"@watson.parc.xerox.com> > 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? I share some of Jeremy's concerns about the single goal. My favorite tack on these things is to focus on what the problem is. In my view, the largest single technical problem with Python is that it doesn't afford the static type checking that Java has. This, in my experience when I ask people about it, always turns out to mean that there's no way to type-check the use of an imported module. So I'd make the priority be the ability to optionally declare types in both callable signatures and in the code itself, and to have types checked at least across use of imported modules. Note that, contrary to Jeremy's assertion, this doesn't explicitly mention interfaces, and doesn't necessarily involve them. Of course, defining a module always implicitly defines an interface, so one could argue that interfaces are always a factor. Bill From paul@prescod.net Sat Dec 4 16:32:50 1999 From: paul@prescod.net (Paul Prescod) Date: Sat, 04 Dec 1999 10:32:50 -0600 Subject: [meta-sig] Static typing considered HARD Message-ID: <38494232.C1381ED9@prescod.net> I'm still not sure what to do about the static typing and the types sig. The more I thought about types the less I became convinced that a quick "low hanging fruit" approach would work. I no longer propose a quick RFC on static typing. Here's the problem: in Visual Basic, Java, ML and other languages I am most familiar with, compilation is conceptually three pass: * parse * "resolve names to type/code/variable references" * execute In other words, the entire universe of types is figured out before a single line of code executes. In that context the words "static typing" have an obvious meaning. While you are resolve name references you do a bunch of checks to make sure that they are used consistently. But in Python, type objects only come about *through* the execution of code. This makes Python incredibly dynamic but it also means that the question of what exactly static type checking means is confused. Simple example: import sys if sys.argv[0]=="weirdness": from foo_mod import foo_class else: from foo_mod2 import foo_class One could imagine that in some Python 2, import statements and class definitions could be limited to being at the top, before "code". There might be some special syntax (e.g. __import__, __define_class__ ) for doing module-loading and type definition at runtime. Still, I don't consider that something for the types-sig to work out. My personal opinion is that it would be a Good Thing for Python to become a tad less dynamic in the "core syntax" in exchange for compile-time checking of names. Note that in a lot of ways, Java is "as dynamic" as Python. You can introduce new functions and classes "at runtime." The difference is that Java's syntax for doing so is brutally complex and verbose so you are disinclined to do it. I think that there must be a middle ground where our "default semantics" are static but it is easy enough to do dynamic things (e.g. foo_mod = __import__( "foo.py")) that we don't feel burdened. Our innovation beyond Java would not just be syntax. We could recognize that modules and types introduced "at runtime" are pyobjects and just allow them to be used with no casting or special syntax. Only the *introduction syntax* would be special. So where Java would say something like: this.that.Module mod = this.that.LoadModule( "foo" ) this.that.Class cls = mod.loadClass( "myclass" ) this.that.Method meth = cls.loadMethod( "doit" ) this.that.Arglist args = new ArgList() args.addArg( "arg1" ) args.addArg( "arg2" ) Object rc = meth.Invoke( args ) Python would say something like: foo = __import__( "foo" ) foo.myclass.doit( "arg1", "arg2" ) Once again, Visual Basic (shudder) is a good guide here. Although I am not consciously cloning Visual Basic, my ideas seem to be naturally tending towards it. Once again it seems to have a pretty common sense (to me!) approach to static type checking. Even if we ignore static type checking Python 2 really has to do something about the "misspelling problem." One extra character on a method name can crash a server that has been running for weeks. Once this problem is fixed, the term "static type checking" will become meaningful. In the current environment, it is probably not and thus should not be the first focus of a new types-sig. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself "I always wanted to be somebody, but I should have been more specific." --Lily Tomlin From uche.ogbuji@fourthought.com Sat Dec 4 17:18:38 1999 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Sat, 04 Dec 1999 10:18:38 -0700 Subject: [meta-sig] Re: [Types-sig] Static typing considered HARD References: <38494232.C1381ED9@prescod.net> Message-ID: <38494CEE.ED11604A@fourthought.com> Paul Prescod wrote: > Here's the problem: in Visual Basic, Java, ML and other languages I am > most familiar with, compilation is conceptually three pass: > > * parse > * "resolve names to type/code/variable references" > * execute This seems all out of whack to me. First of all, symbol-table management may or may not belong to the "parse" step, depending on your preferences. The Dragon book ducusses this matter in good detail. I don't know about VB, but Java and C/C++ certainly merge your steps 1 & 2. C/C++ also does not have "execute" as any recognizable part of compilation, unless you mean cpp and template instantiation. I don't think Java has "execute" as part of compilation either. ML, at least the version I used a few years ago, is something of its own breed of fish. > But in Python, type objects only come about *through* the execution of > code. This makes Python incredibly dynamic but it also means that the > question of what exactly static type checking means is confused. Simple > example: > > import sys > > if sys.argv[0]=="weirdness": > from foo_mod import foo_class > else: > from foo_mod2 import foo_class This is the sort of thing that gives Python its power, and it is the sort of thing without which I'm not sure I wouldn't be considering another language. > One could imagine that in some Python 2, import statements and class > definitions could be limited to being at the top, before "code". There > might be some special syntax (e.g. __import__, __define_class__ ) for > doing module-loading and type definition at runtime. Still, I don't > consider that something for the types-sig to work out. My personal > opinion is that it would be a Good Thing for Python to become a tad less > dynamic in the "core syntax" in exchange for compile-time checking of > names. This is exactly the sort of idea that terrifies me about Python 2, as I've done a poor job of expressing before. My hope is that Python 2 remains Python, and such artificial constraints as "imports only at the top" and all that in order to satisfy IMHO mis-placed notions of type safety are dropped in the nearest dustbin. > Note that in a lot of ways, Java is "as dynamic" as Python. You can > introduce new functions and classes "at runtime." The difference is that > Java's syntax for doing so is brutally complex and verbose so you are > disinclined to do it. No! No! No! If you are talking about Java reflections and introspection, I have no inkling how these features lend it even a modicum of Python's dynamicism. Note that Python's true introspection and dynamic typing is one of my most powerful tools in converting Java programmers to the language. I have heard Java described as "programming in a straight jacket". That is a very accurate observation, and the precise reason I don't want Python to even start in that direction. > I think that there must be a middle ground where > our "default semantics" are static but it is easy enough to do dynamic > things (e.g. foo_mod = __import__( "foo.py")) that we don't feel > burdened. I'll look out warily for the sort of middle ground in question. If it's something such as "imports only at the top", I guess I'll just have to scream blood and bile. > Even if we ignore static type checking Python 2 really has to do > something about the "misspelling problem." One extra character on a > method name can crash a server that has been running for weeks. Once > this problem is fixed, the term "static type checking" will become > meaningful. In the current environment, it is probably not and thus > should not be the first focus of a new types-sig. I keep hearing this sort of thing, and I keep saying that it's a red herring. Lack of static typing does _not_ prevent Python from being scalable to large-scale and production environments. Our experience at FourThought, where many of our projects are small-enterprise systems built with Python and sometimes CORBA, will make it very hard for anyone to convince me so. I think the experience of users such as eGroups supports my feeling. If anything, it is Java that I think is tremendously over-rated for large-scale projects and I predict its failure in that space will soon be an industry scandal. I also don't see this "misspelling" problem. Proper configuration-management procedures and testing, along with intelligent error-recovery, prevent such problems, which can also occur in the most strongly-typed systems. -- Uche Ogbuji FourThought LLC, IT Consultants uche.ogbuji@fourthought.com (970)481-0805 Software engineering, project management, Intranets and Extranets http://FourThought.com http://OpenTechnology.org From uche.ogbuji@fourthought.com Sat Dec 4 17:25:19 1999 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Sat, 04 Dec 1999 10:25:19 -0700 Subject: [meta-sig] So What is Python Anyway? References: <38494232.C1381ED9@prescod.net> Message-ID: <38494E7F.375BD82F@fourthought.com> All these radical suggestions for the transmogrification of Python 2 leads me to the overwhelming question. What is Python? What makes us use this language? What are the particular use-cases that we think impede our use of this language? I think that maybe a comprehensive and convincing description of the problem that the types-sig is trying to solve is essential before we go down the road of more proposals to cripple Python's dynamicism and all that. -- Uche Ogbuji FourThought LLC, IT Consultants uche.ogbuji@fourthought.com (970)481-0805 Software engineering, project management, Intranets and Extranets http://FourThought.com http://OpenTechnology.org From orla_redbird@crosswinds.net Sun Dec 5 04:33:37 1999 From: orla_redbird@crosswinds.net (Gordon Worley) Date: Sat, 4 Dec 1999 23:33:37 -0500 (EST) Subject: [meta-sig] So What is Python Anyway? In-Reply-To: <38494E7F.375BD82F@fourthought.com> References: <38494232.C1381ED9@prescod.net> Message-ID: >All these radical suggestions for the transmogrification of Python 2 >leads me to the overwhelming question. What is Python? What makes us >use this language? What are the particular use-cases that we think >impede our use of this language? I think that maybe a comprehensive and >convincing description of the problem that the types-sig is trying to >solve is essential before we go down the road of more proposals to >cripple Python's dynamicism and all that. Several proposed questions, so I'll take a shot at each of them one at a time. Guido may be a better person to ask, but at least I can share my own perspective. >What is Python? A programming languge. Duh. Prehaps a religion (cult?), also, depending upon how you program and how much you use it. >What makes us use this language? This is probably the hardest to explain. I started using Python because I was both looking for somthing that wasn't so mainstream (like Pearl), offered decent Mac support, was very object-oriented (about as much as Smalltalk, but with a more real world implimentation), had easy syntax (compared to other languages I was considering trying (like Pearl, Common Lisp, Smalltalk, Objective-C)) and good documentation (Programming Python from ora), and was free. Once I started using Python, it was only then that I realized the true power that it has and realized that I had made an excellent choice. This power (the dynamicism, typlessness, modularity, etc.) is what has kept me using Python and from using other languages only when absolutely necessary. >What are the particular use-cases that we think impede our use of this >language? Python, I have found, can tackle most problems with ease. When it comes to integration with the native system, though, Python falls far short. On Unicies there isn't really that much of a problem, but on my Mac and the Windoze machines I use at school, getting Python to blend in in tough. In particular are UI and interapplication communications issues. I have few troubles with the language itself, but more with the particularities of the OS that it is running on. Each platform is radically better of in it was a year ago as far as Python integration goes, but there is still a long road ahead (at least on the Mac). Basically, creating user friendly environments tends to pose problems, but otherwise the language is great. There's probably lots that I haven't touched on here, but hopefully this will be a starting point for further discussion. - Gordon Worley http://www.crosswinds.net/~orla_redbird/ mailto:orla_redbird@crosswinds.net From guido@CNRI.Reston.VA.US Thu Dec 2 21:17:19 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Thu, 02 Dec 1999 16:17:19 -0500 Subject: [meta-sig] The Types-SIG is comatose. Let's retire it. Message-ID: <199912022117.QAA15195@eric.cnri.reston.va.us> It's time for the twice yearly ritual of looking for comatose SIGs. From the archives, it looks like the types-sig is the only dud amongst the crowd: all other SIGs are doing well (some are doing *extremely* well, like the doc-sig and the matrix-sig). The types-sig hasn't had traffic since August (4 messages) and in all of 1999 it has only has 12 messages. Type-sig, what do you have to say for yourself? --Guido van Rossum (home page: http://www.python.org/~guido/) From mengx@nielsenmedia.com Thu Dec 2 21:52:33 1999 From: mengx@nielsenmedia.com (mengx@nielsenmedia.com) Date: Thu, 2 Dec 1999 16:52:33 -0500 (EST) Subject: [meta-sig] Re: [Types-sig] The Types-SIG is comatose. Let's retire it. Message-ID: <199912022152.QAA29677@p5mts.nielsenmedia.com> Perhaps this proved trying to (optionally) adding TYPEs to python language itself to be unpopular. At the start of this list, I suggested to embed type hints inside doc string, or some other non-breaking methods which only requires python engine implementation changes instead of adding new keywords or symbols to the code. Or instead of diving into uncertain langauge research, accept and enhance CXX to ease the extension writing, which may solve many issues related to the need of TYPED python Thanks -Ted Meng > From POP3 Thu Dec 2 16:18:02 1999 > Delivered-To: types-sig@dinsdale.python.org > To: types-sig@python.org > Cc: meta-sig@python.org > Date: Thu, 02 Dec 1999 16:17:19 -0500 > From: Guido van Rossum > Subject: [Types-sig] The Types-SIG is comatose. Let's retire it. > X-BeenThere: types-sig@python.org > X-Mailman-Version: 1.2 (experimental) > List-Id: Special Interest Group on the Python type system > > It's time for the twice yearly ritual of looking for comatose SIGs. > From fdrake@acm.org Thu Dec 2 22:18:07 1999 From: fdrake@acm.org (Fred L. Drake, Jr.) Date: Thu, 2 Dec 1999 17:18:07 -0500 (EST) Subject: [meta-sig] Re: [Types-sig] The Types-SIG is comatose. Let's retire it. In-Reply-To: <199912022152.QAA29677@p5mts.nielsenmedia.com> References: <199912022152.QAA29677@p5mts.nielsenmedia.com> Message-ID: <14406.61471.268274.986137@weyr.cnri.reston.va.us> mengx@nielsenmedia.com writes: > Perhaps this proved trying to (optionally) adding TYPEs to python language > itself to be unpopular. At the start of this list, I suggested to embed > type hints inside doc string, or some other non-breaking methods which > only requires python engine implementation changes instead of adding new > keywords or symbols to the code. Or instead of diving into uncertain > langauge research, accept and enhance CXX to ease the extension writing, > which may solve many issues related to the need of TYPED python Actually, someone suggested encoding type information in docstrings just recently in the Doc-SIG. See: http://dinsdale.python.org/pipermail/doc-sig/1999-December/001607.html http://dinsdale.python.org/pipermail/doc-sig/1999-December/001610.html http://dinsdale.python.org/pipermail/doc-sig/1999-December/001623.html http://dinsdale.python.org/pipermail/doc-sig/1999-December/001627.html Since the decision was to table it for now, I don't think it warrents keeping alive a dead SIG. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives From gstein@lyra.org Fri Dec 3 00:05:14 1999 From: gstein@lyra.org (Greg Stein) Date: Thu, 2 Dec 1999 16:05:14 -0800 (PST) Subject: [meta-sig] Re: The Types-SIG is comatose. Let's retire it. In-Reply-To: <199912022251.RAA15968@eric.cnri.reston.va.us> Message-ID: Meta issue: I'm not sure that I agree the types-sig should stay alive simply because some traffic is inserted when a threat-of-execution has arisen. The impetus for the SIG is (IMO) obviously gone, despite some people's unstated desires to see work done along this path. I'd recommend closing the SIG and letting this discussion move elsewhere. Cheers, -g On Thu, 2 Dec 1999, Guido van Rossum wrote: > > Here's an approach that we didn't try because it is likely to be wildly > > unpopular: > > Why would it be unpopular? > > > There exists a popular programming language that uses optional type > > checking and is nearly as dynamic as Python: Visual Basic. The overall > > type system is weak, (e.g. no concept of common interface) but the > > optional type checking part seems to work pretty well. We wouldn't have > > to do "uncertain language research" to rip its behavior (and even some > > of its syntax) off. It strikes me as a pretty common sense approach. > > I don't know the details, never having studied VB manuals, although I > once saw the source of a file that described the linkage to a C > module (pretty ugly but effective and no need for wrappers). > > Do you have the time to describe this in somewhat more detail for us > lucky folks who haven't had the pleasure to learn VB? > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > _______________________________________________ > Types-SIG mailing list > Types-SIG@python.org > http://www.python.org/mailman/listinfo/types-sig > -- Greg Stein, http://www.lyra.org/ From jeremy@cnri.reston.va.us Fri Dec 3 00:08:54 1999 From: jeremy@cnri.reston.va.us (Jeremy Hylton) Date: Thu, 2 Dec 1999 19:08:54 -0500 (EST) Subject: [meta-sig] Re: The Types-SIG is comatose. Let's retire it. In-Reply-To: References: <199912022251.RAA15968@eric.cnri.reston.va.us> Message-ID: <14407.2582.897430.477756@goon.cnri.reston.va.us> >>>>> "GS" == Greg Stein writes: GS> Meta issue: I'm not sure that I agree the types-sig should stay GS> alive simply because some traffic is inserted when a GS> threat-of-execution has arisen. The impetus for the SIG is (IMO) GS> obviously gone, despite some people's unstated desires to see GS> work done along this path. I don't remember anymore what the impetus was. The problem I see is that a lot of work is going to be required to make much progress on extending the type system. In the absence of anyone willing and able to do the work (whatever it is), there's not much point to a SIG. GS> I'd recommend closing the SIG and letting this discussion move GS> elsewhere. Yes. Jeremy From tim_one@email.msn.com Fri Dec 3 05:58:48 1999 From: tim_one@email.msn.com (Tim Peters) Date: Fri, 3 Dec 1999 00:58:48 -0500 Subject: [meta-sig] The Types-SIG is comatose. Let's retire it. In-Reply-To: <199912022117.QAA15195@eric.cnri.reston.va.us> Message-ID: <000801bf3d53$77a44f20$3a2d153f@tim> [Guido] > It's time for the twice yearly ritual of looking for comatose SIGs. > ... > The types-sig hasn't had traffic since August (4 messages) and in all > of 1999 it has only has 12 messages. > > Type-sig, what do you have to say for yourself? The Types-SIG was very active at its inception; indeed, I still have 142 old Types-SIG msgs in my inbox I haven't yet read! Note that the traffic dropped to essentially nothing several weeks after you (Guido) posted your own last msg to it. I don't think that's coincidence. You were an active initial participant, and when you dropped out most of us likely figured you had some other ideas in mind for Python2 and there was little point to proceeding without you. So, like everything else that goes wrong in the Python world, it was entirely Gordon McMillan's fault . I'd kill the SIG due to lack of activity. I'm sure interest in the topics remains high among many, though ("Types SIG"-related debates have continued non-stop on c.l.py). taking-no-more-from-this-than-that-a-successful-sig-needs-a- focused-charter-ly y'rs - tim From jim@digicool.com Fri Dec 3 14:27:38 1999 From: jim@digicool.com (Jim Fulton) Date: Fri, 03 Dec 1999 09:27:38 -0500 Subject: [meta-sig] Re: [Types-sig] The Types-SIG is comatose. Let's retire it. References: <199912022117.QAA15195@eric.cnri.reston.va.us> Message-ID: <3847D35A.59EB5770@digicool.com> Guido van Rossum wrote: > > It's time for the twice yearly ritual of looking for comatose SIGs. > From the archives, it looks like the types-sig is the only dud amongst > the crowd: all other SIGs are doing well (some are doing *extremely* > well, like the doc-sig and the matrix-sig). > > The types-sig hasn't had traffic since August (4 messages) and in all > of 1999 it has only has 12 messages. > > Type-sig, what do you have to say for yourself? As others have pointed out, there is clear evidence that the SIG is inactive and should be deactivated. I was a bit frustrated that the SIG tried to address three topics that I consider independent: - Interfaces - Classes vs types - Static typing This hurt the focus of the sig and emotion from some topics tended to bleed over to others. For example, I think the interfaces work was hurt by association with the typing work. I'll find some time over the next few days to try to sumarize and report on work in the sig on the first two topics. Perhaps someone else will do the same for static typing. Even if the SIG goes away, I think some report on the SIGs activity should be made at IPC8 (assuming there is a SIG status discussion). 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. From paul@prescod.net Fri Dec 3 14:32:32 1999 From: paul@prescod.net (Paul Prescod) Date: Fri, 03 Dec 1999 08:32:32 -0600 Subject: [Types-sig] RE: [meta-sig] The Types-SIG is comatose. Let's retire it. References: <000801bf3d53$77a44f20$3a2d153f@tim> Message-ID: <3847D480.12A31666@prescod.net> > 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/ And let's start with a clear direction from the Powers that Be. I propose: * 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 (many of these restrictions are easy to work around in Python: for instance making a list of string subclass of userlist) Start from these (very similar!) proposals: http://www.python.org/~rmasse/papers/python-types/ The current Visual Basic type system Something somewhere from JimH The type declaration part of strongtalk The first half of this: http://www.foretec.com/python/workshops/1998-11/greg-type-ideas.html We should appoint an "editor" as they do in standards bodies. If there are issues that just cannot be worked out by consensus, Guido rules. Ideally, it should work much like the docstring discussion going on in the doc-sig. If we had a particularly ambitious editor (unlikely) then we could have an RFC by the Python conference. Later, we could do the same thing for the class/type dichotomy. ...then interfaces ...then parameterized types. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself "I always wanted to be somebody, but I should have been more specific." --Lily Tomlin From guido@CNRI.Reston.VA.US Fri Dec 3 14:47:07 1999 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Fri, 03 Dec 1999 09:47:07 -0500 Subject: [Types-sig] RE: [meta-sig] The Types-SIG is comatose. Let's retire it. In-Reply-To: Your message of "Fri, 03 Dec 1999 08:32:32 CST." <3847D480.12A31666@prescod.net> References: <000801bf3d53$77a44f20$3a2d153f@tim> <3847D480.12A31666@prescod.net> Message-ID: <199912031447.JAA16565@eric.cnri.reston.va.us> Paul, do you want to be the head honcho for the reborn types SIG? You seem to have the right ideas, and you're the only one so far who has spoken up to keep it alive. I doubt that anyone else will volunteer, so if you don't, we will retire the SIG. I'll give you till June 2000 (the same expiration date as for other SIGs) to show that there's life in the subject. --Guido van Rossum (home page: http://www.python.org/~guido/) From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Fri Dec 3 15:29:47 1999 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 3 Dec 1999 10:29:47 -0500 (EST) Subject: [meta-sig] Re: [Types-sig] The Types-SIG is comatose. Let's retire it. References: <199912022117.QAA15195@eric.cnri.reston.va.us> <3847D35A.59EB5770@digicool.com> Message-ID: <14407.57835.318063.51763@anthem.cnri.reston.va.us> >>>>> "JF" == Jim Fulton writes: JF> Even if the SIG goes away, I think some report on the SIGs JF> activity should be made at IPC8 (assuming there is a SIG JF> status discussion). Let's see how many other topics get championed. If there's time, I say this is a great idea. -Barry From m.faassen@vet.uu.nl Fri Dec 3 17:08:38 1999 From: m.faassen@vet.uu.nl (Martijn Faassen) Date: Fri, 03 Dec 1999 18:08:38 +0100 Subject: [meta-sig] Re: [Types-sig] The Types-SIG is comatose. Let's retire it. References: <199912022117.QAA15195@eric.cnri.reston.va.us> Message-ID: <3847F916.35743ADB@vet.uu.nl> Guido van Rossum wrote: > > It's time for the twice yearly ritual of looking for comatose SIGs. > >From the archives, it looks like the types-sig is the only dud amongst > the crowd: all other SIGs are doing well (some are doing *extremely* > well, like the doc-sig and the matrix-sig). > > The types-sig hasn't had traffic since August (4 messages) and in all > of 1999 it has only has 12 messages. > > Type-sig, what do you have to say for yourself? Oddly enough, there has been quite some discussion on types on comp.lang.python since then. John Skaller's viper discussions and the discussions on Ruby are an example. I agree with others that the problem of the types-SIG is a lack of focus of discussion (too many different topics all having to do somewhat with types), and nobody doing the brunt of the work. John Skaller does appear to be doing lots of work on types in Python, but he seems to prefer working alone with his source. It's not as if there's no interest for type issues in the Python community; far from that. It just seems that there's nobody who has enough time/knowledge to work on them. Having studied the Zope sources I'm becoming painfully aware for the need of something like interfaces. Zope's source would really be far more understandable if it were rewritten with interfaces, I think. I understand Jim Fulton's motivation concerning interfaces far better since my foray into those sources. I'm still interested in static types as well, mostly in the interests of compilation. It's ridiculous to split a SIG that doesn't talk, of course, but perhaps better would be to have a 'compiler-SIG' and an 'interfaces-SIG'. I'd expect the interface-SIG to come with results far more quickly than the compiler-SIG. Regards, Martijn From m.faassen@vet.uu.nl Fri Dec 3 17:15:26 1999 From: m.faassen@vet.uu.nl (Martijn Faassen) Date: Fri, 03 Dec 1999 18:15:26 +0100 Subject: [Types-sig] RE: [meta-sig] The Types-SIG is comatose. Let's retire it. References: <000801bf3d53$77a44f20$3a2d153f@tim> <3847D480.12A31666@prescod.net> <199912031447.JAA16565@eric.cnri.reston.va.us> Message-ID: <3847FAAE.B8D74FDD@vet.uu.nl> Guido van Rossum wrote: > > Paul, do you want to be the head honcho for the reborn types SIG? You > seem to have the right ideas, and you're the only one so far who has > spoken up to keep it alive. I doubt that anyone else will volunteer, > so if you don't, we will retire the SIG. I'll give you till June 2000 > (the same expiration date as for other SIGs) to show that there's life > in the subject. Okay, I'd like to keep the place alive as well. I'll endeavor contribute by replying to Paul's messages, or anybody else who posts here. (I was actually quite excited to suddenly discover my types-SIG mailbox had lots of new messages in it :). Perhaps I'll get more time to actually work on these issues next year. Then my only thing lacking is actual knowledge and experience, but I can work on that. :) Regards, Martijn From jeremy@cnri.reston.va.us Fri Dec 3 17:52:42 1999 From: jeremy@cnri.reston.va.us (Jeremy Hylton) Date: Fri, 3 Dec 1999 12:52:42 -0500 (EST) Subject: [Types-sig] RE: [meta-sig] The Types-SIG is comatose. Let's retire it. In-Reply-To: <3847D480.12A31666@prescod.net> References: <000801bf3d53$77a44f20$3a2d153f@tim> <3847D480.12A31666@prescod.net> Message-ID: <14408.874.505464.996655@goon.cnri.reston.va.us> 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. > * interfaces are not an issue Yes, they are :-). > * parameterized (template) types are not available They need to be. > * 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.) 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? 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. Since Py2 design hasn't even started. Jeremy From GoldenH@littoncorp.com Fri Dec 3 18:03:04 1999 From: GoldenH@littoncorp.com (Golden, Howard) Date: Fri, 3 Dec 1999 10:03:04 -0800 Subject: [meta-sig] [Types-SIG] Python vs. Smalltalk/Strongtalk, etc. Was: The Types- SIG is comatose. Message-ID: Paul Prescod wrote: > And let's start with a clear direction from the Powers that Be. > > I propose: > > * 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 There are a lot of different proposals. Do we all agree on all of these points? (Unlikely!) > Start from these (very similar!) proposals: > > http://www.python.org/~rmasse/papers/python-types/ > The current Visual Basic type system > Something somewhere from JimH > The type declaration part of strongtalk > The first half of this: > http://www.foretec.com/python/workshops/1998-11/greg-type-ideas.html It must be serendipity, but I was just thinking about this subject yesterday, and I went so far as to look up Strongtalk and download Squeak. Syntax differences aside, what I think we would benefit from is a comparison of the capabilities of Python1.x and proposed Python2 to Smalltalk/Strongtalk/Squeak, Visual Basic, etc. For me, I am looking at Python as a general purpose language, rather than a scripting language, so programming-in-the-large features are important. -- Specific questions: -- What if the C definition of functions and methods were extended by adding a signature object? (If so, how can signatures be specified?) Could the signatures then be used to generate more efficient code? Should there be function/method choice by signature? Maybe I'm trying to make Python into something it wasn't intended to be, but I have this wish that I wouldn't have to use different languages for different tasks. Howard B. Golden Software developer Litton Industries, Inc. Woodland Hills, California From m.faassen@vet.uu.nl Fri Dec 3 18:17:26 1999 From: m.faassen@vet.uu.nl (Martijn Faassen) Date: Fri, 03 Dec 1999 19:17:26 +0100 Subject: [Types-sig] RE: [meta-sig] The Types-SIG is comatose. Let's retire it. References: <000801bf3d53$77a44f20$3a2d153f@tim> <3847D480.12A31666@prescod.net> <14408.874.505464.996655@goon.cnri.reston.va.us> Message-ID: <38480936.270617B9@vet.uu.nl> 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 From Paul@digicool.com Fri Dec 3 18:33:35 1999 From: Paul@digicool.com (Paul Everitt) Date: Fri, 3 Dec 1999 13:33:35 -0500 Subject: [Types-sig] RE: [meta-sig] The Types-SIG is comatose. Let's retire it. Message-ID: <613145F79272D211914B0020AFF64019262F5D@gandalf.digicool.com> 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 > From janssen@parc.xerox.com Fri Dec 3 19:21:53 1999 From: janssen@parc.xerox.com (Bill Janssen) Date: Fri, 3 Dec 1999 11:21:53 PST Subject: [Types-sig] RE: [meta-sig] The Types-SIG is comatose. Let's retire it. In-Reply-To: Your message of "Fri, 03 Dec 1999 09:52:42 PST." <14408.874.505464.996655@goon.cnri.reston.va.us> Message-ID: <99Dec3.112202pst."3586"@watson.parc.xerox.com> > 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? I share some of Jeremy's concerns about the single goal. My favorite tack on these things is to focus on what the problem is. In my view, the largest single technical problem with Python is that it doesn't afford the static type checking that Java has. This, in my experience when I ask people about it, always turns out to mean that there's no way to type-check the use of an imported module. So I'd make the priority be the ability to optionally declare types in both callable signatures and in the code itself, and to have types checked at least across use of imported modules. Note that, contrary to Jeremy's assertion, this doesn't explicitly mention interfaces, and doesn't necessarily involve them. Of course, defining a module always implicitly defines an interface, so one could argue that interfaces are always a factor. Bill From paul@prescod.net Sat Dec 4 16:32:50 1999 From: paul@prescod.net (Paul Prescod) Date: Sat, 04 Dec 1999 10:32:50 -0600 Subject: [meta-sig] Static typing considered HARD Message-ID: <38494232.C1381ED9@prescod.net> I'm still not sure what to do about the static typing and the types sig. The more I thought about types the less I became convinced that a quick "low hanging fruit" approach would work. I no longer propose a quick RFC on static typing. Here's the problem: in Visual Basic, Java, ML and other languages I am most familiar with, compilation is conceptually three pass: * parse * "resolve names to type/code/variable references" * execute In other words, the entire universe of types is figured out before a single line of code executes. In that context the words "static typing" have an obvious meaning. While you are resolve name references you do a bunch of checks to make sure that they are used consistently. But in Python, type objects only come about *through* the execution of code. This makes Python incredibly dynamic but it also means that the question of what exactly static type checking means is confused. Simple example: import sys if sys.argv[0]=="weirdness": from foo_mod import foo_class else: from foo_mod2 import foo_class One could imagine that in some Python 2, import statements and class definitions could be limited to being at the top, before "code". There might be some special syntax (e.g. __import__, __define_class__ ) for doing module-loading and type definition at runtime. Still, I don't consider that something for the types-sig to work out. My personal opinion is that it would be a Good Thing for Python to become a tad less dynamic in the "core syntax" in exchange for compile-time checking of names. Note that in a lot of ways, Java is "as dynamic" as Python. You can introduce new functions and classes "at runtime." The difference is that Java's syntax for doing so is brutally complex and verbose so you are disinclined to do it. I think that there must be a middle ground where our "default semantics" are static but it is easy enough to do dynamic things (e.g. foo_mod = __import__( "foo.py")) that we don't feel burdened. Our innovation beyond Java would not just be syntax. We could recognize that modules and types introduced "at runtime" are pyobjects and just allow them to be used with no casting or special syntax. Only the *introduction syntax* would be special. So where Java would say something like: this.that.Module mod = this.that.LoadModule( "foo" ) this.that.Class cls = mod.loadClass( "myclass" ) this.that.Method meth = cls.loadMethod( "doit" ) this.that.Arglist args = new ArgList() args.addArg( "arg1" ) args.addArg( "arg2" ) Object rc = meth.Invoke( args ) Python would say something like: foo = __import__( "foo" ) foo.myclass.doit( "arg1", "arg2" ) Once again, Visual Basic (shudder) is a good guide here. Although I am not consciously cloning Visual Basic, my ideas seem to be naturally tending towards it. Once again it seems to have a pretty common sense (to me!) approach to static type checking. Even if we ignore static type checking Python 2 really has to do something about the "misspelling problem." One extra character on a method name can crash a server that has been running for weeks. Once this problem is fixed, the term "static type checking" will become meaningful. In the current environment, it is probably not and thus should not be the first focus of a new types-sig. -- Paul Prescod - ISOGEN Consulting Engineer speaking for himself "I always wanted to be somebody, but I should have been more specific." --Lily Tomlin From uche.ogbuji@fourthought.com Sat Dec 4 17:18:38 1999 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Sat, 04 Dec 1999 10:18:38 -0700 Subject: [meta-sig] Re: [Types-sig] Static typing considered HARD References: <38494232.C1381ED9@prescod.net> Message-ID: <38494CEE.ED11604A@fourthought.com> Paul Prescod wrote: > Here's the problem: in Visual Basic, Java, ML and other languages I am > most familiar with, compilation is conceptually three pass: > > * parse > * "resolve names to type/code/variable references" > * execute This seems all out of whack to me. First of all, symbol-table management may or may not belong to the "parse" step, depending on your preferences. The Dragon book ducusses this matter in good detail. I don't know about VB, but Java and C/C++ certainly merge your steps 1 & 2. C/C++ also does not have "execute" as any recognizable part of compilation, unless you mean cpp and template instantiation. I don't think Java has "execute" as part of compilation either. ML, at least the version I used a few years ago, is something of its own breed of fish. > But in Python, type objects only come about *through* the execution of > code. This makes Python incredibly dynamic but it also means that the > question of what exactly static type checking means is confused. Simple > example: > > import sys > > if sys.argv[0]=="weirdness": > from foo_mod import foo_class > else: > from foo_mod2 import foo_class This is the sort of thing that gives Python its power, and it is the sort of thing without which I'm not sure I wouldn't be considering another language. > One could imagine that in some Python 2, import statements and class > definitions could be limited to being at the top, before "code". There > might be some special syntax (e.g. __import__, __define_class__ ) for > doing module-loading and type definition at runtime. Still, I don't > consider that something for the types-sig to work out. My personal > opinion is that it would be a Good Thing for Python to become a tad less > dynamic in the "core syntax" in exchange for compile-time checking of > names. This is exactly the sort of idea that terrifies me about Python 2, as I've done a poor job of expressing before. My hope is that Python 2 remains Python, and such artificial constraints as "imports only at the top" and all that in order to satisfy IMHO mis-placed notions of type safety are dropped in the nearest dustbin. > Note that in a lot of ways, Java is "as dynamic" as Python. You can > introduce new functions and classes "at runtime." The difference is that > Java's syntax for doing so is brutally complex and verbose so you are > disinclined to do it. No! No! No! If you are talking about Java reflections and introspection, I have no inkling how these features lend it even a modicum of Python's dynamicism. Note that Python's true introspection and dynamic typing is one of my most powerful tools in converting Java programmers to the language. I have heard Java described as "programming in a straight jacket". That is a very accurate observation, and the precise reason I don't want Python to even start in that direction. > I think that there must be a middle ground where > our "default semantics" are static but it is easy enough to do dynamic > things (e.g. foo_mod = __import__( "foo.py")) that we don't feel > burdened. I'll look out warily for the sort of middle ground in question. If it's something such as "imports only at the top", I guess I'll just have to scream blood and bile. > Even if we ignore static type checking Python 2 really has to do > something about the "misspelling problem." One extra character on a > method name can crash a server that has been running for weeks. Once > this problem is fixed, the term "static type checking" will become > meaningful. In the current environment, it is probably not and thus > should not be the first focus of a new types-sig. I keep hearing this sort of thing, and I keep saying that it's a red herring. Lack of static typing does _not_ prevent Python from being scalable to large-scale and production environments. Our experience at FourThought, where many of our projects are small-enterprise systems built with Python and sometimes CORBA, will make it very hard for anyone to convince me so. I think the experience of users such as eGroups supports my feeling. If anything, it is Java that I think is tremendously over-rated for large-scale projects and I predict its failure in that space will soon be an industry scandal. I also don't see this "misspelling" problem. Proper configuration-management procedures and testing, along with intelligent error-recovery, prevent such problems, which can also occur in the most strongly-typed systems. -- Uche Ogbuji FourThought LLC, IT Consultants uche.ogbuji@fourthought.com (970)481-0805 Software engineering, project management, Intranets and Extranets http://FourThought.com http://OpenTechnology.org From uche.ogbuji@fourthought.com Sat Dec 4 17:25:19 1999 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Sat, 04 Dec 1999 10:25:19 -0700 Subject: [meta-sig] So What is Python Anyway? References: <38494232.C1381ED9@prescod.net> Message-ID: <38494E7F.375BD82F@fourthought.com> All these radical suggestions for the transmogrification of Python 2 leads me to the overwhelming question. What is Python? What makes us use this language? What are the particular use-cases that we think impede our use of this language? I think that maybe a comprehensive and convincing description of the problem that the types-sig is trying to solve is essential before we go down the road of more proposals to cripple Python's dynamicism and all that. -- Uche Ogbuji FourThought LLC, IT Consultants uche.ogbuji@fourthought.com (970)481-0805 Software engineering, project management, Intranets and Extranets http://FourThought.com http://OpenTechnology.org From orla_redbird@crosswinds.net Sun Dec 5 04:33:37 1999 From: orla_redbird@crosswinds.net (Gordon Worley) Date: Sat, 4 Dec 1999 23:33:37 -0500 (EST) Subject: [meta-sig] So What is Python Anyway? In-Reply-To: <38494E7F.375BD82F@fourthought.com> References: <38494232.C1381ED9@prescod.net> Message-ID: >All these radical suggestions for the transmogrification of Python 2 >leads me to the overwhelming question. What is Python? What makes us >use this language? What are the particular use-cases that we think >impede our use of this language? I think that maybe a comprehensive and >convincing description of the problem that the types-sig is trying to >solve is essential before we go down the road of more proposals to >cripple Python's dynamicism and all that. Several proposed questions, so I'll take a shot at each of them one at a time. Guido may be a better person to ask, but at least I can share my own perspective. >What is Python? A programming languge. Duh. Prehaps a religion (cult?), also, depending upon how you program and how much you use it. >What makes us use this language? This is probably the hardest to explain. I started using Python because I was both looking for somthing that wasn't so mainstream (like Pearl), offered decent Mac support, was very object-oriented (about as much as Smalltalk, but with a more real world implimentation), had easy syntax (compared to other languages I was considering trying (like Pearl, Common Lisp, Smalltalk, Objective-C)) and good documentation (Programming Python from ora), and was free. Once I started using Python, it was only then that I realized the true power that it has and realized that I had made an excellent choice. This power (the dynamicism, typlessness, modularity, etc.) is what has kept me using Python and from using other languages only when absolutely necessary. >What are the particular use-cases that we think impede our use of this >language? Python, I have found, can tackle most problems with ease. When it comes to integration with the native system, though, Python falls far short. On Unicies there isn't really that much of a problem, but on my Mac and the Windoze machines I use at school, getting Python to blend in in tough. In particular are UI and interapplication communications issues. I have few troubles with the language itself, but more with the particularities of the OS that it is running on. Each platform is radically better of in it was a year ago as far as Python integration goes, but there is still a long road ahead (at least on the Mac). Basically, creating user friendly environments tends to pose problems, but otherwise the language is great. There's probably lots that I haven't touched on here, but hopefully this will be a starting point for further discussion. - Gordon Worley http://www.crosswinds.net/~orla_redbird/ mailto:orla_redbird@crosswinds.net