Do you recommend any alternatives to Logi Options+? I've heard about BetterMouse, does anyone use it?

I paid for bettermouse and can recommend it. Light and powerful. No bloatware.

They have more security incidents than you'd expect for a documentation company. There was another one just last month.

I wish Daylight team would make a monitor. Mira Pro is cool, but it screams "first-gen."

The hardest bugs are the ones that only show up after you “optimize.”

The ones that only happen when you remove the debug statements are super fun.

When you search for "dotfiles" on GitHub, you'll find plenty of good script examples for setting up a new computer. Since Apple doesn't provide good documentation on what you can configure with "defaults" variables, these examples are a goldmine.

That's how I found some to be honest. :-)

In a healthy org, titles are a trailing indicator of impact. In a dysfunctional one, they’re just armor.

Like running Doom on a printer, but now it’s in the same engine powering your BI dashboards. Peak 2025 energy.

Not sure about introducing yet another string prefix. Between f-strings, raw strings, and i18n stuff, it’s already getting crowded. Curious how readable this will be in large codebases.

I'm of the opposite opinion. Let's set the prefixes free!

    from sql import sql

    query = sql"SELECT user_id, user_name FROM {user_table_versioned} WHERE user_name = {user_name}"

This was considered and rejected: https://peps.python.org/pep-0750/#arbitrary-string-literal-p...

How would this be different from a function sql() that operates on one of these new t-strings?

The syntactic sugar of changing it from sql(t"...") doesn't seem particularly valuable. The novel thing about t-strings is that they change the parsing at compile-time.

> The syntactic sugar of changing it from sql(t"...") doesn't seem particularly valuable.

It's valuable because:

- IDEs could then syntax-highlight SQL inside of SQL strings and HTML inside of HTML strings

- You can't accidentally pass an HTML string to your SQL library

It’s different from a function the same way f”” is different from f(“”) and t”” is different from t(“”)

There’s nothing stopping you from building a Python function that parses a string looking for {} and then searching globals for those variables. And you can extend that to also do some code execution and formatting.

To me the real sugar of f-strings is that the editor knows that it’s a template and not just a string. Expanding this to having SQL and regex syntax highlighting, linting and code formatting inside my Python code is a pretty cool prospect.

It wouldn't be different, but it would be more convenient because we no longer have to count the number of %s, you'd put the variable inline.

That's... already the case of t-strings?

Yes, that's my point. The GP was already talking about a t-string.

dmurray was comparing a hypothetical sql"..." with sql(t"..."). There are no %s either way.

This is how JavaScript does it with tagged template literals.

Your sql there would just be a function that receives the array of strings/values and returns whatever.

This is what JS does with tagged template literals. https://github.com/dsego/sql_tag

Are there string prefixes for i18n stuff?

They're probably talking about the convention of using _ as an alias for `translate`

"Yet another" is not my main worry

The concept of prefixes itself feels a little deviant from readable code that is close to human language -- which is the spirit of Python

Additionally, it will probably be confusing that it is called a t-string but it is actually a constructor for a Template object and not string at all. I would rather see a new special term `template` than this.

The single letter f or t does make it unnatural to read, but if it were sql"..." or html"...", I think that would help with that.

Should have been a keyword.

    a = template "foo {bar}"

As should raw and format.

They declared an incident: https://status.ubicloud.com/incidents/wwjvgx89k9gx