On 25.02.15 12:25, Steven D'Aprano wrote:

On Wed, Feb 25, 2015 at 10:12:03AM +0200, Serhiy Storchaka wrote:

...

What if change default reprs of classes and functions to just full qualified name __module__ + '.' + __qualname__ (or just __qualname__ if __module__ is builtins)? This will look more neatly. And such reprs are evaluable.

Do you mean like this?

repr(int) => 'int'

repr(int.from_bytes) => 'int.from_bytes'

Yes, it is.

-1 on that idea.

The suggested repr gives no clue as to what kind of object they are. Are they functions, methods, classes, some kind of Enum-like constant or something special like None? That hurts the usefulness of object reprs at the interactive interpreter. And it leads to weirdness like this:

def spam(x): if not isinstance(x, int): raise TypeError('expected int, got %r' % x)

This is uncommon case and bugprone code. Don't write so. spam('x'*1000000) or spam(()) will produce unhelpful error messages. Usually it is written as: def spam(x): if not isinstance(x, int): raise TypeError('expected int, got %s' % type(x).__name__)

On Feb 25, 2015, at 8:21, Guido van Rossum wrote:

A variant I've often wanted is to make str() return the "clean" type only (e.g. 'int') while leaving repr() alone -- this would address most problems Steven brought up.

On further thought, I'm not sure backward compatibility can be dismissed. Surely code shouldn't care about the str of a callable, right? But yeah, sometimes it might care, if it's, say, a reflective framework for bridging or debugging or similar. I once wrote a library that exposed Python objects over AppleEvents. I needed to know all the bound methods of the object. For pure-Python objects, this is easy, but for builtin/extension objects, the bound methods constructed from both slot-wrapper and method-descriptor are of type method-wrapper. (The bug turned up when an obscure corner of our code that tried lxml, cElementTree, then ElementTree was run on a 2.x system without lxml installed, something we'd left out of the test matrix for that module.) When you print out the method, it's obvious what type it is. But how do you deal with it programmatically? Despite what the docs say, method-descriptor does not return true for either isbuiltin or isroutine. In fact, nothing in inspect is much help. And the type isn't in types. Printing out the method, it's dead obvious what it is. As it turned out, callable(x) and (hasattr(x, 'im_self') or hasattr(x, '__self__')) was good enough for my particular use case, at least in all Python interpreters/versions we supported (it even works in PyPy with CPyExt extension types and an early version of NumPyPy). But what would a good general solution be? I think dynamically constructing the type from int().__add__ and then verifying that all extension types in all interpreters and versions I care about pass isinstance(that) unless they look like pure-Python bound methods might be the best way. And even if I did resort to using the string representation, I'd probably use the repr rather than the str, and I'd probably look at type(x) rather than x itself. But still, I can imagine someone deciding "whatever I do is going to be hacky, because there's no non-hacky way to get this information, so I might as well go with the simplest hack that's worked on every CPython and PyPy version from 2.2 to today" and use "... or str(x).startswith('

On Wed, Feb 25, 2015 at 12:12 AM, Serhiy Storchaka wrote:

...

This idea is already casually mentioned, but sank deep into the threads of the discussion. Raise it up.

Currently reprs of classes and functions look as:

...

...

...

int int.from_bytes open <built-in function open> import collections collections.Counter collections.Counter.fromkeys > collections.namedtuple

What if change default reprs of classes and functions to just full qualified name __module__ + '.' + __qualname__ (or just __qualname__ if __module__ is builtins)? This will look more neatly. And such reprs are evaluable.

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

I plan on committing http://bugs.python.org/issue13224 tomorrowish (the patch is a little stale and I want to poke around some to be sure its ok). If anyone objects please follow up in the issue. -Rob On 26 February 2015 at 16:28, Guido van Rossum wrote:

I didn't read all that, but my use case is that for typing.py (PEP 484) I want "nice" reprs for higher-order classes, and if str(int) returned just 'int' it would be much simpler to e.g. make the str() or repr() of Optional[int] return "Optional[int]". I've sort of solved this already in https://github.com/ambv/typehinting/blob/master/prototyping/typing.py, but it would still be nice if I didn't have to work so hard at it.

On Wed, Feb 25, 2015 at 5:41 PM, Andrew Barnert wrote:

...

On Feb 25, 2015, at 8:21, Guido van Rossum wrote:

A variant I've often wanted is to make str() return the "clean" type only (e.g. 'int') while leaving repr() alone -- this would address most problems Steven brought up.

On further thought, I'm not sure backward compatibility can be dismissed. Surely code shouldn't care about the str of a callable, right? But yeah, sometimes it might care, if it's, say, a reflective framework for bridging or debugging or similar.

I once wrote a library that exposed Python objects over AppleEvents. I needed to know all the bound methods of the object. For pure-Python objects, this is easy, but for builtin/extension objects, the bound methods constructed from both slot-wrapper and method-descriptor are of type method-wrapper. (The bug turned up when an obscure corner of our code that tried lxml, cElementTree, then ElementTree was run on a 2.x system without lxml installed, something we'd left out of the test matrix for that module.)

When you print out the method, it's obvious what type it is. But how do you deal with it programmatically? Despite what the docs say, method-descriptor does not return true for either isbuiltin or isroutine. In fact, nothing in inspect is much help. And the type isn't in types. Printing out the method, it's dead obvious what it is.

As it turned out, callable(x) and (hasattr(x, 'im_self') or hasattr(x, '__self__')) was good enough for my particular use case, at least in all Python interpreters/versions we supported (it even works in PyPy with CPyExt extension types and an early version of NumPyPy). But what would a good general solution be?

I think dynamically constructing the type from int().__add__ and then verifying that all extension types in all interpreters and versions I care about pass isinstance(that) unless they look like pure-Python bound methods might be the best way. And even if I did resort to using the string representation, I'd probably use the repr rather than the str, and I'd probably look at type(x) rather than x itself. But still, I can imagine someone deciding "whatever I do is going to be hacky, because there's no non-hacky way to get this information, so I might as well go with the simplest hack that's worked on every CPython and PyPy version from 2.2 to today" and use "... or str(x).startswith('

On Wed, Feb 25, 2015 at 12:12 AM, Serhiy Storchaka wrote:

...

This idea is already casually mentioned, but sank deep into the threads of the discussion. Raise it up.

Currently reprs of classes and functions look as:

...

...

...

int int.from_bytes open <built-in function open> import collections collections.Counter collections.Counter.fromkeys > collections.namedtuple

What if change default reprs of classes and functions to just full qualified name __module__ + '.' + __qualname__ (or just __qualname__ if __module__ is builtins)? This will look more neatly. And such reprs are evaluable.

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido van Rossum (python.org/~guido)

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido van Rossum (python.org/~guido)

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

-- Robert Collins Distinguished Technologist HP Converged Cloud