<div dir="ltr">On 15 December 2017 at 17:47, Yury Selivanov <span dir="ltr"><<a href="mailto:yselivanov.ml@gmail.com" target="_blank">yselivanov.ml@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Shouldn't we optimize the usability for pure-Python first, and then for C API?<br>
<br>
Right now we have the '__new__' magic method, which isn't a<br>
@classmethod.  Making '__class_getitem__' a @classmethod will confuse<br>
regular Python users.  For example:<br>
<br>
   class Foo:<br>
      def __new__(cls, ...): pass<br>
<br>
      @classmethod<br>
      def __class_getitem__(cls, item): pass<br>
<br>
To me it makes sense that type methods that are supposed to be called<br>
on type by the Python interpreter don't need the classmethod<br>
decorator.<br></blockquote><div><br></div><div>Good point! Pure Python will be the primary use case and we have another precedent</div><div>for "automatic" class method: __init_subclass__ (it does not need to be decorated).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
METH_STATIC is a public working API, and in my opinion it's totally<br>
fine if we use it. It's not even hard to use it, it's just *mildly*<br>
inconvenient at most<font color="#888888">.</font><span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>OK, then documenting this "recipe" (METH_STATIC plus tuple unpacking) should be sufficient.</div><div><br></div><div>--</div><div>Ivan</div><div><br></div><div><br></div></div></div></div>