fix(python): Remove incorrect warning when using an IO[bytes] instance

[adamreeve]

Fixes #18417

When passing something like a gzip.GzipFile or zipfile.ZipExtFile, it's not possible to pass a file path instead. And since #17315, Polars will extract the underlying fileno for faster IO performance if possible, so it doesn't appear that this warning is useful any more.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 79.78%. Comparing base (ee9bafb) to head (70acf7b).
Report is 8 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #19154   +/-   ##
=======================================
  Coverage   79.78%   79.78%           
=======================================
  Files        1531     1531           
  Lines      208449   208431   -18     
  Branches     2913     2913           
=======================================
- Hits       166317   166303   -14     
+ Misses      41581    41577    -4     
  Partials      551      551           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[coastalwhite]

This warning might need to stay for windows.

[miccoli]

I fear I do not completely understand in which this situations this warning is meaningful.

If it's only to nudge a user to rewrite

with open(foobar, 'rb') as fp:
    df = pl.read_csv(fp)

as

df = pl.read_csv(foobar)

then a runtime user warning is overkill, in my opinion.

Please give me the opportunity to shoot myself in the foot without adding the annoyance of a warning!
More seriously, I think that only a very small number of polars user can benefit from this warning, so better drop it, and instead add a line in the user docs.

If there are other non-trivial situations in which this warning is useful, please forgive me for the added noise to this thread.

[adamreeve]

This warning might need to stay for windows.

I initially missed that the fileno optimisation was Unix only, but I still agree with @miccoli that the benefit of the warning seems minimal and it's probably more effort than it's worth to fix the false positives and detect when a file path could have been used.