(original) (raw)
On Tue, Oct 8, 2013 at 4:33 PM, Larry Hastings <larry@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:
Hi Larry,
My comments below. TL;DR I'm -1, but trying to figure out your rationale and motivation in more detail.
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
Discussions-To: Python-Dev
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
>>> 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))
?
�
>>> 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
Eli