But the predominant concern in a lot of porting efforts is interoperability with developers who are already familiar with the current API. Porting the API to feel very Rusty would be a mistake when your audience is people who already know the Python API. Python itself has adopted some decidedly non-pythonic APIs for the same reason.
In the Python world if this bothers you you're supposed to use the adapter pattern to Pythonify the mechanically ported API.
I would first start by asking - why am I porting an identical API? Why am I not going back to first principles and rethinking from ground zero? Usually there is a compelling reason to switch from A to B, likely for performance in this case (going from py -> rust). Any programmer worth a salt knows that nothing in life is free - and everything has a tradeoff. In this case the tradeoff (should) be that the API might change, but the performance benefits will be worhtwhile.
For instance - lets look at sequential operations against a DB versus batches. In a sequential style, you might iterate your items and just write them one by one. Alternatively, in a batched style you might need to do things like prepare queries or store your queries alongside the actual data values, then hand it all to a batch mechanism that will perform the write. The ergonomics are completely different but at the end of the day the result (rows in the table) will be the same. So even in the same language you will see totally different ways to go about solving the same problem. This is why I do not really see this as a python/rust argument and more of a generic program architecture argument.
In the above db case - the programmer isn't disappointed that they need to rewrite their iterative loop approach because the know that the batching approach is going to be much faster and will achieve their goals.
I think the same parallel can be drawn here: it is not a bad thing to have a slightly different API. Especially in the context of going from a dynamic language to one that is compiled and more performant.
All of this is kind of a moot point though because the Rust lib in question doesn't have any instructions/documentation or design docs so it is hard to say for certain what the intention is here other than a port for the sake of porting.
Mentioned this briefly below, but this was largely an academic exercise: there is a lot of existing code written (in python) against the python API in question, and I was curious to see how feasible it would be to reimplement that API in such a way that this existing code would continue to work with minimal modification, but now running on top of a rust implementation.
What's additionally challenging in this case is that the design of the underlying rust API (the norad crate[1]) was also more or less done, so this really was just a matter of trying to shim.
In any case, I think we more or less agree; just trying to provide a bit more background on the motivation. This was originally just circulated as a gist between a few interested parties, who were largely familiar with the motivations; it certainly didn't occur to me that it might be interesting to a general audience.
Arguably you'd want to write in idiomatic style for the ecosystem you're working in. It doesn't help when the standard library plus any other libraries you're using offer rusty apis and this one library is pythonic.
> interoperability with developers who are already familiar
I wouldn't say it's "predominant". Some instances are code authors trying to bring their library to new audiences (c/c++ frameworks with multiple language bindings), or developers unfamiliar with the language but want that specific API in their own (Python's requests library is a great example, cloned in many languages now).
In the Python world if this bothers you you're supposed to use the adapter pattern to Pythonify the mechanically ported API.