Vote to Add Python Package "pubsub" to the Python Standard Library

T

Tom

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/>.
 
A

Aahz

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
 
T

Terry Reedy

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.
 
C

Carl Banks

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
 
D

Daniel Fetchinson

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
 
V

Vinay Sajip

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.

Only in a very general sense, if you mean the separation of concerns
between loggers and handlers. There isn't a general-purpose pub/sub
infrastructure built into it.

Of course, pub/sub is just one type of message architecture. I would
say that it would be nice to have a Python messaging package which had
pub/sub as one of several different approaches - which is often done
these days using things like RabbitMQ. Are there any such (pure-Python
or Python + C) packages out there which are generally accepted as
being head and shoulders above others in the same category?

It may be too early to bless any one messaging package for the stdlib
- "let a thounsand flowers bloom" and all that. In any case, stdlib
inclusion can be a double-edged sword in terms of backward-
compatibility constraints, leading to reduced developer/maintainer
flexibility going forward.

Regards,

Vinay Sajip
 
C

Carl Banks

Only in a very general sense, if you mean the separation of concerns
between loggers and handlers. There isn't a general-purpose pub/sub
infrastructure built into it.

Which is an implementation of publish-subscribe pattern. I didn't say
or imply it was general purpose. And it doesn't have to be to make a
case for inclusion of a general-purpose implementation in the standard
library.


Carl Banks
 
V

Vinay Sajip

Which is an implementation of publish-subscribe pattern.  I didn't say
or imply it was general purpose.  And it doesn't have to be to make a
case for inclusion of a general-purpose implementation in the standard
library.

It's analogous, but it's not messaging. And I didn't give that as a
reason why there should or shouldn't be a pub/sub module in the
stdlib; my other comments were more relevant in that debate.

Regards,

Vinay Sajip
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top