[issue4113] Add custom __repr__ to functools.partial
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
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')
--
resolution: - accepted
stage: needs patch - committed/rejected
status: open - pending
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4113
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4113] Add custom __repr__ to functools.partial
Terry J. Reedy tjre...@udel.edu added the comment: I would prefer the module.name without the repr decoration. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4113 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4113] Add custom __repr__ to functools.partial
Éric Araujo mer...@netwok.org added the comment: 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). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4113 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4113] Add custom __repr__ to functools.partial
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: 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. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4113 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4113] Add custom __repr__ to functools.partial
Daniel Urban urban.dani...@gmail.com added the comment: 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. -- Added file: http://bugs.python.org/file19643/issue4113b.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4113 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4113] Add custom __repr__ to functools.partial
Daniel Urban urban.dani...@gmail.com added the comment: Here is a patch. It includes tests. -- keywords: +patch nosy: +durban Added file: http://bugs.python.org/file19637/issue4113.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4113 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4113] Add custom __repr__ to functools.partial
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: There is an ongoing discussion about deprecating undocumented PyUnicode_AppendAndDel(). See Marc-Andre's comment in msg121371: +.. 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. -- assignee: - belopolsky nosy: +lemburg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4113 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4113] Add custom __repr__ to functools.partial
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: 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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4113 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4113] Add custom __repr__ to functools.partial
Éric Araujo mer...@netwok.org added the comment: 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? -- nosy: +eric.araujo, rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4113 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4113] Add custom __repr__ to functools.partial
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: 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.) -- keywords: +easy -patch nosy: +belopolsky stage: - needs patch title: functools.partial(), no __name__; wrong __doc__ - Add custom __repr__ to functools.partial ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4113 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4113] Add custom __repr__ to functools.partial
Changes by Alexander Belopolsky belopol...@users.sourceforge.net: -- versions: +Python 3.2 -Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4113 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
