Excellent article about best practices for logging errors, most of it applies for other type of logs though.

You thought averaging two unsigned was trivial? Think again, here what needs to happen in all its glory.

If you didn't try Kate for a while... the next release in the spring will be a good time to try it again.

Good reminder that the words we use matter. Fuzzy terms like "clean" indeed hide various dimensions to look at the code and the tradeoffs we make.

Lots of food for thought in that article. Shows very well some of the trade offs in complexity languages have to deal with when they bring a strong type system to the table. Hence some limitations being in place... and that's why it can get into nasty metaprogramming territory quickly. This show a couple of interesting examples on how this can be mitigated although we don't have any perfect solution yet.

Type annotations become quickly complex with Python. This is in part because it's rolled out incrementally on top or existing practices. Here it collides a bit with decorators. Nice to see this hole is getting plugged though. Also nice to discover an alternative to mypy which seems a bit more precise (at least for the time being).

Interesting caveat on how lru_cache is used in Python.

Good explanation of the Python object model and how parameters are passed to functions. This can look rather surprising or confusing if you come from another language. Always keep in mind: mutability and the fact that variable name are just labels play a big role in this. That means you might need to copy explicitly in the case of mutable objects... which makes the performance burden explicit as well (and this means you need to pick between shallow or deep copying).

PS: I really mean "label" here (like in the post), it's a bit different from "pointer" since you don't get the pointer geometry (you can only reassign). From the C++ perspective I'd say it behaves as if all variables were "reassignable non-const references" only, something like that.

Not very profound but definitely useful tips on how to handle reviews.

Always remember the human beings and the context behind the code you are looking at.

Nice tip about Java collections. Didn't know you could collect streams that way, definitely handy.

I think this applies more largely to any evolving language or ecosystem. You rarely can know such a thing in full and if you do it's only at a given point in time for a few given contexts. Only path to expertise in our field is practicing in various contexts and staying up to date as much as humanly possible.

Good reminder on why mypy is an essential mitigation to use when dealing with Python. This avoids some quite common mistakes.

This is an excellent list, I admit I agree with most of it. Couple of those realizations are in fact a deep part of what I do.

I still think there are indeed options that work better than others. They are then best practices... BUT they are very much contextual. Due to that complexity, the "personal preference" labelled as "best practice" is indeed pervasive in our industry.

Now that is indeed an interesting bug. Time can be a fickle friend... arithmetic as well.

This is a good highlight of the differences. It's not "one is best", it is really "pick what is best in your context".

This sounds like a good approach for optimizing on software durability. Obviously this means you loose other things. This is a trade-off.

Illustration of one of the traps I hate most with Python.

Not 100% convinced by all the points, but definitely a good conversation to have around the pull/merge request model. Might need a minimum threshold to be crossed in term of team maturity though.