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

fabric.main.is_task_module should use isinstance #718

Closed
kmike opened this Issue Aug 28, 2012 · 5 comments

Comments

Projects
None yet
2 participants
@kmike

kmike commented Aug 28, 2012

fabric.main.is_task_module is currently defined like this:

def is_task_module(a):
    """
    Determine if the provided value is a task module
    """
    #return (type(a) is types.ModuleType and
    #        any(map(is_task_object, vars(a).values())))
    if type(a) is types.ModuleType and a not in _seen:
        # Flag module as seen
        _seen.add(a)
        # Signal that we need to check it out
        return True

What's the purpose of type(a) is types.ModuleType? It would be great if isinstance(a, types.ModuleType) is sufficient.

I was trying to use types.ModuleType subclass and fabric fails to discover tasks in this case.

@bitprophet

This comment has been minimized.

Member

bitprophet commented Aug 28, 2012

I don't know offhand why it's done this way. If you want to check the git blame history and see if there was a specific reason, that'd be great. Assuming it's not done on purpose, I'd be fine changing to isinstance.

@kmike

This comment has been minimized.

kmike commented Aug 29, 2012

This was introduced in a6c13cd commit and never changed. I don't see why this commit needed "is" check.

@bitprophet

This comment has been minimized.

Member

bitprophet commented Aug 29, 2012

Yea, that just looks like @goosemo either forgot isinstance is almost always better than type, or figured subclassing from ModuleType was really unlikely. (I admit I was surprised when I heard you were doing so, but there's no reason to actually forbid it :))

If you submit a pull request (don't forget to use hub pull-request to attach it to this issue!) with the change + a changelog entry crediting yourself, I'll merge it. Thanks! You should probably base your PR off the 1.4 branch and not master, by the way, then it can go out in the next 1.4 bugfix release.

@kmike

This comment has been minimized.

kmike commented Aug 29, 2012

I'll submit a pull request soon.

By the way, support for ModuleType subclasses is a real problem for me :) We are developing a framework for Fabric and in order to solve #573 without waiting for Fabric 2.0 we're using https://github.com/kmike/fabric-taskset package. The idea is to just create module objects and put them as variables to fabfile (without adding to sys.modules, etc); fabric loads tasks fine from such objects. Creating objects of ModuleType class works fine but sometimes a subclass provides a cleaner solution.

@bitprophet

This comment has been minimized.

Member

bitprophet commented Sep 8, 2012

See #720

@bitprophet bitprophet closed this Sep 8, 2012

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