[Python-3000] Signature API

[Guido van Rossum]

Jim,

Can you try to produce strawman answers for all those questions? It
may be a while before I'll get to answering them...

--Guido

On 4/21/06, Jim Jewett <jimjjewett at gmail.com> wrote:
> 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
>


--
--Guido van Rossum (home page: http://www.python.org/~guido/)