Skip to content

Conversation

@CloseChoice
Copy link
Contributor

@CloseChoice CloseChoice commented Nov 9, 2025

This is PR builds on top of #7706 to revive the unfinished #6832 but isn't just cleaning up things, here are some important changes:

  • download_mode="FORCE_REDOWNLOAD" is interpreted as always creating a clean slate, that means that even if we already did:
load_dataset("<name>")
load_dataset("<name>", split="train", download_mode="force_redownload")

This makes sure that only the train dataset is available after executing both. This was different in the original PR, which proposed that train and test would be available.

  • download_mode="REUSE_DATASET_IF_EXISTS" is interpreted as only ever adding new data, never redownloading OR deleting other splits. This was different in the original PR, where
load_dataset("<name>", split="test")
load_dataset("<name>", split="train")

resulted in only the train data being available, which I deem very unintuitive and probably not what users want. Also I argue that this is just the first step to a more user friendly partial loading when specifying percentages (or maybe even single instances) via the ReadInstructions, and then doing

load_dataset("<name>", split="test[:10%]")
load_dataset("<name>", split="test[10%:]")

should result IMO in the whole dataset being cached locally without redownloads.

Furthermore this PR fixes a couple issues with the previous PR, e.g. a missing comparison and adding tests for the proposed changes in behaviour, which would both fail on @ArjunJagdale's original PR.

Todo:

  • update docs?

Future outlook (just my opinions and up for debate):
As mentioned before, I would see this as just a step towards the feature of partial percentage loading (though how the API should behave in that case is not entirely clear for me now) and maybe we could introduce another download_mode="FORCE_REDOWNLOAD_SPLIT", which makes sure that even if a split is specified, only the referenced split is redownloaded and everything else left unchanged, this would then allow users more granular control over what they want to redownload.
@lhoestq very curious to get your opinion on this.

Copy link
Member

@lhoestq lhoestq left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great ! Will try to review this asap :)

@ArjunJagdale you should check this out

@ArjunJagdale
Copy link
Contributor

@CloseChoice This looks great! You're absolutely right about the missing comparison - that's a critical bug I missed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants