Respectively, yes.
The ability to create venvs so fast, that it becomes a silent operation that the end user never thinks about anymore.
The dependency management and installation is lightning quick.
It deals with all of the python versioning
and I think a killer feature is the ability to inline dependencies in your Python source code, then use: uv tool run <scriptname>
Then uv will make a new venv, install the dependencies, and execute the script faster than you think. The first run is a bit slower due to downloads and etc, but the second and subsequent runs are a bunch of internal symlink shuffling.
It is really interesting. You should at least take a look at a YT or something. I think you will be impressed.
>Respectively, yes. The ability to create venvs so fast, that it becomes a silent operation that the end user never thinks about anymore.
I might just blow your mind here:
$ time python -m venv with-pip
real 0m3.248s
user 0m3.016s
sys 0m0.219s
$ time python -m venv --without-pip without-pip
real 0m0.054s
user 0m0.046s
sys 0m0.009s
The thing that actually takes time is installing Pip into the venv. I already have local demonstrations that this installation can be an order of magnitude faster in native Python. But it's also completely unnecessary to do that:
I have wrappers for this, of course (and I'm explicitly showing the path to a separate Pip that's already on my path for demonstration purposes).
> a killer feature is the ability to inline dependencies in your Python source code, then use: uv tool run <scriptname>
Yes, Uv implements PEP 723 "Inline Script Metadata" (https://peps.python.org/pep-0723/) - originally the idea of Paul Moore from the Pip dev team, whose competing PEP 722 lost out (see https://discuss.python.org/t/_/29905). He's been talking about a feature like this for quite a while, although I can't easily find the older discussion. He seems to consider it out of scope for Pip, but it's also available in Pipx as of version 1.4.2 (https://pipx.pypa.io/stable/CHANGELOG/).
> The first run is a bit slower due to downloads and etc, but the second and subsequent runs are a bunch of internal symlink shuffling.
Part of why Pip is slow at this is because it insists on checking PyPI for newer versions even if it has something cached, and because its internal cache is designed to simulate an Internet connection and go through all the usual metadata parsing etc. instead of just storing the wheels directly. But it's also just slow at actually installing packages when it already has the wheel.
In principle, nothing prevents a Python program from doing caching sensibly and from shuffling symlinks around.
It's not the "runtime" that's slow for me with pip, but all the steps needed. My biggest gripe with python is you need to basically be an expert in different tools to get a random project running. Uv solves this. Just uv run the script and it works.
I don't care if pip technically can do something. The fact that I explicitly have to mess around with venvs and the stuff is already enough mental overhead that I disregard it.
I'm a python programmer at my job, and I've hated the tooling for years. Uv is the first time I actually like working with python.
None of GP is about what Pip can technically do. It's about what a better tool still written in Python could do.
The problems you're describing, or seeing solved with uv, don't seem to be about a problem with the design of virtual environments. (Uv still uses them.) They're about not having the paradigm of making a venv transiently, as part of the code invocation; or they're about not having a built-in automation of a common sequence of steps. But you can do that just as well with a couple lines of Bash.
I'm not writing any of this to praise the standard tooling. I'm doing it because the criticisms I see most commonly are inaccurate. In particular, I'm doing it to push back against the idea that a non-Python language is required to make functional Python tooling. There isn't a good conceptual reason for that.
It may not be required, but it has the virtue of existing. Now that it does, is it a problem that it's not written in Python? Especially given that they've chosen to take on managing the interpreter as well: being in a compiled language does mean that it doesn't have the bootstrap problem of needing an already functional Python installation that they need to avoid breaking.
You are free to evaluate tooling by your own standards.
But it commonly comes across that people think it can't be written in Python if it's to have XYZ features, and by and large they're wrong, and I'm trying to point that out. In particular, people commonly seem to think that e.g. Pip needs to be in the same environment to work, and that's just not true. There's a system in place that defaults to copying Pip into every environment so that you can `python -m pip`, but this is wasteful and unnecessary. (Pip is designed to run under the install environment's Python, but this is a hacky implementation detail. It really just needs to know the destination paths and the target Python version.)
It also happens that I care about disk footprint quite a bit more than most people. Maybe because I still remember the computers I grew up with.
I like "Hi Team". I do use that in certain social circles, but I do get the point of the article.
Survivor, the US TV show, used to say "Come on in guys" until recently where they made a point to discuss the topic on camera with the contestants. There was a variety of opinions, but they ultimately settled on "Come on in." which conveys the point in a neutral tone.
"Team" makes sense when addressing... well, your team, like if you're in a huddle of basketball players. But there are many contexts where it doesn't make sense as a general purpose second person plural.
I happened to get invited to friends of my in-laws who own a vacation property on the Oregon coast for the 2017 eclipse. Of course, the Pacific coast is dicey at best, so we were crossing our fingers. When the time came, the stars lined up and we had that magical moment, except right at that moment, the waste truck came through picking up the bins. If you have the opportunity, GO. The worst case is you don't see it. The best case is one of the most memorable experiences of your life.
PCI-DSS does not mandate the use of a WAF. It is one of two ways you can fulfill requirement 6.5 or 6.6. WAF + OWASP Top Ten ruleset is typically easier to get evidence for your auditor, but you can show that continuous scanning using a DAST scanning engine to meet requirements.
I would have a WAF installed with very few highly tuned rules against mostly SQLi. Why? Because the damage of letting that through and praying that the developer or web-app framework does it right are significant. The rules for SQLi are pretty easy to get right and dropping that traffic before it gets to your web server is a reasonable thing.
I would have a WAF installed with no rules too. It is nice to have something there where you can drop in a Log4J rule and get protection relatively quickly for attacks of that nature. There have been a number of these over the years and a small performance penalty seems worth the big picture safety net.
I am against the pricey models that the cloud vendors push. WAF can get expensive. They typically are bundled with other cloud services, but hey, if you've gotten that far, you are probably outsourcing most things to the cloud provider anyway.
I do not like WAF pragmatically because it lets the developer off the hook in many ways. There is something there doing their work for them and another reason for some developers to not understand or care about the security of their applications. Something else will do it for me whether I know this or not.
If there is some legitimate reason (say performance) to keep a tighter form (inline assembly, Python 1-liner, whatever), then making the unfurled equivalency as a comment nearby to allow the next developer to have a fighting chance would be really helpful. Also, error handling tends to be not included in the 1-liners.
Diablo Canyon is in an absolutely beautiful part of the central coast of California. Definitely visit the greater San Luis Obispo area. Californians want it all (green and plentiful), but lack the basics to make that happen (coalfire supplemented with wind and solar plus overloaded grids -- see what happens this weekend with FlexAlerts already called).
Nuclear should be considered. I don't know how to make them perfectly safe and their have been incidents where unfortunate accidents occur, but newer technology and designs might make our society able to have their cake and eat it too.
> I don't know how to make them perfectly safe and their have been incidents where unfortunate accidents occur
The issue I have with this argument is that if we don't dramatically reduce CO2 emissions far, far more people are going to die from climate change than nuclear might kill.
Plus, as another commenter already mentioned, the amount of deaths coal is responsible for is 470x higher than nuclear from air pollution alone. We accept these deaths for coal but somehow have a problem with a much smaller number of deaths from nuclear in the theoretical case of a massive incident. I'm not saying there's an acceptable number of deaths to just live with but pragmatically speaking I'll gladly take the proven option that kills orders of magnitudes fewer people than the status quo is already doing.
> Compared with nuclear power, coal is responsible for five times as many worker deaths from accidents, 470 times as many deaths due to air pollution among members of the public, and more than 1,000 times as many cases of serious illness, according to a study of the health effects of electricity generation in Europe.
In a vast country like ours I'd expect the government to be able to find cheap secluded places (in states such as NV?) where new reactors can be built. And then rich states such as CA buy the electricity from them. And probably invest into building them too.
The going to a ball game is an interesting example. I think there are financial disincentives at play, most notably, the price of beer. There are likely forces at play that will maximize the dollar intake while minimizing the amount consumed. This is not popcorn (still expensive) we are talking about. If beer were 1/2 as expensive, then people would drink 2x more and spend the same amount, but the effect on society would be much worse. We would have more fights in the stands, more drunk driving, and other negative effects. So by jacking up the price of a beer, fans can enjoy one or two, then realize they don't have the budget for a 3rd or 4th and cut it off there. They cut off sales in the 7th inning to prevent most of those effects I mentioned.
Not a huge deal in and of itself? Good key management processes would have you rotate every so often. However, we probably have a lot/most/all of us that use the same SSH key for many systems and loss of that private key would be compromise of your Github account.
Have a unique username / password combination for each website, right? Same is true for Github and all other SSH systems.
Also, Github provides Security Key support if you want to go that route. SSH keys are really not that different than passwords, but they seem more complicated, so maybe they are?
Get your colonoscopy. Period. Don't let people tell you fables about "the prep" or be afraid of something going up your butt.
"The prep" is a bit unpleasant for a couple of hours, but no big deal. The actual procedure is done under propofol. Consider that part the best nap you will ever get.
You will either get a clean bill of health, or the doctors will find something that is easily treated right then and there. The stigma (especially of men) about this procedure will lead to countless numbers of them to die from something that doesn't have to be.
Get the procedure when your doctor says. Just do it. Please.
I just had mine a couple days ago and opted for no sedation because I wanted to see what's going on. It was a bit unpleasant, at a couple spots the doc snakes the scope around some sharp bends and you can feel that inside of you. It totally paid off, though, I had a clear view of the monitor and could watch everything going on. I've done a fair amount of optical engineering so I was really curious about the whole thing and it's really fabulous.
Unfortunately, they found quite a few polyps and one was large enough that a) the doc marked the spot with some dye and b) they cauterized it. The puff of smoke inside my gut was definitely the highlight for me.
In my case, I didn't want to be administered a powerful substance (and experience any lasting effects) unless absolutely necessary. My understanding is that adverse reactions are very rare, but if the only upside is avoidance of minor discomfort for 30-60 minutes, I don't see the point.
I cannot imagine why you’d possibly want to be awake for it… especially to the point of calling it fabulous? I’m sure they could have given you a video afterwards without the discomfort.
My original goal was to avoid the extra time and having to organize a ride but also the aftereffects - the last time I felt weird a day or two later (could have been a red herring).
I just found it totally fascinating to see my own insides live in in high res and listen to the doctor and nurses talk about what was going on.
Well, I guess everyone has their own interests. I'm glad you got so much out of it. Personally I have no desire to see and feel myself be rotorootered and am very happy to knocked out, but it would be nice not to have the sedation after effects. The last two times I got one I ended up taking like a 4h nap afterwards. I'd imagine you also wouldn't have the same restrictions around drinking water cutoff times without sedation.
I should have also mentioned that my colonoscopy was done under a sedative, I wasn't knocked out - so I got to see the whole thing! The doctor provided a narrative as we went along. At one point they were having issues making a turn and I could feel it and let them know so the nurse squoze my guts in some way to allow them to get around it. They even showed me the polyp when they found it (I was laying on my left side with the monitors right in front of me - so I could watch the whole thing.) Except for that one turn I didn't feel a thing.
I've had my colonoscopy - I speak from experience when I say the PSA test is a heckuva lot less invasive! With that said, the colonoscopy wasn't bad at all - not nearly as bad as people make it out to be. They found a polyp, extracted it and did a biopsy, and found it to be benign. Now I have to have a colonoscopy every 5 years instead of every 10. Yay!!! :)
and I think a killer feature is the ability to inline dependencies in your Python source code, then use: uv tool run <scriptname>
Your script code would like:
#!/usr/bin/env -S uv run --script # /// script # requires-python = ">=3.12" # dependencies = [ # "...", # "..." # ] # ///
Then uv will make a new venv, install the dependencies, and execute the script faster than you think. The first run is a bit slower due to downloads and etc, but the second and subsequent runs are a bunch of internal symlink shuffling.
It is really interesting. You should at least take a look at a YT or something. I think you will be impressed.
Good luck!