"Consider using an unstable package manager" is a really really rough start.
additional: "However, writing your own code that involves async functions", your code does use async functions, its just monkey patched into your program because you used green threads instead.
ashishb · 10d ago
> "Consider using an unstable package manager" is a really really rough start.
You can use poetry instead.
Poetry is stable.
I wish `uv` was version 1.0 or later.
However, despite it not being version 1.0 yet, I do see that it provides a superior experience for me to switch from `poetry` to `uv` and to make that recommendation after adding the pre-version 1.0 caveat.
Apreche · 9d ago
People get so hung up on the version number. These fools would rather use software with tons of bugs and security holes simply because the devs of that software dared to use a version number greater than 1.0.
I see the entire community gravitating towards uv because of its merits. I tried it, and I agree. I already started using it for every project. I’ve even converted older projects to it.
orev · 9d ago
The fact is that language matters, and the version number is a way to communicate the developers’ perception of how suitable something is for use. If they refuse to label it as 1.0, it means either: they don’t think it’s in a stable state yet, or they don’t realize the importance of this type of communication. Either way, it’s a red flag for people who might otherwise be making a large investment in time/money into using something.
It’s not feasible for everyone to do a full evaluation of everything. At some point you need to rely on an expert to at least provide some basic assurances before spending time on digging deeper.
its-summertime · 9d ago
pip and poetry have tons of bugs and security holes?
Apreche · 9d ago
No. I’m speaking in the general sense not to get hung up on an arbitrary number as the sole indicator of whether software is suitable for use in a production environment.
its-summertime · 9d ago
Uv provides no support period of bugfixing for the previous minor release after a breaking change. So if a breaking change does occur, you must immediately update your entire world, test, etc, to continue to receive fixes. (unfortunately the norm for python projects).
This is from their own documentation and release history. I never brought up version numbers before now, only their self-admitted unstable status. Version numbers were brought up by someone of the opinion that uv is stable enough.
ashishb · 9d ago
> (unfortunately the norm for python projects).
Yeah, that's how it is because it is costly for maintainers to maintain.
What's your point though, is poetry better in this regard or what are you suggesting as a better alternative to uv?
its-summertime · 8d ago
if I was asked to deploy python code? My alternative would probably be crying. Personal deployments? I'd probably go with pip hash installs ideally only of wheels, assuming that this would leave the environment in a reproducible state, probably wouldn't though.
pip has the same problem as uv in this regard, but I'd be hoping that there would be less breaking from breaking changes, due to the amount of people depending on pip not breaking.
If I had money? I'd fork pip or uv and assign some people to make an downstream with extended support.
ashishb · 9d ago
Exactly.
ropable · 6d ago
Sounds like someone really needs to try out uv.
ashishb · 4d ago
I was skeptical too because of the version number and then uv won me with a quick migration and insane speed.
There docs around GitHub Actions and docker are also pretty succinct and usable.
Hackbraten · 12d ago
Multithreading is not a prerequisite for async in Python. The default task executor runs in a single thread. So using async APIs should be safe as long as you stick to the single-threaded executor.
ashishb · 12d ago
Good point.
Have you seen any major advantage of using async API in practice?
phyrex · 10d ago
It's... faster for IO bound workloads? That's literally the whole point of async
andrewstuart · 9d ago
Async programs can do multiple tasks.
Blocking python can’t.
An example is running multiprocesses and parsing their output and looking for patterns. Async python does this sort of thing well.
ibash · 10d ago
If you don’t use `async def` and you are using fastapi it’s easy to accidentally block the event loop.
ashishb · 10d ago
> it’s easy to accidentally block the event loop.
Can you share a scenario where this would happen?
I have deployed multiple machine learning and data analytics-focused web services, and this has never happened to me.
chamoda · 9d ago
Well, you can even block event loop in `async def` if you are not careful. When you are using `async def` you need to do all your IO (disk, network) operations asynchronously or your are blocking the event loop.
winrid · 10d ago
With a for loop? You probably don't know you are, or just aren't doing anything cpu intensive.
jb_gericke · 10d ago
It sounds like the author makes a blanket claim to avoid asynchronous functions, even when using an inherently asynchronous web framework (FastAPI), which would negate any FastAPI asynchronous concurrency gains.
ashishb · 10d ago
> It sounds like the author makes a blanket claim to avoid asynchronous functions, even when using an inherently asynchronous web framework (FastAPI), which would negate any FastAPI asynchronous concurrency gains.
FastAPI is faster than the other popular framework, Flask (I posted data supporting that), even without using async.
I only suggested that one should use their discretion when using async.
When did I suggest not to write async code?
zvr · 9d ago
On the "formatters" and "linters" front, there is no need to use anything else than ruff, since it incorporates the functionality of all the other tools mentioned.
ashishb · 9d ago
Last I checked, 6 months back, it didn't.
However, ruff keeps evolving rapidly, so I am hopeful that I can get rid of all other linters and formatters over time.
If you have a suggestion on streamlining my `make format` and `make lint` commands, I am all ears.
andrewstuart · 9d ago
Perhaps better titled as something like “my personal preferences for how I like to run python in production”.
Presenting these opinions as truths will get the hackles up of those who have a different opinion.
ashishb · 9d ago
> Perhaps better titled as something like “my personal preferences for how I like to run python in production”.
But for certain use-cases, as mentioned in the article itself, it is unavoidable.
Further, you might be working at a company that has decided to use Python, and you can make Python more efficient and effective using these suggestions.
jb_gericke · 10d ago
So first off, don’t use Python in prod. Second off, don’t use async because of complexities in multi-threading?
A lot of the world runs just find on Python (see Django), async is mature and stable.
ashishb · 10d ago
> A lot of the world runs just find on Python (see Django), async is mature and stable.
I never claimed that one should not use `async`, I am only suggesting that be careful about using `async`.
In my experience, a median Go programmer is more comfortable with Go routines than a median Python programmer is with async functions. YMMV.
additional: "However, writing your own code that involves async functions", your code does use async functions, its just monkey patched into your program because you used green threads instead.
You can use poetry instead. Poetry is stable.
I wish `uv` was version 1.0 or later. However, despite it not being version 1.0 yet, I do see that it provides a superior experience for me to switch from `poetry` to `uv` and to make that recommendation after adding the pre-version 1.0 caveat.
I see the entire community gravitating towards uv because of its merits. I tried it, and I agree. I already started using it for every project. I’ve even converted older projects to it.
It’s not feasible for everyone to do a full evaluation of everything. At some point you need to rely on an expert to at least provide some basic assurances before spending time on digging deeper.
This is from their own documentation and release history. I never brought up version numbers before now, only their self-admitted unstable status. Version numbers were brought up by someone of the opinion that uv is stable enough.
Yeah, that's how it is because it is costly for maintainers to maintain. What's your point though, is poetry better in this regard or what are you suggesting as a better alternative to uv?
pip has the same problem as uv in this regard, but I'd be hoping that there would be less breaking from breaking changes, due to the amount of people depending on pip not breaking.
If I had money? I'd fork pip or uv and assign some people to make an downstream with extended support.
There docs around GitHub Actions and docker are also pretty succinct and usable.
Blocking python can’t.
An example is running multiprocesses and parsing their output and looking for patterns. Async python does this sort of thing well.
Can you share a scenario where this would happen?
I have deployed multiple machine learning and data analytics-focused web services, and this has never happened to me.
FastAPI is faster than the other popular framework, Flask (I posted data supporting that), even without using async.
I only suggested that one should use their discretion when using async.
When did I suggest not to write async code?
However, ruff keeps evolving rapidly, so I am hopeful that I can get rid of all other linters and formatters over time. If you have a suggestion on streamlining my `make format` and `make lint` commands, I am all ears.
Presenting these opinions as truths will get the hackles up of those who have a different opinion.
Isn't that always implicit?
But for certain use-cases, as mentioned in the article itself, it is unavoidable.
Further, you might be working at a company that has decided to use Python, and you can make Python more efficient and effective using these suggestions.
A lot of the world runs just find on Python (see Django), async is mature and stable.
I never claimed that one should not use `async`, I am only suggesting that be careful about using `async`.
In my experience, a median Go programmer is more comfortable with Go routines than a median Python programmer is with async functions. YMMV.