[Python-Dev] PEP 362: 4th edition

[Jim Jewett]

On Mon, Jun 18, 2012 at 10:37 AM, Yury Selivanov
<yselivanov.ml at gmail.com> wrote:
> Jim,
>
> On 2012-06-18, at 3:08 AM, Jim Jewett wrote:
>> On Sat, Jun 16, 2012 at 11:27 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> On Sat, Jun 16, 2012 at 1:56 PM, Jim J. Jewett <jimjjewett at gmail.com> wrote:

>>>>    Instead of defining a BoundArguments class, just return
>>>>   a copy  of the Signature, with "value" attributes added to
>>>>   the Parameters.

>>> No, the "BoundArguments" class is designed to be easy to
>>> feed to a function call as f(*args, **kwds)

>> Why does that take a full class, as opposed to a method returning a
>> tuple and a dict?

> Read this thread, please: http://mail.python.org/pipermail/python-dev/2012-June/120000.html

I reread that.  I still don't see why it needs to be an instance of a
specific independent class, as opposed to a Signature method that
returns a (tuple of) a tuple and a dict.

   ((arg1, arg2, arg3...), {key1: val2, key2: val2})


>>>>    Use subclasses to distinguish the parameter kind.

>>> Please, no, using subclasses when there is no behavioural
>>> change is annoying.

[Examples of how the "kinds" of parameters are qualitatively different.]

>> A **kwargs argument is very different from an ordinary parameter.  Its
>> name doesn't matter (and therefore should not be considered in
>> __eq__),

> The importance of its name depends hugely on the use context.  In some
> it may be very important.

The name of kwargs can only be for documentation purposes.  Like an
annotation or a docstring, it won't affect the success of an attempted
call.  Annotations are kept because (often) their entire purpose is to
document the signature.  But docstrings are being dropped, because
they often serve other purposes.  I've had far more use for docstrings
than for the names of positional-only parameters.  (In fact, knowing
the name of a positional-only parameter has sometimes been an
attractive nuisance.)

> And it is treated specially, along with the *args.

Right -- but this was in response to Nick's claim that the
distinctions should not be represented as a subclass, because the
behavior wasn't different.

I consider different __eq__ implementations or formatting concers to
be sufficient on their own; I also consider different possible use
locations and counts, different used-by-the-system attributes (name),
or different value types (object vs collection) to be sufficiently
behavioral.

>>>>> A Signature object has the following public attributes and methods:

>> The more I try to work with it, the more I want direct references to
>> the two special arguments (*args, **kwargs) if they exist.  FWIW, the
>> current bind logic to find them -- particularly kwargs -- seems
>> contorted, compared to self.kwargsparameter.

> Well, 'self.kwargsparameter'  will break 'self.parameters' collection,
> unless you want one parameter to be in two places.

Correct; it should be redundant.  Signature.kwargsparameter should be
the same object that occurs as the nth element of
Signature.parameters.values().  It is just more convenient to retrieve
the parameter directly than it is to iterate through a collection
inspecting each element for the value of a specific attribute.


> In fact, the check types example (in the PEP) is currently shorter and
> easier to read with 'Signature.parameters' than with dedicated property
> for '**kwargs' parameter.

Agreed; the short-cuts *args and **kwargs are only useful because they
are special; they aren't needed when you're doing the same thing to
all parameters regardless of type.

> And if after all you need direct references to *args or **kwargs - write
> a little helper, which finds them in 'Signature.parameters'.

Looking at http://bugs.python.org/review/15008/diff/5143/Lib/inspect.py
you already need one in _bind; it is just that saving the info when
you pass it isn't too bad if you're already iterating through the
whole collection anyhow.

>>  Also,
>> positional_only, *args, and **kwargs should be able to remove name
>> from the list of compared attributes.

> I still believe in the most contexts the name of a parameter matters
> (even if it's **kwargs).  Besides, how can we make __eq__ to be
> configurable?

__eq__ can can an _eq_fields attribute to see which other attributes
matter -- but it makes more sense for that to be (sub-) class
property.

-jJ