On Sun, Feb 12, 2017 at 11:51 AM, Markus Meskanen <markusmeska...@gmail.com>
wrote:
>
> 2. To register callbacks to objects, i.e. plain out set an attribute for
> an instance. I've used the menu example above:
>
> class Menu:
> def __init__(self, items=None, select_callback=None):
> self.items = items if items is not None else []
> self.select_callback = select_callback
>
> my_menu = Menu(['Pizza', 'Cake', 'Pasta'])
> def my_menu.select_callback(item_index):
> if item_index == 0: # Pizza
> serve_food(pizza)
> else: # Cake or Pasta
> ...
> This is just one example of using it to set an instance's variable to a
> callback. It's just shorthand for:
>
> def select_callback(item_index):
> ...
> my_menu.select_callback = select_callback
>
One issue that has been overlooked so far in this thread is that
hypothetical use cases are not as important as real-world use cases. One
way that PEPs can demonstrate real-world relevance is by demonstrating the
effect on some important libraries, e.g. the standard library.
For example, asyncio.Future (and concurrent.futures.Future) has a list of
callbacks and the API has add_done_callback() and remove_done_callback()
functions for manipulating the callback list. The proposed syntax doesn't
cooperate with these callbacks:
f = asyncio.Future()
def my_callback(x):
...
f.add_done_callback(my_callback)
How should I write this using the proposed syntax? If the proposal doesn't
generalize well enough to cover existing callback patterns in Python's own
standard library, then that is a significant weakness.
Please keep this in mind as you write the PEP.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
