Hi,
Thanks for writing this PEP. Blessing one implementation for the stdlib
and one official backport will make programmers’ lives a bit easier :)
> >>> @fun.register(int)
> ... def _(arg, verbose=False):
> ... if verbose:
> ... print("Strength in numbers, eh?", end=" ")
> ... print(arg)
> ...
Does this work if the implementation function is called like the first
decorated function? (I don’t know the proper terminology) e.g.
>>> @fun.register(int)
... def fun(arg, verbose=False):
... if verbose:
... print("Strength in numbers, eh?", end=" ")
... print(arg)
The precedent is 2.6+ properties, where prop.setter mutates and returns
the property object, which then overwrites the previous name in the
class dictionary.
> * the current implementation relies on ``__mro__`` alone, making it
> incompatible with Abstract Base Classes'
> ``register()``/``unregister()`` functionality. A possible solution has
> been proposed by PJE on the original issue for exposing
> ``pkgutil.simplegeneric`` as part of the ``functools`` API
> [#issue-5135]_.
Making generic functions work with ABCs sounds like a requirement to me,
as ABCs are baked into the language (isinstance). ABCs and interfaces
(i.e. zope.interface) are really neat and powerful.
> * the dispatch type is currently specified as a decorator argument. The
> implementation could allow a form using argument annotations. This
> usage pattern is out of scope for the standard library [#pep-0008]_.
> However, whether this registration form would be acceptable for
> general usage, is up to debate.
+1 to passing the type as argument to the decorator and not supporting
annotations. It’s simple and works.
Question: what happens if two functions (say in two different modules)
are registered for the same type?
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
