![](\"/cache/d9/44/d94443c94b1f1d57abc02f7d4dcb717c.png\")
I stumbled into a strange error when running pytest in a side-project:
import file mismatch:\nimported module 'test_comments' has this __file__ attribute:\n /<root>/django-peterbecom/peterbecom/api/tests/test_comments.py\nwhich is not the same as the test file we want to collect:\n /<root>/django-peterbecom/peterbecom/publicapi/tests/test_comments.py\nHINT: remove __pycache__ / .pyc files and/or use a unique basename for your test file modules\n\n
I desperately made sure I deleted every __pycache__ directory and every *.pyc file. I also ran rm -fr .pytest_cache.
It was strange because I knew I had, in the past, had two files called exactly the same. E.g. test_utils.py.
Turns out, you can have two test_something.py called exactly the same but they must both sit in a directory that has a __init__.py.
So there was nothing wrong with /<root>/django-peterbecom/peterbecom/api/tests/test_comments.py. I just had to do:
\ntouch /<root>/django-peterbecom/peterbecom/api/tests/__init__.py\n...and the problem got solved.
", "url": null, "disallow_comments": false, "split": null}, {"oid": "copy-the-current-line-in-vs-code", "title": "Copy the current line in VS Code", "pub_date": "2026-03-12T15:07:52.002Z", "comments": 0, "categories": ["macOS"], "html": "tl;dr; In VS Code you can copy the current line without first selecting it. Cmd-C without selection defaults to whole line.
\nOne of those \"How did I not know this until now?!?!\"
\nVS Code is not emacs even though its emulation gets many things right. But one thing that I only just learned is that to copy a whole current line, you don't have to select it first. If nothing is selected, whichever line the cursor is on gets the entire line copied.
The regular way of doing it:
\n\n\nthe keyboard use here is down, Ctrl-Shift-left, Ctrl-Shift-left, Cmd-C. Then moving down to a new line and Cmd-V
\nHere, note that the cursor is just somewhere on line 6:
\n\n\nthe keyboard use here is down, down, Cmd-C, down, Cmd-V
\nIn this particular demo video, I'm just replicating line 6 and putting a copy of that on (new) line 8. There's actually another keyboard shortcut sequence for that: Option+Shift+down then Option+down
\nOption+Shift+down replicates the current line and puts a copy right below. Then Option+down moves the current line.
", "url": null, "disallow_comments": false, "split": null}, {"oid": "logger.error-or-logger.exception", "title": "logger.error or logger.exception in Python", "pub_date": "2026-03-06T15:27:44.219Z", "comments": 0, "categories": ["Python"], "html": "Consider this Python code:
\n\ntry:\n 1 / 0\nexcept Exception as e:\n logger.error("An error occurred while dividing by zero.: %s", e)\nThe output of this is:
\n\nAn error occurred while dividing by zero.: division by zero\nNo traceback. Perhaps you don't care because you don't need it.
\nI see code like this quite often and it's curious that you even use logger.error if it's not a problem. And it's curious that you include the stringified exception into the logger message.
Another common pattern I see is use of exc_info=True like this:
\ntry:\n 1 / 0\nexcept Exception:\n logger.error("An error occurred while dividing by zero.", exc_info=True)\nIts output is:
\n\nAn error occurred while dividing by zero.\nTraceback (most recent call last):\n File "/Users/peterbengtsson/dummy.py", line 23, in <module>\n 1 / 0\n ~~^~~\nZeroDivisionError: division by zero\nOk, now you get the traceback and the error value (division by zero in this case).
But a more convenient function is logger.exception which looks like this:
\ntry:\n 1 / 0\nexcept Exception:\n logger.exception("An error occurred while dividing by zero.")\nIts output is:
\n\nAn error occurred while dividing by zero.\nTraceback (most recent call last):\n File "/Users/peterbengtsson/dummy.py", line 9, in <module>\n 1 / 0\n ~~^~~\nZeroDivisionError: division by zero\nSo it's sugar for logger.error.
Also, a common logging config is something like this:
\nimport logging\n\nlogger = logging.getLogger(__name__)\nlogging.basicConfig(\n format="%(asctime)s - %(levelname)s - %(name)s - %(message)s", level=logging.ERROR\n)\n\n
So if you use logger.exception what will it print? In short, the same as if you used logger.error. For example, with the logger.exception(\"An error occurred while dividing by zero.\") line above:
\n2026-03-06 10:45:23,570 - ERROR - __main__ - An error occurred while dividing by zero.\nTraceback (most recent call last):\n File "/Users/peterbengtsson/dummy.py", line 12, in <module>\n 1 / 0\n ~~^~~\nZeroDivisionError: division by zero\nadd_noteYou can, if it's applicable, inject some more information about the exception. Consider:
\n\ntry:\n n / 0\nexcept Exception as exception:\n exception.add_note(f"The numerator was {n}.")\n logger.exception("An error occurred while dividing by zero.")\nThe net output of this is:
\n\n2026-03-06 10:48:34,279 - ERROR - __main__ - An error occurred while dividing by zero.\nTraceback (most recent call last):\n File "/Users/peterbengtsson/dummy.py", line 13, in <module>\n 1 / 0\n ~~^~~\nZeroDivisionError: division by zero\nThe numerator was 123.\nPlease tell me there's a better way.
\nI'm in a git feature branch. It was branched off of master some time ago. Then I made some commits. Later, I merged in latest master, and after that some more commits. The question is what was the SHA when I merged in latest master? How to find that out?
Here's what I did:
\nI'm in my feature branch and I run:
\n\ngit log --merges --first-parent\nIt prints this out:
\n\ncommit 2c010ef6e94d792f25f7309ed83a2d35e41e5051\nMerge: 24b2a2513d6f e2817859ed02\nAuthor: Peter Bengtsson <email>\nDate: Thu Feb 26 14:06:24 2026 +0000\n\n Merge remote-tracking branch 'origin' into name-of-my-feature-branch\nThe SHA that was, on master, at the time of merging, was e2817859ed02 which is the second thing the Merge: 24b2a2513d6f e2817859ed02 line.
Now, equipped with this I can go back in time git checkout e2817859ed02 and on that detached HEAD, I can do things like run (unit) tests to see if the master branch was busted at the time I merged it into my feature branch.
gg2 is a command line tool for doing things with Git branches, faster. One of the convenient commands is gg2 branches. \nIt lists your recent branches, sorted by committer-date and for each branch it displays a human-friendly date distance and whether it's already been merged. Looks like this:
Turns out, for large repos figuring out which branches have already been merged is quite slow. For example, in this repo it takes half a second to list all merged branches:
\n\n$ git branch --all --merged | wc -l\n669\n\n$ time git branch --all --merged 1>/dev/null\n\nreal 0m0.490s\nuser 0m0.460s\nsys 0m0.030s\nThe problem was that gg2 branches also does multiple other git branch listing commands to get information. In particular: get the current branch, figure out the default branch, a list of branch committer dates, and a list of merged branches.
\nAll of these async operations were done in serial. With a bit of rearranging, and refactoring, all of these can be turned into this:
\nconst [defaultBranch, currentBranch, dates, isMerged] = await Promise.all([\n getDefaultBranch(git),\n getCurrentBranch(git),\n getAllBranchDates(git),\n getAllMergedBranches(git),\n])\nThe getAllMergedBranches(git) function still takes a very long time and I think it lists all remote branches that have been merged. Anyway, now it's only the slowest part of the Promise.all rather than one of multiple.
UPDATE
\nThe act of blogging about something can sometimes bring out how wrong you are.
\nWhat I didn't realize is that I was using git branch --all --merged to know which local branches have already been merged into the default branch. But you can just use git branch --merged to get the same result but much much faster.
Correcting for this, on a large repo, the average time to execute gg2 branches went from median 541ms to median 188ms. So that's 3x speed improvement.
xbar-my-prs is a plugin I wrote for something called xbar which is a macOS app that let's you write scripts that then show up in the macOS menu bar. Mine is about fetching information about my recent GitHub pull requests.
\nA picture of it in action:
\n![](\"/cache/b8/f6/b8f6c9b52314c6a7674ac86d44fc8a46.png\")
Every minute, it does this GitHub search: is:pr author:@me sort:updated
Then it parses the results and attempts to display a neat summary.
\nAnd each time it runs, it stores a copy of the result in the /tmp directory so that it can compare what the result became compared to before. So if something has changed in the last minute, it displays a summary of the change(s). Example:
![](\"/cache/d5/d5/d5d5ee05f145495eb912840129a5b20b.png\")
First you have to install xbar onto your macOS.
\nAt the time of writing you can't install it with Homebrew. Working on that. But all you need is just and Bun and then you can install it like this:
\ngit clone https://github.com/peterbe/xbar-my-prs.git && cd xbar-my-prs\njust install\njust ship\nIf all goes well, it should have crated an executable file at:
\n\n~/Library/Application\\ Support/xbar/plugins/my-prs.1m.bin\non your system. And that should be all xbar needs to know there's a new plugin to run.
", "url": "https://github.com/peterbe/xbar-my-prs", "disallow_comments": false, "split": null}, {"oid": "optimizing-bun-compiled-binary-for-gg2", "title": "Optimizing Bun compiled binary for gg2", "pub_date": "2026-01-13T16:06:09.784Z", "comments": 0, "categories": ["TypeScript", "Bun"], "html": "tl;dr; adding --bytecode and --production to bun build --compile gives a marginal boost.
I have a CLI tool called gg2 which is written in TypeScript and using Bun compiled to a single executable binary that can be installed with Homebrew. It's fast. Only 17% slower than GitHub's Go-compile gh CLI. But can it get even faster?
I read about Bytecode Caching which is supposed to make the executable \"dramatically improved\". Hmm. Let's see. There's also the --production option, which according to Set NODE_ENV=production and enable minification. Not convinced it's doing much but let's try.
I compiled the binary 4 different ways:
\nbun build src/index.ts --target=bun --compile --outfile out/ggbun build src/index.ts --target=bun --compile --outfile out/gg-bytecode --bytecodebun build src/index.ts --target=bun --compile --outfile out/gg-production --productionbun build src/index.ts --target=bun --compile --outfile out/gg-bytecode-production --production --bytecodeThen I ran hyperfine like this:
\nhyperfine "./out/gg --version" "./out/gg-bytecode --version" "./out/gg-production --version" "./out/gg-bytecode-production --version" --warmup 6\nThe results are as follows:
\n| BINARY | \nTIME (ms, smaller is better) | \nSIZE (MB) | \n
|---|---|---|
| gg | \n87 | \n58 | \n
| gg-bytecode | \n81 | \n60 | \n
| gg-production | \n82.4 | \n55 | \n
| gg-bytecode-production | \n79.6 | \n60 | \n
![](\"/cache/c7/1f/c71f48b8b4ab4acb5c455a140d0301da.png\")
(sorry for being terrible at using Excel to draw charts)
\nI'm skeptical. The hyperfine often complains about statistical outliers so you have to run it with warmup and re-run it till it doesn't complain.
One caveat with using --bytecode is that the compiled code is not re-usable across different versions of bun but I don't understand how that's applicable if it's a executable binary that is shipped outside of Bun.
I'm going to add --bytecode and --production to the next release of gg2.
gg2 is a CLI tool to become more efficient on the command line with git. It's open source and installable with Homebrew. And now it has its own web page:
https://gg2.peterbe.com/
\n\ud83c\udf89 \ud83e\udd73 \ud83c\udf7e
The site is built on Vuepress 2.0. It's a couple of .md files that look pretty. The static site is hosted on GitHub Pages. All the documentation content and configuration is in the docs/ directory.
Because TanStack Query uses a global cache, you can use the same useQuery hook in multiple places without making excess XHR requests.
Traditionally, if you have data on a server, that you want to use in multiple places throughout your component tree, the advice is to lift it to the top and either prop-drill its data or put it in a context. In this contrived example, suppose the <Header> component and the <Dashboard> component both need the data from the primary server fetch. And the <Footer> component needs to know if there was an error fetching that server data:
\nfunction App() {\n const query = useQuery({\n queryKey: ["data"],\n queryFn: () => fetchData()\n })\n\n return <div>\n <Header data={query.data}/>\n <Dashboard data={query.data} isPending={query.isPending}/>\n <Footer error={query.error}/>\n </div>\n}\nBut prop-drilling can be annoying. For example, that <Footer> component might look like this:
\nfunction Footer({error}: {error: Error | null}) {\n return <footer>\n <Alert error={error}/>\n <p>Copyright 2026</p>\n </footer>\n}\n\nfunction Alert({error}: {error: Error | null}) {\n if (error) {\n return <div className="footer-error">There was an error fetching the data</div>\n }\n return null\n}\nFirst, refactor the useQuery call so it becomes a hook that encapsulates any of its configuration. For example:
\nfunction useData() {\n return useQuery({\n queryKey: ["data"],\n queryFn: () => fetchData(),\n retry: 0,\n });\n}\nNow, you can use that hook in all the places where it's needed. For example:
\n\nfunction Header() {\n const {data} = useData();\n return <h1>\n Page Title {data ? ` (${data.count} items)` : null}\n </h1>\n}\n\nfunction Footer() {\n return <footer>\n <Alert/>\n <p>Copyright 2026</p>\n </footer>\n}\n\nfunction Alert() {\n const {error} = useData()\n if (error) {\n return <div className="footer-error">There was an error fetching the data</div>\n }\n return null\n}\nAnd in the end, you can remove any drop-drilling
\n\nfunction App() {\n return <div>\n <Header/>\n <Dashboard/>\n <Footer/>\n </div>\n}\nThe useQuery hook will use the global cache, that probably looks something like this:
\nimport { App } from "./App";\nimport { QueryClient, QueryClientProvider } from "@tanstack/react-query";\n\nconst queryClient = new QueryClient();\n\nconst app = (\n <StrictMode>\n <QueryClientProvider client={queryClient}>\n <App />\n </QueryClientProvider>\n </StrictMode>\n);\nAnd that global cache will recognize if a query has started by the queryKey value. If one such Promise already exists, it won't start another. So you're guaranteed to not make multiple XHR queries to the back end.
Here on my blog I have a site search. Before you search, there's autocomplete. The autocomplete is solved by using downshift in React and on the backend, there's an API /api/v1/typeahead?q=bla. Up until today, that backend was powered by Elasticsearch. Now it's powered by PostgreSQL. Here's how I implemented it.
A cron job loops over all titles in all blog posts and finds portions of the words in the titles as singles, doubles, and triples. For each one, the popularity of the blog post is accumulated to the extracted keywords and combos.
\nThese are then inserted into a Django ORM model that looks like this:
\n\nclass SearchTerm(models.Model):\n term = models.CharField(max_length=100, db_index=True)\n popularity = models.FloatField(default=0.0)\n add_date = models.DateTimeField(auto_now=True)\n index_version = models.IntegerField(default=0)\n\n class Meta:\n unique_together = ("term", "index_version")\n indexes = [\n GinIndex(\n name="plog_searchterm_term_gin_idx",\n fields=["term"],\n opclasses=["gin_trgm_ops"],\n ),\n ]\nThe index_version is used like this, in the indexing code:
\ncurrent_index_version = (\n SearchTerm.objects.aggregate(Max("index_version"))["index_version__max"]\n or 0\n)\nindex_version = current_index_version + 1\n\n...\n\nSearchTerm.objects.bulk_create(bulk)\n\nSearchTerm.objects.filter(index_version__lt=index_version).delete()\nThat means that I don't have to delete previous entries until new ones have been created. So if something goes wrong during the indexing, it doesn't break the API.
\nEssentially, there are about 13k entries in that model. For a very brief moment there are 2x13k entries and then back to 13k entries when the whole task is done.
The search is done with the LIKE operator.
\npeterbecom=# select term from plog_searchterm where term like 'za%';\n term\n-----------------------------\n zahid\n zappa\n zappa biography\n zappa biography barry\n zappa biography barry miles\n zappa blog\n(6 rows)\nIn Python, it's as simple as:
\n\nbase_qs = SearchTerm.objects.all()\nqs = base_qa.filter(term__startswith=term.lower())\nBut suppose someone searches for bio we want it to match things like frank zappa biography so what it actually does is:
\nfrom django.db.models import Q \n\nqs = base_qs.filter(\n Q(term__startswith=term.lower()) | Q(term__contains=f" {term.lower()}")\n)\nThis is done with the % operator.
\npeterbecom=# select term from plog_searchterm where term % 'frenk';\n term\n--------\n free\n frank\n freeze\n french\n(4 rows)\nIn the Django ORM it looks like this:
\n\nbase_qs = SearchTerm.objects.all()\nqs = base_qs.filter(term__trigram_similar=term.lower())\nAnd if that doesn't work, it gets even more desperate. It does this using the similarity() function. Looks like this in SQL:
\npeterbecom=# select term from plog_searchterm where similarity(term, 'zuppa') > 0.14;\n term\n-------------------\n frank zappa\n zappa\n zappa biography\n radio frank zappa\n frank zappa blog\n zappa blog\n zurich\n(7 rows)\nMost of the time, the most basic query works and yields results. I.e. the .filter(term__startswith=term.lower()) query.
\nIt's only if it yields fewer results than the pagination size. That's why the fault tolerance query is only-if-needed. This means, it might send 2 SQL select queries from Python to PostgreSQL. In Elasticsearch, you usually don't do this. You send multiple queries and boost the differently.
It can be done with PostgreSQL too using an UNION operator so that you send one but more complex query.
It's hard to measure the true performance of these things because they're so fast that it's more about the network speed.
\nOn my fast MacBook Pro M4, I ran about 50 realistic queries and measured the time it took each with this new PostgreSQL-based solution versus the previous Elasticsearch solution. They both take about 4ms per query. I suspect, that 90% of that 4ms is serialization & transmission, and not much time inside the database itself.
\nThe number of rows it searches is only, at the time of writing, 13,000+ so it's hard to get a feel for how much faster Elasticsearch would be than PostgreSQL. But with a GIN index in PostgreSQL, it would have to scale much much larger to feel too slow.
\nElasticsearch is better than PostgreSQL at full-text search, including n-grams. Elasticsearch is highly optimized for these kinds of things and has powerful ways that you can make a query be a product of how well it matched with each entry's popularity. With PostgreSQL that gets difficult.
\nBut PostgreSQL is simple. It's solid and it doesn't take up nearly as much memory as Elasticsearch.
", "url": null, "disallow_comments": false, "split": null}]}