Click "parent" a few times and look at the code example that started this thread. It's using the same function in a way that can't distinguish whether the user intentionally used a string (including an f-string) and a t-string.
Yes, and the parent is misguided. As was pointed out in multiple replies, the library can distinguish whether an ordinary string or a t-string is passed because the t-string is not a string instance, but instead creates a separate library type. A user who mistakenly uses an f prefix instead of a t prefix will, with a properly designed library, encounter a `TypeError` at runtime (or a warning earlier, given type annotations and a checker), not SQL injection.
In this particular instance it can't, because there are 3 ways in question here, and it can't distinguish between correct intentional usage and accidental usage of an f-string instead of a t-string:
db.execute("SELECT foo FROM bar;")
db.execute(f"SELECT foo FROM bar WHERE id = {foo_id};")
db.execute(t"SELECT foo FROM bar WHERE id = {foo_id};")
The first and second look identical to execute() because all it sees is a string. But the second one is wrong, a hard-to-see typo of the third.
If f-strings didn't exist there'd be no issue because it could distinguish by type as you say. But we have an incorrect SQL-injection-prone usage here that can't be distinguished by type from the correct plain string usage.
My (and their) point is that's the already existing API. You're proposing a big breaking change, with how many frameworks and tutorials are built on top of that.
It's not like this is the first time APIs have been improved. There are many tools (e.g. deprecation warnings & hints in editors, linter rules) that can help bridge the gap - even if t-strings are only used for new or refactored code, it's still a big improvement!
There's also simply no hard requirement to overload an `execute` function. We have options beyond "no templates at all" and "execute takes templates and strings", for example by introducing a separate function. Why does perfect have to be the enemy of good here?
As I said in another comment, normal cards are easy. The issue is with everything else where each card might have a picture with different animals and you are looking for the lama giving you the bird.
I think it is very doable for card games with thousands of different cards like MTG. I remember there was an old school SIFT/SURF image retrieval system that was able to deal with tens of thousands of album covers super fast. That was more than 10 years ago IIRC.
If the manufacturer is willing to provide the entire db of cards or a well-trained model that could be embedded or a ready mobile app, that would be great. However, waiting on them is not a winning strategy. The other option is community contributions, but you need a large community. This will be welcomed as well, but again not something that should be relied on. Both developments would be wonderful to happen, however in the meantime I'm looking for something cheap, fast, and easy to implement that I can do on my own in the local scope of my deck.
For some of the card games I am familiar with (Netrunner, MTG) there are resources online (wikis, dbs, deck builders) that have all the graphic assets. Alternatively, you can scan or photograph each card in your deck, but that may be time consuming.
As for software, there are engines out there that do content-based image retrieval (CBIR) out of the box [1]. It should be possible to build something quickly in OpenCV. You may be able to get away using simple image template matching by putting a few constraints on how the camera sees each card. Something more robust can be also be build using image descriptors and approximate nearest neighbors, as in [2].
Nassim Taleb wrote a whole book (Skin in the Game) under a similar premise: “Never trust anyone who doesn’t have skin in the game. Without it, fools and crooks will benefit, and their mistakes will never come back to haunt them.”
Sounds like an interesting book. I will check it out. I am wondering if in it, he addresses voting rights? Please don't mistake my retelling of history for bias when I say that before 150 years ago, voting in the United States was limited to white male property owners. The race and sex restrictions are not relevant to my point, but restricting voting to property owners was a prime example of ensuring "skin in the game".
Well, those who live under a modern government have skin in the game in the sense of paying taxes and relying on infrastructure, services, and regulation that make day to day civilization a thing.
True, but property owners pay property tax, which is a big part of where city revenue comes from. Allowing renters to vote on how the money is spent creates the same issue described in the grandparent post.
Money is fungible. Renters have skin in the game, because they paid tax (and because they live in the general society that those tax dollars are being used on). That they paid no property tax is not relevant, because it ceases to become "property tax" as soon as it's paid, and just enters a larger general pool.
People may have differing levels of skin in the game, but it's no more sensible to say that property tax should only be spent on things property owners want than it is to say that property tax paid by people named Dave should only be spent on things that The Council of The Daves want it to be spent on.
It's relevant for the same reason that it's relevant who pays a hospital bill. The person actually making the payment will be sensitive in ways that a pure beneficiary will not be.
You had a reasonable point, till you veered off into fantasy land that renters aren't just as much in the game if not more so. If anything landowners are generally the problem and renters are the majority population.
You're defining skin in the game as everyone "in the game", making the term rather unnecessary.
Skin in the game means a risk of losing some investment you brought to the table, not just losing the ongoing benefits and downsides the game itself provides.
