From klm@CNRI.Reston.Va.US Wed Jul 9 16:00:34 1997 From: klm@CNRI.Reston.Va.US (Ken Manheimer) Date: Wed, 9 Jul 1997 11:00:34 -0400 (EDT) Subject: [META-SIG] Python.org bounces overnight Message-ID: <199707091500.LAA21635@glyph.cnri.reston.va.us> I accidentally disrupted majordomo in the process of some finagling yesterday, so any messages posted to the sigs during that time were bounced to the sig owners, rather than being delivered to the lists. For those of you that are list owners, you can resubmit the bounced messages by copying the relevant parts of the headers (eg, the original "From:", "To:", "Message-id:", etc), plus a "Resent-To:" with the list address as the target, and include the original body. This will reroute the message back to the list, for distribution. Sorry about the disruption - i'm trying to make it easy to prevent some notorious spam sources from using our sig and psa-members lists, and accidentally applied one of my experimental changes to the production code... Ken Manheimer klm@cnri.reston.va.us 703 620-8990 x268 (orporation for National Research |nitiatives 1895 Preston White Drive, Suite 100 Reston, VA 22091 _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From klm@CNRI.Reston.Va.US Wed Jul 9 18:10:44 1997 From: klm@CNRI.Reston.Va.US (Ken Manheimer) Date: Wed, 9 Jul 1997 13:10:44 -0400 (EDT) Subject: [META-SIG] PSA majordomo lists - excluding certain posts Message-ID: <199707091710.NAA22394@glyph.cnri.reston.va.us> Another note to PSA SIG list managers. I've set up something to filter out spam hot spots from all PSA SIG and members traffic. Approved messages are exempt from the exclusion, so mail list bounces that should be accepted can be resent with an appropriate approved line. To start with, i've put something in to exclude everything from hotmail.com, excepting the few hotmail.com addresses i found in the sig subscription lists. Please let me know if you have any problems with or suggestions about this! SOme details about the implementation. There's a new option, "exclude_post", which specifies files containing addresses to be excluded. (The list of files is modelled exactly after the existing "restrict_post" option, and in fact uses its mechanism to get to the file.) The exclusion file consists of lines that start with an exclusion address, optionally followed by exceptions to that exclusion. Senders addresses that _contain_ the exclusion address, and that do *not* contain any of the exception addresses, are bounced. For remote SIG administrators - this file is not remotely settable. You will need to contact us here to get an addition or modification to one of the exclusions. Send email to eg majordomo-owner@python.org, or webmaster@python.org, or whatever. For local people, the file is named "forbidden", located in the lists directory. It is included *by default* for every mailing list. You can override that by adding an explicit entry for "exclude_post" in your config file. Ken Manheimer klm@cnri.reston.va.us 703 620-8990 x268 (orporation for National Research |nitiatives # Thanks for working with the PSA! # # . # _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From JOE_ELLSWORTH@HP-Cupertino-om5.om.hp.com Tue Jul 15 16:33:55 1997 From: JOE_ELLSWORTH@HP-Cupertino-om5.om.hp.com (JOE_ELLSWORTH@HP-Cupertino-om5.om.hp.com) Date: Tue, 15 Jul 97 09:33:55 -0600 Subject: [META-SIG] Python a new opportunity. Message-ID: Python a new opportunity. I have been watching Python for some time and it is apparent that Python could benefit from a large group of new programmers. As such I have would like to propose an idea that may help provide such a group. I have began looking at an area of applications that are ideal candidates for execution on the new class of Windows/CE palmtops such as the HP/LX300. We have developed several applications for Laptops that would be better deployed based on this new class of devices but have no available development environments that would facilitate moving these applications to the device and for the most part any applications built for the CE are not portable or directly inter operable to the desktop My experience in the vertical application market space leads me to believe that this group of devices will represent one of the fastest growing application deployment segments during the next several years. I believe Python and a TK look alike could fill this niche better than currently available development tools and would benefit from doing so by attracting a new group of previously inaccessible pragmatic application developers. Of course marketing the availability of the tool would be as important as making it available in the first place. Some non trivial applications using the tool would also help. The core MFC libraries are available for CE and as such a porting effort should not be terribly difficult except for memory foot print and access to a few proprietary features of the new device. Features Needed to compete in this space: Compatibility with Windows CE. A base memory foot print less than 500K, ideally less than 300K. multiple copies of interpreter should be able to share base memory. Built in extension libraries to support new object store. This should be reflected Built in GUI extension libraries to support Ability to fetch files from a local PC or a remote network source using the PC serial connection. Built in extension library to support core GUI competency of the CE class of devices which would be a primitive grid widget and a sideways note tab container widget. Extension library to support NT / UNIX inter operability. Extension library to support inter operation with the TAPI/IP programming interface. Optional Enhancements that would improve Market acceptance: Compatibility at source level with Newton. A Python UNIX/NT server that can interact with client A browser with better capability than IIE Light. (EG: Scripting). A Javascript to Python Translator or Emulator. An automated bridge to a ODBC data source residing on a the partner PC. This could be done with a small python server residing on the PC which accesses the ODBC data source and proxies requests on behalf of the palmtop device. I understand that this would represent a significant effort but the rewards as per the number of new developers may be well worth the investment. See: http://www.microsoft.com/windowsce/developer/ http://www.hp.com/handheld/handheld_devices/index.html http://www.casio-usa.com/html/products/handheldpc.html http://www.newton-inc.com/product_info/product_info.html If anybody develops such a tool I would be interested in alpha testing it. My primary motivation is in having a more productive tool set available for application deployment while encouraging success of GNU style free software contribute to standards rather than having only proprietary vendor supplied tools control this new segment. Any feedback or different viewpoints would be greatly appreciated. Thanks, Joe E. _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From rushing@nightmare.com Wed Jul 16 05:32:28 1997 From: rushing@nightmare.com (Samual M. Rushing) Date: Tue, 15 Jul 1997 23:32:28 -0500 Subject: [META-SIG] Re: Python a new opportunity. In-Reply-To: (JOE_ELLSWORTH@HP-Cupertino-om5.om.hp.com) Message-ID: <199707160432.XAA20304@ziggurat.nightmare.com> -----BEGIN PGP SIGNED MESSAGE----- >>>>> "je" == JOE ELLSWORTH writes: je> I believe Python and a TK look alike could fill this je> niche better than currently available development tools and je> would benefit from doing so by attracting a new group of je> previously inaccessible pragmatic application developers. Of je> course marketing the availability of the tool would be as je> important as making it available in the first place. Some non je> trivial applications using the tool would also help. je> The core MFC libraries are available for CE and as such a je> porting effort should not be terribly difficult except for je> memory foot print and access to a few proprietary features of je> the new device. I don't know about MFC on the CE platform, but elsewhere MFC is nearly a megabyte. [imagine what you could do with a megabyte of python byte code!] je> Features Needed to compete in this space: Compatibility je> with Windows CE. je> A base memory foot print less than 500K, ideally less je> than 300K. multiple copies of interpreter should be able to je> share base memory. One thing you might want to explore is the fledgling 'class library' that's included with the 'calldll' module: Although it's very incomplete (I don't get to work on it much), it suffices for building windows applications. It uses calldll to speak directly to the windows API: (i.e., it calls functions in user32.dll, gdi32.dll, kernel32.dll, etc...) Even with the message loop written entirely in Python, the performance is good: I've written applications that do scrolled scaled graphics... Most of this is in about, hmmm... 50-60k of pyc files. I think a Tk-like library (in other words, a well-designed, object-oriented library where widgets can be composed) could be built on this. In fact, that was my goal when I started working on it. [see http://www.nightmare.com/software.html for a description of the calldll] - -Sam -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBM8xOpGys8OGgJmJxAQHi7QQApRXBuBabCb74h5yMFCmvCcNVTuX6E8TV 2usRLwsOSH19X3ONKjfNMhK69n/kQ1DnlrHTTFTHQleZICx11+pBgyS6hl+34DI7 XKzU+zelMcE4ySQB+1q93oJzvAAHwbSu6FzXkqPYAIXEjV6NzQztqcg8na9zDxN1 tnIPBqSoSf0= =IXVm -----END PGP SIGNATURE----- _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From JOE_ELLSWORTH@HP-Cupertino-om5.om.hp.com Thu Jul 17 07:04:22 1997 From: JOE_ELLSWORTH@HP-Cupertino-om5.om.hp.com (JOE_ELLSWORTH@HP-Cupertino-om5.om.hp.com) Date: Thu, 17 Jul 97 00:04:22 -0600 Subject: [META-SIG] Re: Python a new opportunity. In-Reply-To: <199707160432.XAA20304@ziggurat.nightmare.com> Message-ID: Hi Sam, Thanks for taking the time to respond. I would be interested in your analysis of the opportunity and my opinion of it's potential benefit to the Python / Freeware community. If such a project is pursued what is your opinion about how to maximise it's visibility to the new group of candidate programmers? I don't believe these people would normally access Python.com and time would be of a essence so a body of Python projects could be created prior to another solution arriving on the seen and confusing the issue. Thanks, Joe E. *** My Response *** This represents a short term opportunity for Python which must be brought to fruition soon if it is to actually deliver a new body of engineers to the Python community before another alternative grabs the mind share. Currently this appears to be virgin territory but a commercial venture of some sort is bound to recognise the gap and move to fill it soon. I think other vendors will require a bit of time to exit their "Windows/NT" unlimited Disk and RAM mentality and switch back to designs that will approximate what Python does so well now. A lot of vendors will not even try and will take the approach that these systems will scale up so quickly that in a year or so they will be able to deploy their Win/95 applications in the same form factor. I cringe at this type of approach and hope Python can step in and provide a workable solution quickly which will encourage a move to maximising the effective use of the resources we have. If we have to wait until I have bandwidth to work on such a project it may be the year 2000 and Microsoft will have recognised the gap and deployed a different solution. Your point about the functionality that can be packed in to Python byte code is one of the primary reasons I was thinking Python would make a great solution in this space. I am predominately a vertical application developer so I am thrilled by the idea of an environment that would let me squeeze full size application logic into a congested Memory space. This would allow me to pursue developing a class of applications that I would currently consider out of scale for such a device. It is unfortunate that we can't get Python added to the device's ROM so there would be no space overhead from the interpreter. From the limited Python I have written I get the impression that Python byte code "per logical feature point" seems to be smaller than equivalent Java byte code but I am not sure why this occurs. I am not an expert in this area but from what I have read so far it appears that a sub set of MFC is actually embedded in the machines ROM and they appear to be working some other magic to minimise the size of programs generated using a custom version of MFC and a custom compiler. An associate of mine thinks that you must include a reference to this special library in order to access the device's special features such as the Object Store, TAPI interface and custom GUI widgets but I have not validated this. Good luck, Joe Ellsworth. P.S. My primary motivation is to see a language I think warrants a chance at wider exposure take advantage of a momentary laps of the industry giants gain a larger mind share. Python's wider spread adoption could encourage industry giants to improve the quality of their product offering to match. At the current time Python for all it's strength does not seem to hold sufficient mind share to be used as such a lever and it is playing in such a congested market segment that it will have a difficult time growing to realise it's full potential. ______________________________ Reply Separator _________________________________ Subject: Re: Python a new opportunity. Author: Non-HP-rushing (rushing@nightmare.com) at HP-ColSprings,shargw5 Date: 7/15/97 10:32 PM -----BEGIN PGP SIGNED MESSAGE----- >>>>> "je" == JOE ELLSWORTH writes: je> I believe Python and a TK look alike could fill this je> niche better than currently available development tools and je> would benefit from doing so by attracting a new group of je> previously inaccessible pragmatic application developers. Of je> course marketing the availability of the tool would be as je> important as making it available in the first place. Some non je> trivial applications using the tool would also help. je> The core MFC libraries are available for CE and as such a je> porting effort should not be terribly difficult except for je> memory foot print and access to a few proprietary features of je> the new device. I don't know about MFC on the CE platform, but elsewhere MFC is nearly a megabyte. [imagine what you could do with a megabyte of python byte code!] je> Features Needed to compete in this space: Compatibility je> with Windows CE. je> A base memory foot print less than 500K, ideally less je> than 300K. multiple copies of interpreter should be able to je> share base memory. One thing you might want to explore is the fledgling 'class library' that's included with the 'calldll' module: Although it's very incomplete (I don't get to work on it much), it suffices for building windows applications. It uses calldll to speak directly to the windows API: (i.e., it calls functions in user32.dll, gdi32.dll, kernel32.dll, etc...) Even with the message loop written entirely in Python, the performance is good: I've written applications that do scrolled scaled graphics... Most of this is in about, hmmm... 50-60k of pyc files. I think a Tk-like library (in other words, a well-designed, object-oriented library where widgets can be composed) could be built on this. In fact, that was my goal when I started working on it. [see http://www.nightmare.com/software.html for a description of the calldll] - -Sam -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBM8xOpGys8OGgJmJxAQHi7QQApRXBuBabCb74h5yMFCmvCcNVTuX6E8TV 2usRLwsOSH19X3ONKjfNMhK69n/kQ1DnlrHTTFTHQleZICx11+pBgyS6hl+34DI7 XKzU+zelMcE4ySQB+1q93oJzvAAHwbSu6FzXkqPYAIXEjV6NzQztqcg8na9zDxN1 tnIPBqSoSf0= =IXVm -----END PGP SIGNATURE----- _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From gstein@microsoft.com Thu Jul 17 21:32:49 1997 From: gstein@microsoft.com (Greg Stein) Date: Thu, 17 Jul 1997 13:32:49 -0700 Subject: [META-SIG] closing db-sig Message-ID: <41135C785691CF11B73B00805FD4D2D703260689@RED-17-MSG.dns.microsoft.com> At this point, I believe the db-sig has completed its business and I'd like to close it down. Most of the traffic over the past year has been question-related rather than mission-related. These kinds of posts can easily be moved to the main Python newsgroup. If somebody would like to refine the mission statement and take over "ownership" of the db-sig, then they should speak up and begin that process. Otherwise, I'll send mail to Barry to have the sig closed down sometime in the next couple of weeks. Thx -g _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From guido@CNRI.Reston.Va.US Sun Jul 20 15:32:00 1997 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Sun, 20 Jul 1997 10:32:00 -0400 Subject: [META-SIG] Proposal for new SIG: Thead SIG Message-ID: <199707201432.KAA13530@eric.CNRI.Reston.Va.US> In response to thread discussion on c.l.p, there were some voices to create a Special Interest Group on Threading. I volunteered to write a draft SIG manifesto for it, and Greg Stein has volunteered to become the SIG champion. (Now that he's dropping the db-sig; has anybody volunteered to keep it alive? If not, I propose to shut it down, keeping the archives of course). If there's no discussion based on this proposal, I take it that there's no need for a Thread-SIG -- so please comment! --Guido ======================================================================== Subject: Thread-SIG -- Mission Statement (DRAFT) The Thread SIG strives to improve the status of threading in Python. It has specific goals and deliverables. The SIG will be shut down (after discussion) when these have been reached and produced, respectively. The (lofty) SIG goals are: - The Python threading interface should be sufficiently powerful that its users can concentrate on using threads rather than writing threading tools. - There should be sufficient documentation for the Python threading interface. - Python should support threading well on every platform where the native OS has decent threading support; if possible, this support should be automatic (e.g. automatically detected by the configure script rather than specified as a command line option to it). In particular, good thread support should exist on Windows 95 and NT, and on all Unix systems for which a vendor-supported pthread implementation exists. - There should be some kind of answer to the problems caused by Python's central interpreter lock -- if not permanent removal of the lock (which seems problematic without significant performance loss), then at least some other way that makes it possible to run multiple threads comfortably on a single-processor machine -- perhaps BEGIN/END thread macros everwhere, perhaps a compile time switch to enable something like Greg Stein's "free threading" patches, perhaps something else. - Some kind of threading that's suitable for multiprocessor machines??? The SIG deliverables will be determined by the SIG. They will include at least: - A "Threading in Python" document that describes HOWTOs, gotchas, available packages/patches, etc. This would address the continual "how do I use threads in Python?" questions. - A design for higher level threading functionality to be added to standard Python (perhaps an extended thread module, perhaps some additional Python modules, perhaps a new "pthread" module more closely modelled after Posix threads, perhaps all three). - A documented implementation of the above design. - Patches to standard Python that reduce the problems with the interpreter lock, perhaps modelled after Greg Stein's patches. While the thread-sig exists, other thread related discussions are welcome, however these should not be confused with the SIG's goals. ======================================================================== --Guido van Rossum (home page: http://www.python.org/~guido/) _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From guido@CNRI.Reston.Va.US Sun Jul 20 15:33:17 1997 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Sun, 20 Jul 1997 10:33:17 -0400 Subject: [META-SIG] Proposal for new SIG: Thread SIG Message-ID: <199707201433.KAA13536@eric.CNRI.Reston.Va.US> [Repost with typo fixed in subject -- please ignore the previous one!] In response to thread discussion on c.l.p, there were some voices to create a Special Interest Group on Threading. I volunteered to write a draft SIG manifesto for it, and Greg Stein has volunteered to become the SIG champion. (Now that he's dropping the db-sig; has anybody volunteered to keep it alive? If not, I propose to shut it down, keeping the archives of course). If there's no discussion based on this proposal, I take it that there's no need for a Thread-SIG -- so please comment! --Guido ======================================================================== Subject: Thread-SIG -- Mission Statement (DRAFT) The Thread SIG strives to improve the status of threading in Python. It has specific goals and deliverables. The SIG will be shut down (after discussion) when these have been reached and produced, respectively. The (lofty) SIG goals are: - The Python threading interface should be sufficiently powerful that its users can concentrate on using threads rather than writing threading tools. - There should be sufficient documentation for the Python threading interface. - Python should support threading well on every platform where the native OS has decent threading support; if possible, this support should be automatic (e.g. automatically detected by the configure script rather than specified as a command line option to it). In particular, good thread support should exist on Windows 95 and NT, and on all Unix systems for which a vendor-supported pthread implementation exists. - There should be some kind of answer to the problems caused by Python's central interpreter lock -- if not permanent removal of the lock (which seems problematic without significant performance loss), then at least some other way that makes it possible to run multiple threads comfortably on a single-processor machine -- perhaps BEGIN/END thread macros everwhere, perhaps a compile time switch to enable something like Greg Stein's "free threading" patches, perhaps something else. - Some kind of threading that's suitable for multiprocessor machines??? The SIG deliverables will be determined by the SIG. They will include at least: - A "Threading in Python" document that describes HOWTOs, gotchas, available packages/patches, etc. This would address the continual "how do I use threads in Python?" questions. - A design for higher level threading functionality to be added to standard Python (perhaps an extended thread module, perhaps some additional Python modules, perhaps a new "pthread" module more closely modelled after Posix threads, perhaps all three). - A documented implementation of the above design. - Patches to standard Python that reduce the problems with the interpreter lock, perhaps modelled after Greg Stein's patches. While the thread-sig exists, other thread related discussions are welcome, however these should not be confused with the SIG's goals. ======================================================================== --Guido van Rossum (home page: http://www.python.org/~guido/) _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From MHammond@skippinet.com.au Mon Jul 21 00:24:45 1997 From: MHammond@skippinet.com.au (Mark Hammond) Date: Mon, 21 Jul 1997 09:24:45 +1000 Subject: [META-SIG] Proposal for new SIG: Thead SIG Message-ID: <199707202340.JAA19735@minotaur.labyrinth.net.au> I have seen enough interest and general questions on the main list that such a SIG is _definately_ called for - we just need to hope there are enough people to keep it alive. But I think there are enough people who care already, so lets go for it... Mark. _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From mclay@nist.gov Mon Jul 21 09:26:14 1997 From: mclay@nist.gov (Michael McLay) Date: Mon, 21 Jul 1997 04:26:14 -0400 Subject: [META-SIG] Proposal for new SIG: Thead SIG In-Reply-To: <199707201432.KAA13530@eric.CNRI.Reston.Va.US> References: <199707201432.KAA13530@eric.CNRI.Reston.Va.US> Message-ID: <199707210826.EAA28691@fermi.eeel.nist.gov> Guido van Rossum writes: > In response to thread discussion on c.l.p, there were some voices to > create a Special Interest Group on Threading. I volunteered to write > a draft SIG manifesto for it, and Greg Stein has volunteered to become > the SIG champion. (Now that he's dropping the db-sig; has anybody > volunteered to keep it alive? If not, I propose to shut it down, > keeping the archives of course). I'd like to keep it alive, so I'll take over as the sig champion. I think it needs to stay open until a few more databases are compliant with the db interface standard. (In particuular the mSQL interface doesn't comply. I just started using it, so I might be able to work on this some.) Also, since the sig web page is the primary hook for getting information about the Python database interface standard it can't just be abandoned. It would create some dead links. I really think we need to classify the SIGs based on activity level. Some of the dormant SIGs should be labeled as such and moved to a separate section at the bottom of the SIG page. _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From guido@CNRI.Reston.Va.US Mon Jul 21 14:56:30 1997 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Mon, 21 Jul 1997 09:56:30 -0400 Subject: [META-SIG] Re: retiring the db-sig In-Reply-To: Your message of "Mon, 21 Jul 1997 04:26:14 EDT." <199707210826.EAA28691@fermi.eeel.nist.gov> References: <199707201432.KAA13530@eric.CNRI.Reston.Va.US> <199707210826.EAA28691@fermi.eeel.nist.gov> Message-ID: <199707211356.JAA14296@eric.CNRI.Reston.Va.US> Michael McLay writes, on retiring the db-sig: > I'd like to keep it alive, so I'll take over as the sig champion. I > think it needs to stay open until a few more databases are compliant > with the db interface standard. (In particuular the mSQL interface > doesn't comply. I just started using it, so I might be able to work > on this some.) Also, since the sig web page is the primary hook for > getting information about the Python database interface standard it > can't just be abandoned. It would create some dead links. > > I really think we need to classify the SIGs based on activity level. > Some of the dormant SIGs should be labeled as such and moved to a > separate section at the bottom of the SIG page. That's a great idea -- perhaps a separate section of "past sigs" could be kept around as well, with their last known home page, archive etc. E.g. I imagine that the archives of the recently closed pythonwin-sig should still be accessible! --Guido van Rossum (home page: http://www.python.org/~guido/) _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From blizzard@appliedtheory.com Mon Jul 21 15:49:44 1997 From: blizzard@appliedtheory.com (Christopher Blizzard) Date: Mon, 21 Jul 1997 10:49:44 -0400 Subject: [META-SIG] Proposal for new SIG: Thread SIG In-Reply-To: Your message of "Sun, 20 Jul 1997 10:33:17 EDT." <199707201433.KAA13536@eric.CNRI.Reston.Va.US> Message-ID: <199707211449.KAA19736@odin.appliedtheory.com> In message <199707201433.KAA13536@eric.CNRI.Reston.Va.US>, Guido van Rossum wri tes: : :======================================================================== :Subject: Thread-SIG -- Mission Statement (DRAFT) : :The Thread SIG strives to improve the status of threading in Python. :It has specific goals and deliverables. The SIG will be shut down :(after discussion) when these have been reached and produced, :respectively. : :The (lofty) SIG goals are: : : - The Python threading interface should be sufficiently powerful that : its users can concentrate on using threads rather than writing : threading tools. : : - There should be sufficient documentation for the Python threading : interface. : : - Python should support threading well on every platform where the : native OS has decent threading support; if possible, this support : should be automatic (e.g. automatically detected by the configure : script rather than specified as a command line option to it). In : particular, good thread support should exist on Windows 95 and NT, : and on all Unix systems for which a vendor-supported pthread : implementation exists. : : - There should be some kind of answer to the problems caused by : Python's central interpreter lock -- if not permanent removal of the : lock (which seems problematic without significant performance loss), : then at least some other way that makes it possible to run multiple : threads comfortably on a single-processor machine -- perhaps BEGIN/END : thread macros everwhere, perhaps a compile time switch to enable : something like Greg Stein's "free threading" patches, perhaps : something else. : : - Some kind of threading that's suitable for multiprocessor : machines??? : :The SIG deliverables will be determined by the SIG. They will include :at least: : : - A "Threading in Python" document that describes HOWTOs, gotchas, : available packages/patches, etc. This would address the continual : "how do I use threads in Python?" questions. : : - A design for higher level threading functionality to be added to : standard Python (perhaps an extended thread module, perhaps some : additional Python modules, perhaps a new "pthread" module more closely : modelled after Posix threads, perhaps all three). : Are you talking about a generic Python threading API that is the same for all underlying thread implimentations? Overall this proposal looks like it's right on the money. I hope this SIG takes shape. :) --Chris : - A documented implementation of the above design. : : - Patches to standard Python that reduce the problems with the : interpreter lock, perhaps modelled after Greg Stein's patches. : :While the thread-sig exists, other thread related discussions are :welcome, however these should not be confused with the SIG's goals. :======================================================================== : : ------------ Christopher Blizzard AppliedTheory Communications, Inc. http://odin.appliedtheory.com/ blizzard@appliedtheory.com ------------ _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From furnish@acl.lanl.gov Mon Jul 21 15:58:38 1997 From: furnish@acl.lanl.gov (Geoffrey Furnish) Date: Mon, 21 Jul 1997 08:58:38 -0600 (MDT) Subject: [META-SIG] Proposal for new SIG: Thread SIG In-Reply-To: <199707201433.KAA13536@eric.CNRI.Reston.Va.US> References: <199707201433.KAA13536@eric.CNRI.Reston.Va.US> Message-ID: <199707211458.IAA03864@steam.acl.lanl.gov> Guido van Rossum writes: > If there's no discussion based on this proposal, I take it that > there's no need for a Thread-SIG -- so please comment! I support the proposal for a Thread-SIG. -- Geoffrey Furnish email: furnish@lanl.gov LANL CIC-19 POOMA/RadTran phone: 505-665-4529 fax: 505-665-7880 "Here are your ball-peen hammers. Now go malleate some heads!" -Jim Morel _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From andrus@chopper.us.dg.com Mon Jul 21 16:26:43 1997 From: andrus@chopper.us.dg.com (Ross Andrus) Date: Mon, 21 Jul 1997 11:26:43 -0400 (EDT) Subject: [META-SIG] Re: Thread-SIG Message-ID: <199707211526.LAA08652@astra.us.dg.com> GvR > If there's no discussion based on this proposal, I take it that > there's no need for a Thread-SIG -- so please comment! > > --Guido I think it's needed, and so I support it's creation. I don't know what I, personally, could contribute, but I'd be happy to try... ross -- Ross Andrus Data General Corporation andrus@chopper.us.dg.com 4400 Computer Drive (508) 898-5156 (voice) Westboro, MA 01580 (508) 898-5097 (fax) MS F135 (SSD) 232-5156 (DG internal) _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From amk@magnet.com Mon Jul 21 16:36:42 1997 From: amk@magnet.com (Andrew Kuchling) Date: Mon, 21 Jul 1997 11:36:42 -0400 (EDT) Subject: [META-SIG] Re: retiring the db-sig In-Reply-To: <199707211356.JAA14296@eric.CNRI.Reston.Va.US> from "Guido van Rossum" at Jul 21, 97 09:56:30 am Message-ID: <199707211536.LAA18383@lemur.magnet.com> > Michael McLay writes, on retiring the db-sig: > > on this some.) Also, since the sig web page is the primary hook for > > getting information about the Python database interface standard it > > can't just be abandoned. It would create some dead links. We really shouldn't have important information only accessible from SIG links. How about following the Linux example and creating a list of HOWTOs? They're small documents that cover one specific topic quite completely; some of the Linux ones cover things like configuring PPP, using Chinese/Japanese character sets. Python ones could cover the database interface, threads, or whatever. (The docstring in cgi.py could almost become a CGI HOWTO.) GvR wrote: > E.g. I imagine that the archives of the recently closed pythonwin-sig > should still be accessible! Who suggested taking them down? I'm certainly not going to remove them just because the SIG closed; people may come across them while doing a Web search and find out about Python that way. Andrew Kuchling amk@magnet.com http://people.magnet.com/%7Eamk/ _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From guido@CNRI.Reston.Va.US Mon Jul 21 16:43:38 1997 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Mon, 21 Jul 1997 11:43:38 -0400 Subject: [META-SIG] Re: retiring the db-sig In-Reply-To: Your message of "Mon, 21 Jul 1997 11:36:42 EDT." <199707211536.LAA18383@lemur.magnet.com> References: <199707211536.LAA18383@lemur.magnet.com> Message-ID: <199707211543.LAA14751@eric.CNRI.Reston.Va.US> > > Michael McLay writes, on retiring the db-sig: > > > on this some.) Also, since the sig web page is the primary hook for > > > getting information about the Python database interface standard it > > > can't just be abandoned. It would create some dead links. > > We really shouldn't have important information only accessible > from SIG links. How about following the Linux example and creating a > list of HOWTOs? They're small documents that cover one specific topic > quite completely; some of the Linux ones cover things like configuring > PPP, using Chinese/Japanese character sets. Python ones could cover > the database interface, threads, or whatever. (The docstring in > cgi.py could almost become a CGI HOWTO.) Agreed. The problem is, we desperately need volunteers to set this up. Ken Manheimer doesn't have time! > GvR wrote: > > E.g. I imagine that the archives of the recently closed pythonwin-sig > > should still be accessible! > > Who suggested taking them down? I'm certainly not going to > remove them just because the SIG closed; people may come across them > while doing a Web search and find out about Python that way. Absolutely -- but good SIGs have links to their own archives too and those might become inaccessible. It is also a bit of a trick I think to keep the raw majordomo archives around when the list is abandoned. --Guido van Rossum (home page: http://www.python.org/~guido/) _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From gstein@microsoft.com Thu Jul 17 21:32:49 1997 From: gstein@microsoft.com (Greg Stein) Date: Thu, 17 Jul 1997 13:32:49 -0700 Subject: [META-SIG] closing db-sig Message-ID: <41135C785691CF11B73B00805FD4D2D703260689@RED-17-MSG.dns.microsoft.com> At this point, I believe the db-sig has completed its business and I'd like to close it down. Most of the traffic over the past year has been question-related rather than mission-related. These kinds of posts can easily be moved to the main Python newsgroup. If somebody would like to refine the mission statement and take over "ownership" of the db-sig, then they should speak up and begin that process. Otherwise, I'll send mail to Barry to have the sig closed down sometime in the next couple of weeks. Thx -g _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From amk@magnet.com Mon Jul 21 17:03:00 1997 From: amk@magnet.com (Andrew Kuchling) Date: Mon, 21 Jul 1997 12:03:00 -0400 (EDT) Subject: [META-SIG] Re: retiring the db-sig In-Reply-To: <199707211543.LAA14751@eric.CNRI.Reston.Va.US> from "Guido van Rossum" at Jul 21, 97 11:43:38 am Message-ID: <199707211603.MAA19460@lemur.magnet.com> > [My furgling about HOWTOs] GvR wrote: > Agreed. The problem is, we desperately need volunteers to set this > up. Ken Manheimer doesn't have time! To actually write the documents, you mean? Ken certainly wouldn't be expected to do that... Perhaps after 1.5 ships we can work on this; for the moment it's not a vital priority. Another particularly useful HOWTO would be one for PythonWin; someday somebody should trawl through the PythonWin-SIG archives and pull out examples, useful references... Andrew Kuchling amk@magnet.com http://people.magnet.com/%7Eamk/ _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From guido@CNRI.Reston.Va.US Tue Jul 22 00:12:37 1997 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Mon, 21 Jul 1997 19:12:37 -0400 Subject: [META-SIG] Re: retiring the db-sig In-Reply-To: Your message of "Mon, 21 Jul 1997 12:03:00 EDT." <199707211603.MAA19460@lemur.magnet.com> References: <199707211603.MAA19460@lemur.magnet.com> Message-ID: <199707212312.TAA16940@eric.CNRI.Reston.Va.US> > > [My furgling about HOWTOs] > GvR wrote: > > Agreed. The problem is, we desperately need volunteers to set this > > up. Ken Manheimer doesn't have time! > > To actually write the documents, you mean? Ken certainly > wouldn't be expected to do that... Perhaps after 1.5 ships we can > work on this; for the moment it's not a vital priority. No -- I meant that Ken doesn't have the time to create the infrastructure. Such as where do they live, how are they indexed, and how are new ones submitted. This may seem surprising, but Ken has told me he's *very* busy, in part with other system management tasks for python.org (e.g., CNRI will be installing a firewall soon), in part with other non-python.org tasks. > Another particularly useful HOWTO would be one for PythonWin; > someday somebody should trawl through the PythonWin-SIG archives and > pull out examples, useful references... Yes... --Guido van Rossum (home page: http://www.python.org/~guido/) _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From gstein@microsoft.com Tue Jul 22 02:44:21 1997 From: gstein@microsoft.com (Greg Stein) Date: Mon, 21 Jul 1997 18:44:21 -0700 Subject: [META-SIG] Re: retiring the db-sig Message-ID: <41135C785691CF11B73B00805FD4D2D7032606D6@RED-17-MSG.dns.microsoft.com> Hmm. I must have missed Michael's original email. Maybe it just went to Guido... dunno. In either case, that would be great if you could "take over." I find I'm just not giving it the justice it needs/deserves and if I'm going to be the thread-sig guy, then I'd really be doing the db-sig a disservice. -g -----Original Message----- From: Guido van Rossum [SMTP:guido@CNRI.Reston.Va.US] Sent: Monday, July 21, 1997 6:56 AM To: Michael McLay Cc: meta-sig@python.org Subject: [META-SIG] Re: retiring the db-sig Michael McLay writes, on retiring the db-sig: > I'd like to keep it alive, so I'll take over as the sig champion. I > think it needs to stay open until a few more databases are compliant > with the db interface standard. (In particuular the mSQL interface > doesn't comply. I just started using it, so I might be able to work > on this some.) Also, since the sig web page is the primary hook for > getting information about the Python database interface standard it > can't just be abandoned. It would create some dead links. > > I really think we need to classify the SIGs based on activity level. > Some of the dormant SIGs should be labeled as such and moved to a > separate section at the bottom of the SIG page. That's a great idea -- perhaps a separate section of "past sigs" could be kept around as well, with their last known home page, archive etc. E.g. I imagine that the archives of the recently closed pythonwin-sig should still be accessible! --Guido van Rossum (home page: http://www.python.org/~guido/) _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From klm@python.org Tue Jul 22 15:41:04 1997 From: klm@python.org (Ken Manheimer) Date: Tue, 22 Jul 1997 10:41:04 -0400 (EDT) Subject: [META-SIG] Re: retiring the db-sig In-Reply-To: <41135C785691CF11B73B00805FD4D2D7032606D6@RED-17-MSG.dns.microsoft.com> Message-ID: On Mon, 21 Jul 1997, Greg Stein wrote: > Hmm. I must have missed Michael's original email. Maybe it just went to > Guido... dunno. > [...] Our ISP, uunet, had a serious name server failure yesterday for some of its clients, and our mail queue got pretty screwed up in the process. The upshot is that some messages sent to python.org mailing yesterday lists morning may not have made it out to some or even most of the recipients. (And some recipients, particularly cnri local ones, may have gotten 2 to 5 copies of the messages!) If you're unsure, you may want to try retransmitting a message you sent during that period. In any case, be sure to cite enough when responding to such a message to give context for those that may not have gotten the original. Ken Manheimer klm@cnri.reston.va.us 703 620-8990 x268 (orporation for National Research |nitiatives # If you appreciate Python, consider joining the PSA! # # . # _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From arw@dante.mh.lucent.com Wed Jul 23 12:10:37 1997 From: arw@dante.mh.lucent.com (Aaron Watters) Date: Wed, 23 Jul 1997 07:10:37 -0400 Subject: [META-SIG] whence db-sig? Message-ID: <199707231154.HAA21015@dante.mh.lucent.com> I modestly propose that the db-sig not disappear. I think there needs to be a focussed forum at least to answer questions, and perhaps to discuss future developments. Where else are such messages to go? They'll get lost in the Big List. I don't even care if it only gets a few messages a month -- the forum should be there. Actually, I'm not even sure that the pythonwin-sig should have vanished either. Maybe both should be reinvented on starship? -- Aaron Watters _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From guido@CNRI.Reston.Va.US Wed Jul 23 15:02:28 1997 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Wed, 23 Jul 1997 10:02:28 -0400 Subject: [META-SIG] whence db-sig? In-Reply-To: Your message of "Wed, 23 Jul 1997 07:10:37 EDT." <199707231154.HAA21015@dante.mh.lucent.com> References: <199707231154.HAA21015@dante.mh.lucent.com> Message-ID: <199707231402.KAA19552@eric.CNRI.Reston.Va.US> Aaron Watters writes: > I modestly propose that the db-sig not > disappear. Don't worry, Michale McLay has volunteered to be the new owner. I think that the db-sig's manifesto ought to be rewritten though to reflect the changed purpose. > I think there needs to be a focussed forum > at least to answer questions, and perhaps > to discuss future developments. Where > else are such messages to go? They'll get > lost in the Big List. I don't even care if > it only gets a few messages a month -- the > forum should be there. Actually, questions on the big list do get answered pretty consistently. > Actually, I'm not even sure that the pythonwin-sig > should have vanished either. The idea was to form a bunch of sub-newsgroups if there got to be too much win specific traffic. Also, a win specific faq would be a good idea. > Maybe both should be reinvented on starship? I won't oppose that... --Guido van Rossum (home page: http://www.python.org/~guido/) _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From MHammond@skippinet.com.au Thu Jul 24 00:03:14 1997 From: MHammond@skippinet.com.au (Mark Hammond) Date: Thu, 24 Jul 1997 09:03:14 +1000 Subject: [META-SIG] whence db-sig? Message-ID: <199707232318.JAA08357@minotaur.labyrinth.net.au> > Actually, I'm not even sure that the pythonwin-sig > should have vanished either. In many ways Im glad it has gone. But I _would_ like to see a Sig focussed on win32 extension developers - a small sig of technical windows programmers to bounce stuff off. It is this traffic that I miss from the SIG. It could cover all win32 stuff - Pythonwin, COM, etc, and would explicitely exclude "end-user" support of the Python code. I may propose this some time soon... Any comments in the meantime? > Maybe both should be reinvented on starship? Id rather see them kept on Python.org. I see starship as a good spot for experiments, etc. eg, my new binary set should go back to pyhton.org some time pretty soon... Mark. _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From davida@pobox.com Thu Jul 24 13:51:54 1997 From: davida@pobox.com (David Arnold) Date: Thu, 24 Jul 1997 22:51:54 +1000 Subject: [META-SIG] Proposal for new SIG: Thread SIG In-Reply-To: Your message of "Sun, 20 Jul 1997 10:33:17 -0400." <199707201433.KAA13536@eric.CNRI.Reston.Va.US> Message-ID: <199707241251.WAA26928@piglet.dstc.edu.au> -->"Guido" == Guido van Rossum writes: Guido> If there's no discussion based on this proposal, I take it Guido> that there's no need for a Thread-SIG -- so please comment! i think a thread SIG is an excellent idea. it's an area where python is currently fairly weak, especially in the combination of threads and a GUI toolkit. Guido> - There should be some kind of answer to the problems Guido> caused by Python's central interpreter lock agreed. Guido> - Some kind of threading that's suitable for multiprocessor Guido> machines??? please! ;-) Guido> The SIG deliverables will be determined by the SIG. They Guido> will include at least: all of these sound good. i'm not sure it needs to be said, but the GUI/threads problems needs to be resolved before threads are truely useful in the language also. -- David Arnold ,================================================= =================' +617 33654310 (voice) CRC for Distributed Systems Technology +617 33654311 (fax) University of Queensland davida@pobox.com (email) Australia (web) C++ compilers rarely optimize for the joy of programming - lwall _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From jim.fulton@digicool.com Thu Jul 24 14:25:02 1997 From: jim.fulton@digicool.com (Jim Fulton) Date: Thu, 24 Jul 1997 09:25:02 -0400 Subject: [META-SIG] Proposal for new SIG: Thread SIG References: <199707241251.WAA26928@piglet.dstc.edu.au> Message-ID: <33D757AE.1E55@digicool.com> David Arnold wrote: > > i'm not sure it needs to be said, but the GUI/threads problems needs > to be resolved before threads are truely useful in the language also. I don't agree with this. I'm not saying that one should not solve important problems, but statements like "xxx will not be truly useful unless it solves (domain specific) problem yyy" give me a bit of heartburn. We use Python for developing Web server applications and find the current thread support to be truly useful to us. Jim -- Jim Fulton Digital Creations jim@digicool.com 540.371.6909 ## Python is my favorite language ## ## http://www.python.org/ ## _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From davida@pobox.com Thu Jul 24 15:02:46 1997 From: davida@pobox.com (David Arnold) Date: Fri, 25 Jul 1997 00:02:46 +1000 Subject: [META-SIG] Proposal for new SIG: Thread SIG In-Reply-To: Your message of "Thu, 24 Jul 1997 09:25:02 -0400." <33D757AE.1E55@digicool.com> Message-ID: <199707241402.AAA27130@piglet.dstc.edu.au> -->"Jim" == Jim Fulton writes: Jim> David Arnold wrote: >> i'm not sure it needs to be said, but the GUI/threads problems >> needs to be resolved before threads are truely useful in the >> language also. Jim> I don't agree with this. I'm not saying that one should not Jim> solve important problems, but statements like "xxx will not be Jim> truly useful unless it solves (domain specific) problem yyy" Jim> give me a bit of heartburn. We use Python for developing Web Jim> server applications and find the current thread support to be Jim> truly useful to us. sorry, point taken. we use threads usefully every day too :-/ it just worries me when such a fundamental thing (IMO) as threads only half works. it'd be very unfortunate if we had to document stuff as MT-Safe or otherwise throughout python. especially with something so widely used as the GUI library. -- David Arnold ,================================================= =================' +617 33654310 (voice) CRC for Distributed Systems Technology +617 33654311 (fax) University of Queensland davida@pobox.com (email) Australia (web) C++ compilers rarely optimize for the joy of programming - lwall _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Fri Jul 25 16:26:46 1997 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 25 Jul 1997 11:26:46 -0400 Subject: [META-SIG] whence db-sig? References: <199707231154.HAA21015@dante.mh.lucent.com> <199707231402.KAA19552@eric.CNRI.Reston.Va.US> Message-ID: <199707251526.LAA02364@anthem.CNRI.Reston.Va.US> >>>>> "MM" == Michael McLay writes: MM> I'd like to keep it alive, so I'll take over as the sig MM> champion. I have made this change, both to the db-sig-owner@python.org alias and on the Web page. (Mike you should get this message at least 3 times! :-). I still feel that SIGs which have accomplished their mission ought to be shut down and different forums be found for some of the non-mission related activities of the lists (e.g. moving them to newsgroups, other links to old archives, etc.). For now... Guido> I think that the db-sig's manifesto ought to be rewritten Guido> though to reflect the changed purpose. ...this is probably fine. Mike, feel free to write up a new mission statement! -Barry _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Fri Jul 25 17:08:57 1997 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 25 Jul 1997 12:08:57 -0400 Subject: [META-SIG] ThreadSIG Message-ID: <199707251608.MAA02450@anthem.CNRI.Reston.Va.US> The infrastructure for the ThreadSIG is in place. I've slightly condensed Guido's draft mission statement into the SIG information that gets sent when you subscribe. To view it, send the word `info' in the body of a message to thread-sig-request@python.org. The Web infrastructure isn't up yet. Ken usually does this and I tried to run his scripts but had some problems. He's out today but we'll get that straightened out ASAP. Please don't announce the formation of the SIG yet. I need to coordinate a few things with Greg, and once that's done, he'll have the pleasure of announcing the SIG to the world. -Barry _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From klm@python.org Mon Jul 28 21:42:51 1997 From: klm@python.org (Ken Manheimer) Date: Mon, 28 Jul 1997 16:42:51 -0400 (EDT) Subject: [META-SIG] whence db-sig? In-Reply-To: <199707251526.LAA02364@anthem.CNRI.Reston.Va.US> Message-ID: On Fri, 25 Jul 1997, Barry A. Warsaw wrote: > [...] > I still feel that SIGs which have accomplished their mission ought to > be shut down and different forums be found for some of the non-mission > related activities of the lists (e.g. moving them to newsgroups, other > links to old archives, etc.). For now... I'm coming to agree (with whoever suggested it) that it would be a good idea to retain SIGs after they've satisfied their goals, if they're going to be useful for answering questions. Why dispose of the information in the SIG archives that accumulated when developing the subject at issue? Plus, sigs often have artifacts - eg pythonwin stuff - that need a place. Why not keep them around? The drawback, of course, is that extra sigs can obscure active ones from view, but i think that could be alleviated by just segregating the listing for the residual sigs to below the active sigs on the index page. I vote for keeping old ones around, when there's a reason for it. Ken Manheimer klm@cnri.reston.va.us 703 620-8990 x268 (orporation for National Research |nitiatives # If you appreciate Python, consider joining the PSA! # # . # _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From amk@magnet.com Mon Jul 28 22:37:50 1997 From: amk@magnet.com (Andrew Kuchling) Date: Mon, 28 Jul 1997 17:37:50 -0400 (EDT) Subject: [META-SIG] whence db-sig? In-Reply-To: (message from Ken Manheimer on Mon, 28 Jul 1997 16:42:51 -0400 (EDT)) Message-ID: <199707282137.RAA00242@lemur.magnet.com> Ken Manheimer wrote: >I'm coming to agree (with whoever suggested it) that it would be a good >idea to retain SIGs after they've satisfied their goals, if they're >going to be useful for answering questions. That's a big IF; what if no one's reading the SIG anymore? If a SIG becomes quiet, the active posters will probably stay subscribed, but no one new will join, and as the active posters change e-mail addresses (and forget to resubscribe to a list they haven't seen a message from in months), the readership will slowly drop. >subject at issue? Plus, sigs often have artifacts - eg pythonwin stuff >- that need a place. Why not keep them around? Then there should be a page under software for that stuff, or the maintainer should have a page on starship for it. It's not very nice to make people hunt around the SIG pages looking for software. ("Go write a locator, then". I know, I know... :( ) Andrew Kuchling amk@magnet.com http://people.magnet.com/%7Eamk/ _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From da@maigret.cog.brown.edu Mon Jul 28 23:12:17 1997 From: da@maigret.cog.brown.edu (David Ascher) Date: Mon, 28 Jul 1997 18:12:17 -0400 (EDT) Subject: [META-SIG] whence db-sig? In-Reply-To: <199707282137.RAA00242@lemur.magnet.com> Message-ID: > >I'm coming to agree (with whoever suggested it) that it would be a good > >idea to retain SIGs after they've satisfied their goals, if they're > >going to be useful for answering questions. > > That's a big IF; what if no one's reading the SIG anymore? If > a SIG becomes quiet, the active posters will probably stay subscribed, > but no one new will join, and as the active posters change e-mail > addresses (and forget to resubscribe to a list they haven't seen a > message from in months), the readership will slowly drop. But what's the cost? I've kept LISTSERV lists alive for a long while after issues died out, and apart from the spamming problem, there's no real cost (as long as the people running the list server don't mind). > >subject at issue? Plus, sigs often have artifacts - eg pythonwin stuff > >- that need a place. Why not keep them around? > > Then there should be a page under software for that stuff, or > the maintainer should have a page on starship for it. It's not very > nice to make people hunt around the SIG pages looking for software. > ("Go write a locator, then". I know, I know... :( ) The most important artifact of a list is the archive of messages, which I think we all agree should be kept in some way or other. But things like the DB API should belong on python.org, not starship. On the same topic -- what's so bad about the hypermail archive of the mailing lists that it's not available by default from each SIG page? I use it all the time, but I keep having to look for it on the main SIG page, as opposed to where I'd expect to find it (I know, I need to rewire a few neurons). _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From gstein@microsoft.com Tue Jul 29 00:55:22 1997 From: gstein@microsoft.com (Greg Stein) Date: Mon, 28 Jul 1997 16:55:22 -0700 Subject: [META-SIG] whence db-sig? Message-ID: <41135C785691CF11B73B00805FD4D2D703260761@RED-17-MSG.dns.microsoft.com> Moving questions to the main python list is better than leaving them on the sig. On the list, there is a broader audience, the PR aspect of the perception of more traffic/involvement, the list is archived/indexed/queryable through any number of sources (can't use DejaNews against db-sig!), etc. IMO, the sig is merely for use as high-volume thrash around of ideas. Doing that on python-list is non-productive for everybody (noise level for many readers, and you get yokels piping in with random comments :-)). Just because a list is cheap to maintain, doesn't mean it should be maintained. The presence of the list introduces a certain type of "noise" in the Python community. -g -----Original Message----- From: David Ascher [SMTP:da@maigret.cog.brown.edu] Sent: Monday, July 28, 1997 3:12 PM To: Andrew Kuchling Cc: meta-sig@python.org Subject: Re: [META-SIG] whence db-sig? > >I'm coming to agree (with whoever suggested it) that it would be a good > >idea to retain SIGs after they've satisfied their goals, if they're > >going to be useful for answering questions. > > That's a big IF; what if no one's reading the SIG anymore? If > a SIG becomes quiet, the active posters will probably stay subscribed, > but no one new will join, and as the active posters change e-mail > addresses (and forget to resubscribe to a list they haven't seen a > message from in months), the readership will slowly drop. But what's the cost? I've kept LISTSERV lists alive for a long while after issues died out, and apart from the spamming problem, there's no real cost (as long as the people running the list server don't mind). > >subject at issue? Plus, sigs often have artifacts - eg pythonwin stuff > >- that need a place. Why not keep them around? > > Then there should be a page under software for that stuff, or > the maintainer should have a page on starship for it. It's not very > nice to make people hunt around the SIG pages looking for software. > ("Go write a locator, then". I know, I know... :( ) The most important artifact of a list is the archive of messages, which I think we all agree should be kept in some way or other. But things like the DB API should belong on python.org, not starship. On the same topic -- what's so bad about the hypermail archive of the mailing lists that it's not available by default from each SIG page? I use it all the time, but I keep having to look for it on the main SIG page, as opposed to where I'd expect to find it (I know, I need to rewire a few neurons). _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From mclay@nist.gov Tue Jul 29 14:29:17 1997 From: mclay@nist.gov (Michael McLay) Date: Tue, 29 Jul 1997 09:29:17 -0400 Subject: [META-SIG] whence db-sig? In-Reply-To: <199707282137.RAA00242@lemur.magnet.com> References: <199707282137.RAA00242@lemur.magnet.com> Message-ID: <199707291329.JAA23867@fermi.eeel.nist.gov> Andrew Kuchling writes: > Ken Manheimer wrote: > >I'm coming to agree (with whoever suggested it) that it would be a good > >idea to retain SIGs after they've satisfied their goals, if they're > >going to be useful for answering questions. > > That's a big IF; what if no one's reading the SIG anymore? If > a SIG becomes quiet, the active posters will probably stay subscribed, > but no one new will join, and as the active posters change e-mail > addresses (and forget to resubscribe to a list they haven't seen a > message from in months), the readership will slowly drop. > > >subject at issue? Plus, sigs often have artifacts - eg pythonwin stuff > >- that need a place. Why not keep them around? > > Then there should be a page under software for that stuff, or > the maintainer should have a page on starship for it. It's not very > nice to make people hunt around the SIG pages looking for software. > ("Go write a locator, then". I know, I know... :( ) I think there's value in keeping even the sleepy SIGS around. They provide a signal to potential Python users that someone has had the idea that Python might work in a particular domain. For instance, the efactory SIG got started by me over a year ago. Contract funding didn't come through so the people in that SIG drifted away. Because of the recent contract awards I have reason to believe that the SIG is likely to become very active. The new traffic on the SIG would automatically find its way to old SIG members so they will get an automatic reminder of Python. I propose we have three catagories in the SIG page. (The less active SIGS could be on a separate web page if the clutter is really that objectionable.) Active SIGS: The top 10 SIGS as measured by activity or SIGS with over 30 messages in the last three months. Sleepy SIGS: SIGS that haven't completed their mission, but who's traffic is slower than the active SIGS. Retired SIGS: SIGS who's mission has been accomplished. They are kept around so that people will know that the work was done as a SIG and also so that if for some reason, such as maintence work, in the future more work is needed the SIG still be there. Let's not through anything away just because it is untouched for an extended period. Historians hate it when that happens. If you want to move it off to an obscure web page that's fine, but don't throw it in the trash. _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From klm@python.org Tue Jul 29 15:01:17 1997 From: klm@python.org (Ken Manheimer) Date: Tue, 29 Jul 1997 10:01:17 -0400 (EDT) Subject: [META-SIG] whence db-sig? In-Reply-To: <199707291329.JAA23867@fermi.eeel.nist.gov> Message-ID: On Tue, 29 Jul 1997, Michael McLay wrote: > I think there's value in keeping even the sleepy SIGS around. They > provide a signal to potential Python users that someone has had the > idea that Python might work in a particular domain. For instance, the > [...] > I propose we have three catagories in the SIG page. (The less active > SIGS could be on a separate web page if the clutter is really that > objectionable.) I don't see the benefit of making an additional, and fuzzy, distinction as being worth the extra work! I don't like this idea, and would like to keep the discussion concentrated on the issue of active vs retired, if possible! > Let's not through anything away just because it is untouched for an > extended period. Historians hate it when that happens. If you want > to move it off to an obscure web page that's fine, but don't throw it > in the trash. I agree. I would strongly advocate keeping around the old sigs (for the email archive and other artifacts), and consider the current issue to concern whether the mailing list distribution for a retired sig stays active, (and/) or an auto-response goes to posters telling them that the sig is no longer active. I'll explore this in response to greg's recent message... Ken _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From klm@python.org Tue Jul 29 15:27:46 1997 From: klm@python.org (Ken Manheimer) Date: Tue, 29 Jul 1997 10:27:46 -0400 (EDT) Subject: [META-SIG] whence db-sig? In-Reply-To: <41135C785691CF11B73B00805FD4D2D703260761@RED-17-MSG.dns.microsoft.com> Message-ID: On Mon, 28 Jul 1997, Greg Stein wrote: > Moving questions to the main python list is better than leaving them on > the sig. On the list, there is a broader audience, the PR aspect of the > perception of more traffic/involvement, the list is I am not sure, but i have a strong impression that answers about special topics are more forthcoming when questions are posed to a relevant sig than when they are posed to the newsgroup at large. This impression gets more solid when thinking about, eg, numerical math oriented questions posed to the matrix-sig. > perception of more traffic/involvement, the list is > archived/indexed/queryable through any number of sources (can't use > DejaNews against db-sig!), etc. Granted that dejanews won't hit it, but there are the pipermail archives for the sigs. You could see the segregation as a benefit. I'm not sure, here. > Just because a list is cheap to maintain, doesn't mean it should be > maintained. The presence of the list introduces a certain type of > "noise" in the Python community. I see clear benefit in retaining artifacts of retired sigs like the email archive and the web contents. I also see a clear benefit in clearly distinguishing retired sigs - segregating the entries for them from the list of active sigs, and clearly registering on the retired sig web pages that it is no longer active. Do we all agree on this? The question then, for me, is what we want to do with the sig members and email traffic. I can see a few reasonable dispositions: 1 Put it out to pasture! Close down the email list, with an auto- responder indicating that questions and comments should be sent to the newsgroup (or a newsgroup, if the python newsgroup splits). 2 Let the sig hang around and kibbitz. Clearly mark it as retired, but retain the email list and let the members unsubscribe themselves or not (and even let new members join), and field questions and residual maintenance of the sig business. (It also occurs to me that we could have an auto-responder but also keep the email distribution active, but i think that really amounts to (1) with some finagling.) I like 2. I could almost be convinced of 1 because keeping a retired sig's distribution active "muddies the waters" - diluting the concentration of information in the main newsgroup - but then i think that active sigs do just that, yet that's what active sigs are for. It *would* be bad if a retired sig appeared to be a useful channel for info but actually had no subscribers. To cover that, we could put auto responders in gear whenver there are less than, say, 10 subscribers. In fact, my ultimate proposal is to let the sig's manager decide whether they want the sig to continue. If they say no, and noone steps forward to take it over, then certainly it should be closed for correspondance. Ken _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From klm@python.org Tue Jul 29 15:40:09 1997 From: klm@python.org (Ken Manheimer) Date: Tue, 29 Jul 1997 10:40:09 -0400 (EDT) Subject: [META-SIG] whence db-sig? In-Reply-To: Message-ID: On Mon, 28 Jul 1997, David Ascher wrote: > [...] > On the same topic -- what's so bad about the hypermail archive of the > mailing lists that it's not available by default from each SIG page? I > use it all the time, but I keep having to look for it on the main SIG > page, as opposed to where I'd expect to find it (I know, I need to rewire > a few neurons). I should hook it up - but i'd like each sig to link to the archive collection for the particular sig, rather than the collection of all archives. Andrew, is there an address for that? If not, it would be sufficient to have a name tag for the section of the collection to which i could link. (Andrew, also note, i changed around the layout of the sigs page, for brevity, you may or may not want to track it on the sigs archive collection page...) Ken _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From amk@magnet.com Tue Jul 29 17:07:36 1997 From: amk@magnet.com (Andrew Kuchling) Date: Tue, 29 Jul 1997 12:07:36 -0400 (EDT) Subject: [META-SIG] whence db-sig? In-Reply-To: (message from Ken Manheimer on Tue, 29 Jul 1997 10:40:09 -0400 (EDT)) Message-ID: <199707291607.MAA22145@lemur.magnet.com> Ken Manheimer wrote: >I should hook it up - but i'd like each sig to link to the archive >collection for the particular sig, rather than the collection of >all archives. Andrew, is there an address for that? If not, it would No, though it could be easily added. Since we really should move the archive to python.org (or, failing that, starship), I should rework the arrangement of the SIG list. >(Andrew, also note, i changed around the layout of the sigs page, for >brevity, you may or may not want to track it on the sigs archive >collection page...) OK; I'll take it and add a table row after each SIG that looks like  1997q3, 1997q2, ..., so the archives will be listed in the last two columns. How's that? Should it be 1997q3 (35), 1997q2 (48), ...? BTW, 'van Rossum' should be sorted under R, not V, right? Also BTW, is there going to be a CD-ROM of python.org produced for SPAM6? Andrew Kuchling amk@magnet.com http://people.magnet.com/%7Eamk/ _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From ldl@ldl.HealthPartners.COM Tue Jul 29 20:35:53 1997 From: ldl@ldl.HealthPartners.COM (LD Landis) Date: Tue, 29 Jul 1997 14:35:53 -0500 (CDT) Subject: [META-SIG] whence db-sig? In-Reply-To: from "David Ascher" at Jul 28, 97 06:12:17 pm Message-ID: <199707291935.OAA23428@ldl.HealthPartners.COM> Hi, I almost didn't comment... BUT... I concur on keeping old lists around. What I've done on some that I administer is that I have a "The list is dead, long live the list" message that I send out once a month (at the beginning). For those messages that bounce, I go in and delete thosei people (figuring that they'll re-subscribe if needed... and I'm talking "no such user" type of bouncing here). Sometimes, people do actually decide to unsubscribe, but most appreciate knowing that the list is still there, and need not do anything to leave it as it is... For example.... let's say that db-sig was "dead", and then some new way cool post-relational "mysql" comes along... The db-sig people get "pinged" every month, so they have the location of the db-sig fairly fresh in their mind and can start right away... and continue to build their history. Just a thought. David Ascher wrote: > > > >I'm coming to agree (with whoever suggested it) that it would be a good > > >idea to retain SIGs after they've satisfied their goals, if they're > > >going to be useful for answering questions. > > > > That's a big IF; what if no one's reading the SIG anymore? If > > a SIG becomes quiet, the active posters will probably stay subscribed, > > but no one new will join, and as the active posters change e-mail > > addresses (and forget to resubscribe to a list they haven't seen a > > message from in months), the readership will slowly drop. > > But what's the cost? I've kept LISTSERV lists alive for a long while > after issues died out, and apart from the spamming problem, there's no > real cost (as long as the people running the list server don't mind). > > > >subject at issue? Plus, sigs often have artifacts - eg pythonwin stuff > > >- that need a place. Why not keep them around? > > > > Then there should be a page under software for that stuff, or > > the maintainer should have a page on starship for it. It's not very > > nice to make people hunt around the SIG pages looking for software. > > ("Go write a locator, then". I know, I know... :( ) > > The most important artifact of a list is the archive of messages, which I > think we all agree should be kept in some way or other. But things like > the DB API should belong on python.org, not starship. > > On the same topic -- what's so bad about the hypermail archive of the > mailing lists that it's not available by default from each SIG page? I > use it all the time, but I keep having to look for it on the main SIG > page, as opposed to where I'd expect to find it (I know, I need to rewire > a few neurons). > > > _______________ > META-SIG - SIG on Python.Org SIGs and Mailing Lists > > send messages to: meta-sig@python.org > administrivia to: meta-sig-request@python.org > _______________ > -- -- Cheers, --ldl ----------------------------------------------------------------------------- LD Landis ldl@HealthPartners.Com N0YRQ Voice 612/883-5511 Fax 612/883-6363 HealthPartners, 8100 34th Avenue So, PO Box 1309, Minneapolis, MN 55440-1309 Shape your life not from your memories, but from your hopes. (Borrowed) Still programming for the day-job... haven't yet gotten that Microsoft PR job ----------------------------------------------------------------------------- _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From furnish@acl.lanl.gov Wed Jul 30 16:03:42 1997 From: furnish@acl.lanl.gov (Geoffrey Furnish) Date: Wed, 30 Jul 1997 09:03:42 -0600 (MDT) Subject: [META-SIG] RE: [MATRIX-SIG] RFP: PLOT-SIG In-Reply-To: References: Message-ID: <199707301503.JAA02104@steam.acl.lanl.gov> I would like to lend my support to David's proposal. David Ascher writes: > After somewhat extensive discussion in the MATRIX-SIG, I am officially > submitting a proposal for the creation of a new sig. Here is the one line > comment and more extended docstring. I am volunteering as sigmeister. > > Please comment. > > This announcement is cc'ed to MATRIX-SIG, but I request that all followups > be directed at the META-SIG. Please check your cc: line before sending > comments. > > --david ascher > > -------------------------------- > > # PLOT-SIG: Development of Data Plotting Solutions for Python > > """ > The purpose of this list is to develop, coddle together, adopt or > otherwise make available Python tools for plotting of scientific and > business plots of data. > > Plotting needs vary greatly depending on each user's requirements. > Some users wish to see a better API between Python and existing > plotting libraries or programs. Others would rather see a new > framework which maximally leverages the OOP and dynamic strengths of > Python, at the cost of reinventing a few wheels. Both strategies will > be entertained by the SIG, with individual members contributing to > projects they wish to see furthered. > > Principles guiding the development of all software will include: > > * Ease of use. > * Integration with other Python packages (NumPy, PIL, etc.). > * Quality of the software. > * Quality of the output. > > One possible goal for the API project is to develop a package- > independent API for plots, which would produce reasonably > similar results regardless of the plotting package used as a backend > (PLPlot, Gist/Yorick, Gnuplot, etc.), in the same spirit as the > interface defined by the DB-SIG. Package-specific extensions could > naturally be provided as well. > > The goals for the new framework need to be further specified by the > SIG, but include: > > * Complete Python Control. > * Extensibility/Customizability. > * High quality rendering both on screen and paper. > * Portability (at least UNIX/X11 and Win32, MacOS if feasible). > * Stealing good ideas others have had. > * Interactivity > > The SIG is open, and membership is expected to include folks who wish to > contribute to the development efforts, folks who have lots of expertise > they wish to share, and novice users who wish to share their lists of > requirements, questions about the available software, etc. > """ > > > > _______________ > MATRIX-SIG - SIG on Matrix Math for Python > > send messages to: matrix-sig@python.org > administrivia to: matrix-sig-request@python.org > _______________ _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From klm@python.org Wed Jul 30 16:18:27 1997 From: klm@python.org (Ken Manheimer) Date: Wed, 30 Jul 1997 11:18:27 -0400 (EDT) Subject: [META-SIG] RE: [MATRIX-SIG] RFP: PLOT-SIG In-Reply-To: <199707301503.JAA02104@steam.acl.lanl.gov> Message-ID: (PLOT-SIG: Development of Solutions for World Domination (Or At Least New Jersey)) :-) :-) (This should not be taken as an objection to the proposed name!) Ken _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From gstein@microsoft.com Thu Jul 31 10:00:56 1997 From: gstein@microsoft.com (Greg Stein) Date: Thu, 31 Jul 1997 02:00:56 -0700 Subject: [META-SIG] whence db-sig? Message-ID: <41135C785691CF11B73B00805FD4D2D7033BA9E4@RED-17-MSG.dns.microsoft.com> > Also BTW, is there going to be a CD-ROM of python.org produced for > SPAM6? possibly... :-) -----Original Message----- From: Andrew Kuchling [SMTP:amk@magnet.com] Sent: Tuesday, July 29, 1997 9:08 AM To: meta-sig@python.org Subject: Re: [META-SIG] whence db-sig? Ken Manheimer wrote: >I should hook it up - but i'd like each sig to link to the archive >collection for the particular sig, rather than the collection of >all archives. Andrew, is there an address for that? If not, it would No, though it could be easily added. Since we really should move the archive to python.org (or, failing that, starship), I should rework the arrangement of the SIG list. >(Andrew, also note, i changed around the layout of the sigs page, for >brevity, you may or may not want to track it on the sigs archive >collection page...) OK; I'll take it and add a table row after each SIG that looks like  1997q3, 1997q2, ..., so the archives will be listed in the last two columns. How's that? Should it be 1997q3 (35), 1997q2 (48), ...? BTW, 'van Rossum' should be sorted under R, not V, right? Also BTW, is there going to be a CD-ROM of python.org produced for SPAM6? Andrew Kuchling amk@magnet.com http://people.magnet.com/%7Eamk/ _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From gstein@microsoft.com Thu Jul 31 10:03:14 1997 From: gstein@microsoft.com (Greg Stein) Date: Thu, 31 Jul 1997 02:03:14 -0700 Subject: [META-SIG] whence db-sig? Message-ID: <41135C785691CF11B73B00805FD4D2D7033BA9E5@RED-17-MSG.dns.microsoft.com> Note that the Mailman package will send out notices once a month to remind you about your Mailman password. It also serves as a nice wake-up call. -g -----Original Message----- From: LD Landis [SMTP:ldl@ldl.HealthPartners.COM] Sent: Tuesday, July 29, 1997 12:36 PM To: da@maigret.cog.brown.edu Cc: amk@magnet.com; meta-sig@python.org Subject: Re: [META-SIG] whence db-sig? Hi, I almost didn't comment... BUT... I concur on keeping old lists around. What I've done on some that I administer is that I have a "The list is dead, long live the list" message that I send out once a month (at the beginning). For those messages that bounce, I go in and delete thosei people (figuring that they'll re-subscribe if needed... and I'm talking "no such user" type of bouncing here). Sometimes, people do actually decide to unsubscribe, but most appreciate knowing that the list is still there, and need not do anything to leave it as it is... For example.... let's say that db-sig was "dead", and then some new way cool post-relational "mysql" comes along... The db-sig people get "pinged" every month, so they have the location of the db-sig fairly fresh in their mind and can start right away... and continue to build their history. Just a thought. David Ascher wrote: > > > >I'm coming to agree (with whoever suggested it) that it would be a good > > >idea to retain SIGs after they've satisfied their goals, if they're > > >going to be useful for answering questions. > > > > That's a big IF; what if no one's reading the SIG anymore? If > > a SIG becomes quiet, the active posters will probably stay subscribed, > > but no one new will join, and as the active posters change e-mail > > addresses (and forget to resubscribe to a list they haven't seen a > > message from in months), the readership will slowly drop. > > But what's the cost? I've kept LISTSERV lists alive for a long while > after issues died out, and apart from the spamming problem, there's no > real cost (as long as the people running the list server don't mind). > > > >subject at issue? Plus, sigs often have artifacts - eg pythonwin stuff > > >- that need a place. Why not keep them around? > > > > Then there should be a page under software for that stuff, or > > the maintainer should have a page on starship for it. It's not very > > nice to make people hunt around the SIG pages looking for software. > > ("Go write a locator, then". I know, I know... :( ) > > The most important artifact of a list is the archive of messages, which I > think we all agree should be kept in some way or other. But things like > the DB API should belong on python.org, not starship. > > On the same topic -- what's so bad about the hypermail archive of the > mailing lists that it's not available by default from each SIG page? I > use it all the time, but I keep having to look for it on the main SIG > page, as opposed to where I'd expect to find it (I know, I need to rewire > a few neurons). > > > _______________ > META-SIG - SIG on Python.Org SIGs and Mailing Lists > > send messages to: meta-sig@python.org > administrivia to: meta-sig-request@python.org > _______________ > -- -- Cheers, --ldl ------------------------------------------------------------------------ ----- LD Landis ldl@HealthPartners.Com N0YRQ Voice 612/883-5511 Fax 612/883-6363 HealthPartners, 8100 34th Avenue So, PO Box 1309, Minneapolis, MN 55440-1309 Shape your life not from your memories, but from your hopes. (Borrowed) Still programming for the day-job... haven't yet gotten that Microsoft PR job ------------------------------------------------------------------------ ----- _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From klm@CNRI.Reston.Va.US Wed Jul 9 16:00:34 1997 From: klm@CNRI.Reston.Va.US (Ken Manheimer) Date: Wed, 9 Jul 1997 11:00:34 -0400 (EDT) Subject: [META-SIG] Python.org bounces overnight Message-ID: <199707091500.LAA21635@glyph.cnri.reston.va.us> I accidentally disrupted majordomo in the process of some finagling yesterday, so any messages posted to the sigs during that time were bounced to the sig owners, rather than being delivered to the lists. For those of you that are list owners, you can resubmit the bounced messages by copying the relevant parts of the headers (eg, the original "From:", "To:", "Message-id:", etc), plus a "Resent-To:" with the list address as the target, and include the original body. This will reroute the message back to the list, for distribution. Sorry about the disruption - i'm trying to make it easy to prevent some notorious spam sources from using our sig and psa-members lists, and accidentally applied one of my experimental changes to the production code... Ken Manheimer klm@cnri.reston.va.us 703 620-8990 x268 (orporation for National Research |nitiatives 1895 Preston White Drive, Suite 100 Reston, VA 22091 _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From klm@CNRI.Reston.Va.US Wed Jul 9 18:10:44 1997 From: klm@CNRI.Reston.Va.US (Ken Manheimer) Date: Wed, 9 Jul 1997 13:10:44 -0400 (EDT) Subject: [META-SIG] PSA majordomo lists - excluding certain posts Message-ID: <199707091710.NAA22394@glyph.cnri.reston.va.us> Another note to PSA SIG list managers. I've set up something to filter out spam hot spots from all PSA SIG and members traffic. Approved messages are exempt from the exclusion, so mail list bounces that should be accepted can be resent with an appropriate approved line. To start with, i've put something in to exclude everything from hotmail.com, excepting the few hotmail.com addresses i found in the sig subscription lists. Please let me know if you have any problems with or suggestions about this! SOme details about the implementation. There's a new option, "exclude_post", which specifies files containing addresses to be excluded. (The list of files is modelled exactly after the existing "restrict_post" option, and in fact uses its mechanism to get to the file.) The exclusion file consists of lines that start with an exclusion address, optionally followed by exceptions to that exclusion. Senders addresses that _contain_ the exclusion address, and that do *not* contain any of the exception addresses, are bounced. For remote SIG administrators - this file is not remotely settable. You will need to contact us here to get an addition or modification to one of the exclusions. Send email to eg majordomo-owner@python.org, or webmaster@python.org, or whatever. For local people, the file is named "forbidden", located in the lists directory. It is included *by default* for every mailing list. You can override that by adding an explicit entry for "exclude_post" in your config file. Ken Manheimer klm@cnri.reston.va.us 703 620-8990 x268 (orporation for National Research |nitiatives # Thanks for working with the PSA! # # . # _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From JOE_ELLSWORTH@HP-Cupertino-om5.om.hp.com Tue Jul 15 16:33:55 1997 From: JOE_ELLSWORTH@HP-Cupertino-om5.om.hp.com (JOE_ELLSWORTH@HP-Cupertino-om5.om.hp.com) Date: Tue, 15 Jul 97 09:33:55 -0600 Subject: [META-SIG] Python a new opportunity. Message-ID: Python a new opportunity. I have been watching Python for some time and it is apparent that Python could benefit from a large group of new programmers. As such I have would like to propose an idea that may help provide such a group. I have began looking at an area of applications that are ideal candidates for execution on the new class of Windows/CE palmtops such as the HP/LX300. We have developed several applications for Laptops that would be better deployed based on this new class of devices but have no available development environments that would facilitate moving these applications to the device and for the most part any applications built for the CE are not portable or directly inter operable to the desktop My experience in the vertical application market space leads me to believe that this group of devices will represent one of the fastest growing application deployment segments during the next several years. I believe Python and a TK look alike could fill this niche better than currently available development tools and would benefit from doing so by attracting a new group of previously inaccessible pragmatic application developers. Of course marketing the availability of the tool would be as important as making it available in the first place. Some non trivial applications using the tool would also help. The core MFC libraries are available for CE and as such a porting effort should not be terribly difficult except for memory foot print and access to a few proprietary features of the new device. Features Needed to compete in this space: Compatibility with Windows CE. A base memory foot print less than 500K, ideally less than 300K. multiple copies of interpreter should be able to share base memory. Built in extension libraries to support new object store. This should be reflected Built in GUI extension libraries to support Ability to fetch files from a local PC or a remote network source using the PC serial connection. Built in extension library to support core GUI competency of the CE class of devices which would be a primitive grid widget and a sideways note tab container widget. Extension library to support NT / UNIX inter operability. Extension library to support inter operation with the TAPI/IP programming interface. Optional Enhancements that would improve Market acceptance: Compatibility at source level with Newton. A Python UNIX/NT server that can interact with client A browser with better capability than IIE Light. (EG: Scripting). A Javascript to Python Translator or Emulator. An automated bridge to a ODBC data source residing on a the partner PC. This could be done with a small python server residing on the PC which accesses the ODBC data source and proxies requests on behalf of the palmtop device. I understand that this would represent a significant effort but the rewards as per the number of new developers may be well worth the investment. See: http://www.microsoft.com/windowsce/developer/ http://www.hp.com/handheld/handheld_devices/index.html http://www.casio-usa.com/html/products/handheldpc.html http://www.newton-inc.com/product_info/product_info.html If anybody develops such a tool I would be interested in alpha testing it. My primary motivation is in having a more productive tool set available for application deployment while encouraging success of GNU style free software contribute to standards rather than having only proprietary vendor supplied tools control this new segment. Any feedback or different viewpoints would be greatly appreciated. Thanks, Joe E. _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From rushing@nightmare.com Wed Jul 16 05:32:28 1997 From: rushing@nightmare.com (Samual M. Rushing) Date: Tue, 15 Jul 1997 23:32:28 -0500 Subject: [META-SIG] Re: Python a new opportunity. In-Reply-To: (JOE_ELLSWORTH@HP-Cupertino-om5.om.hp.com) Message-ID: <199707160432.XAA20304@ziggurat.nightmare.com> -----BEGIN PGP SIGNED MESSAGE----- >>>>> "je" == JOE ELLSWORTH writes: je> I believe Python and a TK look alike could fill this je> niche better than currently available development tools and je> would benefit from doing so by attracting a new group of je> previously inaccessible pragmatic application developers. Of je> course marketing the availability of the tool would be as je> important as making it available in the first place. Some non je> trivial applications using the tool would also help. je> The core MFC libraries are available for CE and as such a je> porting effort should not be terribly difficult except for je> memory foot print and access to a few proprietary features of je> the new device. I don't know about MFC on the CE platform, but elsewhere MFC is nearly a megabyte. [imagine what you could do with a megabyte of python byte code!] je> Features Needed to compete in this space: Compatibility je> with Windows CE. je> A base memory foot print less than 500K, ideally less je> than 300K. multiple copies of interpreter should be able to je> share base memory. One thing you might want to explore is the fledgling 'class library' that's included with the 'calldll' module: Although it's very incomplete (I don't get to work on it much), it suffices for building windows applications. It uses calldll to speak directly to the windows API: (i.e., it calls functions in user32.dll, gdi32.dll, kernel32.dll, etc...) Even with the message loop written entirely in Python, the performance is good: I've written applications that do scrolled scaled graphics... Most of this is in about, hmmm... 50-60k of pyc files. I think a Tk-like library (in other words, a well-designed, object-oriented library where widgets can be composed) could be built on this. In fact, that was my goal when I started working on it. [see http://www.nightmare.com/software.html for a description of the calldll] - -Sam -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBM8xOpGys8OGgJmJxAQHi7QQApRXBuBabCb74h5yMFCmvCcNVTuX6E8TV 2usRLwsOSH19X3ONKjfNMhK69n/kQ1DnlrHTTFTHQleZICx11+pBgyS6hl+34DI7 XKzU+zelMcE4ySQB+1q93oJzvAAHwbSu6FzXkqPYAIXEjV6NzQztqcg8na9zDxN1 tnIPBqSoSf0= =IXVm -----END PGP SIGNATURE----- _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From JOE_ELLSWORTH@HP-Cupertino-om5.om.hp.com Thu Jul 17 07:04:22 1997 From: JOE_ELLSWORTH@HP-Cupertino-om5.om.hp.com (JOE_ELLSWORTH@HP-Cupertino-om5.om.hp.com) Date: Thu, 17 Jul 97 00:04:22 -0600 Subject: [META-SIG] Re: Python a new opportunity. In-Reply-To: <199707160432.XAA20304@ziggurat.nightmare.com> Message-ID: Hi Sam, Thanks for taking the time to respond. I would be interested in your analysis of the opportunity and my opinion of it's potential benefit to the Python / Freeware community. If such a project is pursued what is your opinion about how to maximise it's visibility to the new group of candidate programmers? I don't believe these people would normally access Python.com and time would be of a essence so a body of Python projects could be created prior to another solution arriving on the seen and confusing the issue. Thanks, Joe E. *** My Response *** This represents a short term opportunity for Python which must be brought to fruition soon if it is to actually deliver a new body of engineers to the Python community before another alternative grabs the mind share. Currently this appears to be virgin territory but a commercial venture of some sort is bound to recognise the gap and move to fill it soon. I think other vendors will require a bit of time to exit their "Windows/NT" unlimited Disk and RAM mentality and switch back to designs that will approximate what Python does so well now. A lot of vendors will not even try and will take the approach that these systems will scale up so quickly that in a year or so they will be able to deploy their Win/95 applications in the same form factor. I cringe at this type of approach and hope Python can step in and provide a workable solution quickly which will encourage a move to maximising the effective use of the resources we have. If we have to wait until I have bandwidth to work on such a project it may be the year 2000 and Microsoft will have recognised the gap and deployed a different solution. Your point about the functionality that can be packed in to Python byte code is one of the primary reasons I was thinking Python would make a great solution in this space. I am predominately a vertical application developer so I am thrilled by the idea of an environment that would let me squeeze full size application logic into a congested Memory space. This would allow me to pursue developing a class of applications that I would currently consider out of scale for such a device. It is unfortunate that we can't get Python added to the device's ROM so there would be no space overhead from the interpreter. From the limited Python I have written I get the impression that Python byte code "per logical feature point" seems to be smaller than equivalent Java byte code but I am not sure why this occurs. I am not an expert in this area but from what I have read so far it appears that a sub set of MFC is actually embedded in the machines ROM and they appear to be working some other magic to minimise the size of programs generated using a custom version of MFC and a custom compiler. An associate of mine thinks that you must include a reference to this special library in order to access the device's special features such as the Object Store, TAPI interface and custom GUI widgets but I have not validated this. Good luck, Joe Ellsworth. P.S. My primary motivation is to see a language I think warrants a chance at wider exposure take advantage of a momentary laps of the industry giants gain a larger mind share. Python's wider spread adoption could encourage industry giants to improve the quality of their product offering to match. At the current time Python for all it's strength does not seem to hold sufficient mind share to be used as such a lever and it is playing in such a congested market segment that it will have a difficult time growing to realise it's full potential. ______________________________ Reply Separator _________________________________ Subject: Re: Python a new opportunity. Author: Non-HP-rushing (rushing@nightmare.com) at HP-ColSprings,shargw5 Date: 7/15/97 10:32 PM -----BEGIN PGP SIGNED MESSAGE----- >>>>> "je" == JOE ELLSWORTH writes: je> I believe Python and a TK look alike could fill this je> niche better than currently available development tools and je> would benefit from doing so by attracting a new group of je> previously inaccessible pragmatic application developers. Of je> course marketing the availability of the tool would be as je> important as making it available in the first place. Some non je> trivial applications using the tool would also help. je> The core MFC libraries are available for CE and as such a je> porting effort should not be terribly difficult except for je> memory foot print and access to a few proprietary features of je> the new device. I don't know about MFC on the CE platform, but elsewhere MFC is nearly a megabyte. [imagine what you could do with a megabyte of python byte code!] je> Features Needed to compete in this space: Compatibility je> with Windows CE. je> A base memory foot print less than 500K, ideally less je> than 300K. multiple copies of interpreter should be able to je> share base memory. One thing you might want to explore is the fledgling 'class library' that's included with the 'calldll' module: Although it's very incomplete (I don't get to work on it much), it suffices for building windows applications. It uses calldll to speak directly to the windows API: (i.e., it calls functions in user32.dll, gdi32.dll, kernel32.dll, etc...) Even with the message loop written entirely in Python, the performance is good: I've written applications that do scrolled scaled graphics... Most of this is in about, hmmm... 50-60k of pyc files. I think a Tk-like library (in other words, a well-designed, object-oriented library where widgets can be composed) could be built on this. In fact, that was my goal when I started working on it. [see http://www.nightmare.com/software.html for a description of the calldll] - -Sam -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBM8xOpGys8OGgJmJxAQHi7QQApRXBuBabCb74h5yMFCmvCcNVTuX6E8TV 2usRLwsOSH19X3ONKjfNMhK69n/kQ1DnlrHTTFTHQleZICx11+pBgyS6hl+34DI7 XKzU+zelMcE4ySQB+1q93oJzvAAHwbSu6FzXkqPYAIXEjV6NzQztqcg8na9zDxN1 tnIPBqSoSf0= =IXVm -----END PGP SIGNATURE----- _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From gstein@microsoft.com Thu Jul 17 21:32:49 1997 From: gstein@microsoft.com (Greg Stein) Date: Thu, 17 Jul 1997 13:32:49 -0700 Subject: [META-SIG] closing db-sig Message-ID: <41135C785691CF11B73B00805FD4D2D703260689@RED-17-MSG.dns.microsoft.com> At this point, I believe the db-sig has completed its business and I'd like to close it down. Most of the traffic over the past year has been question-related rather than mission-related. These kinds of posts can easily be moved to the main Python newsgroup. If somebody would like to refine the mission statement and take over "ownership" of the db-sig, then they should speak up and begin that process. Otherwise, I'll send mail to Barry to have the sig closed down sometime in the next couple of weeks. Thx -g _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From guido@CNRI.Reston.Va.US Sun Jul 20 15:32:00 1997 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Sun, 20 Jul 1997 10:32:00 -0400 Subject: [META-SIG] Proposal for new SIG: Thead SIG Message-ID: <199707201432.KAA13530@eric.CNRI.Reston.Va.US> In response to thread discussion on c.l.p, there were some voices to create a Special Interest Group on Threading. I volunteered to write a draft SIG manifesto for it, and Greg Stein has volunteered to become the SIG champion. (Now that he's dropping the db-sig; has anybody volunteered to keep it alive? If not, I propose to shut it down, keeping the archives of course). If there's no discussion based on this proposal, I take it that there's no need for a Thread-SIG -- so please comment! --Guido ======================================================================== Subject: Thread-SIG -- Mission Statement (DRAFT) The Thread SIG strives to improve the status of threading in Python. It has specific goals and deliverables. The SIG will be shut down (after discussion) when these have been reached and produced, respectively. The (lofty) SIG goals are: - The Python threading interface should be sufficiently powerful that its users can concentrate on using threads rather than writing threading tools. - There should be sufficient documentation for the Python threading interface. - Python should support threading well on every platform where the native OS has decent threading support; if possible, this support should be automatic (e.g. automatically detected by the configure script rather than specified as a command line option to it). In particular, good thread support should exist on Windows 95 and NT, and on all Unix systems for which a vendor-supported pthread implementation exists. - There should be some kind of answer to the problems caused by Python's central interpreter lock -- if not permanent removal of the lock (which seems problematic without significant performance loss), then at least some other way that makes it possible to run multiple threads comfortably on a single-processor machine -- perhaps BEGIN/END thread macros everwhere, perhaps a compile time switch to enable something like Greg Stein's "free threading" patches, perhaps something else. - Some kind of threading that's suitable for multiprocessor machines??? The SIG deliverables will be determined by the SIG. They will include at least: - A "Threading in Python" document that describes HOWTOs, gotchas, available packages/patches, etc. This would address the continual "how do I use threads in Python?" questions. - A design for higher level threading functionality to be added to standard Python (perhaps an extended thread module, perhaps some additional Python modules, perhaps a new "pthread" module more closely modelled after Posix threads, perhaps all three). - A documented implementation of the above design. - Patches to standard Python that reduce the problems with the interpreter lock, perhaps modelled after Greg Stein's patches. While the thread-sig exists, other thread related discussions are welcome, however these should not be confused with the SIG's goals. ======================================================================== --Guido van Rossum (home page: http://www.python.org/~guido/) _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From guido@CNRI.Reston.Va.US Sun Jul 20 15:33:17 1997 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Sun, 20 Jul 1997 10:33:17 -0400 Subject: [META-SIG] Proposal for new SIG: Thread SIG Message-ID: <199707201433.KAA13536@eric.CNRI.Reston.Va.US> [Repost with typo fixed in subject -- please ignore the previous one!] In response to thread discussion on c.l.p, there were some voices to create a Special Interest Group on Threading. I volunteered to write a draft SIG manifesto for it, and Greg Stein has volunteered to become the SIG champion. (Now that he's dropping the db-sig; has anybody volunteered to keep it alive? If not, I propose to shut it down, keeping the archives of course). If there's no discussion based on this proposal, I take it that there's no need for a Thread-SIG -- so please comment! --Guido ======================================================================== Subject: Thread-SIG -- Mission Statement (DRAFT) The Thread SIG strives to improve the status of threading in Python. It has specific goals and deliverables. The SIG will be shut down (after discussion) when these have been reached and produced, respectively. The (lofty) SIG goals are: - The Python threading interface should be sufficiently powerful that its users can concentrate on using threads rather than writing threading tools. - There should be sufficient documentation for the Python threading interface. - Python should support threading well on every platform where the native OS has decent threading support; if possible, this support should be automatic (e.g. automatically detected by the configure script rather than specified as a command line option to it). In particular, good thread support should exist on Windows 95 and NT, and on all Unix systems for which a vendor-supported pthread implementation exists. - There should be some kind of answer to the problems caused by Python's central interpreter lock -- if not permanent removal of the lock (which seems problematic without significant performance loss), then at least some other way that makes it possible to run multiple threads comfortably on a single-processor machine -- perhaps BEGIN/END thread macros everwhere, perhaps a compile time switch to enable something like Greg Stein's "free threading" patches, perhaps something else. - Some kind of threading that's suitable for multiprocessor machines??? The SIG deliverables will be determined by the SIG. They will include at least: - A "Threading in Python" document that describes HOWTOs, gotchas, available packages/patches, etc. This would address the continual "how do I use threads in Python?" questions. - A design for higher level threading functionality to be added to standard Python (perhaps an extended thread module, perhaps some additional Python modules, perhaps a new "pthread" module more closely modelled after Posix threads, perhaps all three). - A documented implementation of the above design. - Patches to standard Python that reduce the problems with the interpreter lock, perhaps modelled after Greg Stein's patches. While the thread-sig exists, other thread related discussions are welcome, however these should not be confused with the SIG's goals. ======================================================================== --Guido van Rossum (home page: http://www.python.org/~guido/) _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From MHammond@skippinet.com.au Mon Jul 21 00:24:45 1997 From: MHammond@skippinet.com.au (Mark Hammond) Date: Mon, 21 Jul 1997 09:24:45 +1000 Subject: [META-SIG] Proposal for new SIG: Thead SIG Message-ID: <199707202340.JAA19735@minotaur.labyrinth.net.au> I have seen enough interest and general questions on the main list that such a SIG is _definately_ called for - we just need to hope there are enough people to keep it alive. But I think there are enough people who care already, so lets go for it... Mark. _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From mclay@nist.gov Mon Jul 21 09:26:14 1997 From: mclay@nist.gov (Michael McLay) Date: Mon, 21 Jul 1997 04:26:14 -0400 Subject: [META-SIG] Proposal for new SIG: Thead SIG In-Reply-To: <199707201432.KAA13530@eric.CNRI.Reston.Va.US> References: <199707201432.KAA13530@eric.CNRI.Reston.Va.US> Message-ID: <199707210826.EAA28691@fermi.eeel.nist.gov> Guido van Rossum writes: > In response to thread discussion on c.l.p, there were some voices to > create a Special Interest Group on Threading. I volunteered to write > a draft SIG manifesto for it, and Greg Stein has volunteered to become > the SIG champion. (Now that he's dropping the db-sig; has anybody > volunteered to keep it alive? If not, I propose to shut it down, > keeping the archives of course). I'd like to keep it alive, so I'll take over as the sig champion. I think it needs to stay open until a few more databases are compliant with the db interface standard. (In particuular the mSQL interface doesn't comply. I just started using it, so I might be able to work on this some.) Also, since the sig web page is the primary hook for getting information about the Python database interface standard it can't just be abandoned. It would create some dead links. I really think we need to classify the SIGs based on activity level. Some of the dormant SIGs should be labeled as such and moved to a separate section at the bottom of the SIG page. _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From guido@CNRI.Reston.Va.US Mon Jul 21 14:56:30 1997 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Mon, 21 Jul 1997 09:56:30 -0400 Subject: [META-SIG] Re: retiring the db-sig In-Reply-To: Your message of "Mon, 21 Jul 1997 04:26:14 EDT." <199707210826.EAA28691@fermi.eeel.nist.gov> References: <199707201432.KAA13530@eric.CNRI.Reston.Va.US> <199707210826.EAA28691@fermi.eeel.nist.gov> Message-ID: <199707211356.JAA14296@eric.CNRI.Reston.Va.US> Michael McLay writes, on retiring the db-sig: > I'd like to keep it alive, so I'll take over as the sig champion. I > think it needs to stay open until a few more databases are compliant > with the db interface standard. (In particuular the mSQL interface > doesn't comply. I just started using it, so I might be able to work > on this some.) Also, since the sig web page is the primary hook for > getting information about the Python database interface standard it > can't just be abandoned. It would create some dead links. > > I really think we need to classify the SIGs based on activity level. > Some of the dormant SIGs should be labeled as such and moved to a > separate section at the bottom of the SIG page. That's a great idea -- perhaps a separate section of "past sigs" could be kept around as well, with their last known home page, archive etc. E.g. I imagine that the archives of the recently closed pythonwin-sig should still be accessible! --Guido van Rossum (home page: http://www.python.org/~guido/) _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From blizzard@appliedtheory.com Mon Jul 21 15:49:44 1997 From: blizzard@appliedtheory.com (Christopher Blizzard) Date: Mon, 21 Jul 1997 10:49:44 -0400 Subject: [META-SIG] Proposal for new SIG: Thread SIG In-Reply-To: Your message of "Sun, 20 Jul 1997 10:33:17 EDT." <199707201433.KAA13536@eric.CNRI.Reston.Va.US> Message-ID: <199707211449.KAA19736@odin.appliedtheory.com> In message <199707201433.KAA13536@eric.CNRI.Reston.Va.US>, Guido van Rossum wri tes: : :======================================================================== :Subject: Thread-SIG -- Mission Statement (DRAFT) : :The Thread SIG strives to improve the status of threading in Python. :It has specific goals and deliverables. The SIG will be shut down :(after discussion) when these have been reached and produced, :respectively. : :The (lofty) SIG goals are: : : - The Python threading interface should be sufficiently powerful that : its users can concentrate on using threads rather than writing : threading tools. : : - There should be sufficient documentation for the Python threading : interface. : : - Python should support threading well on every platform where the : native OS has decent threading support; if possible, this support : should be automatic (e.g. automatically detected by the configure : script rather than specified as a command line option to it). In : particular, good thread support should exist on Windows 95 and NT, : and on all Unix systems for which a vendor-supported pthread : implementation exists. : : - There should be some kind of answer to the problems caused by : Python's central interpreter lock -- if not permanent removal of the : lock (which seems problematic without significant performance loss), : then at least some other way that makes it possible to run multiple : threads comfortably on a single-processor machine -- perhaps BEGIN/END : thread macros everwhere, perhaps a compile time switch to enable : something like Greg Stein's "free threading" patches, perhaps : something else. : : - Some kind of threading that's suitable for multiprocessor : machines??? : :The SIG deliverables will be determined by the SIG. They will include :at least: : : - A "Threading in Python" document that describes HOWTOs, gotchas, : available packages/patches, etc. This would address the continual : "how do I use threads in Python?" questions. : : - A design for higher level threading functionality to be added to : standard Python (perhaps an extended thread module, perhaps some : additional Python modules, perhaps a new "pthread" module more closely : modelled after Posix threads, perhaps all three). : Are you talking about a generic Python threading API that is the same for all underlying thread implimentations? Overall this proposal looks like it's right on the money. I hope this SIG takes shape. :) --Chris : - A documented implementation of the above design. : : - Patches to standard Python that reduce the problems with the : interpreter lock, perhaps modelled after Greg Stein's patches. : :While the thread-sig exists, other thread related discussions are :welcome, however these should not be confused with the SIG's goals. :======================================================================== : : ------------ Christopher Blizzard AppliedTheory Communications, Inc. http://odin.appliedtheory.com/ blizzard@appliedtheory.com ------------ _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From furnish@acl.lanl.gov Mon Jul 21 15:58:38 1997 From: furnish@acl.lanl.gov (Geoffrey Furnish) Date: Mon, 21 Jul 1997 08:58:38 -0600 (MDT) Subject: [META-SIG] Proposal for new SIG: Thread SIG In-Reply-To: <199707201433.KAA13536@eric.CNRI.Reston.Va.US> References: <199707201433.KAA13536@eric.CNRI.Reston.Va.US> Message-ID: <199707211458.IAA03864@steam.acl.lanl.gov> Guido van Rossum writes: > If there's no discussion based on this proposal, I take it that > there's no need for a Thread-SIG -- so please comment! I support the proposal for a Thread-SIG. -- Geoffrey Furnish email: furnish@lanl.gov LANL CIC-19 POOMA/RadTran phone: 505-665-4529 fax: 505-665-7880 "Here are your ball-peen hammers. Now go malleate some heads!" -Jim Morel _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From andrus@chopper.us.dg.com Mon Jul 21 16:26:43 1997 From: andrus@chopper.us.dg.com (Ross Andrus) Date: Mon, 21 Jul 1997 11:26:43 -0400 (EDT) Subject: [META-SIG] Re: Thread-SIG Message-ID: <199707211526.LAA08652@astra.us.dg.com> GvR > If there's no discussion based on this proposal, I take it that > there's no need for a Thread-SIG -- so please comment! > > --Guido I think it's needed, and so I support it's creation. I don't know what I, personally, could contribute, but I'd be happy to try... ross -- Ross Andrus Data General Corporation andrus@chopper.us.dg.com 4400 Computer Drive (508) 898-5156 (voice) Westboro, MA 01580 (508) 898-5097 (fax) MS F135 (SSD) 232-5156 (DG internal) _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From amk@magnet.com Mon Jul 21 16:36:42 1997 From: amk@magnet.com (Andrew Kuchling) Date: Mon, 21 Jul 1997 11:36:42 -0400 (EDT) Subject: [META-SIG] Re: retiring the db-sig In-Reply-To: <199707211356.JAA14296@eric.CNRI.Reston.Va.US> from "Guido van Rossum" at Jul 21, 97 09:56:30 am Message-ID: <199707211536.LAA18383@lemur.magnet.com> > Michael McLay writes, on retiring the db-sig: > > on this some.) Also, since the sig web page is the primary hook for > > getting information about the Python database interface standard it > > can't just be abandoned. It would create some dead links. We really shouldn't have important information only accessible from SIG links. How about following the Linux example and creating a list of HOWTOs? They're small documents that cover one specific topic quite completely; some of the Linux ones cover things like configuring PPP, using Chinese/Japanese character sets. Python ones could cover the database interface, threads, or whatever. (The docstring in cgi.py could almost become a CGI HOWTO.) GvR wrote: > E.g. I imagine that the archives of the recently closed pythonwin-sig > should still be accessible! Who suggested taking them down? I'm certainly not going to remove them just because the SIG closed; people may come across them while doing a Web search and find out about Python that way. Andrew Kuchling amk@magnet.com http://people.magnet.com/%7Eamk/ _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From guido@CNRI.Reston.Va.US Mon Jul 21 16:43:38 1997 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Mon, 21 Jul 1997 11:43:38 -0400 Subject: [META-SIG] Re: retiring the db-sig In-Reply-To: Your message of "Mon, 21 Jul 1997 11:36:42 EDT." <199707211536.LAA18383@lemur.magnet.com> References: <199707211536.LAA18383@lemur.magnet.com> Message-ID: <199707211543.LAA14751@eric.CNRI.Reston.Va.US> > > Michael McLay writes, on retiring the db-sig: > > > on this some.) Also, since the sig web page is the primary hook for > > > getting information about the Python database interface standard it > > > can't just be abandoned. It would create some dead links. > > We really shouldn't have important information only accessible > from SIG links. How about following the Linux example and creating a > list of HOWTOs? They're small documents that cover one specific topic > quite completely; some of the Linux ones cover things like configuring > PPP, using Chinese/Japanese character sets. Python ones could cover > the database interface, threads, or whatever. (The docstring in > cgi.py could almost become a CGI HOWTO.) Agreed. The problem is, we desperately need volunteers to set this up. Ken Manheimer doesn't have time! > GvR wrote: > > E.g. I imagine that the archives of the recently closed pythonwin-sig > > should still be accessible! > > Who suggested taking them down? I'm certainly not going to > remove them just because the SIG closed; people may come across them > while doing a Web search and find out about Python that way. Absolutely -- but good SIGs have links to their own archives too and those might become inaccessible. It is also a bit of a trick I think to keep the raw majordomo archives around when the list is abandoned. --Guido van Rossum (home page: http://www.python.org/~guido/) _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From gstein@microsoft.com Thu Jul 17 21:32:49 1997 From: gstein@microsoft.com (Greg Stein) Date: Thu, 17 Jul 1997 13:32:49 -0700 Subject: [META-SIG] closing db-sig Message-ID: <41135C785691CF11B73B00805FD4D2D703260689@RED-17-MSG.dns.microsoft.com> At this point, I believe the db-sig has completed its business and I'd like to close it down. Most of the traffic over the past year has been question-related rather than mission-related. These kinds of posts can easily be moved to the main Python newsgroup. If somebody would like to refine the mission statement and take over "ownership" of the db-sig, then they should speak up and begin that process. Otherwise, I'll send mail to Barry to have the sig closed down sometime in the next couple of weeks. Thx -g _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From amk@magnet.com Mon Jul 21 17:03:00 1997 From: amk@magnet.com (Andrew Kuchling) Date: Mon, 21 Jul 1997 12:03:00 -0400 (EDT) Subject: [META-SIG] Re: retiring the db-sig In-Reply-To: <199707211543.LAA14751@eric.CNRI.Reston.Va.US> from "Guido van Rossum" at Jul 21, 97 11:43:38 am Message-ID: <199707211603.MAA19460@lemur.magnet.com> > [My furgling about HOWTOs] GvR wrote: > Agreed. The problem is, we desperately need volunteers to set this > up. Ken Manheimer doesn't have time! To actually write the documents, you mean? Ken certainly wouldn't be expected to do that... Perhaps after 1.5 ships we can work on this; for the moment it's not a vital priority. Another particularly useful HOWTO would be one for PythonWin; someday somebody should trawl through the PythonWin-SIG archives and pull out examples, useful references... Andrew Kuchling amk@magnet.com http://people.magnet.com/%7Eamk/ _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From guido@CNRI.Reston.Va.US Tue Jul 22 00:12:37 1997 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Mon, 21 Jul 1997 19:12:37 -0400 Subject: [META-SIG] Re: retiring the db-sig In-Reply-To: Your message of "Mon, 21 Jul 1997 12:03:00 EDT." <199707211603.MAA19460@lemur.magnet.com> References: <199707211603.MAA19460@lemur.magnet.com> Message-ID: <199707212312.TAA16940@eric.CNRI.Reston.Va.US> > > [My furgling about HOWTOs] > GvR wrote: > > Agreed. The problem is, we desperately need volunteers to set this > > up. Ken Manheimer doesn't have time! > > To actually write the documents, you mean? Ken certainly > wouldn't be expected to do that... Perhaps after 1.5 ships we can > work on this; for the moment it's not a vital priority. No -- I meant that Ken doesn't have the time to create the infrastructure. Such as where do they live, how are they indexed, and how are new ones submitted. This may seem surprising, but Ken has told me he's *very* busy, in part with other system management tasks for python.org (e.g., CNRI will be installing a firewall soon), in part with other non-python.org tasks. > Another particularly useful HOWTO would be one for PythonWin; > someday somebody should trawl through the PythonWin-SIG archives and > pull out examples, useful references... Yes... --Guido van Rossum (home page: http://www.python.org/~guido/) _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From gstein@microsoft.com Tue Jul 22 02:44:21 1997 From: gstein@microsoft.com (Greg Stein) Date: Mon, 21 Jul 1997 18:44:21 -0700 Subject: [META-SIG] Re: retiring the db-sig Message-ID: <41135C785691CF11B73B00805FD4D2D7032606D6@RED-17-MSG.dns.microsoft.com> Hmm. I must have missed Michael's original email. Maybe it just went to Guido... dunno. In either case, that would be great if you could "take over." I find I'm just not giving it the justice it needs/deserves and if I'm going to be the thread-sig guy, then I'd really be doing the db-sig a disservice. -g -----Original Message----- From: Guido van Rossum [SMTP:guido@CNRI.Reston.Va.US] Sent: Monday, July 21, 1997 6:56 AM To: Michael McLay Cc: meta-sig@python.org Subject: [META-SIG] Re: retiring the db-sig Michael McLay writes, on retiring the db-sig: > I'd like to keep it alive, so I'll take over as the sig champion. I > think it needs to stay open until a few more databases are compliant > with the db interface standard. (In particuular the mSQL interface > doesn't comply. I just started using it, so I might be able to work > on this some.) Also, since the sig web page is the primary hook for > getting information about the Python database interface standard it > can't just be abandoned. It would create some dead links. > > I really think we need to classify the SIGs based on activity level. > Some of the dormant SIGs should be labeled as such and moved to a > separate section at the bottom of the SIG page. That's a great idea -- perhaps a separate section of "past sigs" could be kept around as well, with their last known home page, archive etc. E.g. I imagine that the archives of the recently closed pythonwin-sig should still be accessible! --Guido van Rossum (home page: http://www.python.org/~guido/) _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From klm@python.org Tue Jul 22 15:41:04 1997 From: klm@python.org (Ken Manheimer) Date: Tue, 22 Jul 1997 10:41:04 -0400 (EDT) Subject: [META-SIG] Re: retiring the db-sig In-Reply-To: <41135C785691CF11B73B00805FD4D2D7032606D6@RED-17-MSG.dns.microsoft.com> Message-ID: On Mon, 21 Jul 1997, Greg Stein wrote: > Hmm. I must have missed Michael's original email. Maybe it just went to > Guido... dunno. > [...] Our ISP, uunet, had a serious name server failure yesterday for some of its clients, and our mail queue got pretty screwed up in the process. The upshot is that some messages sent to python.org mailing yesterday lists morning may not have made it out to some or even most of the recipients. (And some recipients, particularly cnri local ones, may have gotten 2 to 5 copies of the messages!) If you're unsure, you may want to try retransmitting a message you sent during that period. In any case, be sure to cite enough when responding to such a message to give context for those that may not have gotten the original. Ken Manheimer klm@cnri.reston.va.us 703 620-8990 x268 (orporation for National Research |nitiatives # If you appreciate Python, consider joining the PSA! # # . # _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From arw@dante.mh.lucent.com Wed Jul 23 12:10:37 1997 From: arw@dante.mh.lucent.com (Aaron Watters) Date: Wed, 23 Jul 1997 07:10:37 -0400 Subject: [META-SIG] whence db-sig? Message-ID: <199707231154.HAA21015@dante.mh.lucent.com> I modestly propose that the db-sig not disappear. I think there needs to be a focussed forum at least to answer questions, and perhaps to discuss future developments. Where else are such messages to go? They'll get lost in the Big List. I don't even care if it only gets a few messages a month -- the forum should be there. Actually, I'm not even sure that the pythonwin-sig should have vanished either. Maybe both should be reinvented on starship? -- Aaron Watters _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From guido@CNRI.Reston.Va.US Wed Jul 23 15:02:28 1997 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Wed, 23 Jul 1997 10:02:28 -0400 Subject: [META-SIG] whence db-sig? In-Reply-To: Your message of "Wed, 23 Jul 1997 07:10:37 EDT." <199707231154.HAA21015@dante.mh.lucent.com> References: <199707231154.HAA21015@dante.mh.lucent.com> Message-ID: <199707231402.KAA19552@eric.CNRI.Reston.Va.US> Aaron Watters writes: > I modestly propose that the db-sig not > disappear. Don't worry, Michale McLay has volunteered to be the new owner. I think that the db-sig's manifesto ought to be rewritten though to reflect the changed purpose. > I think there needs to be a focussed forum > at least to answer questions, and perhaps > to discuss future developments. Where > else are such messages to go? They'll get > lost in the Big List. I don't even care if > it only gets a few messages a month -- the > forum should be there. Actually, questions on the big list do get answered pretty consistently. > Actually, I'm not even sure that the pythonwin-sig > should have vanished either. The idea was to form a bunch of sub-newsgroups if there got to be too much win specific traffic. Also, a win specific faq would be a good idea. > Maybe both should be reinvented on starship? I won't oppose that... --Guido van Rossum (home page: http://www.python.org/~guido/) _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From MHammond@skippinet.com.au Thu Jul 24 00:03:14 1997 From: MHammond@skippinet.com.au (Mark Hammond) Date: Thu, 24 Jul 1997 09:03:14 +1000 Subject: [META-SIG] whence db-sig? Message-ID: <199707232318.JAA08357@minotaur.labyrinth.net.au> > Actually, I'm not even sure that the pythonwin-sig > should have vanished either. In many ways Im glad it has gone. But I _would_ like to see a Sig focussed on win32 extension developers - a small sig of technical windows programmers to bounce stuff off. It is this traffic that I miss from the SIG. It could cover all win32 stuff - Pythonwin, COM, etc, and would explicitely exclude "end-user" support of the Python code. I may propose this some time soon... Any comments in the meantime? > Maybe both should be reinvented on starship? Id rather see them kept on Python.org. I see starship as a good spot for experiments, etc. eg, my new binary set should go back to pyhton.org some time pretty soon... Mark. _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From davida@pobox.com Thu Jul 24 13:51:54 1997 From: davida@pobox.com (David Arnold) Date: Thu, 24 Jul 1997 22:51:54 +1000 Subject: [META-SIG] Proposal for new SIG: Thread SIG In-Reply-To: Your message of "Sun, 20 Jul 1997 10:33:17 -0400." <199707201433.KAA13536@eric.CNRI.Reston.Va.US> Message-ID: <199707241251.WAA26928@piglet.dstc.edu.au> -->"Guido" == Guido van Rossum writes: Guido> If there's no discussion based on this proposal, I take it Guido> that there's no need for a Thread-SIG -- so please comment! i think a thread SIG is an excellent idea. it's an area where python is currently fairly weak, especially in the combination of threads and a GUI toolkit. Guido> - There should be some kind of answer to the problems Guido> caused by Python's central interpreter lock agreed. Guido> - Some kind of threading that's suitable for multiprocessor Guido> machines??? please! ;-) Guido> The SIG deliverables will be determined by the SIG. They Guido> will include at least: all of these sound good. i'm not sure it needs to be said, but the GUI/threads problems needs to be resolved before threads are truely useful in the language also. -- David Arnold ,================================================= =================' +617 33654310 (voice) CRC for Distributed Systems Technology +617 33654311 (fax) University of Queensland davida@pobox.com (email) Australia (web) C++ compilers rarely optimize for the joy of programming - lwall _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From jim.fulton@digicool.com Thu Jul 24 14:25:02 1997 From: jim.fulton@digicool.com (Jim Fulton) Date: Thu, 24 Jul 1997 09:25:02 -0400 Subject: [META-SIG] Proposal for new SIG: Thread SIG References: <199707241251.WAA26928@piglet.dstc.edu.au> Message-ID: <33D757AE.1E55@digicool.com> David Arnold wrote: > > i'm not sure it needs to be said, but the GUI/threads problems needs > to be resolved before threads are truely useful in the language also. I don't agree with this. I'm not saying that one should not solve important problems, but statements like "xxx will not be truly useful unless it solves (domain specific) problem yyy" give me a bit of heartburn. We use Python for developing Web server applications and find the current thread support to be truly useful to us. Jim -- Jim Fulton Digital Creations jim@digicool.com 540.371.6909 ## Python is my favorite language ## ## http://www.python.org/ ## _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From davida@pobox.com Thu Jul 24 15:02:46 1997 From: davida@pobox.com (David Arnold) Date: Fri, 25 Jul 1997 00:02:46 +1000 Subject: [META-SIG] Proposal for new SIG: Thread SIG In-Reply-To: Your message of "Thu, 24 Jul 1997 09:25:02 -0400." <33D757AE.1E55@digicool.com> Message-ID: <199707241402.AAA27130@piglet.dstc.edu.au> -->"Jim" == Jim Fulton writes: Jim> David Arnold wrote: >> i'm not sure it needs to be said, but the GUI/threads problems >> needs to be resolved before threads are truely useful in the >> language also. Jim> I don't agree with this. I'm not saying that one should not Jim> solve important problems, but statements like "xxx will not be Jim> truly useful unless it solves (domain specific) problem yyy" Jim> give me a bit of heartburn. We use Python for developing Web Jim> server applications and find the current thread support to be Jim> truly useful to us. sorry, point taken. we use threads usefully every day too :-/ it just worries me when such a fundamental thing (IMO) as threads only half works. it'd be very unfortunate if we had to document stuff as MT-Safe or otherwise throughout python. especially with something so widely used as the GUI library. -- David Arnold ,================================================= =================' +617 33654310 (voice) CRC for Distributed Systems Technology +617 33654311 (fax) University of Queensland davida@pobox.com (email) Australia (web) C++ compilers rarely optimize for the joy of programming - lwall _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Fri Jul 25 16:26:46 1997 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 25 Jul 1997 11:26:46 -0400 Subject: [META-SIG] whence db-sig? References: <199707231154.HAA21015@dante.mh.lucent.com> <199707231402.KAA19552@eric.CNRI.Reston.Va.US> Message-ID: <199707251526.LAA02364@anthem.CNRI.Reston.Va.US> >>>>> "MM" == Michael McLay writes: MM> I'd like to keep it alive, so I'll take over as the sig MM> champion. I have made this change, both to the db-sig-owner@python.org alias and on the Web page. (Mike you should get this message at least 3 times! :-). I still feel that SIGs which have accomplished their mission ought to be shut down and different forums be found for some of the non-mission related activities of the lists (e.g. moving them to newsgroups, other links to old archives, etc.). For now... Guido> I think that the db-sig's manifesto ought to be rewritten Guido> though to reflect the changed purpose. ...this is probably fine. Mike, feel free to write up a new mission statement! -Barry _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) Fri Jul 25 17:08:57 1997 From: bwarsaw@CNRI.Reston.Va.US (Barry A. Warsaw) (Barry A. Warsaw) Date: Fri, 25 Jul 1997 12:08:57 -0400 Subject: [META-SIG] ThreadSIG Message-ID: <199707251608.MAA02450@anthem.CNRI.Reston.Va.US> The infrastructure for the ThreadSIG is in place. I've slightly condensed Guido's draft mission statement into the SIG information that gets sent when you subscribe. To view it, send the word `info' in the body of a message to thread-sig-request@python.org. The Web infrastructure isn't up yet. Ken usually does this and I tried to run his scripts but had some problems. He's out today but we'll get that straightened out ASAP. Please don't announce the formation of the SIG yet. I need to coordinate a few things with Greg, and once that's done, he'll have the pleasure of announcing the SIG to the world. -Barry _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From klm@python.org Mon Jul 28 21:42:51 1997 From: klm@python.org (Ken Manheimer) Date: Mon, 28 Jul 1997 16:42:51 -0400 (EDT) Subject: [META-SIG] whence db-sig? In-Reply-To: <199707251526.LAA02364@anthem.CNRI.Reston.Va.US> Message-ID: On Fri, 25 Jul 1997, Barry A. Warsaw wrote: > [...] > I still feel that SIGs which have accomplished their mission ought to > be shut down and different forums be found for some of the non-mission > related activities of the lists (e.g. moving them to newsgroups, other > links to old archives, etc.). For now... I'm coming to agree (with whoever suggested it) that it would be a good idea to retain SIGs after they've satisfied their goals, if they're going to be useful for answering questions. Why dispose of the information in the SIG archives that accumulated when developing the subject at issue? Plus, sigs often have artifacts - eg pythonwin stuff - that need a place. Why not keep them around? The drawback, of course, is that extra sigs can obscure active ones from view, but i think that could be alleviated by just segregating the listing for the residual sigs to below the active sigs on the index page. I vote for keeping old ones around, when there's a reason for it. Ken Manheimer klm@cnri.reston.va.us 703 620-8990 x268 (orporation for National Research |nitiatives # If you appreciate Python, consider joining the PSA! # # . # _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From amk@magnet.com Mon Jul 28 22:37:50 1997 From: amk@magnet.com (Andrew Kuchling) Date: Mon, 28 Jul 1997 17:37:50 -0400 (EDT) Subject: [META-SIG] whence db-sig? In-Reply-To: (message from Ken Manheimer on Mon, 28 Jul 1997 16:42:51 -0400 (EDT)) Message-ID: <199707282137.RAA00242@lemur.magnet.com> Ken Manheimer wrote: >I'm coming to agree (with whoever suggested it) that it would be a good >idea to retain SIGs after they've satisfied their goals, if they're >going to be useful for answering questions. That's a big IF; what if no one's reading the SIG anymore? If a SIG becomes quiet, the active posters will probably stay subscribed, but no one new will join, and as the active posters change e-mail addresses (and forget to resubscribe to a list they haven't seen a message from in months), the readership will slowly drop. >subject at issue? Plus, sigs often have artifacts - eg pythonwin stuff >- that need a place. Why not keep them around? Then there should be a page under software for that stuff, or the maintainer should have a page on starship for it. It's not very nice to make people hunt around the SIG pages looking for software. ("Go write a locator, then". I know, I know... :( ) Andrew Kuchling amk@magnet.com http://people.magnet.com/%7Eamk/ _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From da@maigret.cog.brown.edu Mon Jul 28 23:12:17 1997 From: da@maigret.cog.brown.edu (David Ascher) Date: Mon, 28 Jul 1997 18:12:17 -0400 (EDT) Subject: [META-SIG] whence db-sig? In-Reply-To: <199707282137.RAA00242@lemur.magnet.com> Message-ID: > >I'm coming to agree (with whoever suggested it) that it would be a good > >idea to retain SIGs after they've satisfied their goals, if they're > >going to be useful for answering questions. > > That's a big IF; what if no one's reading the SIG anymore? If > a SIG becomes quiet, the active posters will probably stay subscribed, > but no one new will join, and as the active posters change e-mail > addresses (and forget to resubscribe to a list they haven't seen a > message from in months), the readership will slowly drop. But what's the cost? I've kept LISTSERV lists alive for a long while after issues died out, and apart from the spamming problem, there's no real cost (as long as the people running the list server don't mind). > >subject at issue? Plus, sigs often have artifacts - eg pythonwin stuff > >- that need a place. Why not keep them around? > > Then there should be a page under software for that stuff, or > the maintainer should have a page on starship for it. It's not very > nice to make people hunt around the SIG pages looking for software. > ("Go write a locator, then". I know, I know... :( ) The most important artifact of a list is the archive of messages, which I think we all agree should be kept in some way or other. But things like the DB API should belong on python.org, not starship. On the same topic -- what's so bad about the hypermail archive of the mailing lists that it's not available by default from each SIG page? I use it all the time, but I keep having to look for it on the main SIG page, as opposed to where I'd expect to find it (I know, I need to rewire a few neurons). _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From gstein@microsoft.com Tue Jul 29 00:55:22 1997 From: gstein@microsoft.com (Greg Stein) Date: Mon, 28 Jul 1997 16:55:22 -0700 Subject: [META-SIG] whence db-sig? Message-ID: <41135C785691CF11B73B00805FD4D2D703260761@RED-17-MSG.dns.microsoft.com> Moving questions to the main python list is better than leaving them on the sig. On the list, there is a broader audience, the PR aspect of the perception of more traffic/involvement, the list is archived/indexed/queryable through any number of sources (can't use DejaNews against db-sig!), etc. IMO, the sig is merely for use as high-volume thrash around of ideas. Doing that on python-list is non-productive for everybody (noise level for many readers, and you get yokels piping in with random comments :-)). Just because a list is cheap to maintain, doesn't mean it should be maintained. The presence of the list introduces a certain type of "noise" in the Python community. -g -----Original Message----- From: David Ascher [SMTP:da@maigret.cog.brown.edu] Sent: Monday, July 28, 1997 3:12 PM To: Andrew Kuchling Cc: meta-sig@python.org Subject: Re: [META-SIG] whence db-sig? > >I'm coming to agree (with whoever suggested it) that it would be a good > >idea to retain SIGs after they've satisfied their goals, if they're > >going to be useful for answering questions. > > That's a big IF; what if no one's reading the SIG anymore? If > a SIG becomes quiet, the active posters will probably stay subscribed, > but no one new will join, and as the active posters change e-mail > addresses (and forget to resubscribe to a list they haven't seen a > message from in months), the readership will slowly drop. But what's the cost? I've kept LISTSERV lists alive for a long while after issues died out, and apart from the spamming problem, there's no real cost (as long as the people running the list server don't mind). > >subject at issue? Plus, sigs often have artifacts - eg pythonwin stuff > >- that need a place. Why not keep them around? > > Then there should be a page under software for that stuff, or > the maintainer should have a page on starship for it. It's not very > nice to make people hunt around the SIG pages looking for software. > ("Go write a locator, then". I know, I know... :( ) The most important artifact of a list is the archive of messages, which I think we all agree should be kept in some way or other. But things like the DB API should belong on python.org, not starship. On the same topic -- what's so bad about the hypermail archive of the mailing lists that it's not available by default from each SIG page? I use it all the time, but I keep having to look for it on the main SIG page, as opposed to where I'd expect to find it (I know, I need to rewire a few neurons). _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From mclay@nist.gov Tue Jul 29 14:29:17 1997 From: mclay@nist.gov (Michael McLay) Date: Tue, 29 Jul 1997 09:29:17 -0400 Subject: [META-SIG] whence db-sig? In-Reply-To: <199707282137.RAA00242@lemur.magnet.com> References: <199707282137.RAA00242@lemur.magnet.com> Message-ID: <199707291329.JAA23867@fermi.eeel.nist.gov> Andrew Kuchling writes: > Ken Manheimer wrote: > >I'm coming to agree (with whoever suggested it) that it would be a good > >idea to retain SIGs after they've satisfied their goals, if they're > >going to be useful for answering questions. > > That's a big IF; what if no one's reading the SIG anymore? If > a SIG becomes quiet, the active posters will probably stay subscribed, > but no one new will join, and as the active posters change e-mail > addresses (and forget to resubscribe to a list they haven't seen a > message from in months), the readership will slowly drop. > > >subject at issue? Plus, sigs often have artifacts - eg pythonwin stuff > >- that need a place. Why not keep them around? > > Then there should be a page under software for that stuff, or > the maintainer should have a page on starship for it. It's not very > nice to make people hunt around the SIG pages looking for software. > ("Go write a locator, then". I know, I know... :( ) I think there's value in keeping even the sleepy SIGS around. They provide a signal to potential Python users that someone has had the idea that Python might work in a particular domain. For instance, the efactory SIG got started by me over a year ago. Contract funding didn't come through so the people in that SIG drifted away. Because of the recent contract awards I have reason to believe that the SIG is likely to become very active. The new traffic on the SIG would automatically find its way to old SIG members so they will get an automatic reminder of Python. I propose we have three catagories in the SIG page. (The less active SIGS could be on a separate web page if the clutter is really that objectionable.) Active SIGS: The top 10 SIGS as measured by activity or SIGS with over 30 messages in the last three months. Sleepy SIGS: SIGS that haven't completed their mission, but who's traffic is slower than the active SIGS. Retired SIGS: SIGS who's mission has been accomplished. They are kept around so that people will know that the work was done as a SIG and also so that if for some reason, such as maintence work, in the future more work is needed the SIG still be there. Let's not through anything away just because it is untouched for an extended period. Historians hate it when that happens. If you want to move it off to an obscure web page that's fine, but don't throw it in the trash. _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From klm@python.org Tue Jul 29 15:01:17 1997 From: klm@python.org (Ken Manheimer) Date: Tue, 29 Jul 1997 10:01:17 -0400 (EDT) Subject: [META-SIG] whence db-sig? In-Reply-To: <199707291329.JAA23867@fermi.eeel.nist.gov> Message-ID: On Tue, 29 Jul 1997, Michael McLay wrote: > I think there's value in keeping even the sleepy SIGS around. They > provide a signal to potential Python users that someone has had the > idea that Python might work in a particular domain. For instance, the > [...] > I propose we have three catagories in the SIG page. (The less active > SIGS could be on a separate web page if the clutter is really that > objectionable.) I don't see the benefit of making an additional, and fuzzy, distinction as being worth the extra work! I don't like this idea, and would like to keep the discussion concentrated on the issue of active vs retired, if possible! > Let's not through anything away just because it is untouched for an > extended period. Historians hate it when that happens. If you want > to move it off to an obscure web page that's fine, but don't throw it > in the trash. I agree. I would strongly advocate keeping around the old sigs (for the email archive and other artifacts), and consider the current issue to concern whether the mailing list distribution for a retired sig stays active, (and/) or an auto-response goes to posters telling them that the sig is no longer active. I'll explore this in response to greg's recent message... Ken _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From klm@python.org Tue Jul 29 15:27:46 1997 From: klm@python.org (Ken Manheimer) Date: Tue, 29 Jul 1997 10:27:46 -0400 (EDT) Subject: [META-SIG] whence db-sig? In-Reply-To: <41135C785691CF11B73B00805FD4D2D703260761@RED-17-MSG.dns.microsoft.com> Message-ID: On Mon, 28 Jul 1997, Greg Stein wrote: > Moving questions to the main python list is better than leaving them on > the sig. On the list, there is a broader audience, the PR aspect of the > perception of more traffic/involvement, the list is I am not sure, but i have a strong impression that answers about special topics are more forthcoming when questions are posed to a relevant sig than when they are posed to the newsgroup at large. This impression gets more solid when thinking about, eg, numerical math oriented questions posed to the matrix-sig. > perception of more traffic/involvement, the list is > archived/indexed/queryable through any number of sources (can't use > DejaNews against db-sig!), etc. Granted that dejanews won't hit it, but there are the pipermail archives for the sigs. You could see the segregation as a benefit. I'm not sure, here. > Just because a list is cheap to maintain, doesn't mean it should be > maintained. The presence of the list introduces a certain type of > "noise" in the Python community. I see clear benefit in retaining artifacts of retired sigs like the email archive and the web contents. I also see a clear benefit in clearly distinguishing retired sigs - segregating the entries for them from the list of active sigs, and clearly registering on the retired sig web pages that it is no longer active. Do we all agree on this? The question then, for me, is what we want to do with the sig members and email traffic. I can see a few reasonable dispositions: 1 Put it out to pasture! Close down the email list, with an auto- responder indicating that questions and comments should be sent to the newsgroup (or a newsgroup, if the python newsgroup splits). 2 Let the sig hang around and kibbitz. Clearly mark it as retired, but retain the email list and let the members unsubscribe themselves or not (and even let new members join), and field questions and residual maintenance of the sig business. (It also occurs to me that we could have an auto-responder but also keep the email distribution active, but i think that really amounts to (1) with some finagling.) I like 2. I could almost be convinced of 1 because keeping a retired sig's distribution active "muddies the waters" - diluting the concentration of information in the main newsgroup - but then i think that active sigs do just that, yet that's what active sigs are for. It *would* be bad if a retired sig appeared to be a useful channel for info but actually had no subscribers. To cover that, we could put auto responders in gear whenver there are less than, say, 10 subscribers. In fact, my ultimate proposal is to let the sig's manager decide whether they want the sig to continue. If they say no, and noone steps forward to take it over, then certainly it should be closed for correspondance. Ken _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From klm@python.org Tue Jul 29 15:40:09 1997 From: klm@python.org (Ken Manheimer) Date: Tue, 29 Jul 1997 10:40:09 -0400 (EDT) Subject: [META-SIG] whence db-sig? In-Reply-To: Message-ID: On Mon, 28 Jul 1997, David Ascher wrote: > [...] > On the same topic -- what's so bad about the hypermail archive of the > mailing lists that it's not available by default from each SIG page? I > use it all the time, but I keep having to look for it on the main SIG > page, as opposed to where I'd expect to find it (I know, I need to rewire > a few neurons). I should hook it up - but i'd like each sig to link to the archive collection for the particular sig, rather than the collection of all archives. Andrew, is there an address for that? If not, it would be sufficient to have a name tag for the section of the collection to which i could link. (Andrew, also note, i changed around the layout of the sigs page, for brevity, you may or may not want to track it on the sigs archive collection page...) Ken _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From amk@magnet.com Tue Jul 29 17:07:36 1997 From: amk@magnet.com (Andrew Kuchling) Date: Tue, 29 Jul 1997 12:07:36 -0400 (EDT) Subject: [META-SIG] whence db-sig? In-Reply-To: (message from Ken Manheimer on Tue, 29 Jul 1997 10:40:09 -0400 (EDT)) Message-ID: <199707291607.MAA22145@lemur.magnet.com> Ken Manheimer wrote: >I should hook it up - but i'd like each sig to link to the archive >collection for the particular sig, rather than the collection of >all archives. Andrew, is there an address for that? If not, it would No, though it could be easily added. Since we really should move the archive to python.org (or, failing that, starship), I should rework the arrangement of the SIG list. >(Andrew, also note, i changed around the layout of the sigs page, for >brevity, you may or may not want to track it on the sigs archive >collection page...) OK; I'll take it and add a table row after each SIG that looks like  1997q3, 1997q2, ..., so the archives will be listed in the last two columns. How's that? Should it be 1997q3 (35), 1997q2 (48), ...? BTW, 'van Rossum' should be sorted under R, not V, right? Also BTW, is there going to be a CD-ROM of python.org produced for SPAM6? Andrew Kuchling amk@magnet.com http://people.magnet.com/%7Eamk/ _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From ldl@ldl.HealthPartners.COM Tue Jul 29 20:35:53 1997 From: ldl@ldl.HealthPartners.COM (LD Landis) Date: Tue, 29 Jul 1997 14:35:53 -0500 (CDT) Subject: [META-SIG] whence db-sig? In-Reply-To: from "David Ascher" at Jul 28, 97 06:12:17 pm Message-ID: <199707291935.OAA23428@ldl.HealthPartners.COM> Hi, I almost didn't comment... BUT... I concur on keeping old lists around. What I've done on some that I administer is that I have a "The list is dead, long live the list" message that I send out once a month (at the beginning). For those messages that bounce, I go in and delete thosei people (figuring that they'll re-subscribe if needed... and I'm talking "no such user" type of bouncing here). Sometimes, people do actually decide to unsubscribe, but most appreciate knowing that the list is still there, and need not do anything to leave it as it is... For example.... let's say that db-sig was "dead", and then some new way cool post-relational "mysql" comes along... The db-sig people get "pinged" every month, so they have the location of the db-sig fairly fresh in their mind and can start right away... and continue to build their history. Just a thought. David Ascher wrote: > > > >I'm coming to agree (with whoever suggested it) that it would be a good > > >idea to retain SIGs after they've satisfied their goals, if they're > > >going to be useful for answering questions. > > > > That's a big IF; what if no one's reading the SIG anymore? If > > a SIG becomes quiet, the active posters will probably stay subscribed, > > but no one new will join, and as the active posters change e-mail > > addresses (and forget to resubscribe to a list they haven't seen a > > message from in months), the readership will slowly drop. > > But what's the cost? I've kept LISTSERV lists alive for a long while > after issues died out, and apart from the spamming problem, there's no > real cost (as long as the people running the list server don't mind). > > > >subject at issue? Plus, sigs often have artifacts - eg pythonwin stuff > > >- that need a place. Why not keep them around? > > > > Then there should be a page under software for that stuff, or > > the maintainer should have a page on starship for it. It's not very > > nice to make people hunt around the SIG pages looking for software. > > ("Go write a locator, then". I know, I know... :( ) > > The most important artifact of a list is the archive of messages, which I > think we all agree should be kept in some way or other. But things like > the DB API should belong on python.org, not starship. > > On the same topic -- what's so bad about the hypermail archive of the > mailing lists that it's not available by default from each SIG page? I > use it all the time, but I keep having to look for it on the main SIG > page, as opposed to where I'd expect to find it (I know, I need to rewire > a few neurons). > > > _______________ > META-SIG - SIG on Python.Org SIGs and Mailing Lists > > send messages to: meta-sig@python.org > administrivia to: meta-sig-request@python.org > _______________ > -- -- Cheers, --ldl ----------------------------------------------------------------------------- LD Landis ldl@HealthPartners.Com N0YRQ Voice 612/883-5511 Fax 612/883-6363 HealthPartners, 8100 34th Avenue So, PO Box 1309, Minneapolis, MN 55440-1309 Shape your life not from your memories, but from your hopes. (Borrowed) Still programming for the day-job... haven't yet gotten that Microsoft PR job ----------------------------------------------------------------------------- _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From furnish@acl.lanl.gov Wed Jul 30 16:03:42 1997 From: furnish@acl.lanl.gov (Geoffrey Furnish) Date: Wed, 30 Jul 1997 09:03:42 -0600 (MDT) Subject: [META-SIG] RE: [MATRIX-SIG] RFP: PLOT-SIG In-Reply-To: References: Message-ID: <199707301503.JAA02104@steam.acl.lanl.gov> I would like to lend my support to David's proposal. David Ascher writes: > After somewhat extensive discussion in the MATRIX-SIG, I am officially > submitting a proposal for the creation of a new sig. Here is the one line > comment and more extended docstring. I am volunteering as sigmeister. > > Please comment. > > This announcement is cc'ed to MATRIX-SIG, but I request that all followups > be directed at the META-SIG. Please check your cc: line before sending > comments. > > --david ascher > > -------------------------------- > > # PLOT-SIG: Development of Data Plotting Solutions for Python > > """ > The purpose of this list is to develop, coddle together, adopt or > otherwise make available Python tools for plotting of scientific and > business plots of data. > > Plotting needs vary greatly depending on each user's requirements. > Some users wish to see a better API between Python and existing > plotting libraries or programs. Others would rather see a new > framework which maximally leverages the OOP and dynamic strengths of > Python, at the cost of reinventing a few wheels. Both strategies will > be entertained by the SIG, with individual members contributing to > projects they wish to see furthered. > > Principles guiding the development of all software will include: > > * Ease of use. > * Integration with other Python packages (NumPy, PIL, etc.). > * Quality of the software. > * Quality of the output. > > One possible goal for the API project is to develop a package- > independent API for plots, which would produce reasonably > similar results regardless of the plotting package used as a backend > (PLPlot, Gist/Yorick, Gnuplot, etc.), in the same spirit as the > interface defined by the DB-SIG. Package-specific extensions could > naturally be provided as well. > > The goals for the new framework need to be further specified by the > SIG, but include: > > * Complete Python Control. > * Extensibility/Customizability. > * High quality rendering both on screen and paper. > * Portability (at least UNIX/X11 and Win32, MacOS if feasible). > * Stealing good ideas others have had. > * Interactivity > > The SIG is open, and membership is expected to include folks who wish to > contribute to the development efforts, folks who have lots of expertise > they wish to share, and novice users who wish to share their lists of > requirements, questions about the available software, etc. > """ > > > > _______________ > MATRIX-SIG - SIG on Matrix Math for Python > > send messages to: matrix-sig@python.org > administrivia to: matrix-sig-request@python.org > _______________ _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From klm@python.org Wed Jul 30 16:18:27 1997 From: klm@python.org (Ken Manheimer) Date: Wed, 30 Jul 1997 11:18:27 -0400 (EDT) Subject: [META-SIG] RE: [MATRIX-SIG] RFP: PLOT-SIG In-Reply-To: <199707301503.JAA02104@steam.acl.lanl.gov> Message-ID: (PLOT-SIG: Development of Solutions for World Domination (Or At Least New Jersey)) :-) :-) (This should not be taken as an objection to the proposed name!) Ken _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From gstein@microsoft.com Thu Jul 31 10:00:56 1997 From: gstein@microsoft.com (Greg Stein) Date: Thu, 31 Jul 1997 02:00:56 -0700 Subject: [META-SIG] whence db-sig? Message-ID: <41135C785691CF11B73B00805FD4D2D7033BA9E4@RED-17-MSG.dns.microsoft.com> > Also BTW, is there going to be a CD-ROM of python.org produced for > SPAM6? possibly... :-) -----Original Message----- From: Andrew Kuchling [SMTP:amk@magnet.com] Sent: Tuesday, July 29, 1997 9:08 AM To: meta-sig@python.org Subject: Re: [META-SIG] whence db-sig? Ken Manheimer wrote: >I should hook it up - but i'd like each sig to link to the archive >collection for the particular sig, rather than the collection of >all archives. Andrew, is there an address for that? If not, it would No, though it could be easily added. Since we really should move the archive to python.org (or, failing that, starship), I should rework the arrangement of the SIG list. >(Andrew, also note, i changed around the layout of the sigs page, for >brevity, you may or may not want to track it on the sigs archive >collection page...) OK; I'll take it and add a table row after each SIG that looks like  1997q3, 1997q2, ..., so the archives will be listed in the last two columns. How's that? Should it be 1997q3 (35), 1997q2 (48), ...? BTW, 'van Rossum' should be sorted under R, not V, right? Also BTW, is there going to be a CD-ROM of python.org produced for SPAM6? Andrew Kuchling amk@magnet.com http://people.magnet.com/%7Eamk/ _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________ From gstein@microsoft.com Thu Jul 31 10:03:14 1997 From: gstein@microsoft.com (Greg Stein) Date: Thu, 31 Jul 1997 02:03:14 -0700 Subject: [META-SIG] whence db-sig? Message-ID: <41135C785691CF11B73B00805FD4D2D7033BA9E5@RED-17-MSG.dns.microsoft.com> Note that the Mailman package will send out notices once a month to remind you about your Mailman password. It also serves as a nice wake-up call. -g -----Original Message----- From: LD Landis [SMTP:ldl@ldl.HealthPartners.COM] Sent: Tuesday, July 29, 1997 12:36 PM To: da@maigret.cog.brown.edu Cc: amk@magnet.com; meta-sig@python.org Subject: Re: [META-SIG] whence db-sig? Hi, I almost didn't comment... BUT... I concur on keeping old lists around. What I've done on some that I administer is that I have a "The list is dead, long live the list" message that I send out once a month (at the beginning). For those messages that bounce, I go in and delete thosei people (figuring that they'll re-subscribe if needed... and I'm talking "no such user" type of bouncing here). Sometimes, people do actually decide to unsubscribe, but most appreciate knowing that the list is still there, and need not do anything to leave it as it is... For example.... let's say that db-sig was "dead", and then some new way cool post-relational "mysql" comes along... The db-sig people get "pinged" every month, so they have the location of the db-sig fairly fresh in their mind and can start right away... and continue to build their history. Just a thought. David Ascher wrote: > > > >I'm coming to agree (with whoever suggested it) that it would be a good > > >idea to retain SIGs after they've satisfied their goals, if they're > > >going to be useful for answering questions. > > > > That's a big IF; what if no one's reading the SIG anymore? If > > a SIG becomes quiet, the active posters will probably stay subscribed, > > but no one new will join, and as the active posters change e-mail > > addresses (and forget to resubscribe to a list they haven't seen a > > message from in months), the readership will slowly drop. > > But what's the cost? I've kept LISTSERV lists alive for a long while > after issues died out, and apart from the spamming problem, there's no > real cost (as long as the people running the list server don't mind). > > > >subject at issue? Plus, sigs often have artifacts - eg pythonwin stuff > > >- that need a place. Why not keep them around? > > > > Then there should be a page under software for that stuff, or > > the maintainer should have a page on starship for it. It's not very > > nice to make people hunt around the SIG pages looking for software. > > ("Go write a locator, then". I know, I know... :( ) > > The most important artifact of a list is the archive of messages, which I > think we all agree should be kept in some way or other. But things like > the DB API should belong on python.org, not starship. > > On the same topic -- what's so bad about the hypermail archive of the > mailing lists that it's not available by default from each SIG page? I > use it all the time, but I keep having to look for it on the main SIG > page, as opposed to where I'd expect to find it (I know, I need to rewire > a few neurons). > > > _______________ > META-SIG - SIG on Python.Org SIGs and Mailing Lists > > send messages to: meta-sig@python.org > administrivia to: meta-sig-request@python.org > _______________ > -- -- Cheers, --ldl ------------------------------------------------------------------------ ----- LD Landis ldl@HealthPartners.Com N0YRQ Voice 612/883-5511 Fax 612/883-6363 HealthPartners, 8100 34th Avenue So, PO Box 1309, Minneapolis, MN 55440-1309 Shape your life not from your memories, but from your hopes. (Borrowed) Still programming for the day-job... haven't yet gotten that Microsoft PR job ------------------------------------------------------------------------ ----- _______________ META-SIG - SIG on Python.Org SIGs and Mailing Lists send messages to: meta-sig@python.org administrivia to: meta-sig-request@python.org _______________