Allow len(x) for select and data parameters with multiple="true"

[bernt-matthias]

For select parameters len(str($x).slipt(",")) seemed to be the best solution so far. Now we can just len($x).

Data parameters already had len() (via list), but returned 1 since it was treated as [None] for optional parameters without a value. This behavior is preserved for profile versions. From profile 26 we have [].

How to test the changes?

(Select all options that apply)

• I've included appropriate automated tests.
• This is a refactoring of components with existing test coverage.
• Instructions for manual testing are as follows:
  1. [add testing steps and prerequisites here if you didn't write automated tests covering all your changes]

License

• I agree to license these and all my past contributions to the core galaxy codebase under the MIT license.

[mvdbeek]

That seems wrong ? Nothing selected for an optional parameter (independently of multiple="true") should be None, not a list of anything, so len should just fail if we want to improve the situation.

[mvdbeek]

That seems like the thing to fix ? list|None is the type i'd assign to an optional list, not list[HDA|None]

[bernt-matthias]

I would suggest [] in case nothing is in it.

The advantage would be that one can still use it in a conditional bool([]) = False if needed, but one can also just start a for loop without checking for None.

[bernt-matthias]

Another argument for this solution might be that it is consistent to the select case.

[mvdbeek]

This seems so wrong. An optional multi-select without a provided value should also be None. If we merge this the only chance to get this right is yaml tools that don't run through this module :(.

[bernt-matthias]

I have to admit, that I never understood the intention of this module. Where outside of the cheetah command block of XML tools are these wrappers used? Output filters for instance already seem to get None for selects already: #4221 (which was criticized there). Wondering what they get for optional data parameters :)? Funnily I also used null in the test definition, xref #19325.

So, there are definitely more arguments pro None in terms of consistency in addition to get more similar to yaml tools.

I'm just a bit afraid that we will need to touch quite a few tools ... and that the codebase needs quite some changes (i.e. more than I have time).

This seems so wrong. An optional multi-select without a provided value should also be None.

Just for my understanding. I'm wondering if a tool form can differentiate between the two case to not provide a value and provide an empy selection. Could be useful #9203, #14635.

• Message to myself: need to change XML docs for data parameters:

Unfortunately, if 0 datasets are selected the resulting value for the parameter during Cheetah templating (such > as in a command block) will effectively be a list with one None-like entity in it.