Python context managers somewhat require it. You have to create an object on which you can call `__enter__`.

This is the exact opposite? They explicitly encourage doing resource-opening in the __enter__ method call, and then returning the opened resource encapsulated inside an object.

Nothing about the contract encourages doing anything fallible in __init__

It is a tragedy that python almost got some form or RAII but then figured out an object has 2 stages of usage.

I also strongly disagree constructors cannot fail. An object that is not usable should fail fast and stop code flow the earliest possible. Fail early is a good thing.

There is no contradiction between “constructors cannot fail” and “fail early”, nobody is arguing the constructor should do fallible things and then hide the failure.

What you should do is the fallible operation outside the constructor, before you call __init__, then ask for the opened file, socket, lock, what-have-you as an argument to the constructor.

Fallible initialisation operations belong in factory functions.

The real problem is that constructors and factory functions are distinct in the first place. They aren't, in Rust, and it's much easier to reason about and requires far less verbiage to write.

Why though?

You can make globals thread safe by using thread locals. You can make methods using them reentrant by carefully saving and restoring state. What about exceptions? Any exception from `process()` is going to leave this global state in a total mess.

I should have talked more about that in the article. I mentioned defer, making functions reentrant, etc, but languages with exceptions and without defer can make things much harder. I tried to make it clear the global state should be accessible from a handful of functions or within a file/module

100% agree with the AI on @cache decorator. It's a footgun and should never be recommended without a proper disclaimer. Unless it's a simple "single shoot" script, you really do not want the cache global like that.

Zotero Flatpak comes with 4 year old Firefox binary and full access to your home directory.

The compromise currently being made here is your security.

This is how all undefined behavior works. It seems to be working now but breaks with new CPU, GCC version or on wrong moon phase.

"-Wcast-align=strict" will work in this but not all cases - that's why we have UBSAN:

    $ gcc -fsanitize=undefined test.c
    $ ./a.out 
    test.c:6:6: runtime error: store to misaligned address 0x55e4007adeb1 for type 'int', which requires 4 byte alignment
    0x55e4007adeb1: note: pointer points here
     00 00 00  01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  51 00 00 00 00

You can pin your JVM process to a single core and will effectively get Python multithreading model.

Defining string as a sequence of unicode codepoints is the mistake.

Nobody ever cares about unicode codepoints. You either want the number of bytes or the width of the string on screen.

UTF-32 codepoints waste space and give you neither.

The width on the screen is in pixels. Yes, I find monospace fonts increasingly pointless.

Object oriented programming is not about defining classes. It's about using objects. You don't have to define new classes to do OOP. Just use existing classes and objects polymorphically!

    url_layout.format()
    resp.raise_for_status()
    resp.json()
    session.add()

All those calls are dynamically dispatched - the essence of object oriented programming. This is what allows you to not worry about: * which string implementation `url_layout` uses * which HTTP protocol, encryption, authentication, chunking `resp` uses * what database is connected to `session`

You cannot avoid using objects - that's how all modern operating systems work.

Using classes without the need to call them polimorphically just as a nice namespace for methods is a separate issue.

The problem with scp is that the trust also needs to go the other way. There is a lot of ways ssh server can trick the client into doing bad things on your local machine.

That's not mentioned in the article, do you know if it is worse than just normal ssh?

First issue mentioned: CVE-2019-6111 is an example of such attack.

Mocks have to be updated and fixed every time you do any meaningful changes in production code. Good fake can be reused in many tests and will keep behaving like a real thing with minimum maintenance. Much less complex than maintaining hundreds of mocks each implementing different parts of the interface.