On 28 Dec 2020, at 14:00, Inada Naoki
wrote: On Mon, Dec 28, 2020 at 8:52 PM Phil Thompson
wrote: I would have thought that an object was defined by its behaviour rather than by any particular implementation detail.
As my understanding, the policy "an object was defined by its behavior..." doesn't mean "put unlimited amount of implementation behind one concrete type." The policy means APIs shouldn't limit input to one concrete type without a reason. In other words, duck typing and structural subtyping are good.
For example, we can try making io.TextIOWrapper accepts not only Unicode objects (including subclass) but any objects implementing some protocol. We already have __index__ for integers and buffer protocol for byts-like objects. That is examples of the policy.
I agree that that would be the cleanest approach, although I worry about how long it will take until 3th-party code is converted to the new protocol. That’s why I wrote earlier that adding this feature to PyUnicode_Type is the most pragmantic solution ;-) There are two clear options for a new protocol: 1. Add something similar to __index__ of __fspath__, but for “string-like” objects 2. Add an extension to the buffer protocol In either case an ABC for string-like objects would also be nice, to be able to opt in to the fairly common pattern of excluding strings from types that can be iterated over, that is: if isinstance(value, collections.abc.Iterable) and not isinstance(value, str): for item in value: proces_item(item) else: process_item(value) Ronald — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ https://blog.ronaldoussoren.net/