Uvtrick
simonwillison.net
simonwillison.net
See "Single File Scripts" in the recent release blog here: https://astral.sh/blog/uv-unified-python-packaging#single-fi...
Incidentally also using "rich" in this example, uv natively does this now (first adding deps to main.py itself, then showing the revised main.py):
$ uv add --script main.py "requests<3" "rich"
$ cat main.py
# /// script
# requires-python = ">=3.12"
# dependencies = [
# "requests<3",
# "rich",
# ]
# ///
import requests
from rich.pretty import pprint
resp = requests.get("https://peps.python.org/api/peps.json")
data = resp.json()
pprint([(k, v["title"]) for k, v in data.items()][:10])
- https://docs.astral.sh/uv/guides/scripts/#declaring-script-d...
- https://packaging.python.org/en/latest/specifications/inline...
I'm pulling this all the way into a comment because if you haven't been paying attention to `uv`, this snippet here shows how "this changes everything".
This feels like it abuts the live vs dead software distinction, that most software has fixed code, fixed runtimes, is dead. Rarely is the runtime extending itself, adjustable.
The code itself that Simon walks through is some excellently concise metaprogramming.
And here we have the language being used to pull in specific versions for the language and go.
I wish the whole Electron vs Tauri vs whatever debate had some options like this, where there are a repository of runtimes to call upon on demand.
Python packaging papercut pains are solvable, we just need to get it in front of users.
It's not, a lot of this are comments. It's around 99 LOC
> there is no standard definition of what a line of code is. Do comments count? Are data declarations included? What happens if a statement extends over several lines? – These are the questions that often arise. Though organizations like SEI and IEEE have published some guidelines in an attempt to standardize counting, it is difficult to put these into practice especially in the face of newer and newer languages being introduced every year.
The term SLOC specifically excludes comments ("the most common definition of physical SLOC is a count of lines in the text of the program's source code excluding comment lines", Wikipedia), so a less negative response might have been "and only around 99 SLOC".
This is all very pedantic and very meaningless - but I think that the parent comment was more right in spirit, even though "technically" wrong since LOC doesn't seem to have a very clear definition and assuming that LOC stands for physical SLOC doesn't seem to be dominant enough to be the de facto assumption. But if I want to know about the maintenance surface area for a lib, I'd want to know the physical sloc, so I think it's a fair assumption here.
And I want to end with I hate myself for even bothing to waste my time with this nonsense, but the parent comment was downvoted, and I hate seeing people that are right be downvoted. But if I participate, I usually like to explain my reasoning for my involvement.
For what it's worth, while Microsoft GitHub reports "99 sloc", that number is still not "physical SLOC" because, quoting Wikipedia, "the most common definition of physical SLOC is a count of lines in the text of the program's source code excluding comment lines", while that 99 appears to be computed by removing all blank lines - including those in docstrings - but keeping the three comment lines.
Even more fun, this specific program contains a docstring containing a Python code example containing a Python comment, with a blank line that improves readability and cannot be cleaned up by a code formatter.
Hence my use of "around 99". This is an inherently fuzzy metric, not deserving of such precise interpretations.
As long as your code base is consistent in comment style, docstring detail, formatting, etc., all of these loc measures should be equally predictive of your maintenance overhead.
And if they aren't, that Wikipedia entry gives an example of how a single logical SLOC could be 1 or 4 physical SLOC, making physical SLOC at best a rough estimate.
> Rye is Armin's personal one-stop-shop for all his Python needs. [...] It is a wish of what Python was, with no guarantee to work for anyone else.
That text was removed only a few weeks before the announcement that Astral was taking stewardship of Rye.
[1]: https://github.com/astral-sh/rye/commit/f7c928898ae5f952fc2f...