<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 15 December 2017 at 19:35, Serhiy Storchaka <span dir="ltr"><<a href="mailto:storchaka@gmail.com" target="_blank">storchaka@gmail.com</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">15.12.17 20:02, Yury Selivanov пише:<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">
But nobody decorates __new__ with a @staticmethod.  And making<br>
__class_getitem__ a @classmethod will only confuse users -- that's all<br>
I'm saying.<br>
<br>
So I'm +1 to keep the things exactly as they are now.  It would be<br>
great do document that in order to implement __class_getitem__ in C<br>
one should add it as METH_STATIC.  I also think we should merge your<br>
PR that tests that it works the way it's expected.<br>
</blockquote>
<br></span>
In this case I suggest to make __class_getitem__ an automatic class method like __init_subclass__.<br>
<br>
The number of special cases bothers me.<br></blockquote><div><br></div><div>I just want to clarify what is proposed. As I understand:</div><div><br></div><div>* From the point of view of a pure Python class there will be no difference with the current behaviour, one just writes</div><div><br></div><div>      class C:</div><div>          def __class_getitem__(cls, item):</div><div>              ...</div><div><br></div><div>*  In `type_new`, `__class_getitem__` will be wrapped in classmethod</div><div>*  From the point of view of C extensions one will use METH_CLASS and no tuple unpacking</div><div><br></div><div>If this is true that this looks reasonable. If no-one is against, then I can make a PR.</div><div>The only downside to this that I see is that `type.__new__` will be slightly slower.<br></div><div></div><div></div><div><br></div><div>--</div><div>Ivan</div><div><br></div><div><br></div></div></div></div>