Mark, with that comment now added to the PEP, are you satisfied? https://github.com/python/peps/pull/479
On Mon, Nov 20, 2017 at 12:32 PM, Ivan Levkivskyi <levkivs...@gmail.com> wrote: > On 20 November 2017 at 10:22, Mark Shannon <m...@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 > > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > guido%40python.org > > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com