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).
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.
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.
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.
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).
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.
> 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.