[issue5135] Expose simplegeneric function in functools module

Łukasz Langa added the comment: For the record, this has been implemented as PEP 443. -- nosy: +lukasz.langa ___ Python tracker ___ ___

[issue5135] Expose simplegeneric function in functools module

Changes by Eric Snow : -- nosy: +eric.snow ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.or

[issue5135] Expose simplegeneric function in functools module

Changes by Terry J. Reedy : -- stage: -> committed/rejected ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: htt

[issue5135] Expose simplegeneric function in functools module

Terry J. Reedy added the comment: Guido said "Please don't introduce this without a PEP." and that has not happened and if it did, the result would probably look quite different from the patches. So this is 'unripe' and no current action here is possible. -- nosy: +terry.reedy resoluti

[issue5135] Expose simplegeneric function in functools module

Changes by Daniel Urban : -- nosy: +durban ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.or

[issue5135] Expose simplegeneric function in functools module

Éric Araujo added the comment: Thanks for the detailed explanation. Note that type annotations are disallowed in the stdlib, as per PEP 8. -- ___ Python tracker ___ ___

[issue5135] Expose simplegeneric function in functools module

Phillip J. Eby added the comment: Just as an FYI, it *is* possible to do generic functions that work with Python's ABCs (PEAK-Rules supports it for Python 2.6), but it requires caching, and a way of handling ambiguities. In PEAK-Rules' case, unregistering is simply ignored, and ambiguity cau

[issue5135] Expose simplegeneric function in functools module

Changes by Éric Araujo : -- nosy: +pje -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue5135] Expose simplegeneric function in functools module

Éric Araujo added the comment: > The register() method of an ABC only fakes out isinstance checks, it > doesn't actually make the abstract base class a base class of the class. > It doesn't make any sense for a class to say it is an instance of an > ABC, but not have that ABC in [its] MRO. I di

[issue5135] Expose simplegeneric function in functools module

Changes by Éric Araujo : Removed file: http://bugs.python.org/file18131/unnamed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue5135] Expose simplegeneric function in functools module

Changes by Éric Araujo : -- nosy: +merwok ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org

[issue5135] Expose simplegeneric function in functools module

Nick Coghlan added the comment: A couple more relevant links. I brought this issue up in the context of a JSON serialisation discussion on python-ideas: http://mail.python.org/pipermail/python-ideas/2010-July/007854.html Andrey Popp mentioned his pure Python generic functions library in that

[issue5135] Expose simplegeneric function in functools module

Ryan Freckleton added the comment: An elaborate PEP for generic functions already exists, PEP 3124 [ http://www.python.org/dev/peps/pep-3124/]. Also note the reasons for deferment. I'd be interested in creating a "more limited" generic function implementation based on this PEP, minus func_code r

[issue5135] Expose simplegeneric function in functools module

Antoine Pitrou added the comment: Generic functions are a lesser-known paradigm than OO, and nowhere do common Python documents (including the official docs) try to teach them. That means the first public appearance of generic functions in the stdlib should really be well thought out if we do

[issue5135] Expose simplegeneric function in functools module

Paul Moore added the comment: I don't propose to raise a PEP myself. The issue with ABCs seems to me to be a fundamental design issue, and I think it's better to leave raising any PEP, and managing the subsequent discussion, to someone with a deeper understanding of, and interest in, generic

[issue5135] Expose simplegeneric function in functools module

Mark Lawrence added the comment: Changes as Guido has stated that he wants a PEP. -- nosy: +BreamoreBoy stage: patch review -> versions: +Python 3.3 -Python 2.7 ___ Python tracker _

[issue5135] Expose simplegeneric function in functools module

Guido van Rossum added the comment: Please don't introduce this without a PEP. -- nosy: +gvanrossum ___ Python tracker ___ ___ Python-

[issue5135] Expose simplegeneric function in functools module

Nick Coghlan added the comment: Given the point Armin raised, I once again agree that documenting the limitation is a reasonable approach. Longer-term, being able to subcribe to ABCs (and exposing the registration list if it isn't already visible) is likely to be the ultimate solution.

[issue5135] Expose simplegeneric function in functools module

Paul Moore added the comment: I raised issue 5405. Armin Ronacher commented over there that it's not even possible in principle to enumerate the ABCs a class implements because ABCs can do semantic checks (e.g., checking for the existence of a special method). So documenting the limitation is a

[issue5135] Expose simplegeneric function in functools module

Changes by Paul Moore : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bug

[issue5135] Expose simplegeneric function in functools module

Paul Moore added the comment: I raised issue 5405. Armin Roachner commented over there that it's not even possible in principle to enumerate the ABCs a class implements because ABCs can do semantic checks (e.g., checking for the existence of a special method). So documenting the limitation is a

[issue5135] Expose simplegeneric function in functools module

Kevin Teague added the comment: The problem with generic functions supporting ABCs is it's a bug with the way ABCs work and not a problem with the generic function implementation. The register() method of an ABC only fakes out isinstance checks, it doesn't actually make the abstract base class a

[issue5135] Expose simplegeneric function in functools module

Nick Coghlan added the comment: Unassigning - the lack of support for ABC registration still bothers me, but a) I don't have a good answer for it, and b) I'm going to be busy for a while working on some proposed changes to the with statement. -- assignee: ncoghlan -> _

[issue5135] Expose simplegeneric function in functools module

Paul Moore added the comment: Here's an updated patch. I've reverted to the name "simplegeneric" and documented the limitation around ABCs (I've tried to give an explanation why it's there, as well as a hint on now to work around the limitation - let me know if I'm overdoing it, or the text need

[issue5135] Expose simplegeneric function in functools module

Nick Coghlan added the comment: Even more inconveniently, the existence of unregister() on ABCs makes it difficult for the generic to cache the results of the isinstance() checks (you don't want to be going through the chain of registered ABCs every time calling isinstance(), since that would be

[issue5135] Expose simplegeneric function in functools module

Paul Moore added the comment: Very good point. Registering for the standard ABCs seems like an important use case. Unfortunately, it seems to me that ABCs simply don't provide that capability - is there a way, for a given class, of listing all the ABCs it's registered under? Even if the order is

[issue5135] Expose simplegeneric function in functools module

Nick Coghlan added the comment: Hmm, there is such a thing as being *too* simple... a generic function implementation that doesn't even respect ABCs seems pretty pointless to me (e.g. I'd like to be able to register a default Sequence implementation for pprint and have all declared Sequences use

[issue5135] Expose simplegeneric function in functools module

Paul Moore added the comment: Agreed (in principle). However, in practice the subtleties of override order must be documented (and a method of implementation must be established!!!) Consider: >>> class A: ... pass ... >>> class C: ... __metaclass__ = abc.ABCMeta ... >>> class D: ...

[issue5135] Expose simplegeneric function in functools module

Nick Coghlan added the comment: Failure to respect isinstance() should be fixed, not documented :) As far as registering existing functions goes, I also expect registering lambdas and functools.partial will be popular approaches, so keeping direct registration is a good idea. There isn't any am

[issue5135] Expose simplegeneric function in functools module

Ryan Freckleton added the comment: I think that registering existing functions is an important use case, so I vote for keeping the non-decorator version of register. Another thing that we may want to document is that [simple]generic doesn't dispatch based on registered abstract base classes. >

[issue5135] Expose simplegeneric function in functools module

Paul Moore added the comment: Agreed about the compatibility. It's there from pkgutil, where to be honest, it's even less necessary, as simplegeneric was for internal use only, there. I'm certainly not aware of any backward compatibility requirements for functools. Assuming nobody speaks up to

[issue5135] Expose simplegeneric function in functools module

Walter Dörwald added the comment: The patch looks fine to me. Tests pass. I have no opinion about the name. Both "simplegeneric" and "generic" are OK to me. I wonder if being able to use register() directly instead of as a decorator should be dropped. Also IMHO the Python 2.3 backwards compat

[issue5135] Expose simplegeneric function in functools module

Paul Moore added the comment: Fair comment. As Ryan said, it's a bit of a bikeshed issue. I prefer "generic", on the basis that I'd prefer to keep the simple name for the simple use - something as complex as the RuleDispatch version could use the name "dispatch" (if they want to keep it the name

[issue5135] Expose simplegeneric function in functools module

Nick Coghlan added the comment: The reason I like the simplegeneric name is that that is exactly what this feature is: a *simple* generic implementation that is deliberately limited to dispatching on the first argument (because that is easily explained to users that are already familiar with OOP

[issue5135] Expose simplegeneric function in functools module

Paul Moore added the comment: Here's an updated patch. Added file: http://bugs.python.org/file12936/generic.patch ___ Python tracker ___ ___ P

[issue5135] Expose simplegeneric function in functools module

Paul Moore added the comment: Well spotted! I missed that when I checked. I will add tests and documentation. I agree that generic is better. I only left it as it was because the original intent was simply to move the existing code - but that's not a particularly good reason for keeping a clums

[issue5135] Expose simplegeneric function in functools module

Ryan Freckleton added the comment: PJE seems to have borrowed the time machine :-). Based on the code the register function is already a decorator: def register(typ, func=None): if func is None: return lambda f: register(typ, f) registry[typ] = func retur

[issue5135] Expose simplegeneric function in functools module

New submission from Paul Moore : This patch takes the existing "simplegeneric" decorator, currently an internal implementation detail of the pkgutil module, and exposes it as a feature of the functools module. Documentation and tests have been added, and the pkgutil code has been updated to use