This would represent a significant increase in the number of people paid to work on the Python language. Two years ago it was estimated that it only had (the equivalent of) two full-time employees working on it.
https://discuss.python.org/t/official-list-of-core-developer...
And yet ... collectively we can only find enough money to pay two full time salaries?! Seriously?
I'm not a big fan of "Now this language has gotten popular, let's add all the features to it that made our other language so unpopular."
If more people are working on it full time, we'll just get more Walrus Operators. A very hypothetical gain at cost of an increasingly complex core language.
/rant. Those kind of features are going to keep coming anyway, I'm afraid.
It's like someone used to PHP or JS style coercion, doing: 1 + "2", getting a type error and asking "wtf python?".
The walrus operator is obvious, and very handy in many cases.
The capture part of the pattern matching PEP, on the other hand, has been designed shodilly.
Definitely concerns that more hands could make another Angular, which had 2 incompatible branches, with one going from v2 to v11 in 5 years.
The python3 interpreter could have been largely (or completely) source-compatible with python2 code. They could have done it rust2018 style - where source code files can opt in to a newer parser, and in return get access to the new features. Then the whole python3 drama would have been avoided. MacOS still ships with a python 2.7 interpreter because of all that nonsense.
But if they only had 2 full-time people working on it, no wonder they didn't have the man power to do the transition any other way.
Disappointing.
> WARNING: Python 2.7 is not recommended.
> This version is included in macOS for compatibility with legacy software.
> Future versions of macOS will not include Python 2.7.
> Instead, it is recommended that you transition to using 'python3' from within Terminal.
banner on launch nowadays...
Yet it's become such a widespread sentiment to expect software for free that charging for something like Python would probably be seen as obscene and kill the language through loss of reputation alone.
It's also a big statement about how non realistic were the ideas that FOSS will thrive on volunteers working together.
Back in the day where the "Cathredral and the Bazaar" was published, VALinux got its IPO, and FOSS was the latest hype, people really believed that this will work without corporate sponsorship, just by volunteers doing the work.
Then again, they also believed in many eyes available through the magic of FOSS making bugs shallow (Torvalds), and you get 20+ years of some obvious bug in something as critical as OpenSSL.
Much of the popularity of Python is based upon third party libraries that have been contributed by both individuals and organizations. These are still contributions, and there are many cases where the contributors are paid.
Should Python receive more funding and pay more people to work on the language? Probably, yet it is doubtful that having a large team working on the core language will improve the health of the language.
But what’s the problem here? Is python struggling as a language? If there were clear calls for help companies could find it a lot easier to justify donating money or dev time.
As a language, interpreter, runtime, yes. In terms of adoption, no.
People do this with Google and Facebook all the time. We call them ads. Not every ad campaign has a positive RoI.
This problem isn't solved by little old me pulling out my check book. My bank and my insurance company don't need charity from me in order to fund the technology they've built their businesses on. They need to learn to pony up and start funding the "free" software they use. Paying myself would only help kick the can down the road - and encourage and enable this sort of corporate mooching to keep happening.
In 60 years most of the volunteer maintainers of the software we depend on every day will be dead. Some time between now and then we need solution to this problem of opensource sustainability. Delaying buys us nothing.
Surely you’ve seen volunteers join existing projects out of their own interest and need now. The decades that you contributed (thank you, BTW): were those all on projects you started, or did you also join some existing efforts?
I don’t see any reason to think that will stop in 10, 20, or 60 years.
Will there? I feel like most of the opensource attention flows gradually up stack / toward trendy things on github and away from infrastructure older than github. When heartbleed happened a few years ago it was revealed that OpenSSL was maintained by basically one guy. The same is true of the linux timezone database. Apparently python is mostly 2 people.
I'd put money on this being is a theme for lots of tools we take for granted. How many people work on bash? Or busybox, grub, libpthread or libicu? I bet the number is tiny.
People want to work on popular, useful things. Python is both of those.
Worse: they are exploiting people's good intentions.
They co-opted the Free Software movement.
Copyleft has been painted as "business-unfriendly" and replaced with permissive licenses - aka unpaid labor without "strings attached".
> They need to learn to pony up and start funding the "free" software they use
...instead they even dodge taxes.
There are so many better (and worse) things to finance than Python Foundation.
Your point would make more sense if the claim was that a significant portion of the corporation's profits should go towards financing Python. Then I would agree that "there are so many better things to finance than Python". But if we're discussing a salary or two in the context of corporations that employ hundreds of thousands of people, then your argument makes much less sense in the current context. There are very few things that would have better marginal utility then paying for the (effectively) third full-time Python developer.
So it might be true that there are only a few FTEs working on Python, but the larger community of people contributing to it is much larger.
That post was made while Guido was at Dropbox, and it claims he had one day a week?
Considering the larger Python ecosystem the community does a lot of the work, so saying there are only two people working full-time on Python is quite misleading IMHO, as Python has probably one of the largest communities in the world for a programming language, the Github repo alone lists almost 1.500 contributors.
https://mail.python.org/archives/list/python-dev@python.org/...
Needed funding though.
Ruby got MJT in a big effort to make Ruby a lot faster. PHP is constantly increasing it‘s performance and tries to change a lot to get faster (basic building blocks for JIT in PHP8).
Why is python not iterating so much on it‘s performance? Or is it doing this but it‘s not as public in promoting it like my former two examples.
It doesn't have that much adoption, which suggests that performance isn't critical to Python's user base. If PyPy got significant market share, perhaps the CPython developers would prioritise an approach like this. (Or perhaps they'd have even more justification to say look, there's already a performance-focused implementation, we'll do our thing).
But the speed improvements would be welcome if they were in cpython because you can be quite sure there will be no problems.
One example is that Pypy switched away from reference-counting to fully garbage collected. They are probably right that's faster, but if I'm running a webserver, it's actually really comforting to know that any garbage produced by the processing of a request is collected when that request ends (barring cycles of course) so I don't end up with weird hangups.
I'm not in the python community, so it's possible this person is well known and respected enough that part of this can be taken on faith. However, because the author does not provide benchmarks or any other proof of the effectiveness of the supposedly almost complete stage 1, I cannot personally call this proposal serious.
The most information we got was "on a few simple benchmarks I'm seeing about a 70% speedup vs master for both default and LTO configures." However, this information is almost completely useless. What benchmarks? What architectures? What hardware?
It would take the author 5 minutes of their time to say "here's the benchmark code I ran, it executed in [time] on CPython master commit [hash], and [lower time] on my patch, running on a machine with [hardware]." To be completely honest, I fail to see why they are not providing this information that would make their proposal significantly stronger.
Since he was only asking for payment once he hit his benchmarks for each stage, why does it matter?
The discussion thread on that reveals that it was a bit low even by its explicit premise (core devs that had allocated time for OSS that was used for Python), and that methodology itself undercounted reality because it ignored people who had and made use of employer permission to use paid time but did not have a set allocation.
Coupled with the fact that they get paid for the alleged churn and others have to catch up on unpaid time, this can ruin a project.
The Python dev community has certainly gotten far less vibrant (and productive) in the last decade due to stifling corporate influence.
One is two people. The other is a few thousand person-hours of effort per year.
The equivalent of two full time employees could be 10 people with 20% of their time. I suspect there are a lot of patches submitted to python that were developed by someone being paid while they did the work that isn’t accounted for in the 1 actual full-time plus 5 20% time people.
IOW, paying for 1 additional named person to work ~2000 hours in 2021 will almost surely not be a net increase of 50% of capacity.