From: Tom on
I vote for adding the Python package "pubsub" to the Python standard
library. It has recently been added to wxpython (replacing the old
wx.lib.pubsub package), but it has application to non-gui programs as
well.

For more information see: <http://pubsub.sourceforge.net/>.

From: Aahz on
In article <6b9d2898-4166-40b4-9016-dc55dee77d00(a)q33g2000vbt.googlegroups.com>,
Tom <tom.browder(a)gmail.com> wrote:
>
>I vote for adding the Python package "pubsub" to the Python standard
>library. It has recently been added to wxpython (replacing the old
>wx.lib.pubsub package), but it has application to non-gui programs as
>well.

You should create a ticket on bugs.python.org
--
Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/

"If you don't know what your program is supposed to do, you'd better not
start writing it." --Dijkstra
From: Terry Reedy on
On 5/31/2010 5:37 PM, Aahz wrote:
> In article<6b9d2898-4166-40b4-9016-dc55dee77d00(a)q33g2000vbt.googlegroups.com>,
> Tom<tom.browder(a)gmail.com> wrote:
>>
>> I vote for adding the Python package "pubsub" to the Python standard
>> library. It has recently been added to wxpython (replacing the old
>> wx.lib.pubsub package), but it has application to non-gui programs as
>> well.
>
> You should create a ticket on bugs.python.org

But only if the author of pubsub has agreed to contribute and continue
maintaining the package in the strdlib.


From: Carl Banks on
On May 26, 4:26 am, Tom <tom.brow...(a)gmail.com> wrote:
> I vote for adding the Python package "pubsub" to the Python standard
> library.  It has recently been added to wxpython (replacing the old
> wx.lib.pubsub package), but it has application to non-gui programs as
> well.


Well, I can definitely see a case for adding something like this to
the standard library. If there is a standard publish-subscribe
implementation, then different third-party packages can use it in a
consistent way together. It can open whole paradigms of package
integration.

However, I'm not sure this particular library is the one to use, and I
would not be in favor of throwing the first publish-subscribe
implentation that comes by into the standard library, at least not
without a whole lot of vetting first. (They did that with optparse
and the Python community has been paying for it ever since.)

I think it has a pretty good chance of being accepted, too. The
publish-subscribe pattern, if you will, seems to have been implemented
separately in many places. The logging module in the standard library
uses something like this. Qt's signal/slot mechanism is another
variation. I'm sure there's lots more. I've noticed that pointing
out lots of independetnly crafted examples in the wild, and especially
in the standard library, works quite well.


Carl Banks
From: Daniel Fetchinson on
> I vote for adding the Python package "pubsub" to the Python standard
> library. It has recently been added to wxpython (replacing the old
> wx.lib.pubsub package), but it has application to non-gui programs as
> well.
>
> For more information see: <http://pubsub.sourceforge.net/>.

If you are really interested in this the minimum would be following these steps:

1. discuss various publish-subscribe API variants on python-list (aka c.l.p)
2. when you got tons of feedback summarize the discussion on python-dev
3. tons of feedback will follow and try to converge on a consensus
concerning the API
4. write a PEP
5. produce an implementation (or get someone to do it)
6. add the implementation to the PEP
7. lobby for acceptance of the PEP

A good example for the first couple of stages of this process is PEP
3143 concerning adding a daemon package to the stdlib:
http://www.python.org/dev/peps/pep-3143/

I haven't found the beginning of the thread discussing this but you
can start for example here:

http://mail.python.org/pipermail/python-list/2009-March/1197808.html

Good luck,
Daniel


--
Psss, psss, put it down! - http://www.cafepress.com/putitdown