Some objections against dictionaries are:

• the set of keys is not obvious (nor is their case sensitiveness);
• The meaning of missing keys might also not be obvious;
• Extra or mistyped keys are not immediately detected (if at all);
• Static type checking can't catch any errors in the dict;

Another idea to return intermediate objects when we call predict and only materialize it on direct query.

block_prediction = pipeline.predict(ds).isel(x=slice(0,10), y=slice(0, 17)).result()
# this kind of block interaction is nicer to read imo
predictor = pipeline.Predictor(ds)
computed = []
for block in tile(ds.shape, 256):
     tile_prediction = predictor.isel(**block).result()
     computed.append(tile_prediction)

it would also play nicer if we have multi-value returns

Some objections against dictionaries are:

* the set of keys is not obvious (nor is their case sensitiveness);

* The meaning of missing keys might also not be obvious;

* Extra or mistyped keys are not immediately detected (if at all);

* Static type checking can't catch any errors in the dict;

I agree, there are some nice pro's tho:

• builtin type, anyone knows how to interact with them (I would say this is the strongest argument for dicts, also that xarray implements indexing with dicts is a plus).
• once you're in a notebook, no static type checking will help you (well, there might be tooling though that I don't know, can you mypy live in notebooks these days?)
• There is TypedDict (we'd have to upgrade Python though, or add yet another dependency)

Another idea to return intermediate objects when we call predict and only materialize it on direct query.

What I liked about the first iteration of the api is that was a single call to get a prediction. That is staying with the original predict interface. I could imagine something like this as part of a blockwise_predict function? With this isel method, that would return a future...

builtin type, anyone knows how to interact with them

this is only half-true, though. dict is indeed a builtin, but we don't just take ANY builtin dict; We take a very particular type of dict, which the user will have to learn to build. And he can do that either by reading English ("roi is a Dict[str, Tuple[in, int]] where the keys are in "xyztc" "), or by reading python:

def __init__(self, x: Tuple[int, int], y: Tuple[int, int], z: Tuple[int, int], c: Tuple[int, int], t: Tuple[int, int])

which comes with the added boni that the second version can have explicit default values and does not silently accept bad keys

once you're in a notebook, no static type checking will help you

True that, but basic python functionality will still work. This produces no errors at the call site:

predict(roi={"X": (100, 200), "y": (300, 400)})

While this:

predict(roi=CustomRoi(X=(100, 200), y=(300,400)))

immediately throws a "TypeError: Got an unexpected keyword argument: X" , right at the call site.

There is TypedDict

I guess that could also work; the syntax is indeed more ergonomic at the cost of runtime validation. But if ever we need to add some validation in the constructor or add some methods to the rois (enlarge, split, get_tiles, etc), we're back to a custom Roi class

How about we hide that from users and offer mypy compatibility:

RoiDict = TypedDict('RoiDict', {"x": ..., "y", ....}, total=False)

class Classifier:
    ...
    def predict(roi: RoiDict):
        croi = CustomRoi(**roi)

Wouldn't this be way nicer for users?