`allow_dask_compute` argument of `lazy_xp_function` domain

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