@dmartinol Ended up having to make changes all over. Maybe you can find time to look through.

That's mostly to accommodate the linter for now, I should probably add more feast-specific exceptions (for example if a user is asking to materialize an odfv, which doesn't make sense)

On a general note, I found that we have a following trade-off here:

• When get_feature_view returns all types a lot of most common operations become cleaner to implement, for example when a user is passing a list of fv names that might be any one of them, we no longer need crazy exception handling to figure out which method to call.
• In some other less common cases when only a single fv type makes sense, we will now have to check the type of the object returned, we can no longer rely on the fact that registry method used would do that for us. When we drop py3.9, we should probably start using python match statements for this.

Despite the trade-off, I still think it's a worthwhile change. Still wanted to get your opinion.

• In some other less common cases when only a single fv type makes sense, we will now have to check the type of the object returned, we can no longer rely on the fact that registry method used would do that for us. When we drop py3.9, we should probably start using python match statements for

It we really have this need, can't we apply an optional filter to return only instances of the requested type with no need to further check?
Really pseudo-code:

fv :  StreamFeatureView = fs.get_feature_view(name=..., accept_type=StreamFeatureView)
...

fvs: list[StreamFeatureView] = fs.list_feature_views(...,  accept_type=StreamFeatureView)
for fv in fvs:
    ...

It we really have this need, can't we apply an optional filter to return only instances of the requested type with no need to further check?

Let me look into this. This is actually probably a better idea since we'll definitely need something like this for list_feature_views method anyway, so why not here as well? I was just trying to keep the interface simple, because of the chain of changes this causes in registry server and so on.

P.S. I'm afraid linter issues won't go away even in this case. type annotation will have to be BaseFeatureView and some asserts here and there will be necessary.

P.S. I'm afraid linter issues won't go away even in this case. type annotation will have to be BaseFeatureView and some asserts here and there will be necessary.

Can't we surround it by cast? (asserts of accept_type can be hidden in the methods for all the clients):

fv :  StreamFeatureView = cast(StreamFeatureView, fs.get_feature_view(name=..., accept_type=StreamFeatureView))