Your "fix" doesn't make sense. I'm looking at this from the perspective of a dev that's looking at OP's code for the first time. You're telling me that I have to sift through the codebase (which I might not even have complete access to) to figure out the argument order of a poorly named entity, just so that I can go and add keyword arguments to each place I work with ORM code?

So now you have me going and editing tested, working code just for my personal preference and digging through code that I may or may not be authorized to view. Do you have any other best practices to share?

> Your "fix" doesn't make sense. I'm looking at this from the perspective of a dev that's looking at OP's code for the first time. You're telling me that I have to sift through the codebase (which I might not even have complete access to) to figure out the argument order of a poorly named entity, just so that I can go and add keyword arguments to each place I work with ORM code?

Spoken like someone who never had to deal with recordsets of 40 different values, accessed by position, passed around various functions... ORMs can be a problem, in the sense that complex queries may be harder or impossible to express, and there can be a cost in terms of performance. Snark over keyword arguments, which are completely orthogonal to ORMs, is both rude and misplaced.

Couldn't that argument be used about any function that has multiple values?

Besides, keyword arguments do solve the problem. Also, correctly named variables ( City(city_name,country_name).save() ) and , if need be, some comments all solve this issue.

You'll be looking at the code for a first time just once; you want to optimize for the guy who spends a nontrivial amount of time on code.

Furthermore, ORM queries a much more readable, and the OP's example is bad; Django ORM queries use keyword arguments all the time.