spoonbill

Here is another prediction: the volume of that bet would be nowhere near where it needs to be to make the bet interesting.

Disagree? Create the bet yourself and prove me wrong.

If most people prefer pyproject.toml over requirements.txt, even if it does not support everything you need, isn't it more likely that you will have to change workflow rather than python remaining stuck with requirement.txt?

I was asking why you need to have a centralized pyproject.toml file, which is apparently why you need constraint files? Most people don't have this workflow, so are not even aware of constraint files, much less see them as a must-have.

Why do you need to have a centralized pyproject.toml?

My only use case so far has been fixing broken builds when a package has build-)ldependencies that don't actually work (e.g. a dependency of a dependency breaks stuff). Not super common, but it happens.

But pyproject.toml supports neither locking nor constraints.

Constraints are useful for restricting build dependencies of your dependencies, especially if they follow PEP-518.

How does HATEOAS deal with endpoints that take arguments? E.g. I have an endpoint that merges the currently viewed resource with another one? Does it require a new (argumentless) endpoint showing a form where one can enter the second resource? Wouldn't it be quite inefficient if you have to now do two (or more) requests instead of just one?

I really struggle to see where HATEOAS can be used. Obviously not for machine to machine uses as others have pointed out. But even for humans it would lead to terrible interfaces.

If the state of the resource changes such that the allowable actions available on that resource change (for example, if the account goes into overdraft) then the HTML response would change to show the new set of actions available.

So if I'm in overdraft, some actions are not available? Which means they are not shown at all? How can a user easily know that there are things they could do, it it wasn't for the fact that they are in a specific state? Instead of having disabled buttons and menus, with help text explaining why they are not usable, we just hide them? That can't be right, can it? So how do we actually deliver a useable UX using HATEOAS?

Or is it just meant for "exploration", and real clients would not rely on the returned links? But how is that better than actual docs telling you the same but much more clearly ?

I'm taking a broad approach? The article is literally about the FCC. You know, the Federal Communications Commission. That applies to the entire country.

Data caps are on all plans.

Nonsense. There are lots of plans without caps. Maybe not where you live, but at most that means caps should be banned where you live. IMHO it makes much more sense to require offering a cappless plan, rather than banning capped.

Edit: Googling for "capless internet usa" gives as the first result https://broadbandnow.com/guides/no-data-caps, listing several providers.

Indeed two companies is not really competition. So why not focus on that, instead of reducing choice, which may lead to even less competition by making differentiation harder?