timofurrer/observable

minimalist event system for Python

observable's Issues

Licensing under an open source license

Hi,

Thanks for this handy library! It's perfect for simple use cases like mine.

However, I'd like to use it in a project under Apache License, which can't be changed. Don't get me wrong, I like the GPL a lot for complex works, but for such basic libraries like pyobservable it dramatically limits the possible use cases.

I'm writing this because many software authors are simply not aware of the implications resulting from their license choice. If you want to limit the usage of this library to projects using the GPL, that's fine and you can close the issue. But if not, it'd be better to license under Apache V2, for instance.

What do you think?

Best regards
Robert

Release of v1.0.1 on PyPi

Hi,

is there a reason why v1.0.1 hasn't been pushed to PyPi yet? I'm pulling it as a dependency in one of my packages and still get v0.3.2 without the fixes around once() etc.

Best regards
Robert

Observable properties

Hi,

What do you think about an API for observing properties easily? This would allow something like the following:

>>> import observable as obs
>>> class A(obs.Observable):
...   @obs.ObservableProperty
...   def x(self): return 42
...   @x.setter
...   def x(self, val): pass
... 
>>> a=A()
>>> a.on("x_get", lambda x:print("get",x))
<function <lambda> at 0x7fa793345f28>
>>> a.on("x_set", lambda x:print("set",x))
<function <lambda> at 0x7fa792ae8d90>
>>> a.x
get 42
42
>>> a.x=5
set 5

The ObservableProperty is a child of the built-in property that wraps the getter, setter and deleter to trigger appropriate events on the holding object whenever they are called.

I have an implementation at hand which I could submit as a PR, if desired.

The exact event types and names like "x_get", "x_del" have to be discussed, of course.

Best regards
Robert

Handlers registered via once() only get unregistered after the handler ran

Such handlers should get unregistered before their own code is executed in order to prevent potential new events fired during the handler runs from triggering the original once-registered handler again.

This issue is addressed in PR #8 as well.

Best regards
Robert

New release incl. ObservableProperty

Hiya thanks for this library, I like its usability/API a lot!

Any chance to cut an official release that includes the ObservableProperty feature? It's been a while since it was added. Didn't knew I'd needed it before I stumbled upon it, but now I really do! :-)

Observable wheel on PyPI is marked as universal but it is Python3 only

As I see from README.md observable now is Python3 only however wheel uploaded on PyPI is marked as Python2 and Python3 compatible (https://pypi.org/project/observable/#files): observable-1.0.3-py2.py3-none-any.whl which is incorrect and misleading. Please consider removing --universal switch from bdist_wheel invocation.

Observable collections

I would like to have observable dicts to notify on item add/remove. This seems like a pattern that observable might want to provide an implementation for, and/or docs with a recipe for observing core collection types. If the core types need to be subclassed in order to be observed, a helper/mixin would be useful to make it easy.

Modifying registrations from inside an event handler causes unexpected behaviour

Hello,

I already submitted a PR to fix this, but here comes the corresponding issue.

When triggering an event, the loop goes over the registered handlers and calls them one after another. But when one of these handlers changes the list of registered handlers (e.g. by calling off() like the once() wrapper does), the trigger loop gets disordered andcan skip handlers or execute them twice. Demonstrations for this are provided in the comments of the PR.

My proposed solution for this is creating a working copy of the list of event handlers to iterate over.

See #8.

Best regards
Robert

How to obtain trigger callback returns

First, thanks for this neat package! It looks like it's not possible to obtain the return value of the triggered callbacks as trigger('foo') always returns True.

However, I think it would be nice to have this option to use callbacks to influence the control flow. Consider the following example where an event is triggered in a save method.

def save(data):
      observable.trigger('save', data)
      with open('bla.txt') as f: 
           f.write(data)
# ...

observable.on('save', lambda data: True)

The user can hook into the save method but the callback cannot send anything back to influence what's happening at the trigger point, like here:

def save(data):
      if observable.trigger('save', data) is False:
          return
      with open('bla.txt') as f: 
           f.write(data)
# ...

def custom_save(data):
      with open('a_differnt_save_method.txt') as f:
            f.write(data)
      return False   # returns False to prevent execution of default save logic

observable.on('save', custom_save)

If trigger would collect the callback returns such 'extension via event' could be implemented. Would you consider enhancing the trigger behaviour?