This feels like a needless expansion of the API to me; I don't think I've ever encountered a use-case for this. On the rare occasions that such a use-case turns up, what's wrong with the for loop, or with adding an integer multiple of math.ulp(x) to x?

-1 from me.

I wouldn't posted the issue if I hadn't needed this, so it is not "needless".

In 30 seconds of searching, I found another example:

https://github.com/ericherman/libefloat/blob/ad606d566ac5310aabb4fff8890e35200a718e8d/tests/test-distance-64.c#L94

Python is a high level language and it is suitable to incorporate options that are more expansive than used in low level languages like C that tend to focus on atomic steps.

Sure, I don't doubt that you had a genuine need, but that need is trivially addressed with a for loop. My use of "needless" referred to the expansion of the API. You needing the functionality is not the same thing as the math module needing to support the functionality directly.

Sorry, but I don't see this use-case as valuable enough or common enough to warrant expanding the math.nextafter API.

I'm also concerned that this might be a performance trap: a user could easily write nextafter(x, y, steps=10**6) without realising that that means a million invocations of nextafter internally. With an explicit for loop, the effect on running time is much more obvious.

I concur with @mdickinson. It is too niche feature, and it is not difficult to implement a wrapper in Python. BTW, the case you found is in tests.

I wish this wasn't dismissed so casually. All uses of nextafter() are "niche". There are only a handful of people who will ever use it.

I submitted the feature request because I needed to write the replacement function in pure Python (much like the example I posted above) and it was distracting and felt amiss, like something the should have already have been built in to a higher level language.

I wrote the function while working on another problem and had casually created an incorrect result along the way:

>>> sixth_largest_random = 1.0 - 6 * ulp(1.0)
>>> sixth_largest_random
0.9999999999999987

Fortunately, I spotted the problem before going too far with it and wrote the above function giving the correct answer:

>>> sixth_largest_random = newnextafter(1.0, -inf, n=6)
>>> sixth_largest_random
0.9999999999999993

The entire side trip was distracting and annoying. It took the focus away for the error analysis I was working on at the time.

The proposal is an easy thing to do. It isn't even slightly confusing. It would be handy when needed by the few who ever use this function. I don't see any downside.

Note, in numpy and scipy, most interesting functions have many options. That seems to work well for them. But in Python, there seems to be an urge to fight against the simplest of options as "unnecessary API expansion".

@rhettinger @hauntsaninja @mdickinson

You don't need a loop for this. See this pure Python prototype inspired by an old StackOverflow question of mine.

And here's a prototype of a fix of the PR. (Please keep in mind that the C code in the PR isn't tested nor even run. The pure Python version has Hypothesis tests, so it's much more reliable.)