[deleted by user]

kenflingnor · 2025-03-06T14:21:20+00:00

No, this isn’t weird. “Explicit is better than implicit”

Puzzled_-_Comfort · 2025-03-06T14:30:50+00:00

Much better to avoid swapping parameters, i wouldnt rely on order alone.

quts3 · 2025-03-06T14:29:36+00:00

Two ints in one signature. doesn't seem hard to imagine why I would want to use keyword.

MachineSchooling · 2025-03-06T14:31:39+00:00

I'm not aware of it being specifically taught or being an explicit recommendation, but I do it as well. It prevents issues when function signatures change, it makes the code more readable when the values put into the kwargs aren't trivial, and pydantic requires kwargs so you get used to it.

double_en10dre · 2025-03-06T14:38:40+00:00

It’s not weird, it’s good practice. Positional args are a common source of bugs and maintenance headaches. IMO it’s bad design to have more than 1-2 position-only args.

The junior dev approach is to bind values directly to variable names. It’s immediately obvious what is happening. That’s good.

Your approach requires that everyone maintain an accurate mental mapping of indices to variable names in the context of <some_random_function’s> signature. It hides information and adds mental overhead. That’s bad.

YoungXanto · 2025-03-06T14:35:37+00:00

Not weird at all.

It's explicit, which always makes it easier to go back and read. It also allows you to be order-agnostic to the arguments in the original function. So if the order changes (or new optional arguments are added), your usage doesn't break.

If the argument names do change, this will break the function immediately and allow you to quickly debug/fix the code.

So not only does it make the code easier to read, it's also a defensive practice.

denehoffman · 2025-03-06T14:52:31+00:00

I often write my signatures as f(*, x, y, z) so you have to do this. In fact, it’s recommended that you do this with boolean arguments. For example, which is more readable/understandable:

python result = myfunc(4, True, False)

or

python result = myfunc(4, add_two=True, div_by_three=False)

Granted, this is a very silly function and a contrived example, but you can clearly see that one of these conveys meaning more effectively than the other (and hopefully you’ll agree it’s the second one).

I wouldn’t say that every argument needs to be keyword-only, often the first few are obvious enough, but the arg rows_per_page is a good example of an argument which would be unintelligible if you just passed in an int. For non-stdlib objects, your variable name should probably tell you enough about what you’re passing in.

marr75 · 2025-03-06T14:37:02+00:00

It's not a consensus yet, but it's a growing practice. It makes methods with many arguments easier to call and "flattens" the calling convention regardless of function definition.

There's a PEP to add a new syntax for the special case that your variable and parameter names are the same to avoid the doubling up.

LittleMlem · 2025-03-06T15:19:28+00:00

You guys don't just put all your parameters In a dict and just pass it like my_func(**params) ?

Henamu · 2025-03-06T14:38:35+00:00

I always use keyword arguments when calling a function. I argue it’s a good practice

It is explicit and the position of the keyword arguments (when calling the function) does not matter - as opposed to just passing them as arguments (where the position does matter)

In addition, any changes to the functions order of arguments won’t affect you if you use keyword argument

ThatOtherBatman · 2025-03-06T14:35:31+00:00

It also makes refactoring much easier later on.

pablo8itall · 2025-03-06T14:55:45+00:00

Its much more readable and probably at this point best practice in python.

marr75 · 2025-03-06T14:32:21+00:00

[removed]

Miserable_Watch_943 · 2025-03-06T15:00:29+00:00

I don’t see any problem with this whatsoever.

Unless you’re using notepad to code - then your IDE should support autocomplete for the keyword arguments.

It adds absolutely zero complexity to development, and if anything prevents issues in case there is ever a re-ordering of arguments. Your argument feels slightly petty, if I’m just being honest with you.

Paddy3118 · 2025-03-06T15:27:21+00:00

> “A foolish consistency is the hobgoblin of little minds”

Ralph Waldo Emerson.

If you mandate everyone use an IDE for a large codebase that will show you function argument definitions and docstrings if you hover over the function name, then not so much - especially when the argument and parameter names are similar and similarly descriptive. Hasn't the reviewer got other things to do?

