Since both transformers map from a collection of feature vectors to a distance graph, the "output features" would just be the distance to each point of the fitted data right? This would be very verbose and potentially unwieldy for what I imagine the intended use of get_feature_names_out.

So the two obvious (not necessarily great) solutions to this I see are:

• Make it so that each output feature name is the distance to point in the fitted data (e.g. output features = columns of distance graph).
• Make it so there is a single output feature, which is just the entire distance graph.

Part of me thinks the more "romantic" solution would be to have n_neighbors -many output features, where each describes the (sorted) n_neighbors many non-zero distances but I don't really think that makes sense given that the output of the transformers is a distance graph.

I'm leaning towards the first option (output features = columns of distance graph).

For KNeighborsTransformer, n_neighbors is fixed a priori. That should answer your comment above.

For KNeighborsTransformer, n_neighbors is fixed a priori. That should answer your comment above.

I guess my question is more-so: since the outputs of KNeighborsTransformer and RadiusNeighborsTransformer are distance graphs, is it sufficient to treat them as returning n_samples_fit_ output features, and to then assign them class-prefixed feature names, as does my current implementation?

I guess my question is more-so: since the outputs of KNeighborsTransformer and RadiusNeighborsTransformer are distance graphs, is it sufficient to treat them as returning n_samples_fit_ output features, and to then assign them class-prefixed feature names, as does my current implementation?

Yup, the number of feature names out must match the amount of output features from transform.

Added in the unit tests! Thank you for all your active feedback, and for your patience in this. Let me know if there's anything else I should add here!