Get "super(): no arguments" error in one case but not a similar case
<pre><code>class Works(type):
    def __new__(cls, *args, **kwargs):
        print([cls,args]) # outputs [&lt;class '__main__.Works'&gt;, ()]
        return super().__new__(cls, args)

class DoesNotWork(type):
    def __new__(*args, **kwargs):
        print([args[0],args[:0]]) # outputs [&lt;class '__main__.doesNotWork'&gt;, ()]
        return super().__new__(args[0], args[:0])

Works() # is fine
DoesNotWork() # gets "RuntimeError: super(): no arguments"
</code></pre>

<p>As far as I can see, in both cases super._new__ receives the class literal as first argument, and an empty tuple as the 2nd.</p>

<p>So why does one give an error and the other not?</p>

<p>The zero-argument form of <code>super</code> requires that the method containing it have an explicit (i.e., non-varargs) first argument.  This is suggested by <a href="https://docs.python.org/3.1/library/functions.html?#super" rel="nofollow">an older version of the docs</a> (emphasis added):</p>

<blockquote>
  <p>The zero argument form automatically searches the stack frame for the class (<code>__class__</code>) <strong>and the first argument</strong>.</p>
</blockquote>

<p>For some reason this note was removed in later versions of the docs.  (It might be worth raising a doc bug, because the docs are quite vague about how zero-argument <code>super</code> works and what is required for it to work.)</p>

<p>See also <a href="https://bugs.python.org/issue15753" rel="nofollow">this Python bug report</a> (which is unresolved, and not clearly accepted as even a bug).  The upshot is that zero-argument <code>super</code> is magic, and that magic fails in some cases.  As suggested in the bug report, if you want to accept only varargs, you'll need to use the explicit two-argument form of <code>super</code>.</p>

python super