pypubsub 3.3 release ready

87 views
Skip to first unread message

Oliver

unread,
Nov 30, 2013, 8:56:00 AM11/30/13
to pypu...@googlegroups.com

Ready to release pypubsub v3.3: add support for python 3.3, tweaks to adhere to some of the python styling PEPs, add reference section to docs, simplify examples. All this led to cleanup of the API: not the main functions like sendMessage and subscribe but the "support" functions" like getListeners, exception names, version string, etc. I doubt this cleanup will affect any of you  but I'd prefer to verify via members of this group, if possible. 

So if anyone is inclined to try out the latest release candidate, you can use SVN as in the past, or there is also a dev release which you can install via 

pip install --pre pypubsub 

(if you don't specify '--pre', pip will not find it). 

Please post how it goes. The latest documentation for this release is temporarily at http://pubsub.sourceforge.net/v3.3dev1.

Cheers, 

Oliver

Werner

unread,
Dec 2, 2013, 6:10:00 AM12/2/13
to pypu...@googlegroups.com
Hi Oliver,


On 30/11/2013 14:56, Oliver wrote:

Ready to release pypubsub v3.3: add support for python 3.3, tweaks to adhere to some of the python styling PEPs, add reference section to docs, simplify examples. All this led to cleanup of the API: not the main functions like sendMessage and subscribe but the "support" functions" like getListeners, exception names, version string, etc. I doubt this cleanup will affect any of you  but I'd prefer to verify via members of this group, if possible. 

So if anyone is inclined to try out the latest release candidate, you can use SVN as in the past, or there is also a dev release which you can install via

Got it from SVN (copied the src folder to my Phoenix install folder) and things are working fine for me - just a casual test at this point.

As I have multiple versions floating around I want to output the pubsub version, but I am not sure what to use.

E.g.
wx.lib.pubsub.__version__ = 3.3.0dev1
pub.VERSION_SVN = 243

But looking at my SVN log I see the latest commit is 343.

I think it would be nice to be able to do e.g.:

from wx.lib.pubsub import pub
log.debug(pub.__version__)
or
log.debug(pub.somethingclear)

which clearly identifies what version one is on, including info about a dev build or ......

Werner

oliver

unread,
Dec 2, 2013, 7:36:36 AM12/2/13
to PyPubSub
Hi Werner, the VERSION_SVN is the revision # according to subversion, it is specific to the file so I don't see it as very useful (if there was a tag to get the head revision of a repo that would be useful). As to __version__, the reason I moved it out out of pub module to pubsub level is that the version pertains to package, not just to pub. In the module where you want to log the pubsub version you have to import an extra item: 

    from pubsub import (pub, __version__ as PUBSUB_VERSION)
    log.debug(PUBSUB_VERSION)

or 

    from pubsub import pub
    import pubsub
    log.debug(pubsub.__version__)

You could also output the pubsub API version, this is specific to the pub module so 

    log.debug(pub.VERSION_API)

will output 3.

Oliver


--
You received this message because you are subscribed to the Google Groups "pypubsub" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pypubsub+u...@googlegroups.com.
To post to this group, send email to pypu...@googlegroups.com.
Visit this group at http://groups.google.com/group/pypubsub.
For more options, visit https://groups.google.com/groups/opt_out.

Werner

unread,
Dec 3, 2013, 3:14:41 AM12/3/13
to pypu...@googlegroups.com
Hi Oliver,

On 02/12/2013 13:36, oliver wrote:
> Hi Werner, the VERSION_SVN is the revision # according to subversion,
> it is specific to the file so I don't see it as very useful (if there
> was a tag to get the head revision of a repo that would be useful). As
> to __version__, the reason I moved it out out of pub module to pubsub
> level is that the version pertains to package, not just to pub. In the
> module where you want to log the pubsub version you have to import an
> extra item:
>
> from pubsub import (pub, __version__ as PUBSUB_VERSION)
> log.debug(PUBSUB_VERSION)
>
> or
>
> from pubsub import pub
> import pubsub
> log.debug(pubsub.__version__)
O.K.
>
> You could also output the pubsub API version, this is specific to the
> pub module so
>
> log.debug(pub.VERSION_API)
>
> will output 3.
Yeap, I found that one too.

It would be good to keep a method which is compatible with past
versions, e.g. we had "pub.VERSION_STR", maybe retain that in addition
to the above.

Werner

Jérôme Laheurte

unread,
Dec 1, 2013, 7:18:45 AM12/1/13
to pypu...@googlegroups.com

Le 30 nov. 2013 à 14:56, Oliver <Oliver.S...@gmail.com> a écrit :

Ready to release pypubsub v3.3: add support for python 3.3, tweaks to adhere to some of the python styling PEPs, add reference section to docs, simplify examples. All this led to cleanup of the API: not the main functions like sendMessage and subscribe but the "support" functions" like getListeners, exception names, version string, etc. I doubt this cleanup will affect any of you  but I'd prefer to verify via members of this group, if possible. 


Looks like pub.UndefinedTopic has disappeared ? As well as a number of other topic-related exceptions.

Cheers
Jérôme


oliver

