For Devs: An @notImplemented Decorator

[Thomas Passin]

It can be helpful to be able to handle functions/methods that have not been implemented.  This is often done by having them print a string (such as "Not Implemented") and returning.  This is a bit clumsy and one needs to edit it out when the function is ready to test.

 As an alternative, I sometimes use a decorator.  The decorator depends on having the last line of the function body be "pass".

If the last line is "pass", the function body is not executed even if the function includes code ahead of the "pass" line.  Instead, a "not implemented" message is printed.  Once that last line has been removed, the function body will get executed as if the decorator were not present.

import inspect

def notImplemented(f):
    """Decorator to announce when the decorated function

    has not been implemented.  
   
    The last line of the function must be "pass" for this

    to work.  If the last line is "pass", the function will

    not be invoked even if there is other code before

    the "pass" line.
    """
    _name = f.__name__
    def new_f(*args):
        _lines = inspect.getsourcelines(f)[0]
        if _lines[-1].strip() == 'pass' :
            print('%s() not implemented' % _name)
        else:
            return f(*args)
    return new_f

**keywords could be added to the signatures, but so far I haven't needed it.

[Edward K. Ream]

On Thu, Mar 9, 2023 at 9:51 PM Thomas Passin <tbp1...@gmail.com> wrote:

It can be helpful to be able to handle functions/methods that have not been implemented.  This is often done by having them print a string (such as "Not Implemented") and returning.  This is a bit clumsy and one needs to edit it out when the function is ready to test.

Hmm. The standard way is to raise NotImplemented.

Your post reminds me that Leo's do-nothing gui methods call self.oops(). I'm not sure why I used this pattern: raising NotImplemented gives a full traceback, which would seem to be enough.

Edward

[Edward K. Ream]

On Friday, March 10, 2023 at 5:44:25 AM UTC-6 Edward K. Ream wrote:

Hmm. The standard way is to raise NotImplemented.

pylint prefers  NotImplementedError. See this question.

Edward

[Edward K. Ream]

On Friday, March 10, 2023 at 5:44:25 AM UTC-6 Edward K. Ream wrote:

Hmm. The standard way is to raise[NotImplementedError].

PR #3200 removes all gui-related `oops` methods. This method has been moved into devel.

I have tested the new code with --gui=console and --gui=browser.

Please report any problems :-)

Edward

[Edward K. Ream]

On Fri, Mar 10, 2023 at 7:17 AM Edward K. Ream <edre...@gmail.com> wrote:

PR #3200 removes all gui-related `oops` methods. This method has been moved into devel.

I meant: this branch has been merged into devel.

EKR

[Thomas Passin]

" pylint prefers  NotImplementedError." - EKR

Often during development I prefer not to handle an exception, and want the program continue to run.  Though I suppose I could put exception handling into the decorator.