Repository navigation
API: lazy_xp_function: rename allow_dask_compute to max_dask_computes and adjust accepted values #415
Description
lazy_xp_function' accepts its allow_dask_compute argument as either bool or int where True is equivalent to a very large integer:
allow_dask_compute : bool | int, optional
Whether `func` is allowed to internally materialize the Dask graph, or maximum
number of times it is allowed to do so.
This is very much unexpected. First of all, bool | int typing is equivalent to just int. So I'd expect that either False is converted to zero, or an int gets converted to a boolean via bool(allow_dask_compute).
Since the "number of times" is non-negative, I'd very much expect to express "any number of times" as -1 or just negative.
Activity
lucascolley commentedon Sep 8, 2025
cc @crusaderky
crusaderky commentedon Sep 8, 2025
False (do not allow) and 0 (allow 0 times) are equivalent.
I'm against -1 as a special value for inifinity, because it's lesser than 0 and it is not intuitive what it means.
"allow=True" on the other hand is intuitive. It is allowed, full stop, do not trip on it no matter how high. "allow=False" is also intuitive: crash immediately no matter how small the infraction.
allow_dask_compute=True is actually a second iteration of this design. The first iteration was allow_dask_compute=999, which a lot of people found confusing, so I added the option for bool.
I'm against changing this. "bool | int" being a redundant alias for "int" is a design flaw of python typing which has already been extensively discussed elsewhere, and IMHO not worth arguing about here.
lucascolley commentedon Sep 8, 2025
While I agree with the sentiment that a single type would be nicer than a (fake in this case...) union type, I'm still pretty happy with the current state, and don't feel that this is worth making a change.
ev-br commentedon Sep 8, 2025
I'll just note that IMO this is the case where each individual step might make sense and is intuitive, but the final result does not and is not intuitive.
steppi commentedon Oct 18, 2025
I suggest:
allow_dask_computetomax_dask_computesor something of similar meaningmax_dask_computes=0yield the current behavior ofallow_dask_compute=Falsemax_dask_computes=Nonefor the current behavior ofallow_dask_compute=TrueI think any lack of clarity goes away if the variable name matches the meaning of the values rather than suggesting a boolean when the values are counts.
Nonegives a natural value to mean no limit on dask computes.lucascolley commentedon Oct 18, 2025
thanks Albert, that looks nice to me!
[-]`allow_dask_compute` argument of `lazy_xp_function` domain[/-][+]API: lazy_xp_function: rename `allow_dask_compute` to `max_dask_computes` and adjust accepted values[/+]crusaderky commentedon Oct 23, 2025
I'm happy with this.
Now we just need to find someone who is irked enough by the current syntax to implement it (with deprecation system and scipy migration on top).
lucascolley commentedon Feb 23, 2026
do you fit the criteria @ev-br :) ?
steppi commentedon Feb 23, 2026
@lucascolley. Following the decision in scipy/scipy#24205, my impression is that this has become moot for SciPy developers until Dask support is re-prioritized.
lucascolley commentedon Aug 12, 2026
going to transfer this to a discussion, makes sense to keep it discoverable in case Dask support is re-prioritised I suppose