[Python-Dev] PEP 457: Syntax For Positional-Only Parameters

[Eli Bendersky]

On Tue, Oct 8, 2013 at 4:33 PM, Larry Hastings <larry at hastings.org> wrote:

>
> I've contributed a new PEP to humanity.  I include the RST for your
> reading pleasure below, but you can also read it online here:
>
> http://www.python.org/dev/peps/pep-0457/
>
>
>
Hi Larry,

My comments below. TL;DR I'm -1, but trying to figure out your rationale
and motivation in more detail.



>  Discuss,
>
>
> */arry*
>
> -----
>
> PEP: 457
> Title: Syntax For Positional-Only Parameters
> Version: $Revision$
> Last-Modified: $Date$
> Author: Larry Hastings <larry at hastings.org> <larry at hastings.org>
> Discussions-To: Python-Dev <python-dev at python.org> <python-dev at python.org>
> Status: Draft
> Type: Informational
> Content-Type: text/x-rst
> Created: 08-Oct-2013
>
>
> ========
> Overview
> ========
>
> This PEP proposes a syntax for positional-only parameters in Python.
> Positional-only parameters are parameters without an externally-usable
> name; when a function accepting positional-only parameters is called,
> positional arguments are mapped to these parameters based solely on
> their position.
>
> =========
> Rationale
> =========
>
> Python has always supported positional-only parameters.
> Early versions of Python lacked the concept of specifying
> parameters by name, so naturally all parameters were
> positional-only.  This changed around Python 1.0, when
> all parameters suddenly became positional-or-keyword.
> But, even in current versions of Python, many CPython
> "builtin" functions still only accept positional-only
> arguments.
>
> Functions implemented in modern Python can accept
> an arbitrary number of positional-only arguments, via the
> variadic ``*args`` parameter.  However, there is no Python
> syntax to specify accepting a specific number of
> positional-only parameters.  Put another way, there are
> many builtin functions whose signatures are simply not
> expressable with Python syntax.
>
> This PEP proposes a backwards-compatible syntax that should
> permit implementing any builtin in pure Python code.
>
> -----------------------------------------------------
> Positional-Only Parameter Semantics In Current Python
> -----------------------------------------------------
>
> There are many, many examples of builtins that only
> accept positional-only parameters.  The resulting
> semantics are easily experienced by the Python
> programmer--just try calling one, specifying its
> arguments by name::
>
>     >>> pow(x=5, y=3)
>     Traceback (most recent call last):
>       File "<stdin>", line 1, in <module>
>     TypeError: pow() takes no keyword arguments
>

You mean, like:

>>> def mypow(*args): return pow(args[0], args[1])
...
>>> mypow(2, 3)
8
>>> mypow(x=2, y=3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: mypow() got an unexpected keyword argument 'x'
>>> def myfoo(*args): a, b = *args; print a, b
  File "<stdin>", line 1
    def myfoo(*args): a, b = *args; print a, b
                             ^

?



>
> In addition, there are some functions with particularly
> interesting semantics:
>
>   * ``range()``, which accepts an optional parameter
>     to the *left* of its required parameter. [#RANGE]_
>
>   * ``dict()``, whose mapping/iterator parameter is optional and
>     semantically must be positional-only.  Any externally
>     visible name for this parameter would occlude
>     that name going into the ``**kwarg`` keyword variadic
>     parameter dict! [#DICT]_
>
> Obviously one can simulate any of these in pure Python code
> by accepting ``(*args, **kwargs)`` and parsing the arguments
> by hand.  But this results in a disconnect between the
> Python function's signature and what it actually accepts,
> not to mention the work of implementing said argument parsing.
>
>
I'm not sure what you call "parsing". This?

>>> def myfoo(*args): a, b = args; print("%s, then %s" % (a, b))

?




> ==========
> Motivation
> ==========
>
> This PEP does not propose we implement positional-only
> parameters in Python.  The goal of this PEP is simply
> to define the syntax, so that:
>
>     * Documentation can clearly, unambiguously, and
>       consistently express exactly how the arguments
>       for a function will be interpreted.
>

Can't we do this now? Is the problem only with those existing built-ins, or
for new functions too?


>
>     * The syntax is reserved for future use, in case
>       the community decides someday to add positional-only
>       parameters to the language.
>

This doesn't seem like a valid motivation. YAGNI


>
>     * Argument Clinic can use a variant of the syntax
>       as part of its input when defining
>       the arguments for built-in functions.
>
>
Isn't one of the goals of Argument Clinic to provide a DSL anyhow? I'm not
sure how this help.

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131009/926f89c8/attachment.html>