[Python-3000] Signature API

[Jim Jewett]

On 4/21/06, Guido van Rossum <guido at python.org> wrote:

On 4/21/06, Guido van Rossum <guido at python.org> wrote:

>... pronounce that I now like the single-star syntax:

>   def foo(a, b, *, x=1, y=2): ...

[Alex asked for clarification]

I wrote:

> It has not yet been specified whether the keyword-only
> arguments must each have a default.  Most proposals
> assume not, but then do ugly things to support that
> assumption. The above suggests

>     def foo(a, b=2, *, x=3, y=4):   # OK
>     def foo(a, b=2, *, x, y=4):      # not yet decided


On 4/21/06, Guido van Rossum <guido at python.org> wrote:
> I first was gonna say "illegal of course" but on second
> thought the feature of having required keyword args is
> sometimes useful; I believe I've coded such a signature
> myself once or twice out of **kwds and lots of checking.

On the other hand, it would be pretty easy to miss that x needed a
value, particularly if x were the third or fourth of a dozen keywords.

> FWIW Talin, if you're writing up a PEP for this, could I ask
> you to also specify a new introspection API?

> A function foo should have a magic attribute
>     foo.__signature__
> which provides access to the argument names and
> defaults (and types if in the future we add argument
> declarations).

>__signature__ objects should be copyable and
> mutable and the attribute should be assignable so

Do you just mean that the signature can be replaced, or do you really
mean that it can be modified in place?

> that wrapping decorators can copy and modify the
> signature of the wrapped function onto the wrapper
> function (the latter is usually declared as *args,
> **kwds).

Is the __signature__ used for anything except introspection?

    def f(a, b=2): pass

    f.__signature__ = ()

Should this false assignment raise an error?  (If so, should a change
that only renamed arguments be OK?)

If the assignment is valid, should it actually modify f.func_defaults
to match?  What about f.func_code.co_varnames (etc)?

Should calls to f be (in any way) checked against the new (false) signature?

> (Ideally the __signature__ attribute on a bound method
> should return the unbound method's signature modified to
> remove 'self'.)

Note:  So far this could (theoretically) happen in 2.5

The renamings below might need a bit longer.

> Oh, other standard function attributes probably all
> ought to be renamed from func_whatever to
> __whatever__.  That applies to 'func_closure',
> 'func_code', 'func_defaults', 'func_dict', 'func_doc',
> 'func_globals', 'func_name'.

I think some of this is already done; if not, then there are subtle
issues.  In 2.4, at least for a sample function quickly defined,

    f.func_dict is f.__dict__
    f.func_doc is f.__doc__
    f.func_name is f.__name__

I think func_defaults should probably just go away, and become an
attribute of the signature.  __doc__ and __name__ should probably also
be available on the signature, though removing them from the function
might be a mistake.

Should bound function attributes im_class, im_func, and im_self be
renamed?  (Maybe not, because of the conflict over __class__)

Should code objects' attributes be renamed without the co_ prefix?

Should code objects have a signature, since that is where the
signature really starts?  (Functions add the defaults, change the doc,
and may change the name.)

Should signatures indicate return type (if types are added)?

Are signatures a reasonable place to add other metadata, such as DBC contracts?

Should signatures have a recommended text representation?

-jJ