unread,
Dec 3, 2013, 10:32:30 AM12/3/13
to PyPubSub
Several exceptions were renamed, please see the change log. There it says "UndefinedTopic(RuntimeError) -> TopicNameError(ValueError)" which means that UndefinedTopic, derived from RuntimeError, has been renamed to TopicNameError, and is now derived from ValueError.
Oliver



Jérôme Laheurte

unread,
Dec 3, 2013, 12:01:02 PM12/3/13
to pypu...@googlegroups.com

Le 3 déc. 2013 à 16:32, oliver <oliver.s...@gmail.com> a écrit :

Several exceptions were renamed, please see the change log. There it says "UndefinedTopic(RuntimeError) -> TopicNameError(ValueError)" which means that UndefinedTopic, derived from RuntimeError, has been renamed to TopicNameError, and is now derived from ValueError.

Ah sorry, I’ve been looking at the release notes which aren’t as detailed :)

Cheers
Jérôme

oliver

unread,
Dec 3, 2013, 1:07:40 PM12/3/13
to PyPubSub
No problem. I just noticed that the change log is not formatted right, might be a bit hard to read (some of the bullet points show up inline with text), I'll have to fix that. 


Jérôme Laheurte

unread,
Dec 8, 2013, 7:39:56 AM12/8/13
to pypu...@googlegroups.com
Le 30 nov. 2013 à 14:56, Oliver <Oliver.S...@gmail.com> a écrit :

Okay, concerning Task Coach, all unit tests pass. I’ll post here if I encounter any problem.

Cheers
Jérôme


Jérôme Laheurte

unread,
Dec 11, 2013, 9:26:39 AM12/11/13
to pypu...@googlegroups.com
There is a change that may break some code. In r303, Topic.getListeners() returned self.__listeners.keys() and the comment emphasizes that it’s a copy. In r343 this becomes py2and3.iterkeys(self.__listeners), which does not seem to copy anything, so if a listener is added as a consequence of sendMessage called, this happens:

  File "../hermeslib/utils/pub.py", line 18, in sendMessage
    return self.__publisher.sendMessage(topic, **kwargs)
  File "../hermeslib/thirdparty/pubsub/core/kwargs/publisher.py", line 27, in sendMessage
    topicObj.publish(**kwargs)
  File "../hermeslib/thirdparty/pubsub/core/kwargs/publishermixin.py", line 24, in publish
    self._publish(msgKwargs)
  File "../hermeslib/thirdparty/pubsub/core/topicobj.py", line 370, in _publish
    self.__sendMessage(data, self, iterState)
  File "../hermeslib/thirdparty/pubsub/core/topicobj.py", line 386, in __sendMessage
    for listener in topicObj.getListeners():
RuntimeError: dictionary changed size during iteration

Cheers
Jérôme

Jérôme Laheurte

unread,
Dec 12, 2013, 7:37:59 AM12/12/13
to pypu...@googlegroups.com
Scratch this, I didn’t see the actual implementation of py2and3.iterkeys. Obviously this should not happen, yet it does. I’m trying to find out why.

Cheers
Jérôme

oliver

unread,
Dec 12, 2013, 1:10:37 PM12/12/13
to PyPubSub
After reading your first email I thought "this makes sense". However now I'm wondering why you are iterating the list when sending messages? Are you in Python 2.x?


oliver

unread,
Dec 12, 2013, 1:14:27 PM12/12/13
to PyPubSub
Ah scratch that, no I think you are right, *I* am using the topicObj.getListeners() while sending messages. It should be sufficient to create a temp list in the __sendMessage, then the iteration can be over that temp list. I'll try it out over the next few days, and I should check where else the getListeners() is used inside pubsub in case there are other places that this changes things when listeners are added and removed during the send operation. 
Oliver

Jérôme Laheurte

unread,
Dec 12, 2013, 1:22:58 PM12/12/13
to pypu...@googlegroups.com

Le 12 déc. 2013 à 19:14, oliver <oliver.s...@gmail.com> a écrit :

> Ah scratch that, no I think you are right, *I* am using the topicObj.getListeners() while sending messages. It should be sufficient to create a temp list in the __sendMessage, then the iteration can be over that temp list. I'll try it out over the next few days, and I should check where else the getListeners() is used inside pubsub in case there are other places that this changes things when listeners are added and removed during the send operation.

OK. I was starting to think it was a thread-related problem on my side, but I can reproduce it through my unit tests and they’re not multithreaded so I was lost :)

Cheers
Jérôme


Jérôme Laheurte

unread,
Dec 12, 2013, 1:23:32 PM12/12/13
to pypu...@googlegroups.com
BTW I’m on Python 2.7

Cheers
Jérôme

oliver

unread,
Dec 12, 2013, 1:45:59 PM12/12/13
to PyPubSub
In python 3, I believe this would not be an issue because listener iterator is actually a view onto the dictionary keys and is safe even if list gets changed during iteration. I can't think of another reason (ie it is ok in py 3) that I changed getListeners() to return iter instead of copy. I'll change it so that in py3 getListeners() returns the read-only view of keys, while in py2 it returns the keys list. 

Glad you found this. I guess I'll have to add a unit test to trap this regression. 

Oliver

Reply all
Reply to author
Forward
0 new messages