Stop whining. They’re trying to help give you training wheels. They’re responding with their experience, and you’re being hypercritical about semantics.

If you go to a medical expert complaining about pain, do you get offended when they tell you how to fix it? And for the natural response “they aren’t doctors”, well (a) they may be and (b) if you really want the level of help you’d expect from a medical professional, perhaps don’t ask the internet.

No blanks and limited, expensive kitting. I want to try it, but probably never will.

I use Colemak DH with a numpad and nav layer (there’s a media layer, but it doesn’t see regular use) and Callum-style mods for my layout. I code in python, rust, typescript, sql, latex (and other documentation formats).

34-keys is my sweet spot. My daily is typically a charybdis (home) or sweep (office), and I switch between a totem, zaphod, and 34-key planck periodically.

The key to my layout is callum mods on the left hand layers, with command modifiers underneath (i.e., zxcdv) and alt f and b above. W and Q positions are transparent.

The nav layer is on the right hand, with about what you’d expect (arrows on home row).

The numpad is also on the right hand, and I use the num row keys instead of the numpad, so I get all of my symbols there, too. Various brackets are combos on the num layer (in QMK; all layers in ZMK).

I also have combos for (semi-)colon, tab, capsword, and underscore. And the media layer.

Also, you probably want a rotating file handler for the logging.

Tests. And typing. And comments.

Tests can help you be sure that each piece is working as intended and that they’re working together. You can also mock bits out or create a temporary database for local dev.

Adding typing and comments, especially docstrings will help others read your code more easily.

Yes!

What’s the format for talks? (Maybe I just missed it, but I didn’t see a description)

I’ve seen too many issues caused by relying on the system python. For starters, it’s much more difficult to fix if you screw something up.

I tell everyone to use pyenv – but only to install specific versions of python. I then create a primary venv for a couple of versions, and that’s what I use as my “system” version. Each project creates a separate venv based on the pyenv versions. I use autoenv to activate and deactivate as needed.

It’s a little more setup, but it avoids so much magic, and it’s extremely robust.

I use DictReader all the time, along with a library to hande the type detection. This is the way to go, especially if you need to process line by line or filter columns and rows out first.

Regardless, I’ll avoid pandas wherever I can. It’s not something I want in production level code if I can help it.