Showing content from http://mail.python.org/pipermail/python-dev/attachments/20171120/86c542dc/attachment.html below:
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 20 November 2017 at 10:22, Mark Shannon <span dir="ltr"><<a href="mailto:mark@hotpy.org" target="_blank">mark@hotpy.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 19/11/17 22:36, Ivan Levkivskyi wrote:<span class="gmail-"><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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).<br>
</blockquote>
</span><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In fact, I initially implemented type.__getitem__, but I didn't like it for various reasons.</blockquote></span><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote></span><span class="gmail-">
<br></span>
Could you elaborate?<span class="gmail-"><br></span></blockquote><div><br></div><div>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,</div><div>I don't want to make it even longer. Maybe there were other reasons that I forgot.</div><div><br></div><div>Anyway, I propose to stop here, since this is not about the PEP, this is about implementation.</div><div>This is a topic of a separate discussion.<br></div><div></div><div>Â <span class="gmail-"></span><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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,</blockquote><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">but a few minor hurdles are acceptable to keep the rest of the language (including more common uses of type-hints) clean.<span class="gmail-"><br></span></blockquote><div><br></div><div>This essentially means changing decisions already made in PEP 484 and not a topic of this PEP.</div><div>Also,</div><div><br></div><div><div>Â Â Â @Generic[T]</div><div>Â Â Â class C:</div><div>Â Â Â Â Â Â Â ...</div><div><br></div><div>is currently a syntax error (only names and function calls are allowed in a decorator).</div></div><div>Finally, it is too late to change how generics are declared, since it will break<br></div><div>existing code.<br></div><div></div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  Should `isinstance` and `issubclass` call `__mro_entries__` before<br>
  raising an error if the second argument is not a class?<br>
  In other words, if `List` implements `__mro_entries__` to return<br>
  `list` then should `issubclass(x, List)` act like `issubclass(x, list)`?<br>
  (IMO, it shouldn't) The reasoning behind this decision should be<br>
  made explicit in the PEP.<br>
<br>
<br>
I think this is orthogonal to the PEP. There are many situations where a class is expected,<br>
and IMO it is clear that all that are not mentioned in the PEP stay unchanged.<br>
</blockquote>
<br></span>
Indeed, but you do mention issubclass in the PEP. I think a few extra words of explanation would be helpful.<br></blockquote><div><br></div><div>OK, I will add a comment to the PEP.</div><div><br></div><div>--</div><div>Ivan</div><div><br></div><div><br></div></div></div></div>
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