I hate to say it, but there is a third contender: workers

SciPy tends to use just workers rather than num_workers (e.g. in scipy.fft functions, differential_evolution and quad_vec). For FFTs, it also provides a context manager that can be used to control the default number of workers, which I think is nice. See scipy.fft.set_workers. Adding workers to more functions is in their roadmap.

I think I actually like just workers the best, but don't have a problem with any of the three as long as we use it consistently within scikit-image!

Right, workers also makes sense of course. And it's more a question of workers rather than jobs, so for the sake of clarity I'd prefer either workers or num_workers (not proposing n_workers which would be a really good name, but we don't want to multiply the number of names in the ecosystem).

So, who is for workers and who is for num_workers?

Right, workers also makes sense of course. And it's more a question of workers rather than jobs,

Jobbers ? :)

To be more serious, workers looks sufficient, but num_workers is more explicit, I immediately understand that I'm supposed to pass an integer.

About n_* and num_*, we have both in the lib (n_dim, n_bins, n_inliers, n_tiles) and (num_trials, num_shapes, num_peaks, num_channels, ). A preference must be added to #2616

I'd vote to maintain the consistency throughout the packages: maybe workers is the way to go?

To be consistent with the ecosystem, this requires some careful deliberation.

@thomasjpfan wrote up a good overview of the state of the ecosystem. I see he recommends workers as well.

scikit-learn is currently on n_jobs, and scipy on workers.

Thanks for the link. To quote from that page

We use SciPy’s workers parameter because it is more consistent in controlling the number of cores used. workers denotes any form of parallelism such as: multi-threading, multiprocessing, OpenMP threads, or pthreads.

This argument works just as well in favor of num_workers if you replace "SciPy" with "dask". num_workers seems the more expressive name to me (we are not passing actual workers). But workers is fine with me as well and SciPy is probably closer to us than dask. I really don't care that much about which solution we settle on as long we don't stall this again for a few years. 🤞

How can we move this along with regards to #7302? I'm happy to involve the ecosystem but how do I do that? According to New SPEC Proposals this might be a good fit for a SPEC. I'll make a post in https://discuss.scientific-python.org/c/specs/ideas/9 if there's no objection.

This does seem like exactly the kind of thing we need to agree on across projects, so +1.

Posted this as a SPEC idea in Terminology for parameters controlling parallel computation.