On 28 Dec 2020, at 14:00, Inada Naoki <songofacandy@gmail.com> wrote:

On Mon, Dec 28, 2020 at 8:52 PM Phil Thompson
<phil@riverbankcomputing.com> 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/