I was fresh at university, around 2001, and our mathematics professor introduced us to Python with NumPy/SciPy as an alternative to the commercial math tools. There aren't many events that changed my career as much as that. Being exposed only to compiled languages before that, it blew my mind. It was friendly, expressive and came with batteries included.
There was a huge sense of community around Python, that I didn't really see elsewhere in the programming world. It started with these scientific libraries. Python wouldn't be what Python is today without NumPy. It was nice to see in the last years the boost of the Python scientific community, with basically anything machine learning using Python as the DSL.
I disagree. The scientific libraries were just one of many niches, and an awkward one at that. One could equally say "it started with xml libraries" or "it started with file-handling libraries" or "it started with http libraries" -- all of which were in the Standard Library very early, unlike the horrible-to-build numpy/scipy. All of these made the language popular initially across a number of different crowds. Numpy/scipy reached traction relatively late when Python was already well-established in niches like sysadmin, web, education, 3D, and many others. By 2001 we already had multiple web frameworks, Zope, even WSGI...
It is occasionally annoying how this or that crowd tries to appropriate Python's success, hence flattening its purposes and aims.
But all the other use cases were covered back then primarily by Perl. Python was the first dynamic language to effectively use this class of libraries.
I had been using Perl from 1995-2000. I was a fairly advanced Perl programmer (was there for the Perl 4 -> 5 transition), using it mostly for automating system administration tasks.
In 2000 I joined a new startup and was shown Python 1.5.2 by the startup's chief architect/scientists. He'd come from Infoseek where he'd used it there to help build parts of the company.
Now, I loved Perl. I was one of those annoying geeks with "RSA in 4 lines of Perl" T-shirt. I'd write JAPH programs for fun. But I appreciated how much "smaller" Python was than Perl. I was able to learn pretty much all of its rules in an hour? I didn't have to worry about all the crazy ways Perl programs could express themselves. (Is this scalar context or array context?[^1] Is this script using my or local? What the heck does this crazy line I didn't write do again? Oh wait, I wrote that line!)
So anyway, this startup was using Python and now so was I.
That startup is long gone, but I'm still using Python daily in my career.
And I've never used numpy.
Perl was/is great, but it's just too quirky to have the broad appeal of Python.
FWIW I learned Perl in 2016, and it became my language of choice (sorta) for ~6 months, but the overwhelming momentum of Python is hard to avoid. Perl was/is cool though!
In my university, we were given a choice to use either Matlab or Python for exercises in many advanced courses. We even got Matlab licenses for our personal computers. But since the smallest Matlab installation still came in at several GB and my personal computer was always full with games, I chose the python stack which came in at maybe 100-200 MB for all relevant packages, while nearly everyone else chose Matlab. None of them have ever used Matlab again after University and I still use Python all the time.
That is all good and well. Unfortunately, it degenerated into a tyranny where a small group of mediocre people grabbed power, censored the infrastructure and threatened people with defamation if they didn't obey.
Most developers have left or have been driven out. The remaining ones do corporate projects that generally underdeliver.
This is very normal - people like that are drawn to the free money available at foundations. Thankfully uv etc from Astral are doing what the very medicore minds at the PSF cannot.
Ah, that makes sense, thanks. A few years ago I saw bullying and harassment in one Python project that was instigated by the code of conduct committee. Seems like history is repeating..
Timsort, the Zen of Python, and many other things. Over 2500 commits to the CPython repository overall (11th on the all-time list). Quite good at explaining details of how floating-point works, especially as relates to Python, IMX. And extraordinarily helpful over a long period of time: https://stackoverflow.com/search?q=user%3A2705542+is%3Aanswe...
It is striking that this article equates community with bureaucratic efforts like setting up the PSF and getting funding for the PSF. It is essentially a hagiography for the bureaucrats. The omission of Tim Peters, who was later slandered by bureaucrats, is notable.
well it started out with perl6 as a breaking change major upgrade to perl5
the perl community fractured into those that wanted to avoid a breaking change (since they feared the kind of pain that Python 2 => 3 would later encounter) and those that wanted to evolve the language with things like a Type system and Object Oriented coding as standard
the fracture became a chasm when it became obvious that perl6 was taking years and that there was no migration path from perl5 to perl6 - users began to explore options and often Python was top of the list
this was exacerbated by the use of perl6 as the name ... later (much later) the name was changed to raku ... but by then the perl language was a shadow of its once dominant self and CPAN (the perl module library) lost a lot of folks doing maintenance and improvements so that began to bitrot
fear lead to anger, anger lead to hate
[btw raku is now very nice with all these features and still the great feel of classic perl and has a small but active and friendly community]
Is there a canonical "perl 6" now? LIke I can't go to perl.org and download one, or at least the "latest stable version" is listed in the 5.x range still.
Or is "perl 6" not even a thing to ask about, and "raku" is what was to be "perl 6" became?
he-he, sometimes, but mostly because it shows there are real people behind who have emotions. Agree on rust (put rails or others here) having too much of it sometimes
Python 2 code was absolutely not "thrown away just because". Nobody made your interpreter stop working; it was never on a cloud service or anything like that. It just stopped receiving bugfixes from core team (it's open source so everyone was and is free to take over maintenance) and third-party tool and infrastructure support (notably, PyPI) doesn't take it into consideration any more.
Further, the changes were made for very good reasons, such as allowing beginners to accept user input on day 1 without opening ACE exploits in their programs, and having plain double-quoted string literals actually produce a string rather than an immutable byte buffer that vaguely assumes a generic code-page encoding, except for the contexts where it will complain if it's not plain ASCII (admittedly, this is still an improvement over trying to handle text in C with only the standard library), and making sure that decoding operations don't produce encoding errors and vice-versa, and making `isinstance(1<<64, int)` give the expected `True` result, and making `except` syntax make sense, and making sure there aren't two fundamentally different kinds of user-defined class.
And by making these changes, we actually got Python 3 in about 2.5 years (4.5 if you allow for the first couple of releases having some issues figuring out the string literal transition and other such details — I agree they were premature) and were able to offer another 11 (9) for everyone to migrate. Whereas with Raku the entire 13.5 (more like 15.5) year period was spent on design and implementation, and now there hasn't been a new stable release for almost 5 years.
> it's open source so everyone was and is free to take over maintenance
Open source implementations are fine, though the "if you don't like it fork/make your own" argument is, typically a way of sidestepping criticism rather than a practical solution.
But one of Python's greatest weaknesses is that there is no formal language specification. All you have are implementations and their documentation.
From my perspective (suffering through the python 3 transition and living with ongoing changes in 3.x), compatibility was - and is - poorly handled. Many things can and should be done to ease the maintenance burden - things like intelligent defaults, compatibility features and libraries, and not doing stupid things like ripping out the print statement (which could have coexisted with a print() function) with no recourse.
Unfortunately, python's developers seem to have demonstrated tremendous contempt for the users of the language, and for existing code bases.
Other languages (though not all.... <cough, swift>) have actual language specifications and standards (that even keep working as runtime systems evolve), and are not so keen on throwing users and their code off a cliff.
Platforms should absorb pain so that their users don't have to, and avoid introducing breaking changes that multiply pain across an entire user base.
Apple (also known for arrogance combined with contempt for their developers) also gets this wrong, and routinely breaks iOS and swift apps every year.
Can you give a concrete example of a problem you encountered while porting 2->3 code caused by a poorly chosen default in 3?
> compatibility features and libraries
You mean like `lib2to3`? Or all the backports 2.7 got, e.g. what's listed at https://wiki.python.org/moin/StandardLibraryBackports ? Or the `__future__` system? Or third-party support like `six` (still immensely popular, though presumably only in CI)?
> the print statement (which could have coexisted with a print() function)
No, it absolutely could not have. Not with the same name, and making the name refer to the function was the point. The print statement syntax was inelegant, quirky and confusing. For example, parentheses can affect the meaning in unusual ways:
Besides which, outputting text has no more logical reason to use a dedicated statement form than inputting text.
> python's developers seem to have demonstrated tremendous contempt for the users
I don't understand how you have come to infer such an attitude. Any suspicion that they are introducing breaking changes on a whim will be immediately quashed by reading the discussion behind any of those breaking changes. (Not to mention what happens with the rejected proposals.)
> and avoid introducing breaking changes that multiply pain across an entire user base.
What breaking change was introduced in Python 3.x during your history of using it that caused a nontrivial problem for you? How many years do you believe you were given to account for it?
It could have fairly trivially for the vast majority of use cases (no space between print and parenthesis if you want to call the function) but apparently that would have made some python maintainers unhappy. So it was ripped out and a breaking change was introduced with no recourse (not even, say, from __past__ import print_statement or something).
This is part of what I mean by demonstrating tremendous contempt for the user base and for existing code.
Ruby and Perl are great examples of massively popular languages that withered because the language/platform outpaced the community.
If the first question you’re asking yourself looking at a code base is “what version is this/do I know this version” then that language is not facilitating you.
The successful languages are ones where “the community” prioritises backward compatibility. Java, C, Python have backward compatibility spanning decades. There’s a few discontinuities (lambdas in Java 8, Python 3, C++) but in most cases there’s a clear mapping back to the original. Python 3 is an exception to this but the migration window was something like 15 years…
Busy engineers, scientists and academics have little interest in keeping up to date with language features. A computer and a programming language are a tool for a job and the source code is just an intermediate artifact. These are your “community”, and the stakeholders in your success.
Have you used them? Perl has version tags in source code and everything is feature gated including the stdlib. Python does none of that. The stdlib changes constantly and just looking at source code gives you no indication if you can run it with your installed python version.
I don't believe that "from __future__" is the future-proofing you think it is, they just named it that way to be cute - a hypothetical 3.19 version couldn't even use it, since it's just a normal python import
$ python3.13 -c 'from __future__ import awesome_feature'
File "<string>", line 1
SyntaxError: future feature awesome_feature is not defined
the very idea of "future feature is not defined" is insaneo
Anyway, I'd guess what they intend is
try:
from __future__ import fever_dream
except SyntaxError:
fever_dream = None
because python really gets off on conditional imports
I was responding to the "Python does none of that" by pointing out that Python does indeed have features to help introduce new capabilities in a thoughtful way - I know it's not the same thing as something like conditional imports.
I do not really know which event you mentioned. But if you use the current version of perl interpreter. It still work for most of old versions. And new features keep safe for old perl.
Perl doesn't have "perfect backward compatibility" in the normal sense of the word. There is only Perl 5 which is perfectly compatible since it hasn't changed for 25+ years (which is how they achieved "compatibility" -- by not changing), and there's Perl 6 which isn't backward compatible and nobody really uses it.
A major new version of Perl ships regularly. A few weeks ago the latest major new version shipped. From the 2025 changes document:
> Perl 5.42.0 represents approximately 13 months of development since Perl 5.40.0 and contains approximately 280,000 lines of changes across 1,600 files from 65 authors.
Skipping back 5 major new versions (to 2020):
> Perl 5.32.0 represents approximately 13 months of development since Perl 5.30.0 and contains approximately 220,000 lines of changes across 1,800 files from 89 authors.
2015:
> Perl 5.22.0 represents approximately 12 months of development since Perl 5.20.0 and contains approximately 590,000 lines of changes across 2,400 files from 94 authors.
2010:
> Perl 5.16.0 represents approximately 12 months of development since Perl 5.14.0 and contains approximately 590,000 lines of changes across 2,500 files from 139 authors.
There's been well over 10 million lines of code changed in just the core Perl codebase over the last 25 years reflecting huge changes in Perl.
----
Perl 6 ... isn't backward compatible
Raku runs around 80% of CPAN (Perl modules), including ones that use XS (poking into the guts of the Perl 5 binary) without requiring any change whatsoever.
(The remaining 20% are so Perl 5 specific as to be meaningless in Raku. For example, source filters which convert Perl 5 code into different Perl 5 code.)
----
But you are right about one thing; no one you know cares about backwards compatibility, otherwise you'd know the difference between what you think you know, and what is actually true.
> But you are right about one thing; no one you know cares about backwards compatibility, otherwise you'd know the difference between what you think you know, and what is actually true.
What the hell is this? Even if nobody I know cares about backwards compatibility, how does this relate to whether my knowledge is true or not?
Apologies for trivializing perl5's progress in the past 25 years, but come on, chill out dude.
I know people don't like Perl, I just want to add some info here.
The Perl 5 Porters have restarted adding new features at 15 years ago. It has progressed from version 5.20 to 5.42. Although the speed is slower than popular languages, they are maintaining backward compatibility while adding new features.
How have they withered? Does every programming language have to compete for world domination via cancerous growth? I thought that only applied to VC backed startups and public companies if the startups survive...
They’re not actively used in any circles I move in. The fact that your back is up suggests you have something invested in these antiquated niche tools.
They have a right to exist. But there is strength in community. Successful platforms facilitate this and provide a means for participants to exceed the sum of there parts.
This can in turn fuel development of the platform therefore helping keep it relevant.
In recent times we call this “the network effect” and it applies to more than just social media.
The community withered. 10-15 years ago the cries of “Ruby” “Ruby” “Ruby” were deafening. I used Ruby and I really enjoyed and I thought I would leave Python behind but it but it never went anywhere from there. Somewhere around 3.x I think there were a load of breaking changes introduced and I imagine lots of people like myself just went back to using more stable platforms.
The great thing is that you don't have to join any community. Python is my favorite language and ever since I got flamed for asking a technical question in their subreddit I stopped going there.
There are hardly any non-toxic programming communities out there. And if you value backward compatibility over everything else you can look at C and C++.
Java also has a pretty good compatibility story. I still use python for some applications, but it has created a lot of headaches, and also has the problem of being really slow. YMMV, but usually if you were to rewrite your c++ code in python, you would find that you need 10x as many servers (or likely more) to get the same performance.
Unfortunately, a programming language without a community is nothing, because more than anything programming languages are languages, and a language is dead without a community that speaks it.
It didn't. I've seen people in the Python community tear someone's open source project to shreds because "it isn't Pythonic". It really soured me on the Python community when I saw people acting that way.
this summarizes pretty well my first thoughts when reading the headline: "How python grew from a language to a community", because the Python community in 2000, the Python community in 2010, these are a different place to "whole world uses Python" in 2025.
Back then it felt like a bit of a club, one that forms around a common hobby. Nowadays it feels more like the "community" of a high-school graduation class. Sure there is community there, but its mostly one of folks randomly thrown together into classrooms.
Folks like Raymond Hettinger would today be totally drowned out in the listicle-style attention seeking times.
> in the web world
I would put that more broadly though, it was web, data-science, there was a point when it became the universal scripting language, and part of me kind of hoped that the crowd would move to nodejs for all of it, so that Python can become more peaceful again. But I guess there is no going back, we went from dinghi to cruise ship, and when the crowd leaves, it will just be a deserted cruise ship.
Python is one of the most toxic communities out there. A couple of people sold out python-dev to their corporations and used the CoC and non-programming related activities to gain power. They drove people out who dared to contradict them.
Some of the clique have been fired later and now CPython is basically a hollow shell with some corporate projects still going on.
The Python community is welcoming, many come for the language and stay for the community. It's not, of course, free of politics or drama, but it's very far from what you describe. Local communities are very strong, CPython core community seems to always be trying to improve to me.
Even Tim Peters, who I really hope is part of the documentary, is an enthusiastic participant, both helping with gnarly CPython issues and providing assistance to newbies.
If you look at the Fellows list[0], you can see that many important names aren't active in the community anymore (I don't know the reasons for each one), but many more are either active or in (very) good terms with the community.
The CoC was and is a net positive, the diversity efforts even more so. Last Saturday I was at a local Python conference and the local community has welcome both, to great success and improvement.
I think the Bitcoin part is simple - it doesn't have the perverse incentives of an investment vehicle. Everyone's financial stake is indirect and diffuse, it's not likely that any given PEP is directly connected to a developer's bottom line (though presumably this happens occasionally).
The point is that, unlike in the Bitcoin block size debacle, you don't have people who are pulling in different directions because it directly impacts their bottom line if Python does X or Y. There's no one who particularly profits from there being a GIL.
Nobody is pro-GIL per se. But a lot of people were pro-No-Single-Threaded-Performance-Desegregation. The first GIL-removal patch was submitted all the way back against python 1.4, and regular attempts have been made ever since, but it wasn't possible to remove the GIL without making the single threaded performance of existing python code worse, so Guido and co. refused to accept them.
One of the strengths of Bitcoin is its stability, the fact that it doesn't change on someone's whim like it happened for example with Ethereum which was forked because someone was smarter than their dumb contracts.
Grey beards didn’t take Python seriously, or more like they just didn’t care about. C and Java what matters after all and Python is just a toy for beginners!
I was fresh at university, around 2001, and our mathematics professor introduced us to Python with NumPy/SciPy as an alternative to the commercial math tools. There aren't many events that changed my career as much as that. Being exposed only to compiled languages before that, it blew my mind. It was friendly, expressive and came with batteries included.
There was a huge sense of community around Python, that I didn't really see elsewhere in the programming world. It started with these scientific libraries. Python wouldn't be what Python is today without NumPy. It was nice to see in the last years the boost of the Python scientific community, with basically anything machine learning using Python as the DSL.
> It started with these scientific libraries.
I disagree. The scientific libraries were just one of many niches, and an awkward one at that. One could equally say "it started with xml libraries" or "it started with file-handling libraries" or "it started with http libraries" -- all of which were in the Standard Library very early, unlike the horrible-to-build numpy/scipy. All of these made the language popular initially across a number of different crowds. Numpy/scipy reached traction relatively late when Python was already well-established in niches like sysadmin, web, education, 3D, and many others. By 2001 we already had multiple web frameworks, Zope, even WSGI...
It is occasionally annoying how this or that crowd tries to appropriate Python's success, hence flattening its purposes and aims.
But all the other use cases were covered back then primarily by Perl. Python was the first dynamic language to effectively use this class of libraries.
I had been using Perl from 1995-2000. I was a fairly advanced Perl programmer (was there for the Perl 4 -> 5 transition), using it mostly for automating system administration tasks.
In 2000 I joined a new startup and was shown Python 1.5.2 by the startup's chief architect/scientists. He'd come from Infoseek where he'd used it there to help build parts of the company.
Now, I loved Perl. I was one of those annoying geeks with "RSA in 4 lines of Perl" T-shirt. I'd write JAPH programs for fun. But I appreciated how much "smaller" Python was than Perl. I was able to learn pretty much all of its rules in an hour? I didn't have to worry about all the crazy ways Perl programs could express themselves. (Is this scalar context or array context?[^1] Is this script using my or local? What the heck does this crazy line I didn't write do again? Oh wait, I wrote that line!)
So anyway, this startup was using Python and now so was I.
That startup is long gone, but I'm still using Python daily in my career.
And I've never used numpy.
Perl was/is great, but it's just too quirky to have the broad appeal of Python.
[^1]: "It's all about context": https://archive.ph/IB2kR
FWIW I learned Perl in 2016, and it became my language of choice (sorta) for ~6 months, but the overwhelming momentum of Python is hard to avoid. Perl was/is cool though!
In my university, we were given a choice to use either Matlab or Python for exercises in many advanced courses. We even got Matlab licenses for our personal computers. But since the smallest Matlab installation still came in at several GB and my personal computer was always full with games, I chose the python stack which came in at maybe 100-200 MB for all relevant packages, while nearly everyone else chose Matlab. None of them have ever used Matlab again after University and I still use Python all the time.
2001? But wasn't NumPy created in 2005? Apparently its predecessor was called Numeric.
That is all good and well. Unfortunately, it degenerated into a tyranny where a small group of mediocre people grabbed power, censored the infrastructure and threatened people with defamation if they didn't obey.
Most developers have left or have been driven out. The remaining ones do corporate projects that generally underdeliver.
This is very normal - people like that are drawn to the free money available at foundations. Thankfully uv etc from Astral are doing what the very medicore minds at the PSF cannot.
Lol, what does this mean?
Most recently Tim Peters was suspended and many people found the suspension reasons unjustified. I assume the GP is referring to similar events.
Ah, that makes sense, thanks. A few years ago I saw bullying and harassment in one Python project that was instigated by the code of conduct committee. Seems like history is repeating..
Of the Timsort fame, wow.
Timsort, the Zen of Python, and many other things. Over 2500 commits to the CPython repository overall (11th on the all-time list). Quite good at explaining details of how floating-point works, especially as relates to Python, IMX. And extraordinarily helpful over a long period of time: https://stackoverflow.com/search?q=user%3A2705542+is%3Aanswe...
And still an important voice in the Python community: https://discuss.python.org/u/tim.one/summary
The Talk Python podcast just did an episode adjacent to this
https://talkpython.fm/episodes/show/513/stories-from-python-...
It is striking that this article equates community with bureaucratic efforts like setting up the PSF and getting funding for the PSF. It is essentially a hagiography for the bureaucrats. The omission of Tim Peters, who was later slandered by bureaucrats, is notable.
I really hope Tim being in the documentary is the plot twist. He deserves a big chunk of time too.
OT: if you’re ever in Atlanta, come check out pyatl. We’re a pretty old and established python group. It’s always fun and interesting.
Paul Everitt's confidence and enthusiasm forcontinuous improvement have made Pythonwhat it is today. Thanks
Drama driven development is the truly modern paradigm, and if you think it's limited to Python you're blind.
It's not community, it's meddling, toil, and folly.
true that, perl5 to perl6 (now raku) was a master class in that
Raku is the most modern PL s metric
I stopped using Perl in the early 00s but I've heard rumours, how bad was it?
well it started out with perl6 as a breaking change major upgrade to perl5
the perl community fractured into those that wanted to avoid a breaking change (since they feared the kind of pain that Python 2 => 3 would later encounter) and those that wanted to evolve the language with things like a Type system and Object Oriented coding as standard
the fracture became a chasm when it became obvious that perl6 was taking years and that there was no migration path from perl5 to perl6 - users began to explore options and often Python was top of the list
this was exacerbated by the use of perl6 as the name ... later (much later) the name was changed to raku ... but by then the perl language was a shadow of its once dominant self and CPAN (the perl module library) lost a lot of folks doing maintenance and improvements so that began to bitrot
fear lead to anger, anger lead to hate
[btw raku is now very nice with all these features and still the great feel of classic perl and has a small but active and friendly community]
Is there a canonical "perl 6" now? LIke I can't go to perl.org and download one, or at least the "latest stable version" is listed in the 5.x range still.
Or is "perl 6" not even a thing to ask about, and "raku" is what was to be "perl 6" became?
afaiui the perl folks are targeting perl7 as the next major release to avoid confusion (but suggest you ask them)
if you want raku, then you can install from rakudo.org or rakubrew.org
> Drama driven development
Yes, the main paradigm across the FOSS world.
that's why I love rust!
because you like the drama? It is quite entertaining but so tiresome.
he-he, sometimes, but mostly because it shows there are real people behind who have emotions. Agree on rust (put rails or others here) having too much of it sometimes
I don't want a community - I want a programming language. Preferably one that doesn't throw away billions of lines of existing code just because.
Python 2 code was absolutely not "thrown away just because". Nobody made your interpreter stop working; it was never on a cloud service or anything like that. It just stopped receiving bugfixes from core team (it's open source so everyone was and is free to take over maintenance) and third-party tool and infrastructure support (notably, PyPI) doesn't take it into consideration any more.
Further, the changes were made for very good reasons, such as allowing beginners to accept user input on day 1 without opening ACE exploits in their programs, and having plain double-quoted string literals actually produce a string rather than an immutable byte buffer that vaguely assumes a generic code-page encoding, except for the contexts where it will complain if it's not plain ASCII (admittedly, this is still an improvement over trying to handle text in C with only the standard library), and making sure that decoding operations don't produce encoding errors and vice-versa, and making `isinstance(1<<64, int)` give the expected `True` result, and making `except` syntax make sense, and making sure there aren't two fundamentally different kinds of user-defined class.
And by making these changes, we actually got Python 3 in about 2.5 years (4.5 if you allow for the first couple of releases having some issues figuring out the string literal transition and other such details — I agree they were premature) and were able to offer another 11 (9) for everyone to migrate. Whereas with Raku the entire 13.5 (more like 15.5) year period was spent on design and implementation, and now there hasn't been a new stable release for almost 5 years.
> it's open source so everyone was and is free to take over maintenance
Open source implementations are fine, though the "if you don't like it fork/make your own" argument is, typically a way of sidestepping criticism rather than a practical solution.
But one of Python's greatest weaknesses is that there is no formal language specification. All you have are implementations and their documentation.
From my perspective (suffering through the python 3 transition and living with ongoing changes in 3.x), compatibility was - and is - poorly handled. Many things can and should be done to ease the maintenance burden - things like intelligent defaults, compatibility features and libraries, and not doing stupid things like ripping out the print statement (which could have coexisted with a print() function) with no recourse.
Unfortunately, python's developers seem to have demonstrated tremendous contempt for the users of the language, and for existing code bases.
Other languages (though not all.... <cough, swift>) have actual language specifications and standards (that even keep working as runtime systems evolve), and are not so keen on throwing users and their code off a cliff.
Platforms should absorb pain so that their users don't have to, and avoid introducing breaking changes that multiply pain across an entire user base.
Apple (also known for arrogance combined with contempt for their developers) also gets this wrong, and routinely breaks iOS and swift apps every year.
> things like intelligent defaults
Can you give a concrete example of a problem you encountered while porting 2->3 code caused by a poorly chosen default in 3?
> compatibility features and libraries
You mean like `lib2to3`? Or all the backports 2.7 got, e.g. what's listed at https://wiki.python.org/moin/StandardLibraryBackports ? Or the `__future__` system? Or third-party support like `six` (still immensely popular, though presumably only in CI)?
> the print statement (which could have coexisted with a print() function)
No, it absolutely could not have. Not with the same name, and making the name refer to the function was the point. The print statement syntax was inelegant, quirky and confusing. For example, parentheses can affect the meaning in unusual ways:
Besides which, outputting text has no more logical reason to use a dedicated statement form than inputting text.> python's developers seem to have demonstrated tremendous contempt for the users
I don't understand how you have come to infer such an attitude. Any suspicion that they are introducing breaking changes on a whim will be immediately quashed by reading the discussion behind any of those breaking changes. (Not to mention what happens with the rejected proposals.)
> and avoid introducing breaking changes that multiply pain across an entire user base.
What breaking change was introduced in Python 3.x during your history of using it that caused a nontrivial problem for you? How many years do you believe you were given to account for it?
> No, it absolutely could not have
It could have fairly trivially for the vast majority of use cases (no space between print and parenthesis if you want to call the function) but apparently that would have made some python maintainers unhappy. So it was ripped out and a breaking change was introduced with no recourse (not even, say, from __past__ import print_statement or something).
This is part of what I mean by demonstrating tremendous contempt for the user base and for existing code.
> (no space between print and parenthesis if you want to call the function)
This would be unlike anything else in any ALGOL-extended-family language, never mind Python.
There are countless dead programming languages without communities you can pick then.
Ruby and Perl are great examples of massively popular languages that withered because the language/platform outpaced the community.
If the first question you’re asking yourself looking at a code base is “what version is this/do I know this version” then that language is not facilitating you.
The successful languages are ones where “the community” prioritises backward compatibility. Java, C, Python have backward compatibility spanning decades. There’s a few discontinuities (lambdas in Java 8, Python 3, C++) but in most cases there’s a clear mapping back to the original. Python 3 is an exception to this but the migration window was something like 15 years…
Busy engineers, scientists and academics have little interest in keeping up to date with language features. A computer and a programming language are a tool for a job and the source code is just an intermediate artifact. These are your “community”, and the stakeholders in your success.
Have you used them? Perl has version tags in source code and everything is feature gated including the stdlib. Python does none of that. The stdlib changes constantly and just looking at source code gives you no indication if you can run it with your installed python version.
> Perl has version tags in source code and everything is feature gated including the stdlib. Python does none of that.
> just looking at source code gives you no indication if you can run it with your installed python versionI prefer Perl's approach for both:
That's explicit, tied to a specific version, and executable code which can be scoped to a single source file.(I'd argued for that feature for years with my `Modern::Perl` feature bundle; glad to see that can be deprecated now.)
I don't believe that "from __future__" is the future-proofing you think it is, they just named it that way to be cute - a hypothetical 3.19 version couldn't even use it, since it's just a normal python import
the very idea of "future feature is not defined" is insaneoAnyway, I'd guess what they intend is
because python really gets off on conditional importsI was responding to the "Python does none of that" by pointing out that Python does indeed have features to help introduce new capabilities in a thoughtful way - I know it's not the same thing as something like conditional imports.
Not sure that >= is going to age well.
Perl have almost perfect backward compatibility, but small community and bad renown are not so good.
Backwards compatibility is terrible if what you're being backwards compatible with is terrible.
Isn’t the actual “platform” itself fragmented these days? Different language versions, different libraries, different “engine”?
I dunno it was 20 years ago I jumped ship when they tried shoehorning object oriented semantics into it. Eugh.
I do not really know which event you mentioned. But if you use the current version of perl interpreter. It still work for most of old versions. And new features keep safe for old perl.
Perl doesn't have "perfect backward compatibility" in the normal sense of the word. There is only Perl 5 which is perfectly compatible since it hasn't changed for 25+ years (which is how they achieved "compatibility" -- by not changing), and there's Perl 6 which isn't backward compatible and nobody really uses it.
> Perl 5 ... hasn't changed for 25+ years.
A major new version of Perl ships regularly. A few weeks ago the latest major new version shipped. From the 2025 changes document:
> Perl 5.42.0 represents approximately 13 months of development since Perl 5.40.0 and contains approximately 280,000 lines of changes across 1,600 files from 65 authors.
Skipping back 5 major new versions (to 2020):
> Perl 5.32.0 represents approximately 13 months of development since Perl 5.30.0 and contains approximately 220,000 lines of changes across 1,800 files from 89 authors.
2015:
> Perl 5.22.0 represents approximately 12 months of development since Perl 5.20.0 and contains approximately 590,000 lines of changes across 2,400 files from 94 authors.
2010:
> Perl 5.16.0 represents approximately 12 months of development since Perl 5.14.0 and contains approximately 590,000 lines of changes across 2,500 files from 139 authors.
There's been well over 10 million lines of code changed in just the core Perl codebase over the last 25 years reflecting huge changes in Perl.
----
Perl 6 ... isn't backward compatible
Raku runs around 80% of CPAN (Perl modules), including ones that use XS (poking into the guts of the Perl 5 binary) without requiring any change whatsoever.
(The remaining 20% are so Perl 5 specific as to be meaningless in Raku. For example, source filters which convert Perl 5 code into different Perl 5 code.)
----
But you are right about one thing; no one you know cares about backwards compatibility, otherwise you'd know the difference between what you think you know, and what is actually true.
> But you are right about one thing; no one you know cares about backwards compatibility, otherwise you'd know the difference between what you think you know, and what is actually true.
What the hell is this? Even if nobody I know cares about backwards compatibility, how does this relate to whether my knowledge is true or not?
Apologies for trivializing perl5's progress in the past 25 years, but come on, chill out dude.
I know people don't like Perl, I just want to add some info here. The Perl 5 Porters have restarted adding new features at 15 years ago. It has progressed from version 5.20 to 5.42. Although the speed is slower than popular languages, they are maintaining backward compatibility while adding new features.
Perl6 had been renamed to new language, Raku.
How have they withered? Does every programming language have to compete for world domination via cancerous growth? I thought that only applied to VC backed startups and public companies if the startups survive...
They’re not actively used in any circles I move in. The fact that your back is up suggests you have something invested in these antiquated niche tools.
Seriously? I tried Perl only once ever in my life time and I've never done Ruby.
Doesn't mean I have to deny them the right to exist because they don't have a "community*".
* more like a religion for some programming languages.
They have a right to exist. But there is strength in community. Successful platforms facilitate this and provide a means for participants to exceed the sum of there parts.
This can in turn fuel development of the platform therefore helping keep it relevant.
In recent times we call this “the network effect” and it applies to more than just social media.
What makes you think Ruby withered? It has been stagnant, but not withered.
The community withered. 10-15 years ago the cries of “Ruby” “Ruby” “Ruby” were deafening. I used Ruby and I really enjoyed and I thought I would leave Python behind but it but it never went anywhere from there. Somewhere around 3.x I think there were a load of breaking changes introduced and I imagine lots of people like myself just went back to using more stable platforms.
The great thing is that you don't have to join any community. Python is my favorite language and ever since I got flamed for asking a technical question in their subreddit I stopped going there.
There are hardly any non-toxic programming communities out there. And if you value backward compatibility over everything else you can look at C and C++.
Java also has a pretty good compatibility story. I still use python for some applications, but it has created a lot of headaches, and also has the problem of being really slow. YMMV, but usually if you were to rewrite your c++ code in python, you would find that you need 10x as many servers (or likely more) to get the same performance.
Only if you use CPython. I use PyPy3 most of the time and I get the same performance as Java and Go.
C++ is still faster than PyPy3, but not 10x faster. That is good enough for me to not deal with the messy C++ syntax.
Java community is strangely nice. Bog standard enterprise software developers are nearly always polite.
Unfortunately, a programming language without a community is nothing, because more than anything programming languages are languages, and a language is dead without a community that speaks it.
Exactly, that’s why Bjarne Strousoup says there are only 2 types of languages, one that people complain about, and one nobody uses
that's what Delphi said
The real question is how did Python avoid the toxicity of the Linux or bitcoin dev community (remember the block size debate?)
Though there was a developer who was forced to quit a while ago.
It didn't. I've seen people in the Python community tear someone's open source project to shreds because "it isn't Pythonic". It really soured me on the Python community when I saw people acting that way.
It actually did, all the way until it got so mainstream in the web world that avoiding drama became basically impossible.
Until the "cool kids" started meddling, it was a lovely village. It had a strong focus on beginners and teachers.
this summarizes pretty well my first thoughts when reading the headline: "How python grew from a language to a community", because the Python community in 2000, the Python community in 2010, these are a different place to "whole world uses Python" in 2025.
Back then it felt like a bit of a club, one that forms around a common hobby. Nowadays it feels more like the "community" of a high-school graduation class. Sure there is community there, but its mostly one of folks randomly thrown together into classrooms.
Folks like Raymond Hettinger would today be totally drowned out in the listicle-style attention seeking times.
> in the web world
I would put that more broadly though, it was web, data-science, there was a point when it became the universal scripting language, and part of me kind of hoped that the crowd would move to nodejs for all of it, so that Python can become more peaceful again. But I guess there is no going back, we went from dinghi to cruise ship, and when the crowd leaves, it will just be a deserted cruise ship.
The folks at the German python forum were very friendly to beginners and even answered the ‘dumb’ questions back then. Don’t know how it is today.
Yeah, like most (maybe all) communities, Pythonistos can be pretty toxic if you're not in the in-group.
Python is one of the most toxic communities out there. A couple of people sold out python-dev to their corporations and used the CoC and non-programming related activities to gain power. They drove people out who dared to contradict them.
Some of the clique have been fired later and now CPython is basically a hollow shell with some corporate projects still going on.
This is completely bonkers.
The Python community is welcoming, many come for the language and stay for the community. It's not, of course, free of politics or drama, but it's very far from what you describe. Local communities are very strong, CPython core community seems to always be trying to improve to me.
Even Tim Peters, who I really hope is part of the documentary, is an enthusiastic participant, both helping with gnarly CPython issues and providing assistance to newbies.
If you look at the Fellows list[0], you can see that many important names aren't active in the community anymore (I don't know the reasons for each one), but many more are either active or in (very) good terms with the community.
The CoC was and is a net positive, the diversity efforts even more so. Last Saturday I was at a local Python conference and the local community has welcome both, to great success and improvement.
[0] https://www.python.org/psf/fellows-roster/
> The CoC was and is a net positive, the diversity efforts even more so
By what measures?
Who sold it out?
I think the Bitcoin part is simple - it doesn't have the perverse incentives of an investment vehicle. Everyone's financial stake is indirect and diffuse, it's not likely that any given PEP is directly connected to a developer's bottom line (though presumably this happens occasionally).
Big companies submit PEPs to force their will on Python. Meta and GIL removal.
Who is pro-GIL...?
The point is that, unlike in the Bitcoin block size debacle, you don't have people who are pulling in different directions because it directly impacts their bottom line if Python does X or Y. There's no one who particularly profits from there being a GIL.
Who is pro-GIL
Nobody is pro-GIL per se. But a lot of people were pro-No-Single-Threaded-Performance-Desegregation. The first GIL-removal patch was submitted all the way back against python 1.4, and regular attempts have been made ever since, but it wasn't possible to remove the GIL without making the single threaded performance of existing python code worse, so Guido and co. refused to accept them.
And the performance hit is still up to 50%, just like in the first attempts. Except this time it comes from Facebook.
Poking around, I've not been able to find anyone else claiming higher than 10%? Is this 50% from your benchmarks, or is there a link I can see?
One of the strengths of Bitcoin is its stability, the fact that it doesn't change on someone's whim like it happened for example with Ethereum which was forked because someone was smarter than their dumb contracts.
Grey beards didn’t take Python seriously, or more like they just didn’t care about. C and Java what matters after all and Python is just a toy for beginners!
Do Grey beards care about AI?
The Lisp grey beards do.
They are AI
[flagged]