I'm Switching to Python and Actually Liking It
107 comments
·July 16, 2025reedf1
wiseowise
Bizarre is that you don’t consider it ugly.
Kotlin: constructor is either part of class definition or keyword constructor.
Ruby: initialize
JS: constructor
Python: ______new______, _______init_______
Literally this meme: https://knowyourmeme.com/memes/three-headed-dragon
NoboruWataya
I like that magic method names generally all follow the same form so it's obvious that they are magic methods and not intended to be part of the public API. Whether that form uses double underscores or something else doesn't really matter to me as they are not being called directly.
fiedzia
> it's obvious that they are magic methods and not intended to be part of the public API
Is there an alternative API? No. This is public API regardless of anyone's intentions. Though "it's weird" is really not a very strong argument against it.
63stack
Would you consider a constructor magic though?
t43562
You don't call __init__ directly so the ugliness is limited to the definition which seems fairly minimal to me. It seems to be a naming convention for methods that are not invoked by name anywhere and that's at least informative when you're reading the class definition.
IMO this is less horrendous than e.g. go's insistence that exported functions are indicated by a capital letter - that really affects code using the module not just the definition.
reedf1
I had honestly not considered that the author might have been talking about the visual aesthetic of the dunder methods themselves. Honestly that has me a bit stumped; all I can say is that if you don't like underscores, don't pick python.
dncornholio
I have found to believe that ugly and beautiful are irrelevant. As long as it's doing the job and not cause major headaches. Life is too short to worry about syntax.
orphea
Right? I'm kind of surprised that a few underscores invoke such strong emotions in people.
timeon
Can you elaborate bit what is the problem here? Is it shape of the characters or something else?
brabel
Amazing. If you need to ask this question I am guessing you have spent too long with Python . No other language uses this underscore madness for special methods or otherwise. Because it’s just , I don’t know a more appropriate word for it , stupid.
andyjohnson0
> What exactly is the problem with __init__ or __new__? @dataclass is very nice syntactic sugar, but are we arguing here that having access to initializer/allocator/constructor dunder methods is "legacy ugliness"?
My read was that the "ugliness" was in the method naming, and specifically the double underscores, not the availability of the methods themselves.
thaumasiotes
Probably the system of giving special meaning to what are otherwise ordinary identifiers. __ isn't a reserved keyword in Python or anything. But there's a set of conventions you're supposed to follow when naming methods and attributes, and they're visibly artificial. It would be cleaner to make the features that are a special part of the language definition also a special part of the language syntax instead of running them in indistinguishably with other nonsimilar things.
In C++, if you want to define the binary + operator on a class, you give the class a method with the special name `operator+`. In Python, to do the same thing, you give the class a method with the pseudo-special name `__add__`. You don't think the Python way is worse?
acdha
> You don't think the Python way is worse?
Have you considered how much familiarity might shape your reaction to the two? Both are specific patterns with arbitrary restrictions which new learners have to internalize, and that’s a fairly advanced task most people won’t hit until they are familiar with the language syntax.
Here’s a counter argument: the Python methods are normal method declarations whereas C++ developers have to learn that “operator=“ means something different than what “operator =“ (or any other assignment statement) would mean, and that this is the only context where you can use those reserved symbols in method names.
To be clear, I don’t think either of these is a big deal - the concepts and usage are harder to learn than the declaration syntax – but I think it’s incredibly easy to conflate familiarity with ease of acquisition for things like this.
thaumasiotes
> Have you considered how much familiarity might shape your reaction to the two?
It doesn't.
> Both are specific patterns with arbitrary restrictions which new learners have to internalize, and that’s a fairly advanced task most people won’t hit until they are familiar with the language syntax.
No, the Python methods are just ordinary methods with valid names. What 'arbitrary restrictions' are you referring to?
reverius42
I'm not sure how "operator+" is supposed to be appreciably different from "__add__".
brabel
One is a sensible choice a human might pick. The other is not.
Mawr
Just a small note on the code in the linked script:
API_KEY = os.environ.get("YOUTUBE_API_KEY")
CHANNEL_ID = os.environ.get("YOUTUBE_CHANNEL_ID")
if not API_KEY or not CHANNEL_ID:
print("Missing YOUTUBE_API_KEY or YOUTUBE_CHANNEL_ID.")
exit(1)
if not API_KEY:
print("Missing YOUTUBE_API_KEY.")
exit(1)
if not CHANNEL_ID:
print("Missing YOUTUBE_CHANNEL_ID.")
exit(1)
CoolCold
> Not only because the syntax is more human-friendly, but also because the Python interpreter is natively integrated in all Unix distros
That's kind of very optimistic evaluation - literally anything beyond "import json" will likely lead you into the abyss of virtual envs. Running something created with say Python 3.13.x on Ubuntu 22.04 or even 24.04 (LTSs) / Rocky 9 and the whole can of worms opened.
things like virtual envs + containers (docker like)/version managers become a must quickly.
acdha
“import json” is the kind of thing which requires picking and installing libraries in batteries-not-included languages, and it’s just one of many modules which are in the standard library. That’s not a compelling basis for large projects but over the years I’ve shipped a ton of useful production code which never needed more than the stdlib and thus spent no time at all thinking about deployment or security patching.
Also, it’s not the 2000s any more. Using venv to isolate application installs is not very hard anymore and there have been decent package managers for a long time.
nikisweeting
this is solved by uv
CoolCold
> things like virtual envs
I consider my point as still valid with UV, what you wanted to express?
On UV specifically - say 'asdf' compiles python right on your system from official sources - means using your ssl libs for example. UV brings Python binary - I feel worried on this.
pyman
From what I was told, Python was originally seen as a Swiss Army knife for sysadmins. It started gaining more traction when Canonical adopted it as the main language for Ubuntu 4.10 in 2004.
Then, in 2005, Guido van Rossum was hired by Google to work on Google Cloud. That opened the door for wider adoption in academia, since Python had strong math libraries and integrated well with tools researchers were already using, like Hadoop, right around the time big data and ML were starting to take off.
Also, between 2005 and 2006, two important things happened: Ruby on Rails came out and inspired Django, which was starting to gain popularity, and web developers were getting tired of Perl's messy syntax. That's how Python quickly became a solid choice not just for server-side scripts, but for building proper web apps. In the meantime, another language that could be embedded directly into HTML was storming the web: PHP. Its syntax was similar to JavaScript, it was easy to pick up, lowered the barrier to entry for software development, worked straight out of the box, and didn't require thousands of print statements to get things done.
The 3 Ps made history. According to programmers from 20 years ago, they were like religions. Each had its own philosophy and a loyal group of followers crusading online, getting into heated debates, all trying to win over more adopters. The new generation of devs is more pragmatic. These days it's less about language wars and more about picking the right tool for the job.
tgv
Python's success is entirely due to entry-level programming courses. They all switched to Python, because you have to explain less. I don't think I heard about web servers in Python before 2012. I suppose a 2005 computer wouldn't be able to serve a Python backend smoothly.
PHP's popularity isn't really from 2005-2006. It was popular at the end of the 90s, and it looks like JS as much as it looks like a potato.
stevesimmons
> I suppose a 2005 computer wouldn't be able to serve a Python backend smoothly.
Python had web servers from 2000, including Jim Fulton's Zope (really a full framework for a content management system) and in 2002 Remi Delon's CherryPy.
Both were useful for their day, well supported by web hosting companies, and certainly very lightweight compared to commercial Java systems that typically needed beefy Sun Solaris servers.
theshrike79
With python you can just go: 'print "hello, world!"' and that's a full-ass program
You run it by saying `python hello.py`.
Compare that to the amount of crap you need(ed) with 2005 Java just to have something running.
The shittiness of ActivePython and generally getting python to run on Windows were a bit of a hurdle, but still it was easier than the competition
pyman
> Python's success is entirely due to entry-level programming courses.
Yeah, after 2008. And by 2014, it had overtaken Java in many CS programs. But I was referring to the events that led to that.
stevesimmons
The key factor imo was Travis Oliphant merging the competing numeric and numarray libraries into numpy in 2005. That quickly became the foundation of Python as the key environment for open source numeric processing.
It brought across a ton of users from R and Matlab.
Pandas, Matplotlib and ScikitLearn then consolidated Python's place as the platform of choice for both academic and commercial ML.
darkstar_16
> These days it's less about language wars and more about picking the right tool for the job
You should talk to the Java advocates in my company :) The language wars are still around, it's just Java vs the rest now.
pyman
One of my colleagues, a retired programmer who spent 20 years at Microsoft, told my students that it used to be Java vs Visual Basic, until Microsoft brought in the big guns, like Anders Hejlsberg. That's when it turned into Java vs .NET, and things really started to heat up :)
smcleod
Python as a language is nice. Python's version and package management is nothing short of a nightmare.
lazzlazzlazz
This hasn't really been true for a while now. `uv` has radically improved the experience.
bborud
For the last 20 years that has been the mantra. Some X "solves" all the problems.
Except it doesn't. It just creates another X that is popular for a while, and doesn't somehow retroactively "fix" all the chaotic projects that are a nightmare to install and upgrade. Yes, I understand people like Python. Yes, I understand the LLM bros love it. But in a real production environment, for real applications, you still want to avoid it because it isn't particularly easy to create robust systems for industrial use. You may survive if you can contain the madness in a datacenter somewhere and have people babysit it.
cedws
There’s still 20 years of projects using everything that became before uv. They didn’t upgrade the moment uv came into existence. Data science-land still uses other rubbish too.
zimpenfish
> They didn’t upgrade the moment uv came into existence.
There's also projects that can't use `uv` because it doesn't like their current `requirements.txt`[0] and I have no bandwidth to try and figure out how to work around it.
[0] We have an install from `git+https` in there and it objects strongly for some reason. Internet searches have not revealed anything helpful.
est
Python's package management is OK. The main culprit is .so libraries
Think JNI or cgo management.
t43562
Yes, I've never really understood the complaint about python packaging - building native code is not something that is ever easy to guarantee across multiple distributions and operating systems.
Those native packages can be in any language and require any odd combination of tools to build. Who has truly solved that problem?
nikisweeting
wheels, conda, docker, firecracker, unikernel, flatpak
xyzsparetimexyz
Using a nix devshell has worked out well for scripts for me so far. I haven't figured out what that workflow is like for larger projects though. I'm not interested in learning Uv
jcattle
Going to be honest: With uv it really isn't that bad anymore. Sure, the whole packaging ecosystem is still really bad, but uv abstracts over most of it. Unless you're doing some really esoteric stuff you'll be just fine.
latexr
> I started to code more in Python around 6 months ago. Why? Because of AI, obviously. It’s clear (to me) that big money opportunities are all over AI these days.
I find this depressing. Not only are LLMs covertly reducing our ability to think and make decisions, they’re now also making people voluntarily conform to some lower common denominator.
It’s like humanity decided to stagnate at this one point in time (and what a bad choice of point it was) and stop exploring other directions. Only what the LLM vomits is valid.
mrpopo999999
humanity tried to save time and allocate it to other pursuits, don't worry
messe
> the Python interpreter is natively integrated in all Unix distros
It's included in the default install of most desktop/server Linux distros (with plenty of exceptions), but I don't believe any of the BSDs ship it in their base system.
IIRC macOS used to have python 2 in its default install, but I vaguely recall that being deprecated and removed at some point. My only Mac is on the other side of the country at the moment, so I can't check myself.
latexr
Python 2 was removed in Monterey 12.3, which was incredibly stupid and disruptive as it caught everyone by surprise. We all knew Apple said they would remove it, but everyone was expecting them to be sensible and do it on a new major OS release, like they did with PHP, not mid-cycle.
https://developer.apple.com/documentation/macos-release-note...
I wonder if that kerfuffle is why they ended up not removing Ruby and Perl yet, despite the same promise. macOS’ Ruby is around 2.6. Perl I somehow doubt they’ll get to, as it’s such an important part of Unix admin I bet they themselves use it somewhere.
There is still a /usr/bin/python3 which is a shim. When you call it, if you don’t have the Xcode Developer Tools you’ll be asked to install them (it’s a non-scary GUI dialog which takes two clicks) and then you’re set. That is also a few versions behind the cutting edge, but it does get updated sometimes.
blitzar
I dont think python is pre-installed on macOS now. (uv has replaced it for me)
Edit: Unlike older versions of macOS that came with Python 2.7 pre-installed, newer macOS versions (Catalina and later) no longer include Python pre-installed.
latexr
Technically macOS doesn’t come with Python pre-installed, but it does provide you with a simple path to do it.
https://news.ycombinator.com/item?id=44580198
The removal was in Monterey. Catalina and its successor Big Sur very much still had it. Catalina was the one that removed 32-bit support.
tovazm
I think they realised the security implications,
you could just take a random person macbook, open the terminal and launch python3 -m http.server 3000 --directory ~
then on the local network you could download all his files
oneeyedpigeon
macOS dropped PHP recently too—doing a wonderful job of losing all that developer share that Apple was slowly building up.
frizlab
Why? Installing python and php can be done in 2 seconds with brew, and you have control over what you install instead of using whatever is in the system, with deprecated versions, etc. It is actually much better now. System tool should be left to the system.
wiseowise
Virtually zero professional developers that I know use built in Python or PHP. Maybe it’s good enough for occasional scripting purposes, though.
comradesmith
I think it’s better for developers to not have conflicting system distributions.
Though for a while there having built in interpreters was great for kids and learners.
stby
I much prefer installing it myself, with the required version for my project and at a known and common location.
est
if you install commandline tools there's
/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/
bravesoul2
I like Python for the language, and for a lot of jobs the threading model limitations do not matter. Its a great language to get stuff done. I find the package management story challenging but I will try uv next time!
rich_sasha
I resisted pipx, poetry, anaconda and probably some other things, as I didn't see the point over venv+pip. But uv is just so damn good, there's no going back.
bootsmann
Feel like pipx walked so uv could run, it popularized the idea of abstracting the environment management away from the user.
gjvc
pipdeptree is all you need for many things, but uv is such a joy to use it's hard to resist, sure.
sudosays
If you haven't already you should check out uv: https://github.com/astral-sh/uv
It solves a lot of the package management headaches for me.
firecall
“I started to code more in Python around 6 months ago. Why? Because of AI, obviously. It’s clear (to me) that big money opportunities are all over AI these days. And guess what’s the de facto programming language for AI? Yep, that sneaky one.”
Why is that?
Why Python for AI?
AlexeyBrin
Because you get first class support in many AI libraries like PyTorch, TensorFlow and so on ... Most of these libraries can be used from other programming languages too, but it is easier to find good documentation and examples for Python.
johnisgood
Because many available LLMs run your Python code in a sandbox, which means less friction for vibe coders.
AlexeyBrin
> Because many available LLMs run your Python code in a sandbox, which means less friction for vibe coders.
This is false, a lot of non "vibe coders" are using Python for AI because of PyTorch and a many other AI libraries have first class Python support.
t43562
I'm glad someone else discovered they can like python.
I got forced to learn it for a project where I was proposing Ruby and the customer insisted on Python. This was years ago when Ruby was much slower. I was annoyed but I got used to it and here I am enjoying it many years later.
I take issue with the description and use of make though! :-D What is the point of it if you're not going to use dependencies? One might as well just write a script with a case statement..... I'm adding smileys because I don't mean to be all that serious but I really do think that the failure of the youth of today to get to grips with Make is a sad reflection on our culture....... and get off my lawn, ok? :-)
Roark66
From what? It would be useful to mention towards the front of the post so we know what is the context in which you approach python.
I've switched to python primarily (from perl) in early 2010s (I think my first "seriously" used version was 2.6. This is mostly for system management, monitoring, and data transformation /visualisation. Nothing fancy like AI back then in a work setting.
I found the biggest impact was not so much on writing code but on it remaining readable for a very long time, even if it was created hastily "just get this working now" style. Especially in a team.
Python is still one of my favourites and the first tool I reach if bash is not enough for what I'm trying to do.
igor47
Good write up, and solid choices. As someone primarily working in python in the last few years, I have a very similar stack.
Two additional suggestions:
* mise to manage system dependencies, including uv version and python itself
* just instead of make; makefile syntax is just too annoying.
Mise actually has a command runner as well which I haven't tried yet, and might work better for running commands in the context of the current environment. It's pretty nice when your GitHub actions workflow is just:
* Install mise
* mise install everything else
> Python has done a good job of hiding its legacy ugliness (such as __init__, __new__, and similar aberrations), swettening its syntax to accomodate developers with good taste.
What exactly is the problem with __init__ or __new__? @dataclass is very nice syntactic sugar, but are we arguing here that having access to initializer/allocator/constructor dunder methods is "legacy ugliness"? This is the core of pythonic built-in aware python. Bizarre.