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
_______________