In its more colloquial sense, I can see why you prefer to call that "answering" questions rather than "finding" facts.

However, it's silly to quibble over the parent thread's author's usage of "found" when it's the dominant phrasing used in the legal system.

But that movie just dragged on, and now I look back and see it as a bungled opportunity. It could've been so much tighter in the edit. They could've cut a third of the movie and made the whole thing so much better.

If module A has a small intended public API, you can structure it no matter how you want to achieve that. You can put those internal symbols behind their own object/class/module if you prefer.

Using `__all__` has one functional consequence, which is `from A import *`. Again, I would avoid * imports entirely, but if you want to try to curb possible downstream problems from users who do indeed use * imports, I would also prefer not defining `__all__` because it's extra boilerplate you have to maintain and can very easily be missed on future updates.

And please, just don't use * imports. It really doesn't save you much time at the cost of implicit untraceable behavior. If you don't worry about * imports, you don't need to add the __all__ boilerplate to every module.

This article is more about advertising a package called tach, that I suppose tries to add "true" private classes to Python.

But it doesn't actually enforce anything, because you still need to run their tool that checks anything. You could just easily configure your standard linter to enforce this type of thing rather than use a super specialized tool.

On the way to changing my mind, I learned that the Fundamental Theorem of Algebra only works for complex numbers (and not "real" numbers), the beauty and simplicity of rotations in the complex plane, but maybe most convincing to me was a history lesson about quaternions.

Quaternions are an extension of the complex numbers, but they're not typically taught in higher math education these days, which contradicted my resentment that mathematicians were just obsessed with getting more and more abstract and general for the sake of it. Of course, they were in vogue in the 19th century (Maxwell's equations were originally written down using them), but mathematicians soon realized they just weren't as useful or as "nice" philosophically as complex numbers and just about anything you can accomplish with quaternions were better accomplished with vectors of complex numbers.

That story played a big part in persuading me that there really is something special about complex numbers -- that maybe they're the most "natural" or "real" numbers of them all.

> I assume from this that 23andMe is reporting the results to this level of accuracy (a tenth of a percent). For the sister who got 2.6% they are strongly implying a certainty that she has a small amount of French and German ancestry rather than what actually seems to be the case which is a small chance of some French and German ancestry.

You picked out the single biggest discrepancy they report in this article, and yet even that doesn't seem to indicate an actual inconsistency to me. I would tend to interpret those results to mean that for one twin, they felt sufficiently confident to call a portion of their DNA "French and German", while in the other it fell below that confidence threshold so it got thrown into the "Broadly European" share.

This process already pretty much precludes objective perfection just based on what they're reporting. What does it mean for your ancestry to come 2.6% come from France? During what time period? What if it's on the border in one of those regions that switched hands several times? These are subjective decisions they have to make but it doesn't invalidate the whole test because occasionally you have enough evidence to call portion of your DNA "French and German" and sometimes you have to fallback to just calling it "Broadly European".

It's not like they're fully sequencing every DNA sample they get.

> AncestryDNA found the twins have predominantly Eastern European ancestry (38 per cent for Carly and 39 per cent for Charlsie). But the results from MyHeritage trace the majority of their ancestry to the Balkans (60.6 per cent for Carly and 60.7 per cent for Charlsie).

This part of the article especially seems like hair splitting considering the Balkans and Eastern Europe tend to have a lot of overlap. In fact, "Balkans" in particular is an extremely ambiguous linguistic term and can mean so many different things to so many people.

Git preserves history as it happened on the remote, which is what matters for collaboration. Why foul up the canonical history up with what amounts to scratch paper? Typically, people only amend local history if they feel it would easier to follow later. Why take that option out of their hands?

The way I do work and the way I submit it are two separate problems with overlap. I use git for both and it works beautifully. Even for personal non-code projects I never intend to collaborate with others, I still use git because it promotes a workflow I'm comfortable with.

On the team I'm in, the convention is to include code changes in the same commit as any test changes. There are advantages and disadvantages, but it's the convention, and it's best we follow it or else it might lead to CI problems. But, in my personal workflow, I tend to try to change the tests, commit, code changes, commit, and then iterate. With git, this is as simple as doing it however which way I want, and then squashing the commits together before pushing. What do I do with Fossil?

I'm trying to figure out what problem it's trying to solve with this, and it just comes off as hollowly idealistic.