Number.range(to) equals Number.range(0, to)

[littledan]

I saw this raised as a question in the README, but couldn't find an issue about it.

Personally, I like the idea of supporting the Number.range(to) form. It's common in other languages and will be common in JS; I think it's quite unambiguous.

(Related discussion: #14)

[devsnek]

I think we should require both arguments. Being explicit seems strictly better to me.

[bakkot]

Python works like this, and its range is one of the most common operations in the language and this point does not seem to cause confusion. If we want to do something different I think there should need to be a very, very good reason; otherwise we should just do what they do.

[jridgewell]

I also like range(to). But as long as we don't do the implicit Infinity upper bound in #14, I don't care. I have never actually wanted to count to infinity…

[erights]

I have never actually wanted to count to infinity…

As a child, I wanted to but was never able to. I just never had the patience.

[devsnek]

We have an issue that says Number.range(to) should be a thing and an issue that says Number.range(from) should be a thing. Some group of humans are going to end up being continuously wrong in their assumptions if we choose one, so I think the reasonable conclusion is that we require the start and the end.

[bakkot]

It is generally impossible to design APIs such that no group of humans will ever end up being confused. The fact that Python has been using these semantics for many years without many people tripping over this shows that not all that many people will be confused, I think rather conclusively.

[devsnek]

Impossible yes, but we can at least try not to make it worse, right?

[Jack-Works]

I also like range(to). But as long as we don't do the implicit Infinity upper bound in #14, I don't care. I have never actually wanted to count to infinity…

One of the possible use case of that is you use the infinity sequence as a source of real numbers and you filter some out to generate another sequence of infinity numbers

[bakkot]

I do not think that copying the semantics of one of the most widely-used operations in one of the most widely-used languages, which causes very little evident confusion there, will make it perceptibly worse.

[ljharb]

That seems to assume that the sensibilities and intuition of Python users will overlap with that of JS users, which I don't think is necessarily true.

[devsnek]

I would say that python has done a great many things right and a great many things wrong (much like we have), and that arguing about which things go in which category is probably not a great way to make our decisions. If there are concrete usability concerns about requiring both arguments I would be more interested in discussing those instead.

[jridgewell]

The up-to range is well established even before Python: https://leancrew.com/all-this/2019/09/making-lists-with-jot-and-seq/.

[tabatkins]

I don't suspect that Pythonistas and JSers have a substantially different intuition, as a class, for whether a single-argument range counts to that number from 0 or from that number to infinity. ^_^ In particular, both languages have the same very common use-case of "enumerate all the indexes of a list of length N" which is done by "count to", whereas I've rarely encountered situations where I needed an infinitely-incrementing range. (Not never; I know of one spot in my code where I'm doing exactly that, but I'm using itertools.count() for it, and reaching for itertools for an infinite iterator felt like the intuitively right choice vs the base built-in.)

I'll say that I've used the Python range syntax without problem before, and my personal range() function in JS works this way as well. I also suspect that it's safer/better, given a reasonably even choice between creating a finite and infinite iterator, to choose the finite one, and require an author to be more explicit about wanting an infinite iterator.

[devsnek]

We could also just require them to be explicit about both. I really don't understand why we want to make guesses about what people are trying to do.

[bakkot]

I'm not trying to argue about whether Python's design is good or bad. I'm making a more specific argument: the usual reason to prefer being more verbose is to avoid confusing people, but the millions of Python users of the less verbose design who are not confused by it is very good evidence that it is not going to confuse many people.

If there is some other reason to prefer to be more verbose, great, we should talk about that. I'm not saying Python's design is necessarily good. But I do think it means we can safely say that the less verbose design is not going to be unduly confusing.

(Also, precedent from other languages has weight on its own, in proportion to how common those languages and the portions of them which we're duplicating are.)

Edit to add:

We could also just require them to be explicit about both. I really don't understand why we want to make guesses about what people are trying to do.

We could further require them to be explicit about step = 1, so as to avoid making guesses about their intent there. Do you think we should do so? The reason not to is the same as the reason not to require from = 0 - there's a very common case which is thereby made simpler without introducing much complexity to the API.