In the olden days, someone on the list would offer to curate a FAQ. The purpose of a FAQ is to squelch debate that is not productive, and I think specifying some guidelines would add value.
Here's my suggestion. 1) What sort of discussion is appropriate for concurrency-sig? a: How to generalize parallel problems (is a discussion topic adequate covered by more general prior discussion)? b: How to generalize Python approaches/components/solutions to parallel problems (frameworks, multicore, MPP clustering, coroutine/pipeline idiom, event processing, etc.) c: How to hypothesize performance of an approach to a problem via Amdahl's Law and/or difficulty getting a good implementation d: How to design and conduct robust testing e: Analysis of test data f: Discussion of implications to general knowledge (goto a:) Discussion should, IMHO, progress through a..f states and then the particular subject can be closed. If you want to know how to get more concurrency in a Python solution to X, that falls under a. If you want to compare X and Y toolkits, that's probably b, but the discussion needs to point to c. Trouble with any given system are under c and d. Bring data everyone loves e! With new data, we can cut loose a little bit and prune our collective dogma together :) 2) What sort of discussion is inappropriate for concurrency-sig? If it doesn't fit one of the states in 1), or it prevents discussion from progressing through those states, we're not interested. On Nov 15, 2011, at 5:00 AM, [email protected] wrote: > From: David Beazley <[email protected]> > To: py concurrency sig <[email protected]> > Subject: Re: [concurrency] about the concurrency-sig list > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > Pete's wiseguy thread comment not withstanding, I'll freely admit that I'm > usually not interested in participating in online discussions about > concurrency due to excessive religious dogma backed by a lack of empirical > data or experiments. IMHO, there needs to be more level-minded > experimentation, analysis, and discussion. If this is what this list might > be about, then it might be worthwhile. > > Cheers, > Dave > > > On Nov 11, 2011, at 2:54 PM, Peter Portante wrote: > >> Perhaps we would want to avoid dogma, and have this list provide >> understanding of how things work and pros & cons? >> >> On Fri, Nov 11, 2011 at 3:47 PM, Jesse Noller <[email protected]> wrote: >> >> >> On Friday, November 11, 2011 at 3:44 PM, Peter Fein wrote: >> >>> Hi- >>> >>> I started this list & the concurrency section on the wiki >>> http://wiki.python.org/moin/Concurrency after taking one of Dave >>> Beazley's classes. Other folks & I wanted a place to discuss the kind >>> of issues Brad discusses below, in a general and cross-toolkit >>> context. I don't know why it never really took off, though I'd love to >>> see it have more life. >>> >>> Other possible topic includes: Python under Hadoop, MPI, data >>> processing pipelines (generators). >>> >>> Should we just establish "Threads: you're doing it wrong" as a ground >>> rule and be done with it? ;-P >>> >>> --Pete >>> >> No, given that "Threads: you're doing it wrong" is patently incorrect except >> for certain cases. I use them more than I use multiprocessing. :) >
_______________________________________________ concurrency-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/concurrency-sig
