Wolf

For decades, I loved and used 1Password across multiple OSs and platforms. It’s the first thing I install when I bring up a new system. I gave them several weeks to fix their decisions. They doubled-down. Life requires compromise; but that is **not** something that extends to my personal values.

I will not tolerate their acceptance of nor involvement in evil. I’m switching, starting today. Seems like BitWarden might be my new choice, but I’m open.

I’m not telling anybody else what to do. Your values are your own.

#1Password #DHH #Omarchy #Facism #Nazis #encryption #BitWarden #morals #Values

I’m incredibly tired of people posting with a (programming) language tag just to hate on that language. Their **words** are always: why said language is wrong and awful and no one should use it, or how the hell did this language become so popular when mine is obviously superior; but their motivations are never that sophisticated.

**Their** language thinks about the problem in some particular way, and they’re so familiar with that way of thinking that it has become part of their identity. The target of their hate thinks about the problem some other way, and that is now an affront to them … to their identity … to their sense of self-worth.

I prefer Python to Ruby (and I’m not a Ruby expert, so I could be persuaded). That doesn’t make Ruby bad or Python good! I prefer Rust to C++ (and by the way, I **am** a Python and C++ expert — and **not** a Rust expert!).

Don’t shut out alternatives! I’m not saying you have to love them or even **use** them; but they still exist because something in them has value! If you pretend they don’t, you’re just deceiving yourself. Like being a flat-earther. Figure out what you can learn! Grow! Keep using your favorite if it remains the best fit for your problem. Just use it smarter!

#Python #Ruby #Cpp #ProgrammingLanguages

If I recall correctly, it was Akkana Peck @akkana@fosstodon.org who first introduced me to Python, probably around 1998 or 1997 (so something in the neighborhood of Python v1.5) while working together at Netscape (I had a different name back then). **That** turned out to be a life-changing event; so thanks, Akkana!

#Python #Netscape

@cartocalypse@norden.social When you define things in Python, either you want others to see them or not. A single initial underscore is one of the things that gently communicates "this is not for you". Omitting it from __init__.py is another. No protection is afforded by the Python itself. If you require enforcement, you’re in the wrong language, sorry. Given that, now the ball is in the consumer’s court: do they know what you meant. In general, an initial underscore tells them the thing they need to know. Double underscore (prefix only) is unusual. Double underscore at both ends is reserved for system related symbols. You sometimes define them. You rarely call them.

Are you trying to tell the user something? Or do you want to actually prevent it? If you’re dead set on the latter then __getattr__ tricks or maybe modules written in Rust or C++ or whatever can get you there while remaining mostly in Python, but it’s not usually worth the trouble.

The Pythonic way is cooperation. If you are trying to sidestep this, you’re not really walking in Python’s footsteps.

Rules are **tools**. They are guidelines that usually lead to the goal(s). Goals are the important part. Goals have value. When a rule in a particular situation **doesn't** lead you towards the goal, it's the rule that must bend, not your movement towards the goal.

A very simplified example. There's a speed limit on the highway. The goal is "be safe". If the speed limit is 70mph, but traffic is going 85 ... do you obey the rule? Or do you try to satisfy the goal? At 70, you are a dangerous obstruction (and there's a law against that). At 85 you are violating the speed limit, but you are safer (if conditions agree) because you are not an obstruction. This is called "the doctrine of competing harms". You break the law either way; but one way, you are better satisfying the actual **goal**.

Laws and rules and guidelines are just formalized steps to narrow your construction of a plan that reaches your goal. Sometimes to do the right thing (reach the goal), you have to bend or even break them.

Today my work machine graduated from Windows 11 to Ubuntu 24.04. The hardware hasn’t changed. I would have preferred Kubuntu. They gave me ext4 instead of btrfs. But my wishes there are nice-to-haves. What they gave me is a huge step!

#Linux #Windows #Ubuntu #Ext4 #Btrfs #Upgrade

I love Bash. I used to write tons of Bash. There is a lot of Bash in my life, even to this day.

