No he just made a mistake.

As usual, readers reading too much into something.

I know it's unrelated because this has an actual explanation, but I had an ex that stopped watches simply by wearing them for a while.

The model didn't matter, give them a few weeks, and they would stop. Put them aside for a while, they started back.

Never could figure out why, no particular behavior emerged, she changed jobs and houses and I couldn't see a pattern.

Fun that life is still full of weird stuff like this.

Reminds me of the Pauli effect https://en.wikipedia.org/wiki/Pauli_effect

> the supposed tendency of technical equipment to encounter critical failure in the presence of certain people

Is there an inverse of this?

Often times, people ask me to help them do something on the computer or with other computer related or electronic things. I walk over, touch the equipment without actually doing anything and their problem is instantly solved. Could be a printer that won’t print, even!

I don’t see any links in the See Also section about any “effect” like this.

That would be "Demonstration Effect" or "IT Support Effect". Happens every other support call.

I bet this is why half the older companies still have a tech person on staff. :-)

Fascinating. Did she work in medical / hard science? I could imagine some exposure to radiation / magnetization could do this.

Nope. Hotel, then airplanes.

Maybe using their watch hand to magnetize the hotel key cards?

I thought about it but their colleagues would have had the same problem, yet didn't. Plus becomming flight attendant removed that activity.

Not to mention it happened during the hollidays too.

It's probably more life style related, but I was there during said life style and couldn't figure it out.

Maybe some sort of magnet phone mount.

