On 9/13/2018 5:52 PM, Petr Viktorin wrote:
> On 09/13/18 14:08, Victor Stinner wrote:
>> Le jeu. 13 sept. 2018 à 16:01, Eric V. Smith <eric at trueblade.com> a
>> écrit :
>>>> * Add !t conversion to format string
>>>
>>> I'm strongly opposed to this. This !t conversion would not be widely
>>> applicable enough to be generally useful, and would need to be exposed
>>> in the f-string and str.format() documentation, even though 99% of
>>> programmers would never need or see it.
>>
>> (I'm thinking aloud.)
>>
>> In the Python code base, I found 115 lines using type(obj).__name__
>> and 228 lines using obj.__class__.__name__.
> [...]
>
> "!t" is not a big improvement over ":T" and "type(obj)".
>
>> I'm not sure if type(obj) or obj.__class__ should be used, but I can
>> say that they are different: obj.__class__ can be overriden:
> [...]
>>
>>
>> Moreover, it's also possible to override the "type" symbol in the
>> global or local scope:
> [...]
>
> I don't think either of those are problematic. If you override
> `__class__` or `type`, things will behave weirdly, and that's OK.
>
>> One advantage of having a builtin formatter would be to always use
>> internally the builtin type() function to get the type of an object,
>> or not use "type()" in the current scope. The second advantage is to
>> prevent the need of having to decide between type(obj) and
>> obj.__class__ :-)
>>
>>
>>> raise TypeError(f"must be str, not {obj!t}")
>>>
>>> Should be written as:
>>> raise TypeError(f"must be str, not {type(obj)}")
> [...]
>>
>> Do you want to modify str(type) to return a value different than
>> repr(type)?
>>
>> Or maybe it's just a typo and you wanted to write f"{type(obj):T}"?
>
> Yes, AFAIK that was a typo.
f'{type(obj)}' becomes type(obj).__format__(''), so you can return
something other than __str__ or __repr__ does. It's only by convention
that an object's __format__ returns __str__: it need not do so.
Eric
>
>>> I think "T" is a good idea, but I think you're adding in obj vs
>>> type(obj) just because of the borrowed reference issue in Py_TYPE().
>>> That issue is so much larger than string formatting the type of an
>>> object that it shouldn't be addressed here.
>>
>> Right, that's a side effect of the discussion on the C API. It seems
>> like Py_TYPE() has to go in the new C API. Sorry, the rationale is not
>> written down yet, but Dino convinced me that Py_TYPE() has to go :-)
>
> I'll be happy when we get rid of Py_TYPE and get to use moving garbage
> collectors... but now is not the time.
> The API for "%T" should be "give me the type". The best way to do that
> might change in the future.
>
>
> But at this point, we're bikeshedding. I think all the relevant voices
> have been heard.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4