[Python-Dev] PEP 362: 4th edition (original) (raw)

Jim Jewett jimjjewett at gmail.com
Mon Jun 18 23:06:50 CEST 2012

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, positionalonly, *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

More information about the Python-Dev mailing list