4 ms·

Keyword arguments are safer and more explicit/self-documenting. It's not clear that further accommodations for positional arguments are needed, except in variad

by ak217 8y ago

Keyword arguments are safer and more explicit/self-documenting. It's not clear that further accommodations for positional arguments are needed, except in variadic situations as described in https://www.python.org/dev/peps/pep-3102/ https://www.python.org/dev/peps/pep-3102/. I would argue the use case described in the "background" section constitutes an unsafe level of uncertainty. One important use case for the existing facilities is to take a function whose signature used to contain positionals, and migrate a positional to be a keyword argument without breaking existing uses of the API. I think `/` is a poor choice of symbol, too. If such a separator were to be a good idea, it should be * * by analogy with `*` for separating keyword-only args.

dietrichepp 8y ago
I think these arguments usually come down to the domain of problems you work with. Some people simply don’t write code where it makes sense to have positional arguments. Some domains have arguments where positional arguments are more natural/self-documenting. For example, concatenation, mathematical operations.
Retra 8y ago
Keyword arguments also encourage overly general functions that try to do everything, and there's a performance cost to that (such functions tend to include a mini arg parser and dispatch mechanism), and it's a wash on documentation, since looking up how to use such a function really isn't any harder than looking up which of a number of functions to use.
masklinn 8y ago
> Keyword arguments are safer and more explicit/self-documenting. Keyword arguments are also more redundant (a function taking a single argument usually does not need that argument to be named, quite the opposite, even for some multi-parameter functions it makes no sense e.g. `max(a=1, b=2)` is downright no matter how you name the arguments)), and the lack of positional-only parameters means any old name to what was intended as a positional effectively becomes part of the API. I think Swift has the better pick there, an argument can be either positional or named, not both, and positional-only parameters are used to great effect. Sadly Python's history of positional-or-named can't really be fixed.
- ehsankia 8y ago
  > a function taking a single argument usually does not need that argument to be named Would you rather have: thread_pool.shutdown(True) or thread_pool.shutdown(wait=True) Even with single argument, it's not always clear what the argument means from the function name, so being explicit makes the code more readable. EDIT: I realize you said "usually", but my point still stands.
  - totalperspectiv 8y ago
    You can maintain clarity with your positional arguments with just: wait = True thread_pool.shutdown(wait)
    - polotics 8y ago
      I am sorry but this looks too much like Java to me.

by ak217 8y ago

dietrichepp 8y ago

I think these arguments usually come down to the domain of problems you work with. Some people simply don’t write code where it makes sense to have positional arguments. Some domains have arguments where positional arguments are more natural/self-documenting. For example, concatenation, mathematical operations.

Retra 8y ago

Keyword arguments also encourage overly general functions that try to do everything, and there's a performance cost to that (such functions tend to include a mini arg parser and dispatch mechanism), and it's a wash on documentation, since looking up how to use such a function really isn't any harder than looking up which of a number of functions to use.

masklinn 8y ago

> Keyword arguments are safer and more explicit/self-documenting. Keyword arguments are also more redundant (a function taking a single argument usually does not need that argument to be named, quite the opposite, even for some multi-parameter functions it makes no sense e.g. `max(a=1, b=2)` is downright no matter how you name the arguments)), and the lack of positional-only parameters means any old name to what was intended as a positional effectively becomes part of the API. I think Swift has the better pick there, an argument can be either positional or named, not both, and positional-only parameters are used to great effect. Sadly Python's history of positional-or-named can't really be fixed.

ehsankia 8y ago
> a function taking a single argument usually does not need that argument to be named Would you rather have: thread_pool.shutdown(True) or thread_pool.shutdown(wait=True) Even with single argument, it's not always clear what the argument means from the function name, so being explicit makes the code more readable. EDIT: I realize you said "usually", but my point still stands.
- totalperspectiv 8y ago
  You can maintain clarity with your positional arguments with just: wait = True thread_pool.shutdown(wait)
  - polotics 8y ago
    I am sorry but this looks too much like Java to me.