| msg74682 - (view) |
Author: Andrew Stribblehill (stribb) |
Date: 2008-10-13 11:45 |
| When I partially apply a function using functools.partial(), the resultant function doesn't have the same name as the original function (it has no __name__) and its docstring is that of functools.partial() rather than that of the function that was partially applied. Transcript: Python 2.6 (r26:66714, Oct 13 2008, 10:32:02) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >> import functools >>> def sum(a,b,c): ... return a+b+c ... >>> functools.partial(sum,1) <functools.partial object at 0xf7efeb6c> >>> p = functools.partial(sum, 1) >>> p.__name__ Traceback (most recent call last): File "", line 1, in AttributeError: 'functools.partial' object has no attribute '__name__' >>> p(2,3) 6 >>> sum.__name__ 'sum' >>> sum.__doc__ >>> p.__doc__ 'partial(func, *args, **keywords) - new function with partial application\n\tof the given arguments and keywords.\n' |
|
|
| msg74945 - (view) |
Author: Terry J. Reedy (terry.reedy) *  |
Date: 2008-10-17 22:45 |
| Same in 3.0 |
|
|
| msg74977 - (view) |
Author: Thomas Lee (thomaslee) |
Date: 2008-10-19 14:58 |
| Here's a patch against the 2.x trunk. Basically just dispatches reads of a partial's __name__ and __doc__ attributes to the underlying function object. |
|
|
| msg74982 - (view) |
Author: Georg Brandl (georg.brandl) * |
Date: 2008-10-19 20:38 |
| I do not think the partial object should have the original function's __name__ or __doc__. It is after all not that function, but a callable that calls it. (This is different from e.g. a decorated function -- the decorator is taken as "modifying the function", even if it returns a wholly different one. This is why functools.wraps() exists.) In any case, this is not a bug but a feature request. |
|
|
| msg74986 - (view) |
Author: Thomas Lee (thomaslee) |
Date: 2008-10-20 02:23 |
| I actually agree with the sentiment Georg. Would it instead be useful to maybe provide a __repr__ implementation that describes the state of the partially applied function? I guess this is an entirely different issue, maybe one for python-ideas. |
|
|
| msg107504 - (view) |
Author: Alexander Belopolsky (belopolsky) * |
Date: 2010-06-11 00:01 |
| I understand that the latest RFE in this issue is to provide a custom __repr__ to functools.partial. Something along the lines of class partial(functools.partial): def __repr__(self): return "functools.partial(%r, %s)" % (self.func, ', '.join(repr(a) for a in self.args) >>> def f(x, y, z): ... pass >>> partial(f, 1, 2) functools.partial(<function f at 0x10065b060>, 1, 2) Looks like a reasonable proposal, but coding this in C is a chore. (The prototype above does not process keywords, so complete implementation is more involved.) |
|
|
| msg121417 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2010-11-18 02:12 |
| One function in inspect can do everything we want, only not in C. How hard/inefficient would it be to have 99% of partial coded in C and one stub in functools.py? |
|
|
| msg121449 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2010-11-18 09:54 |
| > Looks like a reasonable proposal, but coding this in C is a chore. It's not that bad. Most C code is a bit of a chore compared to Python but it really doesn't take much to write a C equivalent of: "functools.partial(%r, %s)" % (self.func, ', '.join(repr(a) for a in self.args) > How hard/inefficient would it be to have 99% of partial > coded in C and one stub in functools.py? Let's not do this. There is too little benefit to warrant going down the path of splitting the code across two langauges. |
|
|
| msg121525 - (view) |
Author: Daniel Urban (daniel.urban) *  |
Date: 2010-11-19 14:47 |
| Here is a patch. It includes tests. |
|
|
| msg121533 - (view) |
Author: Alexander Belopolsky (belopolsky) * |
Date: 2010-11-19 15:23 |
| There is an ongoing discussion about deprecating undocumented PyUnicode_AppendAndDel(). See Marc-Andre's comment in : """ +.. c:function:: void PyUnicode_Append(PyObject **pleft, PyObject *right) + + Concat two strings and put the result in *pleft. Sets *pleft to + NULL on error. + +.. c:function:: void PyUnicode_AppendAndDel(PyObject **pleft, PyObject *right) + + Concat two strings and put the result in *pleft and drop the right + object. Sets *pleft to NULL on error. + + Please don't document these two obscure APIs. Instead we should make them private functions by prepending them with an underscore. If you look at the implementations of those two APIs, they are little more than a macros around PyUnicode_Concat(). 3rd party extensions should use PyUnicode_Concat() to achieve the same effect. """ While it is OK for Python library to use private APIs, please consider if PyUnicode_Concat() may be more appropriate. If not, please make a case at issue 10435 for keeping it public. |
|
|
| msg121569 - (view) |
Author: Daniel Urban (daniel.urban) * |
Date: 2010-11-19 21:20 |
| Well, of course it can be done with PyUnicode_Concat (obviously, since PyUnicode_AppendAndDel uses that). I used PyUnicode_AppendAndDel because that function does exactly what I needed. I don't see why PyUnicode_AppendAndDel should be deprecated. Anyway, here is a new patch which uses PyUnicode_Concat. |
|
|
| msg123006 - (view) |
Author: Alexander Belopolsky (belopolsky) * |
Date: 2010-12-01 20:07 |
| I simplified the partial_repr() code in issue4113b.diff and committed as r86916. I wonder, however, if for the common case of func being a named function, displaying func.__name__ or func.__module__ + '.' + func.__name__ in repr(partial) may be more apropriate than repr(f). For example, functools.partial(f, 1, 2, 3, a=5, b={}, c='7') instead of functools.partial(<function f at 0x100592d98>, 1, 2, 3, a=5, b={}, c='7') |
|
|
| msg123009 - (view) |
Author: Terry J. Reedy (terry.reedy) * |
Date: 2010-12-01 20:28 |
| I would prefer the module.name without the repr decoration. |
|
|
| msg123010 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2010-12-01 20:33 |
| I think the main purpose of repr is debugging, so I’d favor the unambiguous form (with the id) to the nice-looking one (module.name). |
|
|
| msg123011 - (view) |
Author: Alexander Belopolsky (belopolsky) * |
Date: 2010-12-01 20:36 |
| Let me close this issue before any serious bikeshedding begins. We can always reconsider when users complain that eval(repr(x)) does not work for their partial objects. |
|
|