But here's my life now:

* Bash holds some stuff together (small stuff: usually setting variables, aliases, and/or piping together a few CLI tools. See https://github.com/wolf/dotfiles/tree/main/shells/dot-config/shells/topics for examples)

* Zsh is good at doing stuff when I type, so that's my login shell

* If I have to do something interesting, why not just a Python script? In modern times, with a `uv` shebang line and self-specified dependencies ... the only externally visible additional requirement is `uv` itself (you don't even need Python). Just like a shell-based answer: you end up with a single stand-alone file

I'm not going to argue about "but you have to install `uv`". You do you.

#Bash #Zsh #Python #uv #Dotfiles

I’ve fully switched to OmniFocus (The Omni Group) from Things (Cultured Code). The two driving factors were that OF can handle some more complex relationships than can Things; and better external access into OF’s data (in this case through an MCP).

Both are great. Things is perfect for most people. If not for my new needs, I would probably still be there.

#OmniFocus #Things3 #MCP #Productivity #TaskManager

There are scary personal actions in this world: stepping off the ledge of an airplane for your first jump, kissing your romantic interest without knowing yet how they feel about you, trying to live the next day when death has taken a loved one from you.

I just did a scary thing. I asked for a promotion. I love my job. It’s great people working on meaningful solutions. I don’t have any plans to leave it. I’m not in any way looking elsewhere. But my title and compensation do not reflect my impact. I don’t know what comes next. My mind, of course, goes straight to the worst-case scenario. And this would be an awful time to look for a new job.

@mathsppblog I probably would have used some variation of sub from re... but you specifically said join.

My day job is all about #Python (which I love). Here are some personal rules, specific to working with Python projects:

* Do **not** install or modify global tools, especially Python itself or any packages. This means a given system might not even **have** a global Python
* Always use virtual environments (`uv` agrees with me, and doesn't need this but). I always set the global environment variable `PIP_REQUIRE_VIRTUALENV`.
* The two rules above mean my virtual environment contains (not via a link, it's really there) Python itself (and of course, of the right version)
* Virtual environments always live **inside** a project directory. Never global.
* Activate virtual environments only **inside** the project directory (`direnv` #direnv makes this easy)
* Don't install (let alone use) #Anaconda, #Miniconda, or #Mamba, because those violate all the rules above (but see the next rule)
* Anaconda-based packages implies a `pixi` #Pixi project (it's the same people, but a better answer, and you still get what you want -- the correct packages)
* No Anaconda-based packages implies a `uv` #UV project
* Always use `pyproject.toml` #pyprojecttoml over any other config file (e.g., `requirements.txt` #requirementstxt), except where things just don't work, such as needing `pyrefly.toml`
* `uv`, `pixi`, and `direnv` must exist outside of any project, so install them at the user level, or else globally if and only if that is appropriate and compelling enough to override rule one

That was a wall of text, but in practice doing it this way is trivial. It's probably **less** work than you have been doing. This post is just about managing your Python versions, environments, and projects. Not about, e.g., using `pre-commit` #precommit, or doing type checking, etc. But if you follow these rules, your work will be easier, faster, more adaptable, and encounter fewer obstacles.

#HowTo

Yesterday was just a fantastic day for me. I planned to post on it. Just overjoyed. Strongly tempered today by the acquisition of Astral, and therefore the uncertain future of #uv and #ty (and transitively, #pixi).

I’m gonna focus on yesterday.

@davemq @RuntimeArguments @jammcq You are 100% right! Vi was born in 1976. 42 years ago was 1984 ... all three of us were still on vi. Vim was not possible for any of us until 1991.

I think Jim's words were something close to "You know, the fact that I've been using a vim or vim-like editor for, uh, 42 years now. I've got a lot of muscle memory built up."

It's great to see evidence of listeners! Are you getting some enjoyment out of our conversations? Is there anything you'd be interested in hearing us chat about? Feedback and fact-checking are incredibly valuable to us, so thank you both for listening, and for caring enough to tell us what's on your mind!