pl.lit(1) is type Int32 but pl.lit([1]) is type Int64

[cmdlineluser]

Checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of Polars.

Reproducible example

import polars as pl

pl.select(a = 1)
# shape: (1, 1)
# ┌─────┐
# │ a   │
# │ --- │
# │ i32 │
# ╞═════╡
# │ 1   │
# └─────┘

Log output

No response

Issue description

list types default to Int64 which is documented as the expected type.

It seems like the non-list version should be Int64 also?

pl.select(a = [1])
# shape: (1, 1)
# ┌───────────┐
# │ a         │
# │ ---       │
# │ list[i64] │
# ╞═══════════╡
# │ [1]       │
# └───────────┘

Expected behavior

dtype of Int64?

Installed versions

--------Version info---------
Polars:               0.20.1
Index type:           UInt32
Platform:             macOS-13.6.1-arm64-arm-64bit
Python:               3.11.6 (main, Nov  2 2023, 04:39:40) [Clang 14.0.0 (clang-1400.0.29.202)]

----Optional dependencies----
adbc_driver_manager:  <not installed>
cloudpickle:          <not installed>
connectorx:           0.3.2
deltalake:            <not installed>
fsspec:               2023.6.0
gevent:               <not installed>
matplotlib:           3.8.2
numpy:                1.26.2
openpyxl:             <not installed>
pandas:               2.0.3
pyarrow:              12.0.1
pydantic:             2.5.2
pyiceberg:            <not installed>
pyxlsb:               <not installed>
sqlalchemy:           <not installed>
xlsx2csv:             0.8.1
xlsxwriter:           3.1.9

[stinodego]

This is an optimization. The return type of lit depends on the input. For integers, the logic is as follows:

• If it fits in Int32, it's Int32
• Else if it fits in Int64, it's Int64
• Else it's UInt64

You could argue similar logic should apply to nested integers as well. I'm not 100% convinced.