summaryrefslogtreecommitdiff
path: root/CHANGES.txt
diff options
context:
space:
mode:
authorChris McDonough <chrism@plope.com>2011-07-01 03:18:03 -0400
committerChris McDonough <chrism@plope.com>2011-07-01 03:18:03 -0400
commit2ea5c1fbe9fef8fc6a1f16f98368abe68100783d (patch)
treef20baca98db0c022479420eadbf72662fac8171a /CHANGES.txt
parent6c9959c34b403c2b1e3088d34b67bef5c79ee9fc (diff)
downloadpyramid-2ea5c1fbe9fef8fc6a1f16f98368abe68100783d.tar.gz
pyramid-2ea5c1fbe9fef8fc6a1f16f98368abe68100783d.tar.bz2
pyramid-2ea5c1fbe9fef8fc6a1f16f98368abe68100783d.zip
- The ``pyramid.events.subscriber`` directive behaved contrary to the
documentation when passed more than one interface object to its constructor. For example, when the following listener was registered:: @subscriber(IFoo, IBar) def expects_ifoo_events_and_ibar_events(event): print event The Events chapter docs claimed that the listener would be registered and listening for both ``IFoo`` and ``IBar`` events. Instead, it registered an "object event" subscriber which would only be called if an IObjectEvent was emitted where the object interface was ``IFoo`` and the event interface was ``IBar``. The behavior now matches the documentation. If you were relying on the buggy behavior of the 1.0 ``subscriber`` directive in order to register an object event subscriber, you must now pass a sequence to indicate you'd like to register a subscriber for an object event. e.g.: @subscriber([IFoo, IBar]) def expects_object_event(object, event): print object, event
Diffstat (limited to 'CHANGES.txt')
-rw-r--r--CHANGES.txt23
1 files changed, 23 insertions, 0 deletions
diff --git a/CHANGES.txt b/CHANGES.txt
index 2779f905a..3f8fd5049 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -10,6 +10,29 @@ Bug Fixes
tests which use DummyRequest instead of a "real" request, so they know
things are deprecated without necessarily needing a functional test suite.
+- The ``pyramid.events.subscriber`` directive behaved contrary to the
+ documentation when passed more than one interface object to its
+ constructor. For example, when the following listener was registered::
+
+ @subscriber(IFoo, IBar)
+ def expects_ifoo_events_and_ibar_events(event):
+ print event
+
+ The Events chapter docs claimed that the listener would be registered and
+ listening for both ``IFoo`` and ``IBar`` events. Instead, it registered an
+ "object event" subscriber which would only be called if an IObjectEvent was
+ emitted where the object interface was ``IFoo`` and the event interface was
+ ``IBar``.
+
+ The behavior now matches the documentation. If you were relying on the
+ buggy behavior of the 1.0 ``subscriber`` directive in order to register an
+ object event subscriber, you must now pass a sequence to indicate you'd
+ like to register a subscriber for an object event. e.g.:
+
+ @subscriber([IFoo, IBar])
+ def expects_object_event(object, event):
+ print object, event
+
Features
--------