[Python-3000] PEP 3113 (Removal of Tuple Parameter Unpacking)
Ka-Ping Yee
python at zesty.ca
Sun Mar 4 20:37:48 CET 2007
On Fri, 2 Mar 2007, Brett Cannon wrote:
> the removal of the automatic unpacking of sequence
> arguments when a tuple parameter is present in a function's signature
> (e.g., the ``(b, c)`` in ``def fxn(a, (b, c), d): pass``).
As I think most people know by now, it makes me quite sad to see these
going away. This is one of those really nice flexibilities in Python
that makes Python Python (kind of like for/else).
Brett's arguments for making them go (in my opinion) say little about
the feature itself; most are merely observations that other parts of
the language implementation fail to fully support this feature.
For example, the "Introspection Issues" argument is mostly irrelevant:
we are discussing a new incompatible version of the Python language,
so it doesn't make sense to argue based on shortcomings of previous
versions. The weakness is in the introspection capabilities. (It's
difficult to introspect inside local scopes -- of course that does not
mean we should remove local scopes from the language).
Similarly, the complaints about poor error messages are irrelevant.
If the error messages are inadequate, simply fix them.
"Exception to the Rule" is also about other features that don't
support tuple parameters, not about tuple parameters themselves.
If these features are incomplete, they can be completed.
"No Loss of Abilities If Removed" is not an argument to remove
anything; it's a neutral claim that removing it won't hurt. All
for/else loops could be easily rewritten with a break flag instead
and no functionality would be lost -- but functionality is not the
question; the expressiveness of the language suffers.
In summary, all of the arguments for removing this feature are of the
form "It won't hurt very much if we remove the feature"; the arguments
for keeping the feature are of the form "This feature is useful and
good for the language." Notice the asymmetry: there are no arguments
that removing it will actually yield a better language, only arguments
that the harm caused by removing it will be small.
-- ?!ng
More information about the Python-3000
mailing list