ENH: read_html support dtype param

[holymonson]

Is your feature request related to a problem?

To prevent casting str to float. read_json, read_csv, read_table have all supported dtype param already , read_html should not be left behind.

Maybe related: #21379 #30589

[alexprincel]

It seems like a simple change. read_html() could have an additional optional argument for dtype and pass it on to _parse() which will pass it on to _data_to_frame(), TextParser and TextFileReader (same class used by read_csv()) via kwargs.

On another note, read_html() "manually" passes every parameter it receives on to _parse() one by one. read_csv() handles this by calling locals() and pass the (modified) result on to _read(). This seems less convoluted and more flexible.

If the above seems sensible, I can give it a shot.

Edit: I made the edit suggested in my first paragraph in a local environment and it does behave as expected (further testing required). I'm willing to work a bit more on it and submit a PR if this enhancement and the proposed approach are validated.

[alexprincel]

Looking at the code and read_html a bit more, there is the converters parameter which works similarly. Does this solve your issue @holymonson ? If so, then maybe this is more of an inconsistency in the API instead of a lack of feature.

[holymonson]

Looking at the code and read_html a bit more, there is the converters parameter which works similarly. Does this solve your issue @holymonson ? If so, then maybe this is more of an inconsistency in the API instead of a lack of feature.

converters requests knowing columns list in advance, but yes I can make some tricks to get around this. Your view of "an inconsistency in the API" makes sense, IMHO, all the read_* should only handle reading data, and then leave all the type-converting and data-mangling to a common internal function.