No analogy is perfect. They are intended to help illustrate a concept to gain insight. Ideally when using an analogy its limits should also be described. Luckily the very first link after the analogy is explained does just that: http://hyperphysics.phy-astr.gsu.edu/hbase/electric/watcir3.....
My understanding was that if you write a regular function (`def` rather than `async def`) then FastAPI (or really Starlette which it uses under the hood) executes the function in a thread pool so that no blocking of the main event loop should occur.
If for no other reason, pytest requires a lot less boilerplate.
Pytest fixtures are also quite a bit more flexible than unittest's setUp and tearDown methods, although they take a little while to really understand (at least they did for me) since they use some magic.
> think of all the years of unnecessary education they'd pile on to dentistry and the bottle necks they would put up to raise the wages to MD level.
That seems more an indictment of the medical education system than the insurance system. There are already parallel medical education systems in the US (MD vs. DO, although there is little practical difference). Seeing either type of physician is treated equally by health insurance. Why can't health insurance also cover DDS visits as well?
Matplotlib's main API is pretty terrible. But it's just fine for the simple plots that scientists and engineers are often needing (e.g., just plot y vs. x). It's also pretty straightforward to get publication-quality plots. Bokeh can handle simple plotting and more complex visualizations, but it is aimed mostly at interactive visualizations rather than plotting for publication. For now, matplolib is the only real option for that in the Python world.
Matplotlib inherits most of its baggage from originally being meant to mimic Matlab plotting that many were then familiar with. As an aside, I find the pandas interface to plotting with matplotlib to generally be much easier to work with.
TortoiseHg is completely different than TortoiseGit, despite the similar names (and logos). While the latter is an assortment of context menus and dialogs, THG has this plus a great "workbench" which combines everything into one. It's easily possible to use THG alone without ever touching the command line which is a rather nice feature when trying to convince non-programmers to use version control. If there was a git equivalent, I'd happily use it.
Cython is intended for making Python extension modules. So if the end goal is to make something that you interact with only from Python, then Cython is a good choice. You can still use it to simply wrap some existing library, but ctypes or cffi might then be a bit simpler since it they don't require an added compilation step.
I was a loyal Gnuplot user for many years until I got fed up with a bug where tick labels wouldn't be centered with ticks in LaTeX output without some manual hacks. I can see from one of the posts that this issue still exists.
Plus it was easier to just do everything in Python and not have to use a separate process to plot in the end.
Nevertheless, I still find it useful. Nothing else seems as easy to quickly plot an analytical function: `gnuplot -p -e "sin(x)"`
I don't know, and I find this rather frustrating. I write a lot of tools to monitor devices in the lab via a web interface and often want to see updates every 10-100 ms. The only library I have found that seems to be up to the task is [Flot](http://www.flotcharts.org/) (and I've looked into a lot of options). My main complaints about it are its reliance on jQuery (which I am not otherwise using) and its lack of recent development (although it seems fairly feature-complete).
I was using tmux for a while after years of using screen. At least for my use case, the main thing I liked better about tmux was that windows (or whatever the proper term is) get their names updated based on the command running. In screen, I would have to manually change the name (maybe there is a way around this but I was always too lazy to find out).
Why I switched back to screen:
1. It's more commonly installed. Not a big deal these days, but still.
2. It's really easy to resize a window to fit whatever terminal window I'm using: C-a F. As far as I could find, there is no way to do this with tmux.