On 3/3/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> 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.
>
Sure some of them have other solutions, but that does not mean that
they should be fixed just to save this feature.
> On 3/2/07, Brett Cannon <[EMAIL PROTECTED]> 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 the ``co_varnames`` 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.)
>
Possibly, but no one has stepped forward to rectify the situation (I
am obviously not going to since I have other issues with them).
> > 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))
>
Exactly.
> I'm not sure what keyword-only could even mean for strictly positional
> arguments.
>
They don't make sense for them. Jiwon and I discussed this when he
was designed keyword-only 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.
>
In terms of unpacking, there is no equivalent. You can't pass in a
dictionary as an argument and then signify that the dict must have
certain keys whose values are bound to a specific parameter.
> 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 find ``def`` statements that contained a
> > tuple parameter, only 41 matches were found. This means that for
> > ``def`` 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 '^\\s*def\\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.
>
It's rought, I know.
> That said, the frequency is almost certainly still less than 0.5%.
Yep, still paltry.
-Brett
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
