When one specifies a default of NULL, the generated signature doc indicates a default of None. However, if the user actually supplies None, perhaps as a placeholder in a positional-only call, C code which only checks for NULL will fail inappropriately.

The solution may be to convert a None object to a null pointer in the wrapper.

Yes, this issue bothers me. Currently _sha1.sha1 constructor will use NULL (not None) value if used without parameters: _sha1.sha1()

_sha1.sha1(None) will throw error while _sha1.sha1() won't.

So for NULL (not None) default value, the generated signature _sha1.sha1(string=None) is kinda misleading. I am not sure what is the correct signature should be without changing behaviour.

One mandate I've given myself for this project:

  When a function provides a signature, it must be 100% accurate.

A specific corollary of this:

  If you call a function, and for every optional parameter you
  explicitly pass it in with its default value from the signature,
  the result will be identical with calling the function and not
  providing that optional parameter.

So we can't lie here.

You're right that this is a general problem.  It's possible for a C function to accept a parameter that is
 * positional-or-keyword,
 * has a default value, and
 * the default value is not publishable as a Python value.
This is impossible in Python.  But Clinic only allows you to represent Python-compatible signatures.

In this *specific* case we can dodge the bullet:

    /*[clinic input]
    SHA1.SHA1
      string: object(c_default='NULL') = b''

I've realized this is basically insoluble without PEP 457, because any other solution involves changing behavior (None being silently accepted where it would previously raise an exception). If that's OK, then per-function defensive programming is probably the best idea (just emailed python-dev about this).

I didn't like the look of the ways I came up with for adding it to AC (inserting arbitrary crazycode between ParseTuple and _impl), so please close this 'wont fix' unless you really do want to do that.

Why wouldn't my suggestion work?  _sha1.sha1(b'').hexdigest() == _sha1.sha1().hexdigest().

Also: how would PEP 457 help?  PEP 457 only addresses extensions to support positional-only parameters, and the parameter in question (the "string" parameter to _sha1.sha1) is positional-or-keyword.

sha1 is Vajrasky's module. I have a much more complicated example (and Vajrasky and I just both posted on python-dev separately about this issue):

sockobj.sendmsg(buffers[, ancdata[, flags[, address]]])
->
sockobj.sendmsg(buffers, ancdata=None, flags=0, address=None)

Here ancdata wants an iterator and address a tuple, and the existing function expects NULL when these are absent. This is what we've been indirectly discussing via email as well.

Aaand I just realized that I should set py_default to []?

No, that still leaves address broken since neither None nor an empty tuple are acceptable.

Definitely not [].  At the very least ().

I'd appreciate it if you'd stop abruptly changing the subject.  I thought we were talking about SHA1_new, but now you're talking about "address" and "sockobj.sendmsg".  If you have specific cases you'd like to discuss, post them and maybe we can find a workaround.  If you want to discuss the general problem, I guess now we want to have that discussion on python-dev.

After all our discussions I'm closing this with resolution "don't do that then".