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

Jim Jewett jimjjewett at gmail.com
Mon Jun 18 09:08:40 CEST 2012

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:

 Every Parameter attribute is optional, even name.  (Think of  builtins, even if they aren't automatically supported yet.)   So go ahead and define some others that are sometimes useful.

Add only stuff we know is interesting and useful.

Agreed, but it doesn't have to be useful in all cases, or even available on all Signatures; if users are already prepared for missing data, it is enough that the attribute be well-defined, and be useful when it does appear. That said, it looks like is_implemented isn't sufficiently well-defined.

- kind - name (should be given meaningful content, even for POSITIONALONLY parameters)

I agree that it should be given meaningful content, but I don't think the Parameter (or Signature) should be blocked without it. I also don't think that a documentation-only name that cannot be used for keyword calls should participate in equality. The existence of the parameter should participate, and its annotation is more important than usual, but its name is not.

- default (may be missing, since "None" is allowed as a default value) - annotation (may be missing, since "None" is allowed as an annotation)

Position is also important, but I'm not certain whether it should be represented in the Parameter, or only in the Signature.

copy(source, target)
copy(target, source)

have different signatures, but I'm not sure whether it would be appropriate to reuse the same parameter objects.

 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?

 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), it can only appear once per signature, and the possible location of its appearance is different. It is formatted differently (which I would prefer to do in the Parameter, rather than in Signature). 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".)

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.

(3rd edition)

* iskeywordonly : bool ... * isargs : bool ... * iskwargs : bool ...

(4th edition)

... Parameter.POSITIONALONLY ... ... Parameter.POSITIONALORKEYWORD ... ... Parameter.KEYWORDONLY ... ... Parameter.VARPOSITIONAL ... ... Parameter.VARKEYWORD ...

This set has already grown, and I can think of others I would like to use.  (Pseudo-parameters, such as a method's self instance, or an auxiliary variable.)

No. This is the full set of binding behaviours. "self" is just an ordinary "POSITIONALORKEYWORD" argument (or POSITIONALONLY, in some builtin cases).

Or no longer a "parameter" at all, once the method is bound. Except it sort of still is. Same for the space parameter in PyPy. I don't expect the stdlib implementation to support them initially, but I don't want it to get in the way, either. A supposedly closed set gets in the way.

 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. Also, positional_only, *args, and **kwargs should be able to remove name from the list of compared attributes.

-jJ

More information about the Python-Dev mailing list