[Python-Dev] AC Derby and accepting None for optional positional arguments

[Ryan Smith-Roberts]

Let me expand on the issue, and address some of the replies.

The goal of Argument Clinic is to create new docstring signatures for
builtins, with the following properties:

1) Useful. While one can create a signature of func(*args) and then
document complex and arbitrary restrictions on what args contains, that
isn't helpful to the end-user examining the docstring, or to automated
tools.

2) Inspectable. For a signature to be compatible with inspect.signature(),
it *must be a valid native Python declaration*. This means no optional
positional arguments of the form func(foo[, bar]), and no non-Python
default values.

3) Correct. The semantics of the builtin's signature should match the
expectations users have about pure Python declarations.

There are two classes of builtins whose signatures do not have these
properties. The first is those with very weird signatures, like
curses.window.addstr(). It's fine that those don't get converted, they're
hopeless. A second class is builtins with "almost but not quite" usable
signatures, mostly the ones with optional positional parameters. It would
be nice to "rescue" those builtins. So, let us return to my original
example, getservbyname(). Its current signature:

socket.getservbyname(servicename[, protocolname])

This is not an inspectable signature, since pure Python does not support
bracketed arguments. To make it inspectable, we must give protocolname a
(valid Python) default value:

socket.getservbyname(servicename, protocolname=None)

Unfortunately, while useful and inspectable, this signature is not correct.
For a pure Python function, passing None for protocolname is the same as
omitting it. However, if you pass None to getservbyname(), it raises a
TypeError. So, we have these three options:

1) Don't give getservbyname() an inspectable signature.
2) Lie to the user about the acceptability of None.
3) Alter the semantics of getservbyname() to treat None as equivalent to
omitting protocolname.

Obviously #2 is out. My question: is #3 ever acceptable? It's a real
change, as it breaks any code that relies on the TypeError exception.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140116/db5f6752/attachment.html>