Could we deprecate passing a single id to ORM methods

I agree with this. We should make it clear. Support this feature, or don't support it. It's better than having an incoherent API, imo.

The present situation is indeed something we want to change.

But some details about what you propose, or given in the linked mailing list thread, are not right to me. The mail says that some methods are changed to accept a single id *instead* of a list of ids. The example commit doesn't say that. The real purpose of the commit is to bring a uniform API: accept *both* forms: either a single id, or a list of ids.

The fact is that the de facto API is to allow both. So this uniformity is brought back to some methods because there is no real reason to favor one or the other form for those methods.

It is clear for a large part of the community and core developers that allowing both form was a mistake. But having something uniform, without braking existing code was deemed more important than changing things. I don't think that we have an incoherent API, or that this flexibility is hardly used. But indeed it is an unfortunate flexibility and make the code harder to read and write than necessary.

One of the good reasons to think the situation is bad, is that in some situation, there is no reason to allow a list of ids, and thus the API seems inconsistent.

We do plan to change the situation. It is planned to bring a new API (in a broader sense, not just this id vs ids problem) and we will make sure to make clear when methods accept a single id or a list of ids, and that they don't accept both (i.e. most of the methods will only accept a list of ids, and when necessary, some will only accept a single id). The argument names will thus be in sync with the actual accepted argument types.

I suppose your are talking, for example, of on_change methods which take ids whereas you can't trigger an on_change on multiple ids ;-)

Do you plan to integrate the new API in 6.1 ? I saw good changes in that way (use of metaclass, etc). I hope you will continue this way.

More specifically, I was initially thinking of write() and unlink(): nobody seems to know they should accept ints.
But Vo Minh Thu is right, a broader reflexion is always a better move when changing an API.