This is about the one thing where SQL is a badly designed language, and you should use a frontend that forces you to write your queries in the order (table, filter, columns) for consistency.
UPDATE table_name WHERE y = $3 SET w = $1, x = $2, z = $4 RETURNING *
FROM table_name SELECT w, x, y, z
It's because unicode was really broken, and a lot of the obvious breakage was when people mixed the two. So they did fix some of the obvious breakage, but they left a lot of the subtle breakage (in addition to breaking a lot of existing correct code, and introducing a completely nonsensical bytes class).
Python 2 had one mostly-working str class, and a mostly-broken unicode class.
Python 3, for some reason, got rid of the one that mostly worked, leaving no replacement. The closest you can get is to spam surrogateescape everywhere, which is both incorrect and has significant performance cost - and that still leaves several APIs unavailable.
Simply removing str indexing would've fixed the common user mistake if that was really desirable. It's not like unicode indexing is meaningful either, and now large amounts of historical data can no longer be accessed from Python.
The problem with mailing lists is that no mailing list provider ever supports "subscribe to this message tree".
As a result, either you get constant spam, or you don't get half the replies.
The problem is that there's a severe hole in the ABCs: there is no distinction between "container whose elements are mutable" and "container whose elements and size are mutable".
(related, there's no distinction for supporting slice operations or not, e.g. deque)
I guess I forgot to mention the other implicit difference in concerns:
When you are a game, you can reasonably assume: I have the user's full focus and can take all the computing resources of their device, barring a few background apps.
When you are an application, the user will almost always have several other applications running to a meaningful degree, and those eat into available resources (often in a difficult-to-measure way). Unfortunately this rarely gets tested.
I'm not saying you can't write an app using a game toolkit or vice versa, but you have to be aware of the differences and figure out how to configure it correctly for your use case.
(though actually - some purely-turn-based games that do nothing until user enters input do just fine on app toolkits. But the existence of such games means that game toolkits almost always support some way of supporting the app paradigm. By contrast, app toolkits often lack ready support for continuous game paradigms … unless you use APIs designed for video playback, often involving creating a separate child "window". Actual video playback is really hard; even the makers of dedicated video-playing programs mess it up.)
The problem with XCB is that it's designed to be efficient, not easy. If you're avoiding toolkits for some reason, "so what if I block the world" may be a reasonable tradeoff.
There's tends to be one major difference between games and non-game applications, so toolkits designed for one are often quite unsuitable for the other.
A game generally performs logic to paint the whole window, every frame, with at most some framerate-limiting in "paused" states. This burns power but is steady and often tries hard to reduce latency.
An application generally tries to paint as little of the window as possible, as rarely as possible. Reducing video bandwidth means using a lot less power, but can involve variable loads so sometimes latency gets pushed down to "it would be nice".
Notably, the implications of the 4-way choice between {tearing, vsync, double-buffer, triple-buffer} looks very different between those two - and so does the question of "how do we use the GPU"?
1, Don't target X11 specifically these days. Yes a lot of people still use it or at least support it in a backward-compatible manner, but Wayland is only increasing.
2, Don't fear the use of libraries. SDL and GTK, being C-based, should both be feasible from assembly; at most you might want to build a C program that dumps constants (if -dM doesn't suffice) and struct offsets (if you don't want to hard-code them).
It’s solving (and facing) some very interesting problems at a technical level …
but I can’t get over the dumb decision for how IO is done. It’s $CURRENTYEAR; we have global constructors even if your platform really needs them (hint: it probably doesn’t).
Stop reinventing the wheel.
Major translation systems like gettext (especially the GNU variant) have decades of tooling built up for “merging” and all sorts of other operations.
Even if you don’t want to use their binary format at runtime, their tooling is still worth it.
All of these can be done with raw strings just fine.
For the first pathlib bug case, PATH-like lookup is common, not just for binaries but also data and conf files. If users explicitly request ./foo they will be very upset if your program instead looks at /defaultpath/foo. Also, God forbid you dare pass a Path("./--help") to some program. If you're using os.path.dirname this works just fine.
For the second pathlib bug case, dir/ is often written so that you'll cause explicit errors if there's a file by that name. Also there are programs like rsync where the trailing slash outright changes the meaning of the command. Again, os.path APIs give you the correct result.
For the article mistake, backslash is a perfectly legal character in non-Windows filenames and should not be treated as a directory component separator. Thankfully, pathlib doesn't make this mistake at least. OTOH, / is reasonable to treat as a directory component separator on Windows (and some native APIs already handle it, though normalization is always a problem).
I also just found that the pathlib.Path constructor ignores extra kwargs. But Python has never bothered much with safety anyway, and this minor compared to the outright bugs the other issues cause.
The problem with pathlib is that it normalizes away critical information so can't be used in many situations.
./path should not be path should not be path/.
Also the article is wrong about "Path('some\\path') becomes some/path on Linux/Mac."
I’ve done something similar. In my case it was a startup script that did something like the following:
git fetch for your main development branch (the one you perform the real merges to) and all pull/ refs (git does not do this by default; you’ll have to set them up for your local test repo. Note that you want to refer to the unmerged commits for these)git bisect for this since you explicitly do not want to try commit from the middle of a PR. It might be simpler to whitelist or blacklist one commit at a time, but if you’re failing here remember that all tests are unreliable.I likewise don’t really use Godot, but for graphics in general, the 4th coordinate is important, even if it is “usually” 1. It’s most obvious to correctly interpolate near the poles of a sphere with a single rectangular texture, but think for a minute what “near” means.
Back to the main point though: the important things we normally rely on for matrix math are associativity (particularly, for exponentiation!) and anticommutativity (beware definitions that are sloppy about “inverse”).
Related, note that division is much slower than multiplication.
Instead of:
see if you can refactor it to:
where that inverse can then be hoisted out of loops.