Philipp S. Sommer

> What we plan here is more a disruptive 2.0 version to me - I want to rethink this as a whole. Sounds good to me and I am happy...

> Because you mentioned backward compatibility before wrt using input or infile(): IMO we can drop it. Yes, I agree, then we should drop the `infile` method entirely, and just...

> I wrote a short article about the introduction of brackets on the command line for special cases where the parenthesis-free version limits what you can do: in the case...

yes, but as far as I understand the new ` [ ] ` notation, it also forces to specify all input streams in this call. So something like ```python cdo.add(infile=cdo.fldmean.topo('global_0.2'))...

Considering the brackets in the `'+'` operation. I think the best possibility would be to allow strings in this operation and then let the user insert the brackets where he...

> We should not have both I guess. So you mean we should not implement the `+` operation at all, right?

> hm, this looks more and more like string processing Well, we could also use pythons `__getitem__` method and specify input parameters with `[]`: ```python cdo.add[cdo.fldmean.topo('global_0.2') + cdo.fldmax.topo('global_1')] ``` or...

but personally I do not like this approach to much, because one normally uses this so subset an array which is different than specifying input parameters to an operator call

> yes, it doesn't really tell what it's doing 👍 So I propose the following strategy: 1. The recommended usage for input streams is to specify them with the `infile`...

> we concentrated on the input, but what about output? So at the moment this is implemented in the `run` method and I would leave it there. I think this...