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

Allow lists/tuples of tensors to get tagged as application inputs #1140

Open
dwf opened this issue Aug 18, 2016 · 2 comments
Open

Allow lists/tuples of tensors to get tagged as application inputs #1140

dwf opened this issue Aug 18, 2016 · 2 comments

Comments

@dwf
Copy link
Contributor

dwf commented Aug 18, 2016

Related to #1139 (which is my workaround to this issue for the time being), I'm in a situation where I have multiple, paired sets of inputs to an application but not necessarily a fixed number. It'd be nice if list and tuple arguments to an application method that contain tensors could have their contents sensibly tagged.

What I'm doing in my own code right now (I'm passing all my apply arguments via **kwargs here):

        _annotate = partial(copy_and_tag, brick=self,
                            call=application_call,
                            role=INPUT,
                            application_name=application_call.application.name)
        for kw, value in kwargs.items():
            if isinstance(value, (list, tuple)):
                kwargs[kw] = [_annotate(v, name='{}[{}]'.format(kw, i))
                              for i, v in enumerate(value)]
@dwf
Copy link
Contributor Author

dwf commented Aug 18, 2016

I think the cleanest thing is probably to just do an isinstance check on the variable argument in copy_and_tag recurse if a list or tuple is found. We could also make this behaviour configurable in the Application constructor as pass it as an argument to copy_and_tag.

@dwf
Copy link
Contributor Author

dwf commented Aug 18, 2016

(Actually, type(variable) in (list, tuple) would be safer since we know how to actually construct those objects, but not necessarily for subclasses; we could just assume that type(variable)(<sequence>) is the right constructor but this is dangerous.)

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

No branches or pull requests

1 participant