On Sat, Oct 30, 2021 at 10:32 PM Jonathan Fine <jfine2...@gmail.com> wrote:
> I suggest that an implementation which provides additional flexibility in the 
> manner in which the code frame is initialised would be less invasive. 
> Necessarily, PEP 671 allows programmer supplied code to be used in the 
> 'initialisation phase'. The previous attempts place that code in fn.__code__.
>
> I suggest that the implementation adds a new attribute fn.__wibble__ to fn, 
> which can either be None or a code object. And if fn.__wibble__ is not None, 
> then it is used to initialise the code frame in which fn.__code__ executes. 
> It would as before take as input the arguments actually supplied by the user.
>
> I stop here, saying nothing for now about two important questions. First, 
> what is the programmer syntax for creating such a 'two-part' function fn. 
> Second, what does the user see as a result of help(fn). Or in other words, 
> how to extend the semantics of inspect.signature.
>

The code has to be executed in the context of the called function. How
would fn.__wibble__ be different from checks at the top of
fn.__code__?

And, seeing something in help(fn) largely necessitates that the source
code be retained. I don't know of any other way to do it. If you say
that the default argument is "len(a)", then that's what help() should
say.

ChrisA
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/X42RZ57LC44QV6VAFWTX6DEIVXCY6XR3/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to