Series.is_in called with a mixed list of Python integers and floats fails about polars HOT 4 CLOSED

Thank you for the explanation.

from polars.

The python list get passed to the Series constructor which defaults to strict=True since 1.0.

You can directly pass it to the Series constructor with more lenience:

>>> s = pl.Series([1, 2, 3, 4])
>>> s.is_in(pl.Series([2, 2.5], strict=False))
shape: (4,)
Series: '' [bool]
[
	false
	true
	false
	false
]

I think we should expose the strict argument to the is_in expression so that we can do s.is_in([2, 2.5], strict=False). Then that error message makes sense again.

from polars.

Implicit casting from integer to float64 (when the integer is inside the exact-representable range for a float64) is a standard in many systems (e.g. NumPy, base R, both do this -- Python and many programming languages implicitly cast integers to float in arithmetic operations, etc.), do you have anything written up on what motivated this decision so I can understand the reasoning?

Given how I was impacted in a very innocuous setting of passing a deserialized JSON array of numbers to is_in, I would guess that this could become a sharp edge for many users.

from polars.

Polars is strict about data types. And dynamic user input can lead to data type bugs down the line. We want to catch those bugs at the source.

E.g. if you read in [1] you get a Int64 column, then next time you run the query on other json data and you get [1, 2.0] and the data is inferred to be Float64, but Polars will fail somewhere else because you expected an integer type.

Polars will guard you from that by being strict by default. You can opt-out of it, or even better set the dtype you want the input to be parsed as.

from polars.