While it would be ideal to have all datetime fields in databases and other data stores be time zone aware, that is certainly not the case. Also, SQLite (and probably others) do not have great support for time zones and it’s recommended to store datetimes as UTC (typically unix timestamps).

Deprecating utcnow was a good idea, but they should have replaced it with naive_utcnow. Oh well.

Rocky Linux have said that they can rebuild using publicly available sources in UBI containers and cloud images.

https://rockylinux.org/news/keeping-open-source-open/

Though reading the article, I don’t know if SUSE is simply rebuilding or forking. In any case, it’s cool to see SUSE committed to open source principles.

"I can read this Perl scrip"t should translate to “I’m lying”.

I’ve used pyenv for years and it’s an awesome tool. Keeps python binaries separate and it has a virtualenv plugin. I’ve gotten others to use it as well.

It works great for library owners who need to run tox/nox on multiple versions of python in test suites. Love it.

pyenv also has this with the .python-version file which will switch versions. And with the plugin, you can use virtualenvs in pyenv so that a .python-version can be simply: my-cool-project-virtualenv and switching to that directory automatically switches to it.

Yes but karma makes it worse. It incentivizes getting getting upvotes because you don’t want to “ruin” your karma. Expressing controversial opinions, even if they don’t generate downvotes, are discouraged with karma. Even OP says he gets a dopamine hit by seeing the karma number go up.

I don’t like karma. It incentivizes short, meme-y posts since those are things that get gets a lot of karma.

Yeah that’s a good point. It’s telling that inheritance is by design difficult to change unless you follow very specific rules of good OO design patterns.

I guess it’s easy to write bad code in any programming paradkgm but inheritance makes it easy to screw up.

Most of us have bad memories of over-complex hierarchies we regret seeing, but this is probably due to the dominance of OOP in recent decades.

This sentence here is why inheritance gets a bad reputation, rightly or wrongly. Inheritance sounds intuitive when you’re inheriting Vehicle in your Bicycle class, but it falls apart when dealing with more abstract ideas. Thus, it’s not immediately clear when and why you should use inheritance, and it soon becomes a tangled mess.

Thus, OO programs can easily fall into a trap of organizing code into false hierarchies. And those hierarchies may not make sense from developer to developer who is reading the code.

I’m not a fan of OO programming, but I do think it can occasionally be a useful tool.

If the work I’m doing is on a feature branch on remote or locally, why does it matter to the rest of the team? My integration steps can be done on a server instead of locally. TBD forces teams to collaborate synchronously since changes are pushed straight to trunk. Rebase or squashes are irrelevant here.

Another poster put it great: TBD is trying to solve a culture problem. Feature branches and pull requests into main is much more flexible. The only time TBD make sense is for small teams - like 2 or maybe 3. And even at 2, I’d much rather create feature branches that merge into main.

Precisely. In practice, trunk based development just means your branch is local instead of on remote.

That or messages getting delayed so sorting is out of order. If you are using a score based sort, votes also come in late too. Could also just be bugs.

Federation is buggy and lagged behind especially with the influx of users. It’s currently not scaling very well.

• https://github.com/LemmyNet/lemmy/issues/3062
• https://github.com/LemmyNet/lemmy/issues/3101

Edit:

Also see this PSA: https://programming.dev/post/17801 which is a setting for site admins to improve federation, but then again, it may help that much.

There also may be issues between federating between different version of Lemmy.

Really cool. This was sorely needed for a while, and I’m glad that someone is taking the mantle to provide this valuable service to the Python community. As Seth mentions in his previous post, supply chain attacks are becoming more concerning. Great that the PSF has hired someone specifically for these types of issues.

Nice. I just searched for it and now it’s federating with this instance !pythorhead@lemmy.dbzer0.com

Thanks for creating the lemmy python library!

Yep, though federation syncing is really slowing down. This post from !technology@beehaw.org is at 44 comments from programming.dev but 112 comments on the beehaw instance.

The article itself is not that insightful, but together with the main body of his talk is a good set of reminders of writing a nice API for a Python library.

I was just about to uninstall nginx…

On a serious note: I’m not sure of the details of socketserver but I would think opening a socket would not be a cpu intensive process.

Ehhh, I don’t quite agree with this. I’ve done the same thing where I used a timestamp field to replace a boolean. However, they are technically not the same thing. In databases, boolean fields can be nullable so you actually have 3-valued boolean logic: true, false, and null. You can technically only replace a non-nullable field to a timestamp column because you are treating null in timestamp as false.

Two examples:

1. A table of generated documents for employees to sign. There’s a field where they need to agree to something, but it’s optional. You want to differentiate between employees who agreed, employees who disagreed, and employees who have yet to agree. You can’t change the column from is_agreed to agreed_at.

2. Adding a boolean column to an existing table. These columns need to either default to an value (which is fair) or be nullable.