Note to reviewers, for some reason this file had Windows-style CRLF line endings. This PR only changes the content of first 2 cells.

this is where I wish we had much nicer / easier API to get the same output with much less boilerplate.

We could use a for loop instead of repeating calls. However this is outside of the scope of this PR.

cc @MarcoGorelli 🥳

🥳 nice!

(when I saw I had a notification from scikit-learn, my first thought was "oh no this is gonna be another grid-search cv_results_ issue?" 😅 )

Two questions about this:

• should we use sha256 argument? What's the worst that can happen if we don't use it? Using a corrupted file and have a weird error? Using it in this example kind of makes fetch_file look not super convenient to use. Originally I thought by looking at the code in this example that the sha256 was required but it's not.
• I am guessing the URL is likely to change (my understanding is that this is some kind of OpenML internal details), but we can wait and see if that actually happens.

should we use sha256 argument? What's the worst that can happen if we don't use it? Using a corrupted file and have a weird error? Using it in this example kind of makes fetch_file look not super convenient to use. Originally I thought by looking at the code in this example that the sha256 was required but it's not.

I think it's good to use the sha256 argument here for two reasons:

• it makes it explicit to detect when the upstream dataset changes: some changes in the upstream data could be such that the example still runs without error but the analysis of the results in the example or plots would become invalid.
• it teaches readers about this good practice of always checking the integrity of stuff you download on the open web.

I am guessing the URL is likely to change (my understanding is that this is some kind of OpenML internal details), but we can wait and see if that actually happens.

OpenML URLs that include the dataset id should always server the same contents because new dataset versions get a different id on openml.org.

OK fair enough, let's leave it like this then!

One weird thing in particular, I think, is that there is no way to know the sha256sum in advance in the OpenML parquet case, but maybe one day there will be one.

Apparently this means "representative sample" for those who wonder 😉

It's so meta, like the original contents of the corrupted file ;)

Just curious, here it seems like you are using NamedTemporaryFile only to get a filename, right?

Is it important to use delete=False, I guess maybe this is for Windows (glancing over the doc: https://docs.python.org/3/library/tempfile.html#tempfile.NamedTemporaryFile)?

Just curious, here it seems like you are using NamedTemporaryFile only to get a filename, right?

And create the temporary file in a concurrency-safe way.

Is it important to use delete=False

Because we rename the file at the end. If we keep the default delete=True we get an error because the original file no longer exists when the temporary file object gets garbage collected by Python.

Maybe there is a way to add in the comment that the delete on garbage-collection is only for Python<3.12.

I was a bit confused by your explanation, because I was reading the Python 3.12 doc and delete_on_close=True by default, so I was thinking but then it's deleted at close.

Turns out delete_on_close is a new parameter in Python 3.12 ...

We need to close to be able to call shutil.move. I hadn't realized that delete_on_close existed in 3.12 but it's ignored when delete=False.

Not sure how to improve the comment. I think mentioning the 3.12 only delete_on_close option that we don't use would be more confusing than helpful.

I decided to add a dedicated inline comment before the line where we close temp_file in anticipation: bed8515.

OK good enough I think, thanks!

I looked a bit more and the behaviour is Python version specific, for example in Python 3.11 there is a traceback with the following snippet (moving a NamedTemporaryFile before it is deleted) but not in Python 3.12:

import tempfile
import shutil

tf = tempfile.NamedTemporaryFile(mode='w')

shutil.move(tf.name, '/tmp/new')
del tf

I miss the fact originally, that indeed NamedTemporaryFile ensures that the file name does not already exist so that is a protection when calling this function in parallel.