API: lazy_xp_function: rename `allow_dask_compute` to `max_dask_computes` and adjust accepted values

[ev-br]

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.

[lucascolley]

cc @crusaderky

[crusaderky]

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]

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]

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]

I suggest:

• Renaming allow_dask_compute to max_dask_computes or something of similar meaning
• Having max_dask_computes=0 yield the current behavior of allow_dask_compute=False
• Using max_dask_computes=None for the current behavior of allow_dask_compute=True

I 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. None gives a natural value to mean no limit on dask computes.

[lucascolley]

I suggest:

• Renaming allow_dask_compute to max_dask_computes or something of similar meaning
• Having max_dask_computes=0 yield the current behavior of allow_dask_compute=False
• Using max_dask_computes=None for the current behavior of allow_dask_compute=True

I 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. None gives a natural value to mean no limit on dask computes.

thanks Albert, that looks nice to me!

[crusaderky]

I suggest:

• Renaming allow_dask_compute to max_dask_computes or something of similar meaning
• Having max_dask_computes=0 yield the current behavior of allow_dask_compute=False
• Using max_dask_computes=None for the current behavior of allow_dask_compute=True

I 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. None gives a natural value to mean no limit on dask computes.

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]

I suggest:

• Renaming allow_dask_compute to max_dask_computes or something of similar meaning
• Having max_dask_computes=0 yield the current behavior of allow_dask_compute=False
• Using max_dask_computes=None for the current behavior of allow_dask_compute=True

I 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. None gives a natural value to mean no limit on dask computes.

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).

do you fit the criteria @ev-br :) ?

[steppi]

@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.