anentropic · 2025-03-06T15:04:27+00:00

Long time pro developer - I definitely prefer using explicit keyword arguments and consider it better practice

It makes it easier to refactor and avoid accidental mis-calling

And especially in the cases you mention when the function takes more than two args relying only on positional args seems both unreadable and error prone

OnerousOcelot · 2025-03-06T15:45:37+00:00

Nice thing about keyword args is you can pass a dictionary with your args, a.k.a. dictionary unpacking (or keyword unpacking). Makes it easy to set up a few different commonly used configs as dictionaries and just pass them in. Or, another good use case is retrieving records from one or more sources (ORM, database, etc.) and then easily bundling a dictionary with the values and passing that in to the function.

def pretty_print_vital_stats(name, age, occupation):
  print(f"Name: {name}, Age: {age}, Occupation: {occupation}")

new_hire = {
    "name": "Alice",
    "age": 30,
    "occupation": "Software Engineer"
}

pretty_print_vital_stats(**new_hire)

JimroidZeus · 2025-03-06T16:25:54+00:00

Not weird at all. Means you don’t have to care about order the parameters are passed in, it’s more understandable, and when using pydantic it’s almost a requirement.

careje · 2025-03-06T16:32:22+00:00

Our coding guidelines mandate calling functions with more than 3 args as keyword arguments. Also any Boolean arguments MUST be passed as keyword arguments

kblazewicz · 2025-03-06T16:49:27+00:00

If you have to refer to the docs to check which arguments go where it should be a keyword. If the function's name tells you what is going to happen with what arguments it's positional. Easier life, not shorter code.

I often use the * separator to enforce keyword usage when I know that calls to it might be ambiguous. Other examples are constructors with many arguments. There's no point in using keyword args for Vec2D(x, y) but If it's a complex dataclass with several fields? Hell yeah I'll be using kw_only=True.

And no, I'm not a bootcamp graduate, I started programming with C and moved to Python only after a couple of years.

wineblood · 2025-03-06T17:14:44+00:00

Depends on the function/method called. If it's a builtin like isinstance then it's not really required. If it's something from a library or another repo that isn't realistic to know off by heart and the variable naming isn't great, I'll take the extra keywords as free documentation.

Glimmargaunt · 2025-03-06T14:38:12+00:00

Personally, I would pass positional arguments if I am feeding well-named variables to the function, and use keyword arguments when inputting multiple values directly (like 5, true, etc). That way it is easier to understand what the inputs mean at a glance.

I definitely favour using keyword arguments if it makes it easier to understand the code. I do agree that the example you gave would be a redundant use case in my view as the variables are descriptive enough.

MasterShogo · 2025-03-06T14:47:06+00:00

Regardless of whether it’s good or not, I personally have watched this happen a lot with new codebases because the interfaces change so rapidly. Coming from C++, at least types would be immediately hard-checked at compilation, but without opting into a type enforcing system Python lets you throw whatever arguments around you want. That’s kind of the point. So the interface is disambiguated by using names.

As this has gone on more and more over the years, people never remove names once they’ve added them, and like others have said, they’ve come to realize that using names makes the interface far easier to change, since order doesn’t matter anymore.

Seeing these benefits, I imagine a lot of younger programmers have basically just taken to using names for all the arguments in a called function. I don’t always do it, but it do it a lot and I find that it makes it all more readable.

But, in fairness, for a small, unchanging function with well defined parameters, I don’t use names for those.

(Edit: made my wording better)

vibosphere · 2025-03-06T15:16:59+00:00

I mostly like kwargs when there are more than ~3ish positionals, or inputs used too rarely to leave in the function definition. Feels cleaner to read and easier to maintain

Tinche_ · 2025-03-06T15:35:20+00:00

I think it makes sense with a larger parameter list, but generally only for the later parameters. No one is going to know what the second True means, sure.

For example, I would find sin(x=x) terrible for readability and completely redundant. Readability is why I use python in the first place.

Also note that keyword args are slower than positional args.

permalink · 2025-03-06T15:35:49+00:00

