STINNER Victor <[email protected]> added the comment:
> I think we need to handle only two cases: short and fully qualified names.
> __qualname__ without __module__ doesn't make sense, and the value of tp_name
> depends on implementation details (is it Python class or builtin class, heap
> class or dynamic class?). Maybe use %t and %T?
Ok, I wrote PR 9122 to add %t format and modify %T format:
* %t <=> type(obj).__name__
* %T <=> f"{type(obj).__module__}.{type(obj).__qualname__}"
> But we may want to support formatting the name of the type itself and the
> name of the object's type. This give us 4 variants.
Again, I'm not sure about these ones. _PyType_Name() can be used for %t-like
directly on a type. Later we can expose _PyType_FullName() (function that I
added in my latest PR) as a private function for %T-like directly on a type.
> For old string formatting we can introduce new % codes (with possible
> modifiers). But in modern string formatting "T" can have meaning for some
> types (e.g. for datetime). We can implement __format__ for the type type
> itself (though it can cause confusion if cls.__format__() is different from
> cls.__format__(instance)), but for formatting the name of the object's type
> (as in your original proposition) we need to add a new conversion flag like
> "!r".
I'm not sure that I understood directly.
Do you want to add a third formatter in PyUnicode_FromFormat() which would use
Py_TYPE(obj)->tp_name? I dislike Py_TYPE(obj)->tp_name, since my intent is to
conform to the PEP 399: tp_name is not accessible at the Python level, only
type(obj).__name__ and type(obj).__qualname__.
Or do you want to add a new formatter to type.__format__() to expose %T at the
Python level, f"{type(obj).__module__}.{type(obj).__qualname__}"?
Currently, type(obj).__name__ is the most popular way to format a string. Would
it break the backward compatibility to modify *existing* error messages?
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue34595>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
