Re: [Python-Dev] How long the wrong type of argument should we limit (or not) in the error message (C-api)?
On 15.12.13 17:33, Ethan Furman wrote:
On 12/14/2013 07:51 PM, Steven D'Aprano wrote:
On Sun, Dec 15, 2013 at 11:25:10AM +1000, Nick Coghlan wrote:
Oh, yes, a %T shortcut for "length limited type name of the supplied
object" would be brilliant. We need this frequently for C level error
messages, and I almost always have to look at an existing example to
remember the exact incantation :)
What are the chances that could be made available from pure Python too?
Having to extract the name of the type is a very common need for error
messages, and I never know whether I ought to write type(obj).__name__
or obj.__class__.__name__. A %T and/or {:T} format code could be the One
Obvious Way to include the type name in strings
+1
I'd vote for including the module name in the string and using
__qualname__ instead of __name__, i.e. make "{:T}".format(obj)
equivalent to
"{0.__class__.__module__}.{0.__class__.qualname__}".format(obj).
Servus,
Walter
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How long the wrong type of argument should we limit (or not) in the error message (C-api)?
On 12/16/2013 10:29 AM, Walter Dörwald wrote:
> I'd vote for including the module name in the string and using
> __qualname__ instead of __name__, i.e. make "{:T}".format(obj)
> equivalent to
> "{0.__class__.__module__}.{0.__class__.qualname__}".format(obj).
That's not possible in general. The format specifier interpretation is
done by each type. So, you could add this to str.__format__ and
int.__format__, but you can't add it to an arbitrary type's __format__.
For example, types not in the stdlib would never know about it.
There's no logic for calling through to object.__format__ for unknown
specifiers. Look at datetime, for example. It uses strftime, so "T"
currently just prints a literal "T".
And for object.__format__, we recently made it an error to specify any
format string. This is to prevent you from calling
format(an_object, ".30")
and "knowning" that it's interpreted by str.__format__ (because that's
the default conversion for object.__format__). If in the future
an_object's class added its own __format__, this code would break (or at
least do the wrong thing).
But I really do like the idea! Maybe there's a way to just make
obj.__class__ recognize "T", so you could at least do:
format(obj.__class__, "T")
or equivalently:
"{:T}".format(obj.__class__)
I realize that having to use .__class__ defeats some of the beauty of
this scheme.
Eric.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How long the wrong type of argument should we limit (or not) in the error message (C-api)?
On 17 Dec 2013 02:23, "Eric V. Smith" wrote:
>
> On 12/16/2013 10:29 AM, Walter Dörwald wrote:
> > I'd vote for including the module name in the string and using
> > __qualname__ instead of __name__, i.e. make "{:T}".format(obj)
> > equivalent to
> > "{0.__class__.__module__}.{0.__class__.qualname__}".format(obj).
>
> That's not possible in general. The format specifier interpretation is
> done by each type. So, you could add this to str.__format__ and
> int.__format__, but you can't add it to an arbitrary type's __format__.
> For example, types not in the stdlib would never know about it.
That just suggests it would need to be a type coercion code, like !a, !r,
and !s. However, that observation also suggests that starting with a
"classname" or "typename" builtin would be more appropriate than jumping
directly to a formatting code.
We've definitely drifted well into python-ideas territory at this point,
though :)
Cheers,
Nick.
>
> There's no logic for calling through to object.__format__ for unknown
> specifiers. Look at datetime, for example. It uses strftime, so "T"
> currently just prints a literal "T".
>
> And for object.__format__, we recently made it an error to specify any
> format string. This is to prevent you from calling
> format(an_object, ".30")
> and "knowning" that it's interpreted by str.__format__ (because that's
> the default conversion for object.__format__). If in the future
> an_object's class added its own __format__, this code would break (or at
> least do the wrong thing).
>
> But I really do like the idea! Maybe there's a way to just make
> obj.__class__ recognize "T", so you could at least do:
> format(obj.__class__, "T")
> or equivalently:
> "{:T}".format(obj.__class__)
>
> I realize that having to use .__class__ defeats some of the beauty of
> this scheme.
>
> Eric.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