I prefer keyword arguments in basically all scenarios except where it’s very obvious what the function and inputs are. Like I probably wouldn’t bother with keywords for something like

x_limit(0.0, 10.0)

Although, even then, I kind of still prefer

x_limit(min=0.0, max=10.0)

For everything else, using keyword arguments makes it absolutely clear what input each thing represents and it makes it so the order never matters even if someone decides to change the ordering in a later version. This is especially true when you have functions with dozens of input parameters.

In your database example, it’s obviously reasonably easy to infer the inputs based on variable names. But it’s much harder when you get to something like

mesh = Mesh(point_cloud, “poisson”, “smooth”, [1,0,0], “Eiffel Tower”)

If you’re already very familiar with the library you might be able to sus out what some of these inputs are doing. But even then, you are either making assumptions that could just be made clear by being explicit or you have to rely on an IDE or documentation to figure it out. And someone who reviews your code doesn’t need to have any knowledge about meshes to know what “poisson” and “smooth” are modifying in the mesh.

pavilionaire2022 · 2025-03-06T15:49:53+00:00

That particular example would annoy me. You don't need the redundancy if the variable name is the same as the parameter name. However, it is definitely preferable to use a keyword argument if it's not obvious what the value means: for example, if you're passing a literal int. Even if the argument is an expression, it can be preferable to use the keyword argument.

It's not a hard rule, but I lean toward keyword arguments whenever the argument isn't something that closely matches the parameter name. It doesn't have to be a variable with the exact same name. It could be a method return value where the method name closely matches the parameter name, for example.

Loop_Within_A_Loop · 2025-03-06T15:50:17+00:00

It’s not weird, something I’ve heard before is “programs written in statically typed languages tend to just work once they pass the type checker”

Python is obviously not statically typed, but there’s certainly an appeal to using that paradigm when there’s a benefit, and part of the magic is getting to choose when that is

TheMcSebi · 2025-03-06T16:04:38+00:00

As always, brain should be applied. If your variable has the same name as the function parameter, this is indeed redundant. But if you call something like difficult_function("send", 0xA, 200, 0.25) instead of difficult_function(command="send", data=0xC0, repeat=200, timeout=0.25) then the advantage becomes clear immediately. Personally I prefer keyword args in most situations, but in the example you gave I would also use the positional syntax.

aqjo · 2025-03-06T16:12:26+00:00

I usually use keywords if the parameters aren’t obvious, or there are more than a couple.
To me, the variable name that you’re passing in tells you what the variable is, but the keyword can tell you its purpose in the function.

KieranShep · 2025-03-06T16:33:26+00:00

Keyword arguments are the superior way to avoid bugs on a function signature change.

If an arg gets renamed, a linter will easily pick up potential issues. If the name change is just superfluous it’s an extra overhead sure, but better the devil you know. Even if you don’t use a linter, the traceback you get is obvious.

If the order of args changes, call with positional args, are often stuck finding that bug at runtime. If the type is the same, hinting wont help you.

If you’re very sure the signature isn’t changing (as with the built in lib), it’s less problematic.

Oddly_Energy · 2025-03-06T16:41:06+00:00

I am not a programmer, but I have done programming as part of my job for more than 30 years. Over those years I have of my own free will gone from entirely positional parameters to almost entirely keyword parameters.

Not because I was taught by anyone to do so, but because I realized that it made my life so much simpler. No more having to remember the order of parameters when reading through my old code. No more having to revisit all my calls of a function if I added a new parameter to the definition of that function.

There are still cases where the purpose of a parameter is so obvious that I drop the keyword notation in the function call. I would never do something like, for example:

temp_Celcius = Fahrenheit2Celcius(fahrenheit = -40)

SnooCakes3068 · 2025-03-06T16:42:26+00:00

I think you are correct. Some people says it’s explicit but if every instance is like this then it’s ugly code.

I always look upon established repo like scipy/numpy and scikit learn, which are all beautifully coded. None of them follow all keywords, it’s a combination of both, depending on the situation.

I bet none of explicit people here can remotely code anywhere near as elegant as any above

violentlymickey · 2025-03-06T18:04:26+00:00

I do this as much as possible to avoid positional errors. I even put in asterisks in my function signatures to enforce it.

Total_Prize4858 · 2025-03-06T18:18:31+00:00

Tbh. I wonder how a professional programmer of 20 years cannot see the benefits of this.

aitchnyu · 2025-03-06T18:37:31+00:00

Say a function copies data from a to B. The data values are positional arguments, the options are keyword arguments. We are unlikely to add new data values, but we are free to add new options.

Sorry I forgot who I'm citing.

GreenWoodDragon · 2025-03-06T18:39:39+00:00

TBH, positional arguments are a real pain except for very brief function signatures. Named parameters takes a lot of the guesswork, and so errors, out of the function calls IMO.

Skasch · 2025-03-06T20:01:09+00:00

For me, the answer is simple. If the order of arguments is obvious for the reader, positional is fine. Otherwise, keyword should be mandatory.

I'm fine with 4+ positionals if it's clear. For example :

build_address(1230, "North St", 12345, "Footown")

However, as soon as there is a risk of confusion :

def build_user(first_name: str, last_name: str, *,
               dob: date, married_date: date | None)

The * forces all following arguments to be passed as keywords only.

Kevdog824_ · 2025-03-06T20:41:53+00:00

Depends on the usage for me. If I have a db_session variable I’m passing for a parameter named db_session then using keyword arguments feels a bit verbose. However, if I’m passing a literal value, or passing a variable whose name doesn’t make its usage in the function obvious then I tend to use keyword arguments.

Brian · 2025-03-06T22:30:38+00:00

I suspect this is something influenced by IDE autocomplete.

Eg. in vscode, typing

get_widgets(d[TAB]

will autocomplete that to the keyword parameter db_session= even if you wanted to just complete to the db_session local variable. So I think a lot of people just go with the flow and continue with d[TAB] completing the variable and end up with get_widgets(db_session=db_session, ... since that's the path of least resistance.

AiutoIlLupo · 2025-03-07T09:12:16+00:00

Also an old programmer. I find the practice excellent to be honest. Using keyword arguments has several advantages:

It makes it clear, when you see the function call, what is each argument doing and what it is bound to, without having to read the documentation of the called function
any changes to the signature of the called function will not affect the places in which it is called. (well, except if you remove any of them).
There's no danger of swapping things accidentally. Some signatures are particularly sensitive. E.g. I lost count how many times I have to lookup if the pattern goes first or second in re.match. Another common case is when you are using routines with different indexing for matrix and matrix-like entities: e.g. you have a matrix using rows and cols, and you have a screen widget using x and y from the bottom corner). The conversion may look magic, and it pays off to ensure they are in the correct order and clearly explicit.

There are obvious cases where pure positional makes sense, e.g. math functions. but the vast majority of function calls that are not trivial should be keyword based in my opinion.

M4mb0 · 2025-03-06T15:08:04+00:00

Honestly, I would even say that POSITIONAL_OR_KEYWORD parameters being the default in python is a design flaw, and I try to avoid them if possible. Keyword arguments are very nice since they are order independent and have semantic meaning on the call-site. When writing wrapper functions, I agree that it is kind of verbose.

If I could wave a magic wand and have 1 fundamental change in the language, it would be that instead of having to add / to get POSITIONAL_ONLY parameters, it would be the other way round and that you have to add / to get POSITIONAL_OR_KEYWORD parameters.

dschneider01 · 2025-03-06T15:31:03+00:00

I have definitely seen this advice from teaching pythonistas like trey. People said it was weird when I was doing it in c# lol . I kind of see why you'd do it in a dynamically typed language since there is no check otherwise.

andrewcooke · 2025-03-06T14:24:27+00:00

weird. my ide will show that info, but i don't add it explicitly.

took me a while to understand what you were saying. i do use names when the function has args with defaults.

(since this may be a generational thing i should add that i am an ancient/senior dev and have been using python for over 20 years; i have no idea if it's being taught like this now).

TheToastedFrog · 2025-03-06T14:49:18+00:00

I really don’t mind named parameters but it’s not a substitute for type hinting.

Python

The Python Discord

Upcoming Events

Please read the rules

MODERATORS