changed seeding when randomly sampling from List column since 1.33.0

[Bramtimm]

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

Probably a small regression, but it seems another seeding is used when sampling from a List column since 1.33.0.

df = pl.DataFrame({'a': [[1,2,3,4,5,6,7,8,9,10]]})
df.with_columns(pl.col('a').list.sample(1, seed=1).alias('sample'))

Log output

with 1.33.1

shape: (1, 2)
┌──────────────┬───────────┐
│ a            ┆ sample    │
│ ---          ┆ ---       │
│ list[i64]    ┆ list[i64] │
╞══════════════╪═══════════╡
│ [1, 2, … 10] ┆ [9]       │
└──────────────┴───────────┘

Issue description

I did not find any mention of this regression or change in the release docs, so thought it relevant to mention here. The samples seems to be consistent when repeatedly ran, so seeding seems to be still working.

Expected behavior

with 1.31.0

shape: (1, 2)
┌──────────────┬───────────┐
│ a            ┆ sample    │
│ ---          ┆ ---       │
│ list[i64]    ┆ list[i64] │
╞══════════════╪═══════════╡
│ [1, 2, … 10] ┆ [8]       │
└──────────────┴───────────┘

Installed versions

Details

--------Version info---------
Polars:              1.33.1
Index type:          UInt32
Platform:            Linux-6.6.87.2-microsoft-standard-WSL2-x86_64-with-glibc2.35
Python:              3.12.0 (main, Oct  3 2023, 01:27:23) [Clang 17.0.1 ]
LTS CPU:             False

----Optional dependencies----
Azure CLI            <not installed>
adbc_driver_manager  <not installed>
altair               <not installed>
azure.identity       <not installed>
boto3                1.36.3
cloudpickle          3.1.1
connectorx           <not installed>
deltalake            <not installed>
fastexcel            <not installed>
fsspec               2025.7.0
gevent               <not installed>
google.auth          <not installed>
great_tables         0.15.0
matplotlib           3.10.0
numpy                2.3.2
openpyxl             3.1.5
pandas               2.2.3
polars_cloud         <not installed>
pyarrow              19.0.1
pydantic             2.11.7
pyiceberg            <not installed>
sqlalchemy           <not installed>
torch                <not installed>
xlsx2csv             
0.8.4
xlsxwriter           <not **installed>

--------Version info---------
Polars:              1.31.0
Index type:          UInt32
Platform:            Linux-6.6.87.2-microsoft-standard-WSL2-x86_64-with-glibc2.35
Python:              3.12.0 (main, Oct  3 2023, 01:27:23) [Clang 17.0.1 ]
LTS CPU:             False

----Optional dependencies----
Azure CLI            <not installed>
adbc_driver_manager  <not installed>
altair               <not installed>
azure.identity       <not installed>
boto3                1.36.3
cloudpickle          3.1.1
connectorx           <not installed>
deltalake            <not installed>
fastexcel            <not installed>
fsspec               2025.7.0
gevent               <not installed>
google.auth          <not installed>
great_tables         0.15.0
matplotlib           3.10.0
numpy                2.3.2
openpyxl             3.1.5
pandas               2.2.3
polars_cloud         <not installed>
pyarrow              19.0.1
pydantic             2.11.7
pyiceberg            <not installed>
sqlalchemy           <not installed>
torch                <not installed>
xlsx2csv             0.8.4
xlsxwriter           <not installed>

[Bramtimm]

seems to be related to #23387, i.e. seeding has changed in updated rand package; rust-random/rand#1580

Leave this open for now as it still can be relevant for others, but feel free to close. maybe an added python test to ensure consisently across versions for seeding might still be relevant though, happy to contribute :-).

[jchen2186]

Hi! Thanks for creating the issue! I believe I'm seeing the same issue as you so I'll add more details.

It looks like this unexpected behavior despite passing the same seed was introduced by #22619, which points to the new algorithm in an updated version of rand. It looks like there are tests that check for consistency across the versions, but they were updated to pass. This was introduced in polars 1.32.0 (confirmed with running your reproducible example on that version).

Questions for the maintainers:
This change breaks reproducibility for existing workflows that depend on consistent shuffle behavior across polars versions when using fixed seeds. Is this breaking change intentional? If so, would you consider adding a compatibility flag to preserve the old behavior?

[coastalwhite]

As far as I am aware, although I am unable to find an issue referencing it, we don't guarantee (seeded) randomness stability between versions. @orlp can probably confirm. It should probably be referenced somewhere in the docs.

[orlp]

Oh, we absolutely do not. The seed only guarantees that for a specific version of Polars the result is the same from run to run.