[Python-Dev] PEP 457: Syntax For Positional-Only Parameters (original) (raw)

Eli Bendersky eliben at gmail.com
Wed Oct 9 19:50:47 CEST 2013

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: RevisionRevisionRevision Last-Modified: DateDateDate 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 "", line 1, in 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 "", line 1, in TypeError: mypow() got an unexpected keyword argument 'x' def myfoo(*args): a, b = *args; print a, b File "", 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>

More information about the Python-Dev mailing list