I thought about it, but it isn’t as expressive as I wished.
Meaning if I do
a = foo(return_more=True)
or
a, b = foo(return_more=False)
it doesn’t catch these errors for me.
In comparison, the other suggested solution does catch these.
I thought about it, but it isn’t as expressive as I wished.
Meaning if I do
a = foo(return_more=True)
or
a, b = foo(return_more=False)
it doesn’t catch these errors for me.
In comparison, the other suggested solution does catch these.
yea, this is pretty close to what I’m looking for.
The only missing piece is the ability to define the overload methods on the bool
something like
@overload
def foo(return_more: True) -> (Data, Data)
@overload
def foo(return_more: False) -> Data
But I don’t think such constructs are possible? I know it is possible in Typescript to define the types using constants, but I don’t suppose Python allows for this?
EDIT: At first, when I tried the above, the typechecker said Literal[True]
was not expected and I thought it was not possible.
But after experimenting some, I figured out that it is actually possible.
Added my solution to the OP
Thanks for the tip!
but from a practical perspective, let’s say you retrieve an object and can either return a subset of its fields as your API. Doesn’t it make sense to re-use the same function, but change what fields are returned?
I’m specifically talking about the narrow use-case where your API returns either A or B of the fields, and won’t extend it in the future
The alternative is to either duplicate the function, or extract it out which seems a bit overkill if it is only 2 different type of functions.
I think there’s a spectrum here, and I’ll clarify the stances.
The spectrum ranges from “Data shouldn’t cause the function to do (something wildly) different” to “It should be allowed, even to the point of variable returns”
I think you stand on the former while I stand on the latter. Correct me if I’m wrong though, but that’s the vibe I’m getting from the tone in your example.
Suppose we have a function that calculates a price of an object. I feel it is agreeable for us to have
compute_price(with_discount: bool)
, overcompute_price_with_discount() + compute_price_without_discount()
I feel your point your making in the example is a bit exaggerated. Again, coming back to my above example, I don’t think we would construe it as
compute_price('with_discount')
.Maybe this is bandwagoning, but one of the reason for my stance is that there are quite a few examples of variable returns.
eg:
getattr
may return a different type base on the key givennumpy
returns different things based on flags. SVD will returnS
ifcompute_uv=False
andS,U,V
otherwise