Welcome to the Python community on the programming.dev Lemmy instance!
Past
November 2023
October 2023
July 2023
August 2023
September 2023
Python is used in so many different contexts it's extremely hard to create "one tutorial to rule them all".
On that subject but also kinda out of topic, does anyone have good resources for learning Python?
My gf is very into excel macros and could benefit from Python as a data analysis tool, but as all resources online are paylocked it's hard to get an idea of their quality. She's also the learn-by-examples kind.
Real Python is great in general! They explain stuff well and correctly. I don't know if it's good for learning start to finish, but at least if there's a specific topic you need to deep diver deeper into. It's my go tho when exploring a new python related topic.
I learned python from codecademy back in the day, are they still around? I remember their examples/course being very interactive and completely free
Yeah, they ask for your payment details after the second section of their Python course ๐ข I think I read somewhere that their Python 2 course was still free, but it's not very convenient. Paying would be okay, but it's hard to get an idea of what you get for the price without asking around ๐คทโโ๏ธ
What do you do when there is/are unavoidable package dependency conflict(s)? <-- biggest question in Python
Often times, split out into mutliple venvs.
For example, Sphinx requires py310+. My default is py39. myst-parser restricts dependencies rather than allow the latest and greatest. So there is an unavoidable need for two venv.
After setting up pyenv, how much setup is required, in pyproject.toml, to setup these two venv?
Looking at poetry, it's focused on one venv. And it's annoying it considers pyproject.toml to be a r/w file. I want to configure for an unlimited number of venv.
The OP author is very familiar with uv, having written multiple articles on it. Pushes it onto his students. So i get it, the article is focused on uv and he is invested in uv. This assessment is a tiny bit unfair, but enough, only, to justify reading the article with a tiny grain of salt.
For package management, i'm happy with pyenv. So there i have a bias.
The biggest praise i have is, it follows the UNIX philosophy, do one thing and do it well. uv does multiple things, the issue comes down to resources required to maintain a super complex thing. Especially in a completely different coding language! I DONT GIVE TWO SHIATS IF ITS FASTER, I care about maintainability after the original geniuses disappear and they will.
Any blog post which doesn't mention competitors, tiny grain of salt --> giant grain of salt.
If not mentioned, have to assume either don't know about them or haven't bothered to try them.
What are the actual competitors to uv (specifically for dependency management)?
The only package mentioned is: poetry
poetry also violates the UNIX philosophy. It combines build backend with dependency management. I want them separate.
Open up that super powerful doom pr0n machine, AI, and get it to find the other (dependency management packages). Mention them in the blog post.
"Do one thing and one thing well"
This is why the Python landscape is such a mess in the first place. The "one thing" should have been project management. Instead, we end up with 20 different tools that have a very limited context, often overlapping or being mutually exclusive to each other in functionality, and it's up to each project to adopt and configure them correctly.
The mass adoption of uv is a clear sign that we're tired of this flawed approach. Leave the Unix philosophy to core utilities of an OS.
The article quite clearly mentions competition:
Because I'm a freelancer dev, and also a trainer, I get to navigate those waters and I've seen all other tools fail spectacularly. pyenv, poetry, pipenv, pdm, pyflow, pipx, anaconda...
As well as discusses anaconda later in relation to CLI and GUI.
The speed is really fantastic, there's nothing else I can say. If you don't see a benefit, the it's fine of course. But going from insanely long resolution times in my previous work place using conda to now resolving stuff in a matter of seconds is incredible. uv is the first tool I have used for Python that just feels right.
I recommend listening to the podcast from Real Python that talks with Charlie, they discuss the commercial aspect https://realpython.com/podcasts/rpp/238/
The biggest praise i have is, it follows the UNIX philosophy, do one thing and do it well.
That isn't a pro on its own, and it's also a very wooly rule. Uv does one thing and it does it well - Python project management.
the issue comes down to resources required to maintain a super complex thing
They seem to be managing fine. I guess having a company back it is enough. But that is also probably my biggest worry about it - what if Astral goes away (which given their apparent lack of business model I suspect they eventually will)? Hopefully uv is popular enough by that point it won't die.
I DONT GIVE TWO SHIATS IF ITS FASTER
It's literally 10x faster. I'm not sure what kind of person wouldn't care about that.
Itโs literally 10x faster
reminds me of the ol' joke
young bull: lets run down the hill and get us a heffer
old bull: lets walk down and do 'em all
wtf is your rush?
It literally doesn't matter how long it takes. Especially when Astral has moved on.
It literally doesnโt matter how long it takes.
Found the Python dev...
Itโs literally 10x faster. Iโm not sure what kind of person wouldnโt care about that. On that, lets agree to disagree.
Thru magic Astral has funding. I don't. So why shoulder the risk that their magical situation will continue forever.
When Astral goes tits up, which we seem to agree on, and everyone is whining crying and screaming, at least there is one or more fallback(s) written in Python which is/are maintainable by people without magical super powers.
I don't know why you think maintaining uv will require magical superpowers. Writing it in the first place requires a ton of work, sure. But that seems to be mostly done.
no cons. you should migrate. I didn't read the article.
Well I can think of a couple:
uv cleanuv which you may not want to impose on users, or CI.But it's sooooo much better than the official tooling (and the competition like Poetry) that the conclusion is still the same: you should definitely use it.
That's pretty much the conclusion: you should try uv first, and there's a small chance it doesn't work for you and you're not willing to fix it, or it's out of your hands.
Examples include legacy projects and companies that don't allow it (but I do question how they'd even enforce this, and how developers can even do their jobs if they can't run binaries at the user level).