There’s an earlier bit that complements that nicely:

“it turns out that the core competency of smiling and promising people things that you can’t actually deliver is highly transferable.”

BukakkIP

In the U.S., you can build rockets all day long, they cannot be guided.

https://www.law.cornell.edu/uscode/text/18/2332g

You’d have to convince the feds it was never designed to be a weapon. Good luck with that.

💀

Yeah, never said it was, just that if you really want to emulate that style you mostly can.

x = foo(y:=bar(), baz(), y) or z should work assuming foo bar and baz are functions being called?

if this is setting y to the effect of bar() + running baz after, then:

x = [bar(), baz()][0] or z

might work

and if you need y to be defined for later use:

x = [(y:=bar()), baz()][0] or z

but thats from memory, not sure if that will even run as written.

if I get to a real computer I'll try that with an actual if statement instead of a bastardized ternary.

“a = x if foo else y” is a perfectly cromulent statement!

iPython makes experimenting in an interactive manner so easy, I use it every day.

Up until now most people hated when shit randomly popped up while they were typing.

The Apple went and made the iPhone and now we have a whole generation that expects it.

Have you considered writing your own projects that you have to hide from your employers, and be careful with whom you discuss, so as to avoid the legal complications of the company owning your work?

so far

I’m gonna need a bell curve hooded figure meme template of this comment, this is comedy gold.

Time is an illusion, lunch time doubly so.

absolutely.

I would say it’s pretty accurate across the grid, but I’d swap HDD and ram. HDD is chaotic neutral, because it can turn into a maraca at any moment.

A repo dedicated to non-unit-test tests would be the best way to go. No need to pollute your main code repo with orders of magnitude more code and junk than the actual application.

That said, from what I understand of the exploit, it could have been avoided by having packaging and testing run in different environments (I could be wrong here, I’ve only given the explanation a cursory look). The tests modified the code that got released. Tests rightly shouldn’t be constrained by other demands (like specific versions of libraries that may be shared between the test and build steps, for example), and the deploy/build step shouldn’t have to work around whatever side effects the tests might create. Containers are easy to spin up.

Keeping them separate helps. Sure, you could do folders on the same repo, but test repos are usually huge compared to code repos (in my experience) and it’s nicer to work with a repo that keeps its focus tight.

It’s comically dumb to assume all tests are equal and should absolutely live in the same repo as the code they test, when writing tests that function multiple codebases is trivial, necessary, and ubiquitous.

It’s not uncommon to keep example bad data around for regression to run against, and I imagine that’s not the only example in a compression library, but I’d definitely consider that a level of testing above unittests, and would not include it in the main repo. Tests that verify behavior at run time, either when interacting with the user, integrating with other software or services, or after being packaged, belong elsewhere. In summary, this is lazy.

I am humbled by your chess of many D’s.

You don’t even need to support anything older than the last windows hot fix with requirements like that.

like, even bash, cat, ls, etc?