Indeed, it's mostly covered, but there is also the argument that it
was already covered in pubsub1 ;).
- Josiah
···
On Thu, Jul 24, 2008 at 8:50 PM, Oliver Schoenborn <oliver.schoenborn@utoronto.ca> wrote:
Josiah Carlson wrote:
I don't know if it would be difficult, but about the only thing
missing from pubsub 1 (available in wxPython today) is keyword
arguments. Though arguably, the only thing missing from pubsub 3
(just released) is positional arguments 
.
It's not missing, it's by design: having just one arg is limiting, so I
first looked at adding *arg, **kwarg. But because of the
looser-than-standard coupling between senders and listeners, it is easy
to get the order of unnamed arguments wrong; it is also easy to forget
to give some named arguments because they have default values. So in the
end I opted for allowing only kwargs in the sendMessage, though the
listener can have both (this is inherent to Python).
Moreover, topics specify what the valid names are so that listeners can
be validated at subscription time, another frequent source of bugs.
Finally, the list of args allowed by a topic is a superset of the args
allowed by parent topic, this is very much like a class hierarchy (these
are some of the reasons that finding ways to decorate sendMessage are
not enough to make pubsub3 backward compatible with pubsub1 -- you'd
also have to add a new ListenerValidator to the library (not difficult
but may be gotchas)).
So the following are valid listeners in pubsub3:
listener1()
listener2(arg1)
listener3(arg1, arg2)
listener4(arg1, arg2=None)
(and soon, listener(arg1, **args))
If you pick the following topic tree and argument specification
(subtopics "inherit" arguments from above):
topic1: (no args)
subtopic1: arg1
subtopic2: (no extra args)
subtopic3: arg2
then
listener1 is valid for topic1 only
listener2 and listener4 are valid for topic1.subtopic1 and topic1.subtopic2
listener3 is valid for topic1.subtopic1.subtopic2.subtopic3
This may sound complicated but in fact is it as straightforward as
remember inheritance of methods.
Then again, one of the
known drawbacks of using pubsub is that you don't get a standard
calling like wx.CallAfter(), etc., you instead get a message object
with the data provided.
If I understand what you are refering to, this is supported by pubsub3.
Karsten Hilbert wrote:
Or how many people use it in their non-wxPython projects who already
have wxPython?
I would start using it today (in our wxPython project) if it
was in Python proper. We currently use a homegrown
pre-pydispatcher descendant.
Why only in Python proper?
I don't like introducing dependancies on wxPython which
aren't strictly necessary. Our middleware - which is
independant of wxPython - uses messages, too.
Karsten
wx.lib.pubsub is *completely* independent of any other module in wx.
That's why it was so easy for me to give it a home of its own. PyPubSub
contains the pubsub code that was in wx.lib.pubsub almost verbatim (a
few words of documentation have changed here and there, and a couple
lines of code have been added to get a consistent import API with
pubsub3). But that code is only available if you tell pubsub you want to
move back to that version. To use the latest pubsub you would simply type
from pubsub import pub
pub.subscribe(...)
....
whereas to use the version *equivalent* of what is currently in
wx.lib.pubsub (but living within PyPubSub), you would prepend the
following lines to the above
import pubsubconf
pubsubconf.setVersion(1)
(only needed in *one* file, typically your top level application
script). Code that uses the pubsub version 1 style of listeners and
senders should then work out of the box.
Oliver
···
On Thu, Jul 24, 2008 at 11:02:20PM -0400, Oliver Schoenborn wrote:
What I mean about wx.CallAfter is not that it offered "multicasting",
but that wx.CallAfter is an example of "call some function with these
arguments". sendMessage() offers a similar "call some function with
these arguments" mechanism, though rather than picking up args and
kwargs via the *args and **kwargs mechanism, it instead (for pubsub 1)
required that you just pass your args tuple and kwargs dictionary as
your data, and handle all of the unpacking by hand. Though in my use
of pubsub, I've not bothered to add wrappers for handling *args and
**kwargs.
- Josiah
···
On Fri, Jul 25, 2008 at 4:54 AM, Oliver Schoenborn <oliver.schoenborn@utoronto.ca> wrote:
Josiah Carlson wrote:
Then again, one of the
known drawbacks of using pubsub is that you don't get a standard
calling like wx.CallAfter(), etc., you instead get a message object
with the data provided.
If I understand what you are refering to, this is supported by pubsub3.
Indeed, it's mostly covered, but there is also the argument that it
was already covered in pubsub1 ;).
Come to think of it, I surely don't understand what you meant because
wxCallAfter is not a publish-subscribe API: the sender calls it with the
listener to send to, so there is no decoupling, and no "multicasting" as
there is with pubsub.
As an aside, can anyone explain why pubsub uses "Publisher.sendMessage"
instead of "Publisher.publish"? It seems quite a bit more intuitive to
me, given the name of the module and all.
-- Andy Henshaw