On Tue, Oct 8, 2013 at 4:33 PM, Larry Hastings <la...@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 <la...@hastings.org> <la...@hastings.org> > Discussions-To: Python-Dev <python-dev@python.org> <python-dev@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
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
