Nobody has to do anything, least of all massive corporations with country-sized revenues. It's /always/ a choice to comply or to put up a fight and deal with the consequences.
I can transfer money from Europe to Brazil in seconds with Wise. I press the button and the money is nearly instantly available in the Brazilian account via PIX. The same in the reverse direction is possible but only if you have a more modern bank in Europe, eg. N26 or Revolut.
I was thinking more of gp's comment "and the first user is an Argentinian bike importer that finds transacting with their suppliers to be challenging"
Wise isn't great for paying suppliers. Their business account limit for debit/credit is $2k, and for ACH is $50k. They have higher limits if you fund with wire, but then we're back at the starting problem again...
And still, you have no way of knowing that the receiving party actually got it. On a blockchain, the source-of-truth "database" is public.
My understanding is that Wise isn't a true international transfer. Wise has money already in a Brazilian account, and when they receive money in their European account then they send you money from their Brazilian account. If they don't have enough money in that Brazilian account then it can't be instant like it is today.
Not the full picture:
Wise is that big that it has already lots of local accounts and/or correspondent banks; so basicly "you get the money from Wise" but from a "local payment way/scheme" (to which Wise is connected in the background through several layers)
that we need one company to achieve such big scale that they literally are regulated in every single country and basically become monopolistic in terms of their influence?
a Blockchain based system can maintain similar effects but with a balance of power
Google's core product has always been advertisement. They sell advertisements to companies looking to advertise, and they bring in tens of billions in revenue from that business. In effect, their core product is you: they're selling your eyeballs.
If the bait that they used to bring you to them so they could sell your eyeballs has finally started to rot and stink, then why do people continue to be attracted by it? You claim they've ruined their core product, but it still works as intended, never mind that you've confused what their products actually are.
1.0 is not an upgrade, it's the first stable release. Usually it signifies the arrival of some amount of feature completeness and stability compared to the fast paced 0.x days. Of course semver doesn't really fit neatly most software let alone a user facing GUI application, but socially that's what they're trying to communicate with the 1.0.
These days those versioning is just PR and doesn't mean much like if something is stable. Gmail used to have beta mark for how many years but was still used. Rect native is 0.79 but doesn't mean it's not production ready.
This is a weakness of the Python typing system and not necessarily of individual typecheckers. Pyright has a policy of only implementing what's standardized, and the Python type system is simply inadequate to annotate most real world Python code out there. It's been years now and something as basic as properly typing kwargs is still not supported.
Ty could solve this if they rebel and decide to ignore the Python typing standards, which I honestly would appreciate, but if they take the sensible approach and follow the standards, it won't change anything.
Python code feels like back in the day when JavaScript was typed using JSDoc comments, and libraries would use all kinds of fantastical object shapes for their option parameters, so users could pass "just about anything" and it would work. You would never know how to configure an Express app without digging through the documentation, for example.
I loathe the Python convention of just using kwargs instead of clearly annotated parameters; most libraries don't even have doc comments in the code, so you're really required to look up the documentation, hope that it actually describes the method you're interested in and contains more than stuff like "foo: the foo to use"—or fall back to rummaging in the library intestines to figure out how it works.
I'm not sure into what kind of industry you're in, but having most functions as (args, *kwargs) is not the way I deal with most of my code and the libraries I work at all (backend development). Everything is typed fully.
Maybe you're in a niche spot, or using scientist-based code. I've seen plenty of trainwrecks in 'conda-only' ""libraries"" done by scientists. Maybe that's the niche you're at?
Sometimes, though, you may get lucky, and find some tests for the code you want to use!
On a more serious note, I can't even blame library devs as long as they try. Type "hints" often are anything but _just_ hints. Some are expected to be statically checked; some may alter runtime behavior (e.g. the @overload decorator). It's like the anti-pattern of TypeScript's enums laid out here and there, and it's even harder to notice such side-effects in Python.
Git natively supports excludes in all pathspecs, e.g. `git log -- ':!generated/'` to exclude files in the `generated/` folder from showing up in the log.
In a practical example you'd create a named intermediate type which becomes a new base for reasoning. Once you convinced yourself that the first part of the chain responsible for creating that type (or a collection of it) is correct, you can forget it and free up working memory to move on to the next part. The pure nature of the steps also makes them trivially testable as you can just call them individually with easy to construct values.
