(original) (raw)

On 20 November 2017 at 10:22, Mark Shannon <mark@hotpy.org> wrote:

On 19/11/17 22:36, Ivan Levkivskyi wrote:

Except that there is no such thing as object.\_getitem\_\_. Probably you mean PyObject\_GetItem (which is just what is done by BINARY\_SUBSCR opcode).

In fact, I initially implemented type.\_\_getitem\_\_, but I didn't like it for various reasons.

Could you elaborate?

I didn't like that although type.\_\_getitem\_\_ would exist, it would almost always raise, which can be confusing. Also dir(type) is already long,

I don't want to make it even longer. Maybe there were other reasons that I forgot.

Anyway, I propose to stop here, since this is not about the PEP, this is about implementation.

This is a topic of a separate discussion.

Given the power and flexibility of the built-in data structures, defining custom containers is relatively rare. I'm not saying that it should not be considered,

but a few minor hurdles are acceptable to keep the rest of the language (including more common uses of type-hints) clean.

This essentially means changing decisions already made in PEP 484 and not a topic of this PEP.

Also,

@Generic\[T\]

class C:

...

is currently a syntax error (only names and function calls are allowed in a decorator).

Finally, it is too late to change how generics are declared, since it will break

existing code.

Should \`isinstance\` and \`issubclass\` call \`\_\_mro\_entries\_\_\` before
raising an error if the second argument is not a class?
In other words, if \`List\` implements \`\_\_mro\_entries\_\_\` to return
\`list\` then should \`issubclass(x, List)\` act like \`issubclass(x, list)\`?
(IMO, it shouldn't) The reasoning behind this decision should be
made explicit in the PEP.

I think this is orthogonal to the PEP. There are many situations where a class is expected,
and IMO it is clear that all that are not mentioned in the PEP stay unchanged.

Indeed, but you do mention issubclass in the PEP. I think a few extra words of explanation would be helpful.

OK, I will add a comment to the PEP.

Ivan