Hacker News Reader

Comment by bakery2k | Hacker News Reader

The Wren scripting language supports this kind of "overloading by arity" [0].

Wren therefore allows overloads such as `range(stop)` and `range(start, stop)`. This is more intuitive than Python's `range(start=0, stop)`, which might be the only function in the language that has an optional parameter before a required one.

[0] http://wren.io/method-calls.html

View on HN

> which is the only(?) function in the language that has an optional parameter before a required one.

The documentation shows it as being overloaded, rather than having default arguments:

    range(stop) -> range object
    range(start, stop[, step]) -> range object

There's iter which is overloaded:

    iter(iterable) -> iterator
    iter(callable, sentinel) -> iterator

That's the thing - it's documented as overloaded, because that's the most intuitive explanation. Wren would allow it to actually be implemented as an overloaded function.

Python doesn't support overloading, and it doesn't support optional arguments before required ones, so the actual implementation in Python is a bit messy - something like:

  def range(start_or_stop, optional_stop=None):
      if optional_stop is None:
          start = 0
          stop = start_or_stop
      else:
          start = start_or_stop
          stop = optional_stop
      ...

there is no optional positional in the implementation. range is overloaded in the raw sense of the term as the implementation checks the number of arguments and their types and does the right thing.

it could have been implemented in pure python as well by doing args, *kwargs.

Well, however the `range` function is implemented, IMO its API would be better expressed as true overloading - as two functions with the same name.

I could have sworn I have written range(1,stop) many times in Python. Did I misunderstand your argument, or has my memory gone all sideways?

    range(a) means range(start=0, end=a)
    range(a, b) means range(start=a, end=b)

`range(stop)` and `range(1, stop)` are both supported, but without overloading, the implementation of `range` is messy as it has to work out the meaning of each argument manually.

Why is that a problem? I want the standard library to contain all messy stuff so my code doesn't have to.

From the call site there's no difference between Python's optional-first-argument range() function and a hypothetical overloaded one. Any perceived complexity in usage, therefore, can be fixed with better documentation.

`range` is an example. Lack of support for overloading makes it harder to replicate its API in our own functions.

Ah right, totally misunderstood.

Yep, true. Overloading is nice.

Reply on news.ycombinator.com