It's loading untrusted python different from loading untrusted dll/so? Unless your use some dedicated sandbox, I think they're equally insecure. I guess a bigger problem with native plugins is that they're not (usually) platform independent.
I don't understand the question about empty values. A row with there empty values is just:
,,
And yeah, dealing with separators is annoying, but pretty much every reader supports quoted values and escapes (not every writer cares up add them, though).
In practice I use csv to process large amount of tabular data (like logs, events, etc) where I care about greppability and performance more than about potential for 0.001% of corrupted data. YMMV of course, if getting it 100% right is important use something else (JSON is not without sins too, consider that JSON numbers are often parsed as floats).
My part of my work is data ingestion and I've seen all these (and more) as answers to the "empty values" question.
I'm not saying that other formats aren't without their problems, they certainly are. However, CSV doesn't just have those problems, it has multiple other problems on top of them.
It's a basic idea with really obvious edge cases addressed in multiple ways depending on who is producing these documents.
CSV is extremely underspecified, but that doesn't mean it deserves the blame for software that fails to implement even the one thing it inherently specifies. A sequence of tabs is one value in a CSV. A sequence of semicolons is one value in a CSV. Any software that thinks otherwise is buggy, and unfortunately that includes some extremely popular software that is supposed to be good at tables (Excel).
Also, in general, people are quick to insult others online. Somehow it's easier to degrade someone online than I'm person, and there's less incentive to look for the common ground.
There are actually a bunch of studies that explore the role of mass media, in particular the radio, in the spread of Nazi propaganda in the years before Hitler came to power.
The radio played a big role in the Rwandan genocide as well.
Mass media was central to fascism because fascism requires the ability to build collective consensus over a broad geography that wasn't easy before mass media. It's hard to otherwise align the morality of millions of people.
I share the concern that social media will be like this, but more potent. And it won't just be a distribution channel, it'll be a breeding ground for the ideas that create extremist ideologies in the first place. It's like the wuhan wet market, but for ideas. The ideas that come from this breeding ground are not necessarily good ideas, just popular ones. And fascism is one subset of bad ideas that have been historically popular.
I think you're confused about the difference between [x]*4 and [x for _ in range (4)]. It's not, at any point, a difference between something being a value or reference.
The first code is equivalent to:
list_multiply([x], 4)
(the function is actually called list.__mul__, but that's an unimportant detail). The latter is a syntax sugar for:
out = []
for _ in range(4):
out.append(x)
(actually a bit more complex, but close enough).
When you understand it, the behavior is obvious in both cases.
>That's the complaint, that [[]]*4 is not shorthand for list comprehensions and that it's something entirely different.
Well, of course. It's a shorthand for duplicating the list elements four times. In this case, the list contains a single reference to an empty list, do the result contains four references to an empty list.
And it's literally impossible for [[]]*4 to be a shorthand for a list comprehension, because nothing in Python can be a shorthand for a list comprehension. Instead, it is but a method call.
I mean, there is no reason Python couldn't special case something that looked like an operator call into shorthand for a comprehension instead of shorthand for a method call, other than the fact that it would make the parser more complex and make it harder to understand the language.
It would be bad for this case, though. As confusing as the particular case of:
[[]] * 4
might be to people who haven't learned how it works, list multiplication doesn't just apply to single element lists, and is useful and usefully distinct from what people are suggesting the behavior should be for the operation based on this one case.
Well, Python is not Raku, so while it could be possible to make "[expr1, expr2, ..., exprN] * exprM" to mean "[*(expr1), *(expr2), ..., *(exprN) for _ in range(exprM)]", it would never happen.
It's syntax sugar. I use it all the time, but of course it could always be respected by, i don't know, a for loop. It also makes writing duck typed code easier, as X3 will work for strings, bytes and lists.
Overall it's a very useful feature and I don't think it's that surprising. It's pretty obvious [x]4 will reuse the same reference. Just like manually adding "x" four times will.
I like how it looks, and I appreciate the effort that went into it, but other than using it to export a table in just a right format that you will then embed into your assembler directly, I'm not sure how to use it.
And I use opcode references [1] very often (sometimes daily, depending on the project). I even wrote my own disassemblers. But I mostly use opcode references for manual cross checking, so maybe I'm not a target of this project?
Musicians put their music on Spotify out of their own will. If they don't like it they can withdraw. Unless they sold the rights to a music label, but that's also their decision.
Can you explain your idea? Your algorithm is correct by definition, but doing this naively would be very slow (even for 32bit number). At this point it would be much faster to just binsearch it.
For an example of binsearch algo, I recently dipped into this while switching some code from floats to fixed point arithmetic (reducing overall wasm blob size)
