Ephera

Kind of wild how this article about improving performance in Python is just like “Step 2: Don’t use Python”.

After seeing how excited some folks got during COVID, that’s genuinely somewhat of a worry for me. Kind of like how lonely, young men can be sold on the idea of war, because they think they’ll finally be adored as a hero, you can just as well find preppers who think they’ll finally be adored, because they bought toilet paper before everyone else could.

In the case of COVID, it was thankfully a disappointment for the preppers, in that the best survival strategy was staying in your cushty home. That will be the case for the vast majority of infectious diseases. But I still bet someone out there had the intrusive thought that maybe they shouldn’t help reduce the spread of COVID, because you won’t be deemed a hero without a real crisis…

Proper ants only have 6 legs, though. But yeah, these spiders-turned-to-ants would have 8 legs.

Well, and crabs technically have 10 legs, with their foremost pair typically equipped with pincers. 🙃

Mice can often find ways you wouldn’t believe, but they still have to adhere to the laws of physics, so you might simply not have suitable holes in your apartment for them to enter. But yeah, also quite possible that they can smell the cat and don’t want to enter the lion’s den.

I don’t think, it’s open-source…

This does not look to be open-source. The webpage lists open-source licenses for the libraries used by this app, but there’s no open-source license for the app itself.
And while there’s a GitHub repo, it’s empty. It seems to be used just for hosting the APK files.

An open-source app with decent editing capabilities is Fossify Gallery: https://f-droid.org/en/packages/org.fossify.gallery/

Yeah, after writing that comment, I was thinking, if I do promote it, that means there’s a certain expectation that I’ll integrate or implement functionality that others want. At that point, it becomes less of an egoistic thing. And I’ll be doing more communication and whatnot, therefore less programming.

Maybe that’s the puzzle piece that OP is missing? If you don’t promote it, you have practically no extra work compared to developing it under a proprietary license. In fact, it often reduces the workload, if you can just post it publicly without having to secure the repo.
And you don’t incur costs from giving it away either. So, if you make sure to only put in the work that you want to put in in the first place, you have no disadvantage from publishing it with an open-source license.

Are you referring to the workspace feature of uv? Is that working well?

Management might want us to revive a project from a few years ago, which is like 5% Python, but for which we had to build a homegrown horrid implementation of workspace builds, using shell scripts and symlinks. We’d definitely want to get rid of that, if uv’s workspace builds work at all, really. 🫠

I mean, it sounds like it’s gonna be a fairly large codebase. Rust is definitely better equipped for large codebases than Python…

I do agree that Python could give them more outside contributors, but from my experience, I don’t think it’s worth swaying from your preferred tooling for that. Outside contributions will make up barely a fraction of code changes either way, so you should rather ensure that your core team is productive.

Many people enjoy programming, you know. I’ve got like ten reasonably-sized projects and I haven’t posted about them anywhere. Because I built them to scratch my own itch, both in terms of functionality I could use and the itch to build something, no matter what it is. I’m not wasting my time, because I’m doing something I enjoy.

The system for domain names is called Punycode: https://en.wikipedia.org/wiki/Punycode

But it’s still combined with domain registrars rejecting names like “αpple.com”, which ultimately needs a human to approve names.

There could also be a system like here on Lemmy, where there’s a separate display name, but it still doesn’t really solve the impersonation problem…

The problem is, even if it were solved for 99% of systems, 1% of systems crashing is still a massive problem.

But yeah, I also don’t believe that it is solved for 99% of systems. There’s a ton of embedded systems all over the place, which are easy to forget about.

Yeah, it’s great. Farmers need to use pesticides and monocultures to stay competitive, since other farmers are using them. Also, pesticides and monocultures kill the ecosystems that provide things like natural pest control, pollination and humus. So, you probably don’t get an increased yield from pesticides and monocultures when they’re employed in wide areas, while you do still get the destruction of ecosystems.

Not sure what your problem with Discover is. It uses PackageKit under the hood, which hooks into APT (as well as other distros’ package management).

If you want to, you can disable Flatpak and Snap support in Discover’s settings and then it is effectively just an APT frontend.

Here’s a description page for Discover: https://apps.kde.org/discover/

Hmm, I’m having a hard time arguing why, but I would not even consider exponential backoff to be covered by the un-inversed “explicit is better than implicit”.

That rule felt more like it concerns itself with code style, whereas exponential backoff feels more like a configuration concern.
Obviously, exponential backoff does change the behavior of the code and could lead to bugs which you couldn’t reason about in the code. But it’s gonna be a rare thing, and you can probably reason about it from the logs.

Oh yeah, I’m in favor of using type hints. People here are also saying that Pyright is more useful, which I haven’t used yet.

I was involved as the unlucky bastard supposed to sprinkle software engineering on top of a Python project 2+ years ago, and I just remember how much I understood right then and there why Python devs thought static typing was cumbersome. Felt like I had to write Java again, except it also didn’t work half the time.

Interesting. If it’s only in the type checker, can IDEs/editors correctly show the type information of inferred types then? Do they call the type checker themselves to retrieve that info?

Yeah, I only used Mypy so far. I thought it was inherent to the language spec, not the type checker.

I guess, some of your colleagues might have also just used Mypy so far, though…

In the case of Rust, you can also omit the type annotation in the vast majority of cases and the compiler will infer it.