And lets be honest, he's earned it.
Thank you Guido, after learning Python, I never looked back, and it has been the source of great joy for me over the last decade.
I’m sure he’s going to take a break from the chaos of being at a unicorn in SF and the departure from BDFL, spend some time in the woods reading books and getting ready for the next thing. He’s got plenty of cash (presumably) so hopefully finances are not a source of concern. Then the itch will come and hopefully he will be poised to scratch it.
I’m sure we’ll see more from him!
That matches my experience. All the pros and cons that in principle apply to any language, whether newer than Python or older, mean nothing to me in practice. Python is the one that feels right, the others feel like a chore. Since I started with Python 10 years ago, nothing has changed that.
There's ways I'll insist that Python is the best at [x], and ways I'll concede some other language is better at [y]. But it never amounts to anything close to a debate about what language I should use.
Beyond times when Python is clearly wrong, there are other issues, mainly around tooling and documentation. Languages have come a long way in the past 20 years.
So if your task was to deliver let's say commercial grade FFT library ( substitute with any other long computationally extensive process ) for consumption by others you would write it in Python?
On my team, we've been successful with this rough approach:
1. write a prototype in Python to explore the idea/ensure correctness
2. extract the core library and re-implement it in Rust
3. consume the core from Javascript via WASM and Python via pyo3 (Python/Rust bindings)
Interestingly I've found something quite opposite for computational algorithms. The problem was that execution of Python under debugger was unbearably slow for me (I used VS Code for this case). So waiting until the code gets to the point I need was not fun. With C however it would get there almost instantly. Compile time for isolated computational function was nearly instant as well. Maybe debugging under VS code was the culprit but I did not feel that for this particular task Python was any more interactive than plain C.
Rather than worry about figuring out structures for our simulation objects like we might need to do in a lower-level language, Python lets us just throw together some numpy arrays and dicts as needed, and really iterate quickly on the solution. If I was working on something with a tight computational core I would probably take the low-level first approach like you have. Horses for courses, and all that.
Kinda seems like you are, mate.
There's ways I'll insist that Python is the best at [x], and ways I'll concede some other language is better at [y]. But it never amounts to anything close to a debate about what language I should use
Anyways I should know better then discuss Python
To the extent I have a choice, I'll go out of my way to use Python and I'll be a little creative to fit it into certain uses cases where it's not a perfect fit, consciously accepting a reasonable penalty. But yeah, sometimes it won't fit at all.
The point is more that I'd go so far as to avoid taking a job or gravitating towards a project where the development would not be enjoyable based on the tools I'd have to use.
I can definitely understand this point of view. Well sorta. I was/am always goal oriented. I find satisfaction in creating a product used by other people. The actual process of implementation is 90% boring work and language for me is just a tool. I do not get too excited by languages.
A carefully controlled message.
PSF now has an elected steering council to replace him.
https://mail.python.org/pipermail/python-committers/2018-Jul...