It sounds to me like they are: `You know they've given up on backward comparability and version control, when the solution is: run everything in a VM, with its own installation.`
uv taking over basically ensures that dependencies won't become managed properly and nothing will work without uv
There's bound to be a way to turn a stream of bytes into a stream of unicode code points (at least I think that's what python is doing for strings). Though I'm explicitly not volunteering to write the code for it.
Oh that's neat, though I might split this into two functions in most cases, no need to entangle opening the file and counting the words in a filelike object.
That's two neat tricks that I'm definitely adding to my bag of python trickery.
Sure, but making one string from the file contents is surely much better than having a separate string per word in the original data.
... Ah, but I suppose the existing code hasn't avoided that anyway. (It's also creating regex match objects, but those get disposed each time through the loop.) I don't know that there's really a way around that. Given the file is barely a KB, I rather doubt that the illustrated techniques are going to move the needle.
In fact, it looks as though the entire data structure (whether a dict, Counter etc.) should a relatively small part of the total reported memory usage. The rest seems to be internal Python stuff.
I dislike loading files into memory entirely, in fact I consider avoiding that one of the few interesting problems here (the other problem being the issue of counting words in a stream of bytes, without converting the whole thing to a string).
If you don't care about efficiency you can just do len(set(text.split())), but that's barely worth making a function for.
That makes some more sense. I think I just misunderstood what Charlie was saying above.
But I'll also add another suggestion/ask. I think this could be improved
$ ruff format --help
Run the Ruff formatter on the given files or directories
$ uv format --help
Format Python code in the project
I think just a little more can go a long way. When --help is the docs instead of man I think there needs to be a bit more description. Just something like this tells users a lot more
$ ruff format --help
Formats the specified files. Acts as a drop-in replacement for black.
$ uv format --help
Experimental uv formatting. Alias to `ruff format`
I think man/help pages are underappreciated. I know I'm not the only one that discovers new capabilities by reading them. Or even the double tab because I can't remember the flag name but see something I didn't notice before. Or maybe I did notice before but since the tool was new I focused on main features first. Having the ability to read enough information to figure out what these things do then and there really speeds up usage. When the help lines don't say much I often never explore them (unless there's some gut feeling). I know the browser exists, but when I'm using the tool I'm not in the browser.
reply