Hi, @adrinjalali thanks for the comment. I have updated the code to reflect the needed changes for the issue. Please have a look. Thanks :)

I think we should discuss this more widely. So basically we're saying that integer column names are fine as long as we don't want feature names. What would that do once we propagate feature names?

I'd say as soon as we have to "look" at the feature names, we raise if they're not strings. We could raise in fit w/o feature name propagation if the user passes integer column names, but I'm okay with being "lazy" there ans raising only if they're used.

I am not sure whether it's merged. I have a suggestion. Do you think we should have a function that raises an error in utils?[or where ever common functions are being stored] For example:
function check_whether_X_has_interger_column_names:
if yes:
raise error
I am wondering if there would be other places where such a functionality check is required.
I would really like to hear what you all think ( @adrinjalali ,@arunavkonwar and @amueller).

I think this would be fixed in #17407

I'd say as soon as we have to "look" at the feature names, we raise if they're not strings. We could raise in fit w/o feature name propagation if the user passes integer column names, but I'm okay with being "lazy" there ans raising only if they're used.

I disagree and would fight not to have this solution. I don't care that what pandas does is bad. I'm happy to deprecate integer column names once pandas deprecated them [i.e. I veto this change so you can't do it without a core dev vote or convincing me :P ].

Closing as get_feature_names is deprecated in favor of get_feature_names_out.