Or, maybe just tell them the JWT they’ve got is expired, and ask them yes or no if they want the new (current) price instead, and update it transparently if they say yes.

Based on this, it seems like you’re suggesting to move the logic closer to the frontend and leave the auto-refetching logic out of the backend?

The more I look at the responses, the more I feel this is a front-end problem to be solved rather than the backend’s.

I think the idea was that if they managed to get the private key, we have away bigger problems on our hands than them submitting fraudulent orders. Even with server-side tokens, the same could happen if someone get access to your machine.

Actually, we are controlling both ends. But the issue is that frontend have rather limited bandwidth most of the time (sadly the truth is that despite that your own team wants to make things clean, other teams may not have the same stance).

I think the idea was that as long as it is within 5 min, our service can be certain that the price shouldn’t change and thus we can save the computation cost of having to compute the price.

It also is a user requirement, cause within that 5 min, even if the price is supposed to be changed, we will still use the price in the JWT.

What are the alternatives to a JWT. I know it is a bit bloated and we could just use the HS256 signature itself, but that doesn’t really change the core problem of expiry vs auto-refetch

Oh, ticks are rare in my region, that’s why I have no prior experience with them.

I was thinking in the context of us slapping the mosquito would be equivalent to slamming a thumbtack into your skin which could increase the damage dealt and penetration depth.

Oh, I didn’t knew you can pass 2 is. I was depending on the tab completion from pacman, but I didn’t see that it says you could specify i’s

Ah, it worked. I thought Qi only works for packages that are already installed. Didn’t knew it worked for things that are synced as a new dependency of a package

ok, here you go https://pastebin.com/uPc5S1LU

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.

Data shouldn’t drive the program in this way.

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), over compute_price_with_discount() + compute_price_without_discount()

You’ve basically spelled:

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 given
• quite a few functions in numpy returns different things based on flags. SVD will return S if compute_uv=False and S,U,V otherwise

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.