Showing content from http://mail.python.org/pipermail/python-dev/attachments/20171120/7c7a8962/attachment.html below:
<div dir="ltr">Mark, with that comment now added to the PEP, are you satisfied? <a href="https://github.com/python/peps/pull/479">https://github.com/python/peps/pull/479</a><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 20, 2017 at 12:32 PM, Ivan Levkivskyi <span dir="ltr"><<a href="mailto:levkivskyi@gmail.com" target="_blank">levkivskyi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">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></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
On 19/11/17 22:36, Ivan Levkivskyi wrote:</span><span class=""><span class="m_-4600715778135903531gmail-"><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><span class="m_-4600715778135903531gmail-"><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="m_-4600715778135903531gmail-"><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="m_-4600715778135903531gmail-">
<br></span>
Could you elaborate?<span class="m_-4600715778135903531gmail-"><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><span class=""><div></div><div>Â <span class="m_-4600715778135903531gmail-"></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="m_-4600715778135903531gmail-"><br></span></blockquote><div><br></div></span><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><span class=""><div>Â Â Â @Generic[T]</div><div>Â Â Â class C:</div><div>Â Â Â Â Â Â Â ...</div><div><br></div></span><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><span class=""><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="m_-4600715778135903531gmail-"><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></span><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>
<br>______________________________<wbr>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/options/python-dev/<wbr>guido%40python.org</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</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