[Python-3000] PEP 3113 (Removal of Tuple Parameter Unpacking) (original) (raw)
Jim Jewett jimjjewett at gmail.com
Sun Mar 4 02:57:39 CET 2007
- Previous message: [Python-3000] PEP 3113 (Removal of Tuple Parameter Unpacking)
- Next message: [Python-3000] PEP 3113 (Removal of Tuple Parameter Unpacking)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I have mixed feelings; I won't go so far as to say I oppose removing tuple-arguments, but some of the problems do have other solutions.
On 3/2/07, Brett Cannon <brett at python.org> wrote:
But there is great difficulty when it comes to tuple parameters. The existence of a tuple parameter is denoted by it name being made of a
.
and a number in thecovarnames
attribute of the function's code object.
I think this is just an implementation detail. For example, co_varnames could itself hold tuples as well as names. (That would itself break backwards compatibility, but only for introspection.)
Consider PEP 3102 (keyword-only arguments) and PEP 3107 (function annotations) [#pep-3102] [#pep-3107]. Both PEPs have been accepted and introduce new functionality within a function's signature. And yet for both PEPs the new feature cannot be applied to tuple parameters.
I hadn't realized that they couldn't be annotated. That could be fixed.
On the other hand, the existence of annotations does take away part of the value -- now you could just annotate a_b_c as having internal structure: (a, (b, c))
I'm not sure what keyword-only could even mean for strictly positional arguments.
The existence of tuple parameters also places sequence objects separately from mapping objects in a function signature. There is no way to pass in a mapping object (e.g., a dict) as a parameter and have it unpack in the same fashion as a sequence does into a tuple parameter.
Either **kwargs or f(**mapping) is pretty close, depending on your perspective.
The main difference is that sequence users have to supply all the names (keys) in advance, so you can't default only part of a tuple. (This oddness does strengthen the "but it really represents a unitary something" aspect.)
Iterating over every line in Python's code repository in the
Lib/
directory using the regular expression^\s*def\s*\w+\s*\(
to detect function and method definitions there were 22,252 matches in the trunk.
Tacking on
.*,\s*\(
to finddef
statements that contained a tuple parameter, only 41 matches were found. This means that fordef
statements, only 0.18% of them seem to use a tuple parameter.
That misses first-argument tuples, such as cgitb.text and pydoc.fixup. Searching '^\sdef\s\w+\s\(\s\(' in C:\Python25\Lib*.py ...
I got 19 first-argument hits, but ten were in test, and another 4 in site-packages.
I think it would also miss multiline defs whose tuple argument was not on the first line.
That said, the frequency is almost certainly still less than 0.5%.
-jJ
- Previous message: [Python-3000] PEP 3113 (Removal of Tuple Parameter Unpacking)
- Next message: [Python-3000] PEP 3113 (Removal of Tuple Parameter Unpacking)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]