New submission from Emanuel Barry: functools.partial is a class in C, but the Python implementation is a function. This doesn't matter for most use cases where you only want the end result of the call to partial.
A simple line in the REPL tells me enough (or so I thought) that I wouldn't need to check the implementation: >>> functools.partial <class 'functools.partial'> Oh, it's a class, which means I can subclass it to add a custom repr for my needs. Unsurprisingly, it works. It may not be the best idea to subclass something that is meant to be final, but I'm simply overriding a single method, what could possibly go wrong? Besides one of the implementations not actually being a class. I'm suggesting to make the Python implementation also a class, for consistency and making sure that both the C and Python implementation match, in case someone else wants to do that too. The documentation ( https://docs.python.org/3/library/functools.html#functools.partial ) doesn't state that the Python and C implementations differ, but IMO this isn't a documentation bug. I haven't written a patch yet, will probably be done by tomorrow. Note: I haven't actually encountered this issue, but I suspect that it might arise if someone doesn't have access to _functools for whatever reason. And IMO, Python and C implementations of a feature should be fully equivalent (modulo implementation details à la OrderedDict.__root). Thoughts? ---------- components: Library (Lib) messages: 266503 nosy: ebarry, ncoghlan, rhettinger priority: normal severity: normal stage: needs patch status: open title: functools.partial: Inconsistency between Python and C implementations type: behavior versions: Python 3.6 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27137> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
