[Types-sig] Keyword arg declarations

[Tim Peters]

[David Ascher]
> ...
> An example of such a signature is familiar to all is the signature for
> range().  The docstring for range reads:
>
> range([start,] stop[, step]) -> list of integers
>
> which is not expressible with the current syntax.  A Python
> version of range would have to do, much like NumPy's arange does,
>
> def range(start, stop=None, step=1):
>     if (stop == None):
>         stop = start
>         start = 0

Or whrandom's funkier:

	def randrange(self, start, stop=None, step=1,
		      # Do not supply the following arguments
		      int=int, default=None):

> Now, the builtin typechecker can of course be told about
> __builtin__.range's signature peculiarities, but is there
> any way we can address the more general problem?  Or is it,
> as I suspect, rare enough that one can ignore it?

I suggest you're wrestling with an illusion here:  Python *internally* has
no such form of argument list as

     range([start,] stop[, step])

This is, that's just the way the *doc* is written, to make it clearer.
bltinmodule.c's builtin_range analyzes the snot out of the arglist, much
like the Python versions do.  A clue that the doc makes no actual sense
<wink> is that it apparently allows expressing a stop and step without a
start.

Everything the builtin truly requires can be captured via the declaration

    decl range: def(Int, =Int, =Int) -> [Int]

using =Type notation for optional arguments that are not also keyword
arguments.  If the builtin also accepted these as keyword arguments, this
could be expressed as (dropping my customary "|" in favor of GregS's "or"):

    decl range: def(stop: Int) -> [Int] or   \
                def(start: Int, stop: Int, step=:Int) -> [Int]

using name=:Type notation for an optional keyword argument.

An alternative is to change the docs to match what actually happens.

but-no-need-for-extremes<wink>-ly y'rs  - tim