[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 <c...@cskk.id.au> wrote: > On 01Mar2017 21:25, Serhiy Storchaka <storch...@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 <c...@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/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
