On Sat, Jun 16, 2012 at 11:27 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On Sat, Jun 16, 2012 at 1:56 PM, Jim J. Jewett <jimjjew...@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 POSITIONAL_ONLY
> 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)
>>> * is_keyword_only : bool ...
>>> * is_args : bool ...
>>> * is_kwargs : bool ...
>> (4th edition)
>>> ... Parameter.POSITIONAL_ONLY ...
>>> ... Parameter.POSITIONAL_OR_KEYWORD ...
>>> ... Parameter.KEYWORD_ONLY ...
>>> ... Parameter.VAR_POSITIONAL ...
>>> ... Parameter.VAR_KEYWORD ...
>> 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 "POSITIONAL_OR_KEYWORD" argument (or POSITIONAL_ONLY, 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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
