4 ms·
I'm glad he's stepped down. His opinion matters to be sure, but python needs to be a community developed language. He's a smart guy, and he matters still to t
by bb88 2y ago
I'm glad he's stepped down. His opinion matters to be sure, but python needs to be a community developed language. He's a smart guy, and he matters still to the python community.
There was a tremendous amount of frustration around the walrus operator, which led to him stepping down.
- ein0p 2y agoThe walrus operator doesn’t seem like such a big deal now given these developments, and no doubt future developments of the same sort. The permanently offended aren’t going to just go until everything is in ruins and all the main contributors are gone.
- bb88 2y agoWell, on the other hand, the only way out for a "Dictator" in the "BDFL" is to resign or be overthrown. He decided to resign, which is probably for the best. Otherwise a fork would have forced the decision, and been worse for the community as a whole. Packaging and the 2.x to 3.x migration were both nightmares under his stewardship. Keep in mind that the leaders of the PSF can be voted out, if so chosen by the community. And the community may have a different opinion on the election cycle and want to take python a different direction.
- Ferret7446 2y agoSo BDFLs are immortal apparently. Maybe that can be a good motivation for people to contribute to open source.
- jart 2y agoGuido is the community. He's the one with the most legitimacy to represent it. To imply that Guido is something separate and divorced from the community is textbook subversion. I can't imagine any reason that others leaders in the Python community would have irreconcilable differences with Guido than if their interests were to corrupt the project.
- bb88 2y agoGuido is part of the community, not the community. At least not anymore. Go to pycon and try to talk to him. He doesn't want to talk to just anyone. And he's not great at accepting feedback. We love him, of course. But there are reasons maybe that the community of users should have a strong voice in where python goes as well.
- bitcharmer 2y agoCan you people just make your own projects and then ruin them in any way you want?
- edward28 2y agoThey can't. That's why they latch on like parasites to working projects.
- bouncing 2y agoIt was happening a lot under Guido too, but IMO, Python was arguably a better language (at least in some ways) 10, 15, even 20 years ago. Python's three super powers were readability, simplicity, and a vast standard library that negated the need for most projects to seek out third party modules. All three of those have declined. It's less readable than it used to be, it's definitely more complicated (not just complex, complicated), and the standard library is declining rapidly in relevance as it ages. And it wasn't just Guido. Tim was a big advocate for all three of those super powers when he was more influential. They banned Tim and they censored Guido, so go figure.
- zahlman 2y ago> All three of those have declined. It's less readable than it used to be, it's definitely more complicated (not just complex, complicated), and the standard library is declining rapidly in relevance as it ages. I find it much more readable, and more importantly more expressive. Certain new features are missteps IMO, but I just don't use them. But more importantly, the language has been moving away from cryptic %-encodings and other C idioms. As for the standard library, that was already happening for a long time, and is inevitable. The world has fundamentally changed. In Python's heyday it was much harder to download and install and use a third-party library, so a rich standard library was an asset. Now it's full of specialized code that handles obscure and increasingly irrelevant data formats; multiple overlapping hacks for binary data; terrible and confusing date support; awkward interfaces that haven't stood the test of time (particularly all the networking stuff; Requests is one of the most downloaded PyPI packages, along with its dependencies which are probably almost never downloaded for any other reason); etc. Lots of people still seem to think that the 2->3 migration was a mistake. They couldn't be more wrong. The old way of handling "strings" was abysmal, and spit in the face of the Zen. Error messages were confusing and implicit conversions abounded. Also, just for the record: Guido van Rossum was in favour of the walrus operator. In fact, he co-authored the PEP (https://peps.python.org/pep-0572/ https://peps.python.org/pep-0572/), along with Tim Peters.
- bouncing 2y agoThe walrus operator is nice, except in comprehensions. f-strings are great, except for the `=` debugging operator. Dictionary merging and update operators contradict the "one way to do it" with weird and confusing syntax that's completely redundant to methods that already exist. Type hints are a sore spot for me. They're good enough when you just don't remember whether an argument is an object or a string, for example, but once you start type hinting deep into data structures, your hints become a mangled soup of nonsense for basically no real benefit. Typing errors are a rare occurrence—perhaps once a year in most projects—yet we clutter our codebases with verbosity to satisfy type checkers instead of prioritizing clarity for developers. There's a lot that's just straight up redundant. Dicts are ordered now, but is OrderedDict deprecated? No, because it's just slightly different in weird and mostly unimportant ways. `frozenset` is a builtin, for all 3 programmers worldwide who use it. Python resisted match/case syntax for decades, but when it finally arrived, it did so in a way that’s anything but standard—good luck figuring it out without consulting the documentation. Obviously some improvements are real. Every new version of Python brings valuable enhancements. But just go back to Python as it used to be -- pseudocode that runs. That's just not true anymore. The simplicity has slipped away and will never ever come back. And the standard library? A very real problem, right now, in computer security is the software supply chain. Remember polyfill from like, yesterday? This is the era when we should double down on having a million dependencies from all over GitHub, from unknown developers with no commitment, because ... npm's hellscape is a model to follow? I would argue the contrary. There's dependency hell, of course, but there's also dependency risk. If you were evaluating a product right now, and you saw its lockfile depended only on a specific version of the Python Standard Library, that gives you exactly 1 product to evaluate, exactly 1 team of developers to depend on. pip is great and all, but dependency resolvers have quietly let in a hundred trojan horses and a thousand unmaintained dependencies into tons of projects, and no one noticed it was even happening. Python in 2005, when everyone depended on the standard library, was a safer place than npm is today.