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 <[EMAIL PROTECTED]> wrote: > On 4/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On 4/21/06, Guido van Rossum <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
