Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pythonic access to generated command methods #11

Open
jesteria opened this issue Apr 11, 2018 · 0 comments
Open

Pythonic access to generated command methods #11

jesteria opened this issue Apr 11, 2018 · 0 comments

Comments

@jesteria
Copy link
Member

Summary

Commands generated from the decoration of method functions should be accessible as they appear to be in code, nevermind that they have been transmuted into Command classes.

class Main(command):

    def __call__(self):
        self.action()

    @cmd
    def action(self):
        …

Currently, the expression self.action() in Main.__call__ will not invoke a method; rather, it will attempt to instantiate a new instance of the Command subclass, action, (but in fact fail).

This is counter-intuitive.

It's not that access to the instance-bound method is impossible. Rather, it would be self['action'].__call__(). However, in this special case, due to decorator manufacture of Command classes, we should likely provide better support for reasonable, syntactic expectations.

Limitations

  • Command.__getitem__ should not change. This is the only way of accessing the hierarchy of Command instances; and, as a novel implementation, it's free to operate however it needs.
  • It might make sense to change how this works for all cmd-generated classes; but, it might not. @cmd is, relatively, more intended for generating classes which have some distinct utility. @cmdmethod, on the other hand, generates classes whose instantiation is only important to their execution, and it is unlikely that (easy) access to their instance is needed. Regardless, the syntactic issue applies to all such decorated method functions, and there's likely little to be gained from distinguishing the two here, particularly so long as the instance remains accessible via subscription.

Implementation

The manufactured class may include a (mix-in) descriptor interface, with __get__ defined, such that reference to the class, (from the parent, for example, or otherwise), returns the instance-bound function, rather than the class, (attached to its instance as either __call__ or prepare).

It shouldn't make a difference to the implementation whether this is general to manufactured commands or not, (since outside of method context __get__ simply isn't involved).

Note: We could instead merely return the command instance, but the goal is to satisfy syntactic expectation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant