[Python-ideas] Positional-only parameters

[Abe Dillon]

[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 at cskk.id.au> wrote:

> On 01Mar2017 21:25, Serhiy Storchaka <storchaka at 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 at cskk.id.au>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180910/e5ad8ba6/attachment.html>