Even if the companies took security seriously (which they don't since it rarely affects their bottom line, even in the event of a breach), it's one of the hardest topics in IT, and there are very few people actually competent in it.

With the explosion of the number of those boxes, we added more surface of attack, but the number of good security people didn't increase.

Yes, there is: https://gcollazo.com/optimal-sqlite-settings-for-django/

Awesome, thanks.

I think @flexterra (aka gcollazo) should also add `"check_same_thread": False` to the recommended OPTIONS, right? Unless they left it out intentionally?

Well, you gotta balance all that tax evasion with something.

Once it ends, we will buy more GPUs because any small website will want its own.

I know that as soon as I can output 100req/s on the cheap on a llama-level model I will put it EVERYWHERE. And my clients too.

DMCA handling? Content flagging alerts? Fuzzy categorization? Natural UI for end user complex queries?

All LLM baby.

And much, much more.

Swift won't be able to compete with rust until it has a great scripting story.

Rust is currently the defactor choice if you want to make something with js/python bindings, of id you want to speed up a dynamic bottleneck because it makes it super easy.

Swift doesn't even have a good ffi.

Swift can import C (and C++) modules directly, and it's fairly straightforward to wrap existing C APIs with callbacks to be usable from structured concurrency. Here's an example I just worked on. [1]

[1] https://github.com/PADL/NetLinkSwift

This is not what holding swift.

What's holding swift is not having a good story to call a swift compiled extension from Python/JS/Ruby/PHP.

Python's community is huge, very active, Python is everywhere, and it needs compiled extensions. And tooling to make them BFF, like pyo3 and maturin, is great

And that's how we got cryptography, pydantic core, polar... Which motives even tooling to be written in rust as a side effect, and how we have uv and ruff.

The scripting community is the most active, if you got them on your side, you get access to a huge pool of devs.

I'm not sure scripting-language interop is holding back Swift, but ...

> call a swift compiled extension from Python/JS/Ruby/PHP

The story there is excellent.

Here's a Swift function callable from C

    @cdecl("myfunc")
    public static func f(){...}

C/C++ types are mostly handled automatically (including sharing memory management), but it can be tricky.

To build a library to load and call from any language:

    swiftc mine.swift -emit-library -o libmine.dylib 

E.g., calling from java 22 FFI:

https://foojay.io/today/java-panama-polyglot-swift-part-2/

But most people instead use a slower json server network interface because (sadly) json is the lingua franca for scripting and Swift Codable makes it trivial to map the json to a swift type.

What Python needs is to catch up to SELF, Smalltalk, Common Lisp, and either embrace PyPy, or finally get a mature JIT into CPython.

Thankfully, Facebook and Microsoft are making it happen.

Yes, but it's a completely unrelated matter: even with a JIT you'll want compiled extensions since you can't beat hand crafted SIMD for the scientific stacks or machine learning.

Ever heard of intrinsics?

Maybe spend some time reading about other JIT languages expose SIMD to developers, without requiring folks to go down to C.

Which incidentally is what all those Python DSLs for GPGPU APIs also do, with the caveat of not being that useful for general purpose programming outside machine learning algorithms.

Try to make Rust interop with C++, C and Objective-C as easy as Swift does it.

This is a big deal. In reality, most of the code that powers your systems (phones, tablets, any computers) is built using C and C++, regardless what OS you use.

Agreed, and rust-c interop is as good as any other I've used. The c++ interop was clunky but getting much better with crates like zngur. That is what was holding back its use on chrome for a while. Oddly its python interop is way better with pyo3 and maturin making it super easy.

C++ is (IME) an order of magnitude more annoying from Rust than C or Objective-C. I've dealt with interop of the latter two on a number of projects and frankly found them to be fine.

(Though I wouldn't fault anyone for making an argument that Swift is still more ergonomic here)

swift-wasm exists

Most rubists like the optional parenthesis, but I suspect must devs don't.

Add functools to the list. Espacially functools.wraps() and functools.partial().

The stdlib is full of goodies.

Now I always appreciated the battery included logic in python. But I noticed this week that LLM diminish that need. It's so easy to prompt for small utilities and saves you from using entire libraries for a few tools.

And the AI can create doc and tests for them as quickly.

So while I was really enthusiastic things like pairwise() were added to itertools, it's not as revolutionary as before.

If you’re saying that LLMs trade idiomatic tools for ease-of-boilerplate-generation, shouldn’t that be a point against them, not in their favor?

Pardon the hyperbole but it’s a bit like lauding an IDE for automatically generating thousands of Java class stubs.

For decades you had the famous itertools recipes taunting you in the doc: https://docs.python.org/3/library/itertools.html#itertools-r...

They were super useful, but not included in the stdlib, despite being a few lines long.

We also had more-itertools, bolton, and others, to bridge that gap.

Now, there was always a tension between adding more stuff to the stdlib, or letting 3rd party libs handle it. Remember the saying: the stdlib is where projects go to die.

And of course tensions about installing full on 3rd party libs just for a few functions.

The result is that many people copy/pasted a lot of small utilities, and endless debates on python-ideas to include some more.

I think this is going to slow down. Now if you want "def first_true(iterable, default=False, predicate=None)", you ask chatgpt, and you don't care.

The cost of adding those into the project is negligeable.

It's nowhere near generating thousand of class stubs. It's actually the opposite: very targetted, specific code needs being filled instead of haunting python debates or your venv.

But to stimulate a bit your anxiety, I do think code gen is going also making a big comeback with LLM :)

Agreed, rewriting standard functions is much worse than using standard tools that already exist.

In addition to the extra boilerplate and reduced readability, that also sounds like an easy way to introduce subtle bugs. Standard library functions have been exhaustively field tested, a similar looking LLM generated function could easily include a footgun.

Sure, but have you tried to introduce a new standard tool in the stdlib?

It's not a fun process.

Writing the code is the easy part.

And installing more-itertools for one functions is a bit silly

I wish there were some syntactic sugar for partial but knowing how patterns like that get abused in other languages maybe it is for the better that there isn't.

What would it look like? Wouldn't it just be lambda?

Yes, sugar so instead of having `partial(foo, w=1, x=2)` or `lambda y,z: foo(1,2,y,z)` just instead something like `foo(1,2,_,_)`

I wish it would at least be a method on any callable.

And itertools!

Checkout shiv for turning even more zipapp goodness: https://shiv.readthedocs.io/en/latest/

shiv has two things over zipapp:

A bootstrap boilerplate that allows the shiv to be able to run as an interpreter. I think zipapp can only be given code.interact as main.

Unpacking wheels into ~/.shiv, which might be faster. I can’t remember if this permits running compiled C, which is not possible from within a zipapp.