ali_m

This is surely trolling? "Fullbody Ultrasonic Computational Tomography" has quite the acronym..

Yes, this only prevents the callee from mutating it, it can't provide a strong guarantee that the underlying mapping won't be changed upstream (and hence MappingProxyType can't be washable).

https://www.google.com/search?q=dutch+angle

Yes, some screen readers such as JAWS can be configured to use a different voice to represent bold text, for example. They can also use non-speech sounds to represent things such as HTML elements.

One of the things that really blew my mind is just how fast a proficient screen reader user can crank up the speed, e.g. https://soundcloud.com/freecodecamp/zersiaxs-screen-reader. It's totally unintelligible to me, and doesn't even sound much like human speech.

If you're no longer constrained by the speed and sound of normal speech all kinds of other interesting audio representations become possible.

I remember reading somewhere in a different HN thread that some tools use pitch to represent indentation depth. There are all sorts of audio cues that can be used to represent syntactic information about code.

I think ctypes shines when it comes to fast prototyping, since you can iterate on the python bindings without a compilation step. It can also simplify distribution since the bindings can be pure python. Where it's arguably not so good is performance and maintainability.

You can absolutely use numpy arrays with C functions using ctypes. Numpy has `numpy.ctypeslib` which takes care of some of the boilerplate involved.

If we're treating them as ordered containers then it really ought to be surprising and confusing that two dicts with the same elements in a different order are considered equal. Other ordered containers such as lists or tuples don't behave this way.

I'd use an `OrderedDict` in situations where I have a mapping where the order of elements is significant. `OrderedDict` signals intent much more clearly, and its `__eq__` method cares about order.

Dicts already have confusing half-ordered, half-not semantics. As of 3.7 they are guaranteed to be insertion-ordered, but operators like == don't care about order.

I don't think it's that simple. No one acts 100% rationally all of the time. In this respect, addicts, children, and the mentally unwell differ from the rest of us by degree - they may have diminished responsibility for their own actions, but I don't think it makes sense to try to draw a sharp line where you're either responsible for your own actions or you're not. Recovery from addiction requires assuming responsibility for one's actions.

One fairly common convention is to suffix with `_` to avoid shadowing, e.g. `input_`

And they are dancing, the board floor slamming under the jackboots and the fiddlers grinning hideously over their canted pieces. Towering over them all is the judge and he is naked dancing, his small feet lively and quick and now in doubletime and bowing to the ladies, huge and pale and hairless, like an enormous infant. He never sleeps, he says. He says he’ll never die. He bows to the fiddlers and sashays backwards and throws back his head and laughs deep in his throat and he is a great favorite, the judge. He wafts his hat and the lunar dome of his skull passes palely under the lamps and he swings about and takes possession of one of the fiddles and he pirouettes and makes a pass, two passes, dancing and fiddling at once. His feet are light and nimble. He never sleeps. He says that he will never die. He dances in light and in shadow and he is a great favorite. He never sleeps, the judge. He is dancing, dancing. He says that he will never die.

I think there's a beauty in the bleakness. Some of the descriptions are just so vivid, like a charcoal sketch.

He came forward, holding his belt by one hand. The holes in it marked the progress of his emaciation and the leather at one side had a lacquered look to it where he was used to stropping the blade of his knife. He stepped down into the roadcut and he looked at the gun and he looked at the boy. Eyes collared in cups of grime and deeply sunk. Like an animal inside a skull looking out the eyeholes. He wore a beard that had been cut square across the bottom with shears and he had a tattoo of a bird on his neck done by someone with an illformed notion of their appearance. He was lean, wiry, rachitic. Dressed in a pair of filthy blue coveralls and a black billcap with the logo of some vanished enterprise embroidered across the front of it.

The line about how the "holes in [his belt] marked the progress of his emaciation" is seared into my brain forever.

No, you have to carry the fire

I'm sure they'd love to carry guns around

Some of them would, but perhaps not a majority. When the Police Federation most recently surveyed their members on this question in 2017 [1], 66% were opposed to routinely arming officers with firearms (although that number is down from 82% in 2006).

[1] https://www.polfed.org/our-work/operational-policing/firearm...

I agree, although I'm not sure if it's partly an unflattering screenshot. To me some of the lowercase letters look a bit indistinct (especially the 'e's and 'a's).

I think one of the challenges with stellarators is that they are harder to simulate due to the twisted geometry of the chamber (with a tokamak you can often simulate a single 2D slice of the torus).

If you can turn it into a collection of STL or MSH files then you can simulate it in MuJoCo. There are some caveats - MuJoCo will use the convex hull of the mesh for collisions, so if you want to accurately simulate collisions with concave features then you'll need to split your mesh into convex submeshes (there are various third party tools that can automate this). Sometimes you need to tweak the mesh geometry a bit in order to get the right contact behaviour, and in some cases it's easier to use primitives for key collision geometry and just use the meshes for visualisation.

This is a completely new model that was entered in CASP14 and published in Nature.

The default function itself should throw KeyError on values that are logically not in the dict (including, due to Python’s dynamically typed nature, those which are outside of the key domain because of type.)

That's not how `defaultdict` works - the key isn't passed to the default factory, so there's no opportunity for it to raise a `KeyError` if the key doesn't "logically belong" in the dict. It's possible to get that sort of behaviour by overriding `__missing__`, but I very rarely see this sort of thing in the wild.

A more typical use case is something like `defaultdict(list)` as a convenient way to build a dict of lists. This is fine within a limited scope where it's obvious to the reader that they are dealing with a defaultdict that has special `__getitem__` semantics, however it's a bad idea to return a defaultdict to a caller who might be expecting a normal dict, and would be surprised that missing keys don't result in KeyErrors.

With `.setdefault(key, default_value)` it's unambiguous what we're trying to achieve - the reader doesn't need to know whether they are dealing with a defaultdict.

IMO defaultdicts are kind of dangerous, especially when passed as arguments to other calls that expect a normal dict. Silently returning a default value instead of a raising KeyError can lead to hard-to-find bugs.

I generally prefer to use .setdefault(key, default_value) with regular dicts, as it's much more explicit. If I do use a defaultdict for convenience, I will usually only use it within a limited scope, and if I'm returning it then I'll cast it back to a normal dict to avoid surprising the caller.

I'm not sure what you're getting at - if you agree with me that "independent" is clearer than "agnostic" then what's the problem? I could understand your objection if you felt that the replacement word was somehow less clear, but if it's at least as good or better then why _not_ mandate its use in a style guide?

I get the impression that most of the people who are complaining in the comments here are really getting worked up about some inferred political bias, rather than because they actually disagree with the substance of the style guide.

I think this is about clarity rather than political correctness. Used in this context, "agnostic" is basically just a bit of jargon that's used where what we really mean is "independent". The latter is a drop-in replacement, and I'd argue that it conveys the meaning more clearly.

Well, it's a policy document for Google developers, who presumably aren't free to just pick and choose which rules to follow.

I personally agree with ~95% of the list, and the other 5% seems too trivial to be worth arguing over. I couldn't care less about the motivation behind the rules (political or otherwise) as long as they don't sacrifice clarity, and I think that's basically true for everything in here.

I think the goal is to provide practical guidance to developers. Splitting it into N different lists seems strictly worse in this regard.

To be fair, it does say:

Ceph is a unified, distributed storage system designed for excellent performance, reliability and scalability.

although it's annoyingly hidden away in a carousel. Carousels - not even once.

I'm in a very similar situation - I basically just slept through almost all of Good Friday. I really regret not spending a bit more for a flat with a garden or terrace - I used to mock my friends in London for being so proud of their pathetic little gardens, but since the lockdowns it doesn't seem so silly at all.

The hyperactive, glossy aesthetic is definitely similar, although I'd place Iglooghost closer to hip-hop/grime (e.g. "White Gum"). Sophie sounds more like a mutated version of chart pop music.

Well you probably do still want the type checker to at least look at the public interfaces of any libraries you depend on, since you want it to enforce that you're calling into them correctly.

Type annotations may be part of the language spec, but the way they are enforced is not. Different type checking libraries have made different design choices (leniency vs strictness, type inference vs gradual typing etc.). Although these differences don't matter at runtime, they do mean that code which passes one particular type checker might fail with another.