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.
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
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.
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.
Ruby has the same thing but it’s called ‘new’.
Implementing the type of customization (idiomatically) that __new__ provides in Kotlin and JS isn’t any cleaner.
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?
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.
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?
My read was that the "ugliness" was in the method naming, and specifically the double underscores, not the availability of the methods themselves.
Think JNI or cgo management.
Those native packages can be in any language and require any odd combination of tools to build. Who has truly solved that problem?
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.
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.
And it seems like the package resolution is finally local by default, although that requires a 'virtualenv', which seems to be a legacy of the global packaging system.
Made me think this is probably normally a Ruby developer indoctrinated against Python. The article doesn’t seem to say what they have come from.
Ruby devs think about code differently. Like Perl, they embrace TIMTOWTDI.
https://perl.fandom.com/wiki/TIMTOWTDI
Also, there's a pride in writing elegant code as opposed to following "Pythonic" conventions. Excellence is not conformity.
I use Python a lot more often now because it's seen as simpler and more approachable and easier to force compliance. I miss Ruby.
Having said that, in reviews you do get lazy comments like "not pythonic" or "not best practises" which often boil down to the reviewer just not liking something and being too much of an *** to say why. This is supposed to be a total shutdown that you cannot argue with and it's the kind of thing that might put you off the term "pythonic" for life.
"There should be one-- and preferably only one --obvious way to do it."
This is probably the core thing you might have issue with but I think its not really about conforming in how you write your own code but about the thing you make being easy for others to use.
> There should be one-- and preferably only one --obvious way to do it.
But I often don't think the Pythonic way is a very good way to do it. And this leaves you a bit stuck!
Yeah, and it's the wrong approach. Of course, you can have whatever preference you want, but in terms of engineering, it's plain wrong.
> If you know me, you know I used to be mostly a Java/JavaScript/R kind of guy. ↩
It solves a lot of the package management headaches for me.
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.
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.
You should talk to the Java advocates in my company :) The language wars are still around, it's just Java vs the rest now.
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.
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
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.
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.
Nonsense.
> I don't think I heard about web servers in Python before 2012.
More nonsense.
> I suppose a 2005 computer wouldn't be able to serve a Python backend smoothly.
Extreme nonsense.
https://medium.com/signal-v-noise/ruby-has-been-fast-enough-...
And this is when Python was edging Ruby performance wise.
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.
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? :-)
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.
That said, I remember writing myself a note a few years ago to avoid Python projects. I had to clean up code from all over the company and make it ready for production. Everyone had their own Python version, dependencies missing from requirements.txt, three way conflicts between 2 dependencies and the python version, wildly different styles, and a habit of pulling in as many libraries as possible [1]. Even recalling those memories makes my stomach turn.
I believe constraints make a project shine and be maintainable. I'd prefer if you throw at me a real python instead of a python project.
[1] Yes, I'm aware of containers, I was the unlucky guy writing them.
In my personal timeline, people giving up waiting for Perl 6 were a huge source of early Python developers.
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.
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.
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.
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
That said, call me old-fashioned, but I really take issue with "curl $URL | bash" as an installation method. If you're going to use an install script, inspect it first.
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)
Why is that?
Why Python for AI?
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.
I am pretty sure some people (maybe this individual, too) may be using Python because their scripts can be executed in a sandbox on one of these websites.
Heck, if it was as good at Factor or Forth as it is at Python, I would be writing more of them, too.
In any case, you cannot claim that it is not one of the reasons. Can you?
Also the vibe coding part gave me the impression that you were implying that people that use/chose Python for AI are all vibe coders which is again false. Sorry if I misunderstood you, but this is what I got from your initial message.
messe•6h ago
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.
blitzar•5h ago
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.
oneeyedpigeon•5h ago
frizlab•5h ago
est•5h ago
/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/
wiseowise•5h ago
stby•5h ago
comradesmith•5h ago
Though for a while there having built in interpreters was great for kids and learners.
latexr•5h ago
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•4h ago
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
latexr•3h ago
It seems much more likely to me they were just tired of having to manage the languages (and being constantly criticised they were behind) and simply chose to remove them.
latexr•5h ago
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.