[Python-Dev] PEP 362: 4th edition

[Yury Selivanov]

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
And also take a look at the check types example in the pep.

In short - it's easy to work with 'BoundArguments.arguments' list,
but it is not enough for invocation, thus 'BoundArguments.args' & 
'.kwargs' properties.

>>>    Use subclasses to distinguish the parameter kind.
> 
>> Please, no, using subclasses when there is no behavioural
>> change is annoying.
> 
> 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.

> it can only appear once per signature, and the possible
> location of its appearance is different.  

I'll fix the __eq__ to ignore positions of **kwargs & keyword-only 
parameters.

> It is formatted differently
> (which I would prefer to do in the Parameter, rather than in
> Signature).  

I think we'll remove the 'Signature.format()' from the PEP, leaving just
'Signature.__str__'.  And just for '__str__' I don't think it's a bad
idea to let Signature format its parameters.

> It also holds very different data, and must be treated
> specially by several Signature methods, particularly when either
> validating or binding.  (It is bound to a Mapping, rather than to a
> single value, so you have to keep it around longer and use a different
> "bind method".)

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

>>>> 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.  I've already had
three or four implementations of this PEP, with the first couple having
**kwargs parameter stored separately, but keeping all parameters in one 
collection turned out to be the most elegant solution.  

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.

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

>>>  I'm not sure
>>> if positional parameters should also check position, or if that
>>> can be left to the Signature.
> 
>> Positional parameters don't know their relative position, so it *has*
>> to be left to the signature.
> 
> But perhaps they *should* know their relative position.

I disagree here.  That will just complicate things.

>  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?  Let's make it do the most explicit and simple logic,
and those who need a custom one will implement such for themselves.

Thank you,
-
Yury