[Cameron Simpson]
I've been writing quite a few functions lately where it is reasonable for a 
caller to want to pass arbitrary keyword arguments, but where I also want some 
additional parameters for control purposes.

I've run into this before and use the trailing '_' convention for names:

def update(self, where_, **column_vals): ... 

Because such names are **probably** never going to show up. But, of course; if such
a name were actually used for a column, it would be a fantastically hard bug to find!

On Thu, Sep 6, 2018 at 11:01 PM Cameron Simpson <cs@cskk.id.au> wrote:
On 01Mar2017 21:25, Serhiy Storchaka <storchaka@gmail.com> wrote:
>On 28.02.17 23:17, Victor Stinner wrote:
>>My question is: would it make sense to implement this feature in
>>Python directly? If yes, what should be the syntax? Use "/" marker?
>>Use the @positional() decorator?
>
>I'm strongly +1 for supporting positional-only parameters. The main
>benefit to me is that this allows to declare functions that takes
>arbitrary keyword arguments like Formatter.format() or
>MutableMapping.update(). Now we can't use even the "self" parameter
>and need to use a trick with parsing *args manually. This harms clearness and
>performance.

I was a mild +0.1 on this until I saw this argument; now I am +1 (unless
there's some horrible unforseen performance penalty).

I've been writing quite a few functions lately where it is reasonable for a
caller to want to pass arbitrary keyword arguments, but where I also want some
additional parameters for control purposes. The most recent example was
database related: functions accepting arbitrary keyword arguments indicating
column values.

As a specific example, what I _want_ to write includes this method:

  def update(self, where, **column_values):

Now, because "where" happens to be an SQL keyword it is unlikely that there
will be a column of that name, _if_ the database is human designed by an SQL
person. I have other examples where picking a "safe" name is harder. I can even
describe scenarios where "where" is plausible: supposing the the database is
generated from some input data, perhaps supplied by a CSV file (worse, a CSV
file that is an export of a human written spreadsheet with a "Where" column
header).  That isn't really even made up: I've got functions whose purpose is
to import such spreadsheet exports, making namedtuple subclasses automatically
from the column headers.

In many of these situations I've had recently positional-only arguments would
have been very helpful. I even had to bugfix a function recently where a
positional argument was being trouced by a keyword argument by a caller.

Cheers,
Cameron Simpson <cs@cskk.id.au>
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/