On Wed, May 14, 2008 at 5:45 AM, Christian Heimes <[EMAIL PROTECTED]> wrote: > Martin v. Löwis schrieb: > > > I'm worried whether it's stable, what user base it has, whether users > > (other than the authors) are lobbying for inclusion. Statistically, > > it seems to be not ready yet: it is not even a year old, and has not > > reached version 1.0 yet. > > I'm on Martin's side here. Although I like to see some sort of multi > processing mechanism in Python 'cause I need it for lots of projects I'm > against the inclusion of pyprocessing in 2.6 and 3.0. The project isn't > old and mature enough and it has some competitors like pp (parallel > processing). > > On the one hand the inclusion of a package gives it an unfair advantage > over similar packages. On the other hand it slows down future > development because a new feature release must be synced with Python > releases about every 1.5 years. > > -0.5 from me > > Christian >
I said this in reply to Martin - but the competitors (in my mind) are not as compelling due to the "alternative" paradigm for application construction they propose. The processing module is an "easy win" for us if included. Personally - I don't see how inclusion in the stdlib would slow down development - yes, you have to stick with the same release cycle as python-core, but if the module is "feature complete" and provides a stable API as it stands I don't see following python-core timelines as overly onerous. The module itself doesn't change that frequently - the last release in April was a bugfix release and API consistency change (the API would have to be locked for inclusion obviously - targeting a 2.7/3.1 release may be advantageous to achieve this). -jesse _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
