Schon wieder so eine konstruierte Diskussion… Als Radfahrer stören mich nicht die E-Mopeds, sondern

• fahrende Autos,
• stehende Autos (dooring),
• Verbrenner-Mopeds/Motorräder die mein Trommelfell zerstören,
• zu kleine Radwege,
• zu kleine Gehsteige (bei denen die Fußgänger dann blind auf den Radweg ausweichen),
• Ampelschaltungen die auf ~50km/h ausgelegt sind
• Radwege, die plötzlich ohne Radübergang über eine Straße führen
• unsichere Kreuzungen
• Radstreifen, die eigentlich nur eine Verschlechterung für Radfahrer sind (wieder dooring)
• und und und

Hier werden mal wieder zwei Gruppen gegeneinander ausgespielt, damit nicht über die eigentlichen Probleme geredet wird.

Oh my gosh… This project and its readme are amazing. I gotta try this at work tomorrow, I hope my co-workers can bear with me.

Edit: I just found the release notes… I love it

In Rust, the tests usually sit right next to the source code, even in the same file. That’s partly because the compiler can just strip the tests from the final binary, and I assume partly just conventional. In Python, you usually want to keep the tests out of the final sdist/wheel, so the setup you described is probably the most common in bigger projects.

Haha, bei der Überschrift dachte ich erst, er verlangt so viel in Euro wie damals in Schilling.

In programming, people often talk in absolutes, but there‘s often exceptions to these rules, depending on situation and depending on the programming language. In Python, things like dependency injection don‘t make a lot of sense, because it just isn‘t needed. It‘s a pattern extensively used in other languages like Java, but only because Java has limitations that don‘t exist in Python. Trying to use Java patterns into Python just because it „sounds right“ or because it‘s a „best practice“ in another language does not make your code actually good python. It‘s not necessarily bad, but more complicated than it needs to be, and simpler is usually better if it yields the same end result. Don‘t overthink it.

You say global variables are a very bad thing, but do you know why that is? People often hear about things like that but don‘t learn about the „why“, which hinders you from properly thinking about your code.

Global variables are a bad thing because it is very hard to reason about their state at certain points in your programs execution. But what if your variable never changes, like a constant? Then you don‘t really have that problem. So an immutable config read in at startup and accessed by multiple classes/functions works just fine. You could also have a function that, when you run it the first time loads the config, „caches“ it in a global variable and then in subsequent calls just returns the global config.

To ensure immutability, you can use a frozen dataclass or something with validation built in like frozen pydantic models.

If you think you need mutability, think again. It’s better to put whatever you need to mutate outside of the global Config class, and then initialize that with the config. But keep the config itself read-only.

Die sind auch Datenschutztechnisch super, kann ich auch sehr empfehlen. Ist halt leider nicht ganz so convenient wie apple/google pay, weils einfach nicht so fest ins Handy Betriebssystem integriert werden kann, und viele Kassierer*innen es nicht ganz so in der muscle memory haben.

Ich kann wefwef.app empfehlen, sehr an Apollo angelehnt und funktioniert soweit ganz gut. Ist aber nur als Webapp implementiert, nicht native.