From jim.fulton@Digicool.com Mon Nov 16 20:39:29 1998 From: jim.fulton@Digicool.com (Jim Fulton) Date: Mon, 16 Nov 1998 15:39:29 -0500 Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG Message-ID: <36508D81.B2E3173C@digicool.com> I propose creation of a new SIG. Problem Two of the Fundamental ideas in object oriented development are - separation of object interfaces from object implementation, and - ability to use objects with the same interface but different implementations interchangeably. When used properly, these two features provide many benefits, such as safety, stability, flexibility, reuse, and so on. Unfortunately, most computer languages provide very little support for reasoning about or testing interfaces. Worse, many languages provide incomplete or misleading interface information. Compounding the problem is that commonly used jargon has many and often conflicting interpretations. For example, the terms "class" and "type" may alternately mean interface or implementation. Even the term "interface" can have different meanings. For some, "interface" refers to method signatures, while for others, the term connotes identical behavior. For some time, Python programmers have wanted simple and efficient means to be able to test object interfaces. For example, a function may be willing to accept an argument that is either a "number" or a "sequence" and must be able to test whether the argument is one or the other to decide how it is used. As Python is used for larger projects and in a larger number of domains, reliability of Python programs is an increasing concern. People would like language support to help assure program correctness. Python 1.5 adds the ability to include assertions in programs and recent advances in the ability to extend class semantics provides the ability to experiment with argument interface checking and Meyer's "development by contract". This subject was discussed at some length in a "Developer's Day Session", "Python Interfaces" at the 7th International Python Conference. In this session, some basic goals: - ability to branch on object behavior, - support tools for providing "type safety", - document and organize the behavior of Python classes, both in the standard library and in extensions. and some basic assumptions (assertions): - interfaces are more than just signatures, - full conformance checking by the language is not practical, - Interfaces should be modeled with a separate (inheritance) hierarchy than implementation. - Subclassing should *not* require subclasses to conform to base class contracts. were presented and discussed. Out of this discussion came a straw-person proposal, dubbed by Skip Montanaro, the "Scarecrow Proposal", for a first step in implementing/prototyping Python interfaces. It was decided that a SIG should be formed to implement the Scarecrow proposal, resolve jargon issues, develop tools, such as conformance or interface documentation tools, and work on a more comprehensive proposal for Python 2. It is expected that the Python 2 interfaces proposal may include: - syntax enhancements, - built-in conformance checks and other tools, - support for richer interface modeling, such as design by contract, - support for static typing features should they materialize, - etc. I propose that a SIG should be formed with some name like "interface" or perhaps the more ecumenical, "scarecrow". :) I volunteer to administer the SIG. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.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 da@skivs.ski.org Tue Nov 17 21:50:51 1998 From: da@skivs.ski.org (David Ascher) Date: Tue, 17 Nov 1998 13:50:51 -0800 (Pacific Standard Time) Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG In-Reply-To: <36508D81.B2E3173C@digicool.com> Message-ID: > I propose creation of a new SIG. I second the proposal and support the honorable gentleman from Virginia's ascendance to the doubtful throne of scarecrow leader. --david [let's pretend this is Congress. Hmm. No, let's not] ascher From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Nov 18 16:22:53 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 18 Nov 1998 11:22:53 -0500 (EST) Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG References: <36508D81.B2E3173C@digicool.com> Message-ID: <13906.62557.725848.760305@anthem.cnri.reston.va.us> I'm surprised no one else has followed up to Jim's message, so I guess I'll be the first. Obviously I support creating a sig to address these issues. In talking with some people, I've heard rumblings about creating a super-sig that will attack 1) the interfaces issue; 2) the class/type split; 3) static typing. My own thoughts are that I'd like to keep the discussions separate because I think we'll be more productive attacking each issue in a separate forum. In reality though, if we do that, it is highly likely that the core contributors to the discussion will be subscribed to all three lists. That path leads to cross-posting such that they might as well be one list (and having 3 separate lists will just be confusing). If we go with separate lists, then I'm not sure I like the name "scarecrow-sig". Cute, but too inside-y, and certainly not descriptive of the topic. "interface-sig" is about as good as I can come up with, even though I personally oppose calling those Fulton-thingies "interfaces" :-) If on the other hand we merge the three topics, then I propose we call it either "language-sig" or "object-sig". Language-sig might be too broad, but (to me) captures the notion that these are core Python language issues we're dealing with. On the other hand, it seems to me we're trying to clarify and extend Python's fundamental object model, and how that interacts with other language features. Thus "object-sig". So please give your feedback: do we merge the three topics or keep them separate? -Barry From guido@CNRI.Reston.VA.US Wed Nov 18 16:25:55 1998 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 18 Nov 1998 11:25:55 -0500 Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG In-Reply-To: Your message of "Wed, 18 Nov 1998 11:22:53 EST." <13906.62557.725848.760305@anthem.cnri.reston.va.us> References: <36508D81.B2E3173C@digicool.com> <13906.62557.725848.760305@anthem.cnri.reston.va.us> Message-ID: <199811181625.LAA14398@eric.cnri.reston.va.us> I would call it types-sig and keep the three topics together on one list. We can still have separate threads and sub-interest groups! --Guido van Rossum (home page: http://www.python.org/~guido/) From klm@python.org Wed Nov 18 16:29:03 1998 From: klm@python.org (Ken Manheimer) Date: Wed, 18 Nov 1998 11:29:03 -0500 (EST) Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG In-Reply-To: <13906.62557.725848.760305@anthem.cnri.reston.va.us> Message-ID: One list, "language-sig". (In musing about it i also came up with "language-sig", with reservations, but reading it in your message convinced me it makes some kind of sense. Sick^H^H^H^HGreat minds think alike.) Ken From jim.fulton@Digicool.com Wed Nov 18 16:31:25 1998 From: jim.fulton@Digicool.com (Jim Fulton) Date: Wed, 18 Nov 1998 11:31:25 -0500 Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG References: <36508D81.B2E3173C@digicool.com> <13906.62557.725848.760305@anthem.cnri.reston.va.us> Message-ID: <3652F65C.4201FF2E@digicool.com> "Barry A. Warsaw" wrote: > > I'm surprised no one else has followed up to Jim's message, so I guess > I'll be the first. > > Obviously I support creating a sig to address these issues. In > talking with some people, I've heard rumblings about creating a > super-sig that will attack 1) the interfaces issue; 2) the class/type > split; 3) static typing. > > My own thoughts are that I'd like to keep the discussions separate > because I think we'll be more productive attacking each issue in a > separate forum. In reality though, if we do that, it is highly likely > that the core contributors to the discussion will be subscribed to all > three lists. That path leads to cross-posting such that they might as > well be one list (and having 3 separate lists will just be confusing). I prefer to keep the discussions separate. For one thing, the interface sig has tasks with a much shorter time frame. I also think mixing the discussions will tend to bog things down. I don't have a problem with an occasional crost post. But, whatever. :) Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.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 rmasse@cnri.reston.va.us (Roger E. Masse) Wed Nov 18 17:03:11 1998 From: rmasse@cnri.reston.va.us (Roger E. Masse) (Roger Masse) Date: Wed, 18 Nov 1998 12:03:11 -0500 (EST) Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG In-Reply-To: <13906.62557.725848.760305@anthem.cnri.reston.va.us> References: <36508D81.B2E3173C@digicool.com> <13906.62557.725848.760305@anthem.cnri.reston.va.us> Message-ID: <13906.64374.832689.471101@nobot.cnri.reston.va.us> I'm for putting them together for several reasons: 1) I don't think the static-types work alone is enough to warrent its own sig at this point 2) The static types work would be based on whatever comes out of the interfaces work 3) I'd like to bring the class/types discussions into the fray (off of egroups) to foster more participation from the community Of course, this assumes Jim is still willing to champion such a beast with a 'modified' charter... I like 'types-sig' for the name. Regards, Roger E. Masse, Systems Engineer Corporation for National Research Initiatives 1895 Preston White Drive, Suite 100 Reston, Virginia, USA 20191 rmasse@CNRI.Reston.VA.US To find out why Python rules, see: From Robin.K.Friedrich@USAHQ.UnitedSpaceAlliance.com Wed Nov 18 17:05:31 1998 From: Robin.K.Friedrich@USAHQ.UnitedSpaceAlliance.com (Friedrich, Robin K) Date: Wed, 18 Nov 1998 11:05:31 -0600 Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG Message-ID: <730BE64C7169D211B07100805FEA51B70DFF7D@usahoum2.unitedspacealliance.com> > From: Jim Fulton[SMTP:jim.fulton@Digicool.com] > > I prefer to keep the discussions separate. For one thing, the interface > sig > has tasks with a much shorter time frame. I also think mixing the > discussions > will tend to bog things down. I don't have a problem with an occasional > crost post. > > But, whatever. :) > > Jim > I agree with Jim on this. I foresee two sigs, the interface-sig and the types-sig. The later would address both the static typing options as well as the merged object model of Py2.0. Although it may be true that both lists will have the same subscribers, I suspect that the typing discussions may generate too much static (sic) for those interested in the pure interface discussions. -Robin From da@skivs.ski.org Wed Nov 18 17:21:26 1998 From: da@skivs.ski.org (David Ascher) Date: Wed, 18 Nov 1998 09:21:26 -0800 (Pacific Standard Time) Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG In-Reply-To: <13906.62557.725848.760305@anthem.cnri.reston.va.us> Message-ID: On Wed, 18 Nov 1998, Barry A. Warsaw wrote: > So please give your feedback: do we merge the three topics or keep > them separate? I'm with Jim on this one. I think that the scarecrow proposal is doable today, and a somewhat enhanced version using metaclasses/extensionclasses can be done tomorrow (or a month from now). And I think that it's important that it be done soon. The types/classes thing, on the other hand, is much more blue-sky. I think it'd be very difficult to maintain two separate thread groups which have such different goals from colliding ("oh, you mean do this with the current syntax?", "but what about backwards compatibility!??"). Move it from egroups to python.org if you want, but I value the separation of topics. I don't know where the static typing thing fits in -- my guess is it would fit in to the types/classes thing, as the part which needs discussion involves changing syntax and semantics. Everything else it requires is just plain work. =) That said, I'll bow to the majority if one emerges. --david From Vladimir.Marangozov@inrialpes.fr Wed Nov 18 17:39:18 1998 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Wed, 18 Nov 1998 18:39:18 +0100 (NFT) Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG In-Reply-To: <730BE64C7169D211B07100805FEA51B70DFF7D@usahoum2.unitedspacealliance.com> from "Friedrich, Robin K" at "Nov 18, 98 11:05:31 am" Message-ID: <199811181739.SAA26580@pukapuka.inrialpes.fr> I'd also prefer separate SIGs, but with discussion summaries crossposted regularily (depending on activity) by the SIG leaders. This will keep them tied, without actually merging them in one SIG. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From tim_one@email.msn.com Thu Nov 19 06:26:48 1998 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 19 Nov 1998 01:26:48 -0500 Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG In-Reply-To: <36508D81.B2E3173C@digicool.com> Message-ID: <000901be1385$962d93a0$079e2299@tim> I don't much care what they're called or how many there are, but I'm strongly in favor of forming the SIG(s) discussed here & in followups. the-future-of-python-rests-in-our-sweaty-palms-ly y'rs - tim From Jack.Jansen@cwi.nl Thu Nov 19 10:53:16 1998 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Thu, 19 Nov 1998 11:53:16 +0100 Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG In-Reply-To: Message by "Barry A. Warsaw" , Wed, 18 Nov 1998 11:22:53 -0500 (EST) , <13906.62557.725848.760305@anthem.cnri.reston.va.us> Message-ID: My feeling is that the type/class issue is pretty different from the other two. I wouldn't mind dumping static typing and interfaces into a single SIG, though. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jim.fulton@digicool.com Thu Nov 19 14:58:23 1998 From: jim.fulton@digicool.com (Jim Fulton) Date: Thu, 19 Nov 1998 09:58:23 -0500 Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG Message-ID: <613145F79272D211914B0020AFF64019022FBC@gandalf.digicool.com> > -----Original Message----- > From: Roger Masse [mailto:rmasse@cnri.reston.va.us] > Sent: Wednesday, November 18, 1998 12:03 PM > To: bwarsaw@cnri.reston.va.us > Cc: Jim Fulton; meta-sig@python.org > Subject: Re: [meta-sig] PROPOSAL: Python Scarecrow SIG > > > > I'm for putting them together for several reasons: > > 1) I don't think the static-types work alone is > enough to warrent its own sig at this point Really? I think that this will generate *far* more discussion than the other topics. > 2) The static types work would be based on whatever > comes out of the interfaces work Yes, but I think there will be a fairly clean small interface between the two. > 3) I'd like to bring the class/types discussions > into the fray (off of egroups) to foster more > participation from the community This can be done with a dedicated SIG. Also, I thought we wanted SIGs to be highly focussed. > Of course, this assumes Jim is still willing to champion > such a beast with a 'modified' charter... Yes, uh, whatever that means. (But please please please can we put GUI-SIG out of it's misery!) How does this decision get made? Does Guido decide? Do we vote? I'd like to get on with it, so someone please decide. :) Jim From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Nov 19 16:37:40 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 19 Nov 1998 11:37:40 -0500 (EST) Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG References: <613145F79272D211914B0020AFF64019022FBC@gandalf.digicool.com> Message-ID: <13908.18772.520949.43774@anthem.cnri.reston.va.us> >>>>> "JF" == Jim Fulton writes: JF> (But please please please can we put GUI-SIG out of JF> it's misery!) No we can't. I guess you missed it but we decided to let Greg Ward hijack GUI-SIG, renaming it to "Generating Usable Installations" SIG. :-) JF> How does this decision get made? Does Guido decide? JF> Do we vote? I'd like to get on with it, so someone JF> please decide. :) I've been keeping a tally, but who cares? We made the decision the only way possible, by arming 4 of us with plastic utensils from Guido's collection, blindfolding us, and putting us in a locked room with the last one standing getting to decide. Lesson: forks are better than knives, but spoons rule (go figure)! Anyway the decision is to create one list called the "types-sig" with a charter to discuss interfaces, static-typing, and class/types. To make the secessionists happy we'll reserve the right to bifurcate this sig at a later date if necessary. I will modify Jim's original charter to include these other two issues and close-loop with him until he's happy. Then I'll secretly annoint him champion, create the sig and make a general announcement on c.l.py. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Nov 19 23:45:51 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 19 Nov 1998 18:45:51 -0500 (EST) Subject: [meta-sig] Types-SIG Message-ID: <13908.44463.662030.696108@anthem.cnri.reston.va.us> I've created the Types-SIG on python.org. To recap, we decided to create a single mailing list to discuss the three following broad subjects: interfaces, classes vs. types, and static typing. Jim and I will be the list owners. We reserve the right to split the list later if necessary. With Jim Fulton's help, I've crafted a preliminary mission page, although I could use some contributions for the subject details (David, Roger, Jim H, feel free to send me stuff! :-). Please take a look at . The mailing list is live too, so you can follow the link off of that page to subscribe. David, we should discuss moving the egroups list discussion to here. I plan to announce the list to c.l.py and c.l.py.a tomorrow. Let the games begin (continue?), -Barry From gward@cnri.reston.va.us Fri Nov 20 19:11:29 1998 From: gward@cnri.reston.va.us (Greg Ward) Date: Fri, 20 Nov 1998 14:11:29 -0500 Subject: [meta-sig] Proposed charter: distutils-sig Message-ID: <19981120141129.A1409@thrak.cnri.reston.va.us> distutils-sig: forum to discuss module distribution utilities for Python The distutils sig is proposed to discuss the design and implementation of a suite of module distribution utilities for Python. These utilities will take the form of some standard modules, probably grouped in the 'distutils' package, for building, packaging, and installing third-party modules. This includes both modules written purely in Python and extension modules written in C/C++. The main deliverable will be the following core modules (in the distutils package): build - provides code for building a module, which might include copying .py files into a staging area, compiling and linking .c files, processing documentation to an installable form, etc. dist - create a source distribution bdist - create a 'built distribution' (the equivalent of a 'binary distribution', except that binaries won't necessarily be present install - install a built library on the local machine gen_make - generate a Makefile to do some of the above tasks (mainly 'build', for developer convenience and efficiency) I will tentatively put forward March 1999 as a target for a working release to run on top of Python 1.5.2, which *might* require a patch-and-rebuild-Python step (or might find ways to work with the information available under 1.5). For a complete, tested, documented suite ready to bundle with Python 1.6, let's shoot for June 1999. Other topics of interest: * encouraging module developers to write test suites by having a standard place for them in module distributions * ditto for documentation -- although this is probably the job of the doc-sig, it would be nice to tie the two together at some point * a standard for representing and comparing version numbers * social engineering in general, ie. convincing module developers to start using the system * the possible need for tweaks to the configure/build process for Python itself, and a place to hold configuration information (possibly a new built-in module, 'sys.config') * possibly rewriting the configure/build/install process for Python 1.6 -- especially useful if the distutils are bundled with 1.6! * ties to Trove -- any module distribution scheme must include a way to describe the package metadata, and there will need to be hooks between any future Trove archive for Python and this metadata The starting point for discussion on the sig will be the summary of the IPC7 Developer's Day session which got this whole thing rolling: http://www.foretec.com/python/workshops/1998-11/dd-ward-sum.html From Fred L. Drake, Jr." References: <19981120141129.A1409@thrak.cnri.reston.va.us> Message-ID: <13909.63176.921291.771914@weyr.cnri.reston.va.us> Greg Ward writes: > distutils-sig: forum to discuss module distribution utilities for Python I support the creation of this SIG. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191 From Edward Welbourne Tue Nov 24 11:58:12 1998 From: Edward Welbourne (Edward Welbourne) Date: Tue, 24 Nov 1998 11:58:12 GMT Subject: [meta-sig] The "distutils" SIG: name Message-ID: <199811241158.LAA04316@lsls4p.lsl.co.uk> just a suggestion ... distribution-sig, distrib-sig, dist-sig because it's all about distribution: the fact that it involves inventing utils for distribution is beside the point, just as the doc-sig isn't called the docutils-sig just because it spends most of its time dealing with doc utilities ... Personally, I'd go for dist-sig for brevity, but distrib-sig trips off the tongue better ... well, better than distutils-sig, anyway ;^> Eddy. -- It is impossible to make anything foolproof because fools are so ingenious. (But trying is a worthy exercise, and useful all the same ;^) From gward@cnri.reston.va.us Wed Nov 25 15:07:31 1998 From: gward@cnri.reston.va.us (Greg Ward) Date: Wed, 25 Nov 1998 10:07:31 -0500 Subject: [meta-sig] The "distutils" SIG: name In-Reply-To: <199811241158.LAA04316@lsls4p.lsl.co.uk>; from Edward Welbourne on Tue, Nov 24, 1998 at 11:58:12AM +0000 References: <199811241158.LAA04316@lsls4p.lsl.co.uk> Message-ID: <19981125100731.A13357@thrak.cnri.reston.va.us> On Tue, Nov 24, 1998 at 11:58:12AM +0000, Edward Welbourne wrote: > just a suggestion ... > > distribution-sig, distrib-sig, dist-sig > > because it's all about distribution: the fact that it involves inventing > utils for distribution is beside the point, just as the doc-sig isn't > called the docutils-sig just because it spends most of its time > dealing with doc utilities ... > > Personally, I'd go for dist-sig for brevity, but distrib-sig trips off the > tongue better ... well, better than distutils-sig, anyway ;^> Not a bad point... the analogy with the doc-sig is a bit flawed, as it's charter states that it's about "form and content" for Python documentation. Documentation utilities are indeed important, but they're not the central thing. For the proposed distutils-sig, the utilities *are* the central focus -- or at least, that's my intention, specifically to keep the sig focussed on writing useful utility modules. At least initially (in the design and implementation stages), social-engineering issues such as getting more people to distribute, document, and test their modules will be strictly ancillary. Later on, they'll step to the forefront. If there's a strong groundswell of support for Eddy's viewpoint, though, I'm not immovable -- and if that happens, I would argue for 'distrib-sig' for it's tongue-trippability feature. Any comments? I'm interpreting the thundering silence over my proposed charter to mean, "Yeah, get on with it already", so if I don't hear anything soon then I will just get on with it.' Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 x287 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 From barrett@compass.gsfc.nasa.gov Wed Nov 25 15:17:06 1998 From: barrett@compass.gsfc.nasa.gov (Paul Barrett) Date: Wed, 25 Nov 1998 10:17:06 -0500 (EST) Subject: [meta-sig] The "distutils" SIG: name In-Reply-To: <19981125100731.A13357@thrak.cnri.reston.va.us> References: <199811241158.LAA04316@lsls4p.lsl.co.uk> <19981125100731.A13357@thrak.cnri.reston.va.us> Message-ID: <13916.7884.987.66864@compass.gsfc.nasa.gov> I vote for 'distrib-sig' based on the previously outlined reasons. Yes, the utilities will be developed first, but I see social-engineering issues becoming and remaining important. -- Paul -- Paul Barrett - Astrophysicist - Universities Space Research Association Compton Observatory Science Support Center NASA/Goddard SFC phone: 301-286-1108 "Guk a 'mzimba, sala 'nhliziyo" Code 660.2, FAX: 301-286-1629 (body grow old, but Greenbelt,MD 20771 barrett@compass.gsfc.nasa.gov heart remain behind) http://lheawww.gsfc.nasa.gov/users/barrett/CV.html From Robin.K.Friedrich@USAHQ.UnitedSpaceAlliance.com Wed Nov 25 15:28:03 1998 From: Robin.K.Friedrich@USAHQ.UnitedSpaceAlliance.com (Friedrich, Robin K) Date: Wed, 25 Nov 1998 09:28:03 -0600 Subject: [meta-sig] The "distutils" SIG: name Message-ID: <730BE64C7169D211B07100805FEA51B70DFF98@usahoum2.unitedspacealliance.com> So as not to have my silence thunder;-) I'll vote for distrib-sig and to get on with this neat stuff post haste. > ---------- > From: Greg Ward[SMTP:gward@cnri.reston.va.us] > Sent: Wednesday, November 25, 1998 9:07 AM > To: meta-sig@python.org > Subject: Re: [meta-sig] The "distutils" SIG: name > > On Tue, Nov 24, 1998 at 11:58:12AM +0000, Edward Welbourne wrote: > > just a suggestion ... > > > > distribution-sig, distrib-sig, dist-sig > > > > because it's all about distribution: the fact that it involves inventing > > utils for distribution is beside the point, just as the doc-sig isn't > > called the docutils-sig just because it spends most of its time > > dealing with doc utilities ... > > > > Personally, I'd go for dist-sig for brevity, but distrib-sig trips off > the > > tongue better ... well, better than distutils-sig, anyway ;^> > > Not a bad point... the analogy with the doc-sig is a bit flawed, as it's > charter states that it's about "form and content" for Python > documentation. Documentation utilities are indeed important, but > they're not the central thing. > > For the proposed distutils-sig, the utilities *are* the central focus -- > or at least, that's my intention, specifically to keep the sig focussed > on writing useful utility modules. At least initially (in the design > and implementation stages), social-engineering issues such as getting > more people to distribute, document, and test their modules will be > strictly ancillary. Later on, they'll step to the forefront. > > If there's a strong groundswell of support for Eddy's viewpoint, though, > I'm not immovable -- and if that happens, I would argue for > 'distrib-sig' for it's tongue-trippability feature. > > Any comments? I'm interpreting the thundering silence over my proposed > charter to mean, "Yeah, get on with it already", so if I don't hear > anything soon then I will just get on with it.' > > Greg > -- > Greg Ward - software developer gward@cnri.reston.va.us > Corporation for National Research Initiatives > 1895 Preston White Drive voice: +1-703-620-8990 x287 > Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 > > _______________________________________________ > Meta-sig maillist - Meta-sig@python.org > http://www.python.org/mailman/listinfo/meta-sig > From Fred L. Drake, Jr." References: <199811241158.LAA04316@lsls4p.lsl.co.uk> <19981125100731.A13357@thrak.cnri.reston.va.us> <13916.7884.987.66864@compass.gsfc.nasa.gov> Message-ID: <13916.9928.245599.888475@weyr.cnri.reston.va.us> Paul Barrett writes: > I vote for 'distrib-sig' based on the previously outlined reasons. > Yes, the utilities will be developed first, but I see > social-engineering issues becoming and remaining important. I don't really care what the name is. I agree that the social engineering is part of the plan. Between early discussions with Greg and the session at IPC7, I'd expect a two-phase plan of attack: 1. Design / implement / test the distutils package as described by Greg; the design can be refined as implementation progresses (we're still talking about Python, right? ;). Get these into the 1.6 distribution, preferably by the first alpha. 2. Write documentation and educational material for the community. This should probably include updating any packages we can to use the new structures and tools. There are at least two important documents that need to be written: a. Extension Installation HOWTO. This is for users and system administrators, and explains how to unpack and install extensions that use this mechanism. This should include information about how to tailor the system to support site-specific installation policies, if there's anything to say about it. b. Extension Buidlers HOWTO. This describes how to write the setup.py script so that installers can use the instructions provided in the Extension Installation HOWTO. It may describe the appropriate directory layout for the extension package to make the installation process easy to specify, etc. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191 From guido@CNRI.Reston.VA.US Wed Nov 25 16:09:33 1998 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 25 Nov 1998 11:09:33 -0500 Subject: [meta-sig] The "distutils" SIG: name In-Reply-To: Your message of "Wed, 25 Nov 1998 10:48:24 EST." <13916.9928.245599.888475@weyr.cnri.reston.va.us> References: <199811241158.LAA04316@lsls4p.lsl.co.uk> <19981125100731.A13357@thrak.cnri.reston.va.us> <13916.7884.987.66864@compass.gsfc.nasa.gov> <13916.9928.245599.888475@weyr.cnri.reston.va.us> Message-ID: <199811251609.LAA25506@eric.cnri.reston.va.us> Good piece, Fred! Let's get this baby on the road. To me, "distutils-sig" is sounding better every time I read it, so I would recommend not wasting any more time on the naming issue. (This is a recurring theme in my posts -- remember, I spent about 0.3 microseconds thinking about whether "Python" would be a good name for a programming language, and I've never regretted it.) --Guido van Rossum (home page: http://www.python.org/~guido/) From mal@lemburg.com Wed Nov 25 22:09:11 1998 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 25 Nov 1998 23:09:11 +0100 Subject: [meta-sig] The "distutils" SIG: name References: <199811241158.LAA04316@lsls4p.lsl.co.uk> <19981125100731.A13357@thrak.cnri.reston.va.us> Message-ID: <365C8007.63845EAA@lemburg.com> Greg Ward wrote: > > On Tue, Nov 24, 1998 at 11:58:12AM +0000, Edward Welbourne wrote: > > just a suggestion ... > > > > distribution-sig, distrib-sig, dist-sig > > Any comments? I'm interpreting the thundering silence over my proposed > charter to mean, "Yeah, get on with it already", so if I don't hear > anything soon then I will just get on with it.' That's the was to go :-) Note that I want to disturb your discussion. After all it's the meta-sig, so it's the right place for it, but.... Aside: I have some tools that I use regularly for publishing my stuff. It's basically two things: a tool to print the package structure and another one to fish out the distribution files and zip/tar/whatever them into an uploadable format. And there's also a PackageTools module that allows to dynamically figure out information about installed packages. If you're interested in those, I'll put them on Starship. -- Marc-Andre Lemburg Y2000: 401 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From gward@cnri.reston.va.us Wed Nov 25 23:00:19 1998 From: gward@cnri.reston.va.us (Greg Ward) Date: Wed, 25 Nov 1998 18:00:19 -0500 (EST) Subject: [meta-sig] ANNOUNCE: Distutils-SIG created Message-ID: <199811252300.SAA14765@thrak.cnri.reston.va.us> This is to announce the creation of the Distutils-SIG on python.org. Sorry to those of you who voted for 'Distrib-SIG' as a name; your arguments were considered, but didn't win in the end. (It's nice to know someone read and thought about my original SIG proposal, at any rate.) You can subscribe to the mailing list in the usual ways: send email to distutils-sig-request@python.org, or visit the list's page at http://www.python.org/mailman/listinfo/distutils-sig/ The charter isn't yet available on www.python.org, so I'll post it to the list. Of course, no one other than me is subscribed yet, so you'll have to visit the list's archive to see it: http://www.python.org/pipermail/distutils-sig/ But it's essentially identical to the proposed charter I posted to the meta-sig, so if you saw that don't worry about tracking down the actual charter. Finally, if you want more details, take a look at my summary of the "Extension Building Considered Painful" session at Developer's Day of this year's Python Conference: http://www.foretec.com/python/workshops/1998-11/dd-ward-sum.html See you on the SIG! Greg From jim.fulton@Digicool.com Mon Nov 16 20:39:29 1998 From: jim.fulton@Digicool.com (Jim Fulton) Date: Mon, 16 Nov 1998 15:39:29 -0500 Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG Message-ID: <36508D81.B2E3173C@digicool.com> I propose creation of a new SIG. Problem Two of the Fundamental ideas in object oriented development are - separation of object interfaces from object implementation, and - ability to use objects with the same interface but different implementations interchangeably. When used properly, these two features provide many benefits, such as safety, stability, flexibility, reuse, and so on. Unfortunately, most computer languages provide very little support for reasoning about or testing interfaces. Worse, many languages provide incomplete or misleading interface information. Compounding the problem is that commonly used jargon has many and often conflicting interpretations. For example, the terms "class" and "type" may alternately mean interface or implementation. Even the term "interface" can have different meanings. For some, "interface" refers to method signatures, while for others, the term connotes identical behavior. For some time, Python programmers have wanted simple and efficient means to be able to test object interfaces. For example, a function may be willing to accept an argument that is either a "number" or a "sequence" and must be able to test whether the argument is one or the other to decide how it is used. As Python is used for larger projects and in a larger number of domains, reliability of Python programs is an increasing concern. People would like language support to help assure program correctness. Python 1.5 adds the ability to include assertions in programs and recent advances in the ability to extend class semantics provides the ability to experiment with argument interface checking and Meyer's "development by contract". This subject was discussed at some length in a "Developer's Day Session", "Python Interfaces" at the 7th International Python Conference. In this session, some basic goals: - ability to branch on object behavior, - support tools for providing "type safety", - document and organize the behavior of Python classes, both in the standard library and in extensions. and some basic assumptions (assertions): - interfaces are more than just signatures, - full conformance checking by the language is not practical, - Interfaces should be modeled with a separate (inheritance) hierarchy than implementation. - Subclassing should *not* require subclasses to conform to base class contracts. were presented and discussed. Out of this discussion came a straw-person proposal, dubbed by Skip Montanaro, the "Scarecrow Proposal", for a first step in implementing/prototyping Python interfaces. It was decided that a SIG should be formed to implement the Scarecrow proposal, resolve jargon issues, develop tools, such as conformance or interface documentation tools, and work on a more comprehensive proposal for Python 2. It is expected that the Python 2 interfaces proposal may include: - syntax enhancements, - built-in conformance checks and other tools, - support for richer interface modeling, such as design by contract, - support for static typing features should they materialize, - etc. I propose that a SIG should be formed with some name like "interface" or perhaps the more ecumenical, "scarecrow". :) I volunteer to administer the SIG. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.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 da@skivs.ski.org Tue Nov 17 21:50:51 1998 From: da@skivs.ski.org (David Ascher) Date: Tue, 17 Nov 1998 13:50:51 -0800 (Pacific Standard Time) Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG In-Reply-To: <36508D81.B2E3173C@digicool.com> Message-ID: > I propose creation of a new SIG. I second the proposal and support the honorable gentleman from Virginia's ascendance to the doubtful throne of scarecrow leader. --david [let's pretend this is Congress. Hmm. No, let's not] ascher From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Wed Nov 18 16:22:53 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Wed, 18 Nov 1998 11:22:53 -0500 (EST) Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG References: <36508D81.B2E3173C@digicool.com> Message-ID: <13906.62557.725848.760305@anthem.cnri.reston.va.us> I'm surprised no one else has followed up to Jim's message, so I guess I'll be the first. Obviously I support creating a sig to address these issues. In talking with some people, I've heard rumblings about creating a super-sig that will attack 1) the interfaces issue; 2) the class/type split; 3) static typing. My own thoughts are that I'd like to keep the discussions separate because I think we'll be more productive attacking each issue in a separate forum. In reality though, if we do that, it is highly likely that the core contributors to the discussion will be subscribed to all three lists. That path leads to cross-posting such that they might as well be one list (and having 3 separate lists will just be confusing). If we go with separate lists, then I'm not sure I like the name "scarecrow-sig". Cute, but too inside-y, and certainly not descriptive of the topic. "interface-sig" is about as good as I can come up with, even though I personally oppose calling those Fulton-thingies "interfaces" :-) If on the other hand we merge the three topics, then I propose we call it either "language-sig" or "object-sig". Language-sig might be too broad, but (to me) captures the notion that these are core Python language issues we're dealing with. On the other hand, it seems to me we're trying to clarify and extend Python's fundamental object model, and how that interacts with other language features. Thus "object-sig". So please give your feedback: do we merge the three topics or keep them separate? -Barry From guido@CNRI.Reston.VA.US Wed Nov 18 16:25:55 1998 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 18 Nov 1998 11:25:55 -0500 Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG In-Reply-To: Your message of "Wed, 18 Nov 1998 11:22:53 EST." <13906.62557.725848.760305@anthem.cnri.reston.va.us> References: <36508D81.B2E3173C@digicool.com> <13906.62557.725848.760305@anthem.cnri.reston.va.us> Message-ID: <199811181625.LAA14398@eric.cnri.reston.va.us> I would call it types-sig and keep the three topics together on one list. We can still have separate threads and sub-interest groups! --Guido van Rossum (home page: http://www.python.org/~guido/) From klm@python.org Wed Nov 18 16:29:03 1998 From: klm@python.org (Ken Manheimer) Date: Wed, 18 Nov 1998 11:29:03 -0500 (EST) Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG In-Reply-To: <13906.62557.725848.760305@anthem.cnri.reston.va.us> Message-ID: One list, "language-sig". (In musing about it i also came up with "language-sig", with reservations, but reading it in your message convinced me it makes some kind of sense. Sick^H^H^H^HGreat minds think alike.) Ken From jim.fulton@Digicool.com Wed Nov 18 16:31:25 1998 From: jim.fulton@Digicool.com (Jim Fulton) Date: Wed, 18 Nov 1998 11:31:25 -0500 Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG References: <36508D81.B2E3173C@digicool.com> <13906.62557.725848.760305@anthem.cnri.reston.va.us> Message-ID: <3652F65C.4201FF2E@digicool.com> "Barry A. Warsaw" wrote: > > I'm surprised no one else has followed up to Jim's message, so I guess > I'll be the first. > > Obviously I support creating a sig to address these issues. In > talking with some people, I've heard rumblings about creating a > super-sig that will attack 1) the interfaces issue; 2) the class/type > split; 3) static typing. > > My own thoughts are that I'd like to keep the discussions separate > because I think we'll be more productive attacking each issue in a > separate forum. In reality though, if we do that, it is highly likely > that the core contributors to the discussion will be subscribed to all > three lists. That path leads to cross-posting such that they might as > well be one list (and having 3 separate lists will just be confusing). I prefer to keep the discussions separate. For one thing, the interface sig has tasks with a much shorter time frame. I also think mixing the discussions will tend to bog things down. I don't have a problem with an occasional crost post. But, whatever. :) Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.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 rmasse@cnri.reston.va.us (Roger E. Masse) Wed Nov 18 17:03:11 1998 From: rmasse@cnri.reston.va.us (Roger E. Masse) (Roger Masse) Date: Wed, 18 Nov 1998 12:03:11 -0500 (EST) Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG In-Reply-To: <13906.62557.725848.760305@anthem.cnri.reston.va.us> References: <36508D81.B2E3173C@digicool.com> <13906.62557.725848.760305@anthem.cnri.reston.va.us> Message-ID: <13906.64374.832689.471101@nobot.cnri.reston.va.us> I'm for putting them together for several reasons: 1) I don't think the static-types work alone is enough to warrent its own sig at this point 2) The static types work would be based on whatever comes out of the interfaces work 3) I'd like to bring the class/types discussions into the fray (off of egroups) to foster more participation from the community Of course, this assumes Jim is still willing to champion such a beast with a 'modified' charter... I like 'types-sig' for the name. Regards, Roger E. Masse, Systems Engineer Corporation for National Research Initiatives 1895 Preston White Drive, Suite 100 Reston, Virginia, USA 20191 rmasse@CNRI.Reston.VA.US To find out why Python rules, see: From Robin.K.Friedrich@USAHQ.UnitedSpaceAlliance.com Wed Nov 18 17:05:31 1998 From: Robin.K.Friedrich@USAHQ.UnitedSpaceAlliance.com (Friedrich, Robin K) Date: Wed, 18 Nov 1998 11:05:31 -0600 Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG Message-ID: <730BE64C7169D211B07100805FEA51B70DFF7D@usahoum2.unitedspacealliance.com> > From: Jim Fulton[SMTP:jim.fulton@Digicool.com] > > I prefer to keep the discussions separate. For one thing, the interface > sig > has tasks with a much shorter time frame. I also think mixing the > discussions > will tend to bog things down. I don't have a problem with an occasional > crost post. > > But, whatever. :) > > Jim > I agree with Jim on this. I foresee two sigs, the interface-sig and the types-sig. The later would address both the static typing options as well as the merged object model of Py2.0. Although it may be true that both lists will have the same subscribers, I suspect that the typing discussions may generate too much static (sic) for those interested in the pure interface discussions. -Robin From da@skivs.ski.org Wed Nov 18 17:21:26 1998 From: da@skivs.ski.org (David Ascher) Date: Wed, 18 Nov 1998 09:21:26 -0800 (Pacific Standard Time) Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG In-Reply-To: <13906.62557.725848.760305@anthem.cnri.reston.va.us> Message-ID: On Wed, 18 Nov 1998, Barry A. Warsaw wrote: > So please give your feedback: do we merge the three topics or keep > them separate? I'm with Jim on this one. I think that the scarecrow proposal is doable today, and a somewhat enhanced version using metaclasses/extensionclasses can be done tomorrow (or a month from now). And I think that it's important that it be done soon. The types/classes thing, on the other hand, is much more blue-sky. I think it'd be very difficult to maintain two separate thread groups which have such different goals from colliding ("oh, you mean do this with the current syntax?", "but what about backwards compatibility!??"). Move it from egroups to python.org if you want, but I value the separation of topics. I don't know where the static typing thing fits in -- my guess is it would fit in to the types/classes thing, as the part which needs discussion involves changing syntax and semantics. Everything else it requires is just plain work. =) That said, I'll bow to the majority if one emerges. --david From Vladimir.Marangozov@inrialpes.fr Wed Nov 18 17:39:18 1998 From: Vladimir.Marangozov@inrialpes.fr (Vladimir Marangozov) Date: Wed, 18 Nov 1998 18:39:18 +0100 (NFT) Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG In-Reply-To: <730BE64C7169D211B07100805FEA51B70DFF7D@usahoum2.unitedspacealliance.com> from "Friedrich, Robin K" at "Nov 18, 98 11:05:31 am" Message-ID: <199811181739.SAA26580@pukapuka.inrialpes.fr> I'd also prefer separate SIGs, but with discussion summaries crossposted regularily (depending on activity) by the SIG leaders. This will keep them tied, without actually merging them in one SIG. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252 From tim_one@email.msn.com Thu Nov 19 06:26:48 1998 From: tim_one@email.msn.com (Tim Peters) Date: Thu, 19 Nov 1998 01:26:48 -0500 Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG In-Reply-To: <36508D81.B2E3173C@digicool.com> Message-ID: <000901be1385$962d93a0$079e2299@tim> I don't much care what they're called or how many there are, but I'm strongly in favor of forming the SIG(s) discussed here & in followups. the-future-of-python-rests-in-our-sweaty-palms-ly y'rs - tim From Jack.Jansen@cwi.nl Thu Nov 19 10:53:16 1998 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Thu, 19 Nov 1998 11:53:16 +0100 Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG In-Reply-To: Message by "Barry A. Warsaw" , Wed, 18 Nov 1998 11:22:53 -0500 (EST) , <13906.62557.725848.760305@anthem.cnri.reston.va.us> Message-ID: My feeling is that the type/class issue is pretty different from the other two. I wouldn't mind dumping static typing and interfaces into a single SIG, though. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From jim.fulton@digicool.com Thu Nov 19 14:58:23 1998 From: jim.fulton@digicool.com (Jim Fulton) Date: Thu, 19 Nov 1998 09:58:23 -0500 Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG Message-ID: <613145F79272D211914B0020AFF64019022FBC@gandalf.digicool.com> > -----Original Message----- > From: Roger Masse [mailto:rmasse@cnri.reston.va.us] > Sent: Wednesday, November 18, 1998 12:03 PM > To: bwarsaw@cnri.reston.va.us > Cc: Jim Fulton; meta-sig@python.org > Subject: Re: [meta-sig] PROPOSAL: Python Scarecrow SIG > > > > I'm for putting them together for several reasons: > > 1) I don't think the static-types work alone is > enough to warrent its own sig at this point Really? I think that this will generate *far* more discussion than the other topics. > 2) The static types work would be based on whatever > comes out of the interfaces work Yes, but I think there will be a fairly clean small interface between the two. > 3) I'd like to bring the class/types discussions > into the fray (off of egroups) to foster more > participation from the community This can be done with a dedicated SIG. Also, I thought we wanted SIGs to be highly focussed. > Of course, this assumes Jim is still willing to champion > such a beast with a 'modified' charter... Yes, uh, whatever that means. (But please please please can we put GUI-SIG out of it's misery!) How does this decision get made? Does Guido decide? Do we vote? I'd like to get on with it, so someone please decide. :) Jim From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Nov 19 16:37:40 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 19 Nov 1998 11:37:40 -0500 (EST) Subject: [meta-sig] PROPOSAL: Python Scarecrow SIG References: <613145F79272D211914B0020AFF64019022FBC@gandalf.digicool.com> Message-ID: <13908.18772.520949.43774@anthem.cnri.reston.va.us> >>>>> "JF" == Jim Fulton writes: JF> (But please please please can we put GUI-SIG out of JF> it's misery!) No we can't. I guess you missed it but we decided to let Greg Ward hijack GUI-SIG, renaming it to "Generating Usable Installations" SIG. :-) JF> How does this decision get made? Does Guido decide? JF> Do we vote? I'd like to get on with it, so someone JF> please decide. :) I've been keeping a tally, but who cares? We made the decision the only way possible, by arming 4 of us with plastic utensils from Guido's collection, blindfolding us, and putting us in a locked room with the last one standing getting to decide. Lesson: forks are better than knives, but spoons rule (go figure)! Anyway the decision is to create one list called the "types-sig" with a charter to discuss interfaces, static-typing, and class/types. To make the secessionists happy we'll reserve the right to bifurcate this sig at a later date if necessary. I will modify Jim's original charter to include these other two issues and close-loop with him until he's happy. Then I'll secretly annoint him champion, create the sig and make a general announcement on c.l.py. -Barry From bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Thu Nov 19 23:45:51 1998 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) (Barry A. Warsaw) Date: Thu, 19 Nov 1998 18:45:51 -0500 (EST) Subject: [meta-sig] Types-SIG Message-ID: <13908.44463.662030.696108@anthem.cnri.reston.va.us> I've created the Types-SIG on python.org. To recap, we decided to create a single mailing list to discuss the three following broad subjects: interfaces, classes vs. types, and static typing. Jim and I will be the list owners. We reserve the right to split the list later if necessary. With Jim Fulton's help, I've crafted a preliminary mission page, although I could use some contributions for the subject details (David, Roger, Jim H, feel free to send me stuff! :-). Please take a look at . The mailing list is live too, so you can follow the link off of that page to subscribe. David, we should discuss moving the egroups list discussion to here. I plan to announce the list to c.l.py and c.l.py.a tomorrow. Let the games begin (continue?), -Barry From gward@cnri.reston.va.us Fri Nov 20 19:11:29 1998 From: gward@cnri.reston.va.us (Greg Ward) Date: Fri, 20 Nov 1998 14:11:29 -0500 Subject: [meta-sig] Proposed charter: distutils-sig Message-ID: <19981120141129.A1409@thrak.cnri.reston.va.us> distutils-sig: forum to discuss module distribution utilities for Python The distutils sig is proposed to discuss the design and implementation of a suite of module distribution utilities for Python. These utilities will take the form of some standard modules, probably grouped in the 'distutils' package, for building, packaging, and installing third-party modules. This includes both modules written purely in Python and extension modules written in C/C++. The main deliverable will be the following core modules (in the distutils package): build - provides code for building a module, which might include copying .py files into a staging area, compiling and linking .c files, processing documentation to an installable form, etc. dist - create a source distribution bdist - create a 'built distribution' (the equivalent of a 'binary distribution', except that binaries won't necessarily be present install - install a built library on the local machine gen_make - generate a Makefile to do some of the above tasks (mainly 'build', for developer convenience and efficiency) I will tentatively put forward March 1999 as a target for a working release to run on top of Python 1.5.2, which *might* require a patch-and-rebuild-Python step (or might find ways to work with the information available under 1.5). For a complete, tested, documented suite ready to bundle with Python 1.6, let's shoot for June 1999. Other topics of interest: * encouraging module developers to write test suites by having a standard place for them in module distributions * ditto for documentation -- although this is probably the job of the doc-sig, it would be nice to tie the two together at some point * a standard for representing and comparing version numbers * social engineering in general, ie. convincing module developers to start using the system * the possible need for tweaks to the configure/build process for Python itself, and a place to hold configuration information (possibly a new built-in module, 'sys.config') * possibly rewriting the configure/build/install process for Python 1.6 -- especially useful if the distutils are bundled with 1.6! * ties to Trove -- any module distribution scheme must include a way to describe the package metadata, and there will need to be hooks between any future Trove archive for Python and this metadata The starting point for discussion on the sig will be the summary of the IPC7 Developer's Day session which got this whole thing rolling: http://www.foretec.com/python/workshops/1998-11/dd-ward-sum.html From Fred L. Drake, Jr." References: <19981120141129.A1409@thrak.cnri.reston.va.us> Message-ID: <13909.63176.921291.771914@weyr.cnri.reston.va.us> Greg Ward writes: > distutils-sig: forum to discuss module distribution utilities for Python I support the creation of this SIG. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191 From Edward Welbourne Tue Nov 24 11:58:12 1998 From: Edward Welbourne (Edward Welbourne) Date: Tue, 24 Nov 1998 11:58:12 GMT Subject: [meta-sig] The "distutils" SIG: name Message-ID: <199811241158.LAA04316@lsls4p.lsl.co.uk> just a suggestion ... distribution-sig, distrib-sig, dist-sig because it's all about distribution: the fact that it involves inventing utils for distribution is beside the point, just as the doc-sig isn't called the docutils-sig just because it spends most of its time dealing with doc utilities ... Personally, I'd go for dist-sig for brevity, but distrib-sig trips off the tongue better ... well, better than distutils-sig, anyway ;^> Eddy. -- It is impossible to make anything foolproof because fools are so ingenious. (But trying is a worthy exercise, and useful all the same ;^) From gward@cnri.reston.va.us Wed Nov 25 15:07:31 1998 From: gward@cnri.reston.va.us (Greg Ward) Date: Wed, 25 Nov 1998 10:07:31 -0500 Subject: [meta-sig] The "distutils" SIG: name In-Reply-To: <199811241158.LAA04316@lsls4p.lsl.co.uk>; from Edward Welbourne on Tue, Nov 24, 1998 at 11:58:12AM +0000 References: <199811241158.LAA04316@lsls4p.lsl.co.uk> Message-ID: <19981125100731.A13357@thrak.cnri.reston.va.us> On Tue, Nov 24, 1998 at 11:58:12AM +0000, Edward Welbourne wrote: > just a suggestion ... > > distribution-sig, distrib-sig, dist-sig > > because it's all about distribution: the fact that it involves inventing > utils for distribution is beside the point, just as the doc-sig isn't > called the docutils-sig just because it spends most of its time > dealing with doc utilities ... > > Personally, I'd go for dist-sig for brevity, but distrib-sig trips off the > tongue better ... well, better than distutils-sig, anyway ;^> Not a bad point... the analogy with the doc-sig is a bit flawed, as it's charter states that it's about "form and content" for Python documentation. Documentation utilities are indeed important, but they're not the central thing. For the proposed distutils-sig, the utilities *are* the central focus -- or at least, that's my intention, specifically to keep the sig focussed on writing useful utility modules. At least initially (in the design and implementation stages), social-engineering issues such as getting more people to distribute, document, and test their modules will be strictly ancillary. Later on, they'll step to the forefront. If there's a strong groundswell of support for Eddy's viewpoint, though, I'm not immovable -- and if that happens, I would argue for 'distrib-sig' for it's tongue-trippability feature. Any comments? I'm interpreting the thundering silence over my proposed charter to mean, "Yeah, get on with it already", so if I don't hear anything soon then I will just get on with it.' Greg -- Greg Ward - software developer gward@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive voice: +1-703-620-8990 x287 Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 From barrett@compass.gsfc.nasa.gov Wed Nov 25 15:17:06 1998 From: barrett@compass.gsfc.nasa.gov (Paul Barrett) Date: Wed, 25 Nov 1998 10:17:06 -0500 (EST) Subject: [meta-sig] The "distutils" SIG: name In-Reply-To: <19981125100731.A13357@thrak.cnri.reston.va.us> References: <199811241158.LAA04316@lsls4p.lsl.co.uk> <19981125100731.A13357@thrak.cnri.reston.va.us> Message-ID: <13916.7884.987.66864@compass.gsfc.nasa.gov> I vote for 'distrib-sig' based on the previously outlined reasons. Yes, the utilities will be developed first, but I see social-engineering issues becoming and remaining important. -- Paul -- Paul Barrett - Astrophysicist - Universities Space Research Association Compton Observatory Science Support Center NASA/Goddard SFC phone: 301-286-1108 "Guk a 'mzimba, sala 'nhliziyo" Code 660.2, FAX: 301-286-1629 (body grow old, but Greenbelt,MD 20771 barrett@compass.gsfc.nasa.gov heart remain behind) http://lheawww.gsfc.nasa.gov/users/barrett/CV.html From Robin.K.Friedrich@USAHQ.UnitedSpaceAlliance.com Wed Nov 25 15:28:03 1998 From: Robin.K.Friedrich@USAHQ.UnitedSpaceAlliance.com (Friedrich, Robin K) Date: Wed, 25 Nov 1998 09:28:03 -0600 Subject: [meta-sig] The "distutils" SIG: name Message-ID: <730BE64C7169D211B07100805FEA51B70DFF98@usahoum2.unitedspacealliance.com> So as not to have my silence thunder;-) I'll vote for distrib-sig and to get on with this neat stuff post haste. > ---------- > From: Greg Ward[SMTP:gward@cnri.reston.va.us] > Sent: Wednesday, November 25, 1998 9:07 AM > To: meta-sig@python.org > Subject: Re: [meta-sig] The "distutils" SIG: name > > On Tue, Nov 24, 1998 at 11:58:12AM +0000, Edward Welbourne wrote: > > just a suggestion ... > > > > distribution-sig, distrib-sig, dist-sig > > > > because it's all about distribution: the fact that it involves inventing > > utils for distribution is beside the point, just as the doc-sig isn't > > called the docutils-sig just because it spends most of its time > > dealing with doc utilities ... > > > > Personally, I'd go for dist-sig for brevity, but distrib-sig trips off > the > > tongue better ... well, better than distutils-sig, anyway ;^> > > Not a bad point... the analogy with the doc-sig is a bit flawed, as it's > charter states that it's about "form and content" for Python > documentation. Documentation utilities are indeed important, but > they're not the central thing. > > For the proposed distutils-sig, the utilities *are* the central focus -- > or at least, that's my intention, specifically to keep the sig focussed > on writing useful utility modules. At least initially (in the design > and implementation stages), social-engineering issues such as getting > more people to distribute, document, and test their modules will be > strictly ancillary. Later on, they'll step to the forefront. > > If there's a strong groundswell of support for Eddy's viewpoint, though, > I'm not immovable -- and if that happens, I would argue for > 'distrib-sig' for it's tongue-trippability feature. > > Any comments? I'm interpreting the thundering silence over my proposed > charter to mean, "Yeah, get on with it already", so if I don't hear > anything soon then I will just get on with it.' > > Greg > -- > Greg Ward - software developer gward@cnri.reston.va.us > Corporation for National Research Initiatives > 1895 Preston White Drive voice: +1-703-620-8990 x287 > Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913 > > _______________________________________________ > Meta-sig maillist - Meta-sig@python.org > http://www.python.org/mailman/listinfo/meta-sig > From Fred L. Drake, Jr." References: <199811241158.LAA04316@lsls4p.lsl.co.uk> <19981125100731.A13357@thrak.cnri.reston.va.us> <13916.7884.987.66864@compass.gsfc.nasa.gov> Message-ID: <13916.9928.245599.888475@weyr.cnri.reston.va.us> Paul Barrett writes: > I vote for 'distrib-sig' based on the previously outlined reasons. > Yes, the utilities will be developed first, but I see > social-engineering issues becoming and remaining important. I don't really care what the name is. I agree that the social engineering is part of the plan. Between early discussions with Greg and the session at IPC7, I'd expect a two-phase plan of attack: 1. Design / implement / test the distutils package as described by Greg; the design can be refined as implementation progresses (we're still talking about Python, right? ;). Get these into the 1.6 distribution, preferably by the first alpha. 2. Write documentation and educational material for the community. This should probably include updating any packages we can to use the new structures and tools. There are at least two important documents that need to be written: a. Extension Installation HOWTO. This is for users and system administrators, and explains how to unpack and install extensions that use this mechanism. This should include information about how to tailor the system to support site-specific installation policies, if there's anything to say about it. b. Extension Buidlers HOWTO. This describes how to write the setup.py script so that installers can use the instructions provided in the Extension Installation HOWTO. It may describe the appropriate directory layout for the extension package to make the installation process easy to specify, etc. -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191 From guido@CNRI.Reston.VA.US Wed Nov 25 16:09:33 1998 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 25 Nov 1998 11:09:33 -0500 Subject: [meta-sig] The "distutils" SIG: name In-Reply-To: Your message of "Wed, 25 Nov 1998 10:48:24 EST." <13916.9928.245599.888475@weyr.cnri.reston.va.us> References: <199811241158.LAA04316@lsls4p.lsl.co.uk> <19981125100731.A13357@thrak.cnri.reston.va.us> <13916.7884.987.66864@compass.gsfc.nasa.gov> <13916.9928.245599.888475@weyr.cnri.reston.va.us> Message-ID: <199811251609.LAA25506@eric.cnri.reston.va.us> Good piece, Fred! Let's get this baby on the road. To me, "distutils-sig" is sounding better every time I read it, so I would recommend not wasting any more time on the naming issue. (This is a recurring theme in my posts -- remember, I spent about 0.3 microseconds thinking about whether "Python" would be a good name for a programming language, and I've never regretted it.) --Guido van Rossum (home page: http://www.python.org/~guido/) From mal@lemburg.com Wed Nov 25 22:09:11 1998 From: mal@lemburg.com (M.-A. Lemburg) Date: Wed, 25 Nov 1998 23:09:11 +0100 Subject: [meta-sig] The "distutils" SIG: name References: <199811241158.LAA04316@lsls4p.lsl.co.uk> <19981125100731.A13357@thrak.cnri.reston.va.us> Message-ID: <365C8007.63845EAA@lemburg.com> Greg Ward wrote: > > On Tue, Nov 24, 1998 at 11:58:12AM +0000, Edward Welbourne wrote: > > just a suggestion ... > > > > distribution-sig, distrib-sig, dist-sig > > Any comments? I'm interpreting the thundering silence over my proposed > charter to mean, "Yeah, get on with it already", so if I don't hear > anything soon then I will just get on with it.' That's the was to go :-) Note that I want to disturb your discussion. After all it's the meta-sig, so it's the right place for it, but.... Aside: I have some tools that I use regularly for publishing my stuff. It's basically two things: a tool to print the package structure and another one to fish out the distribution files and zip/tar/whatever them into an uploadable format. And there's also a PackageTools module that allows to dynamically figure out information about installed packages. If you're interested in those, I'll put them on Starship. -- Marc-Andre Lemburg Y2000: 401 days left --------------------------------------------------------------------- : Python Pages >>> http://starship.skyport.net/~lemburg/ : --------------------------------------------------------- From gward@cnri.reston.va.us Wed Nov 25 23:00:19 1998 From: gward@cnri.reston.va.us (Greg Ward) Date: Wed, 25 Nov 1998 18:00:19 -0500 (EST) Subject: [meta-sig] ANNOUNCE: Distutils-SIG created Message-ID: <199811252300.SAA14765@thrak.cnri.reston.va.us> This is to announce the creation of the Distutils-SIG on python.org. Sorry to those of you who voted for 'Distrib-SIG' as a name; your arguments were considered, but didn't win in the end. (It's nice to know someone read and thought about my original SIG proposal, at any rate.) You can subscribe to the mailing list in the usual ways: send email to distutils-sig-request@python.org, or visit the list's page at http://www.python.org/mailman/listinfo/distutils-sig/ The charter isn't yet available on www.python.org, so I'll post it to the list. Of course, no one other than me is subscribed yet, so you'll have to visit the list's archive to see it: http://www.python.org/pipermail/distutils-sig/ But it's essentially identical to the proposed charter I posted to the meta-sig, so if you saw that don't worry about tracking down the actual charter. Finally, if you want more details, take a look at my summary of the "Extension Building Considered Painful" session at Developer's Day of this year's Python Conference: http://www.foretec.com/python/workshops/1998-11/dd-ward-sum.html See you on the SIG! Greg