Closed bosonie closed 4 years ago
Yes, I didn't realise this.
There's only one situation where assuming this could go wrong: if you expose an iteration_input that makes an input port of _process_class
not needed. At the moment it seems like it would be a rare and easily spottable situation, so it could be solved "manually". Even if that's not the case, a future commit could solve the problem easily. So I'd say there's no problem!
In this case the iteration_input
method should take care of making the correct input port not needed. Not sure how. I guess the easiest solution would be to implement that iteration_input
accepts a list of keywords that needs to be transformed into "not_required"
Yes, but I don't think it's necessary at least for the time being. I would guess it's difficult to find a situation where creating an iteration_input makes an input port optional. It think it would be more common that it makes the input port useless, in which case you can exclude it.
The feature to impose the exposed input ports to be "not-required" was due to the fact that users can now iterate over this ports name, defining them in the
iterate_over
dictionary. However, when theiterate_over
port is not accepted (new feature implemented recently), it has no sense to impose that the exposed inputs are not-required. This commit fixes the problem. @pfebrer96 Do you agree??