10 ms·
Python never followed that or any other absolutist claim. Python is a huge ball of yarn comprised of donations of, perhaps hundreds individual developers w/o s
by crabbone 4y ago
Python never followed that or any other absolutist claim.
Python is a huge ball of yarn comprised of donations of, perhaps hundreds individual developers w/o strong ties to each other. If you look inside the project, you find plenty of distinct styles and approaches coexisting and overlapping. The moderation is very weak / non-existent.
Installation utilities, however, were in Python since very early on. "distutil" dates back to, probably, one of the first public releases. It's since then was always part of the "standard" library, but it's going to be removed in the name of chaos, anarchy and entropy in one of the upcoming releases.
There was never any great design in Python in general, or in distutil in particular, but through a series of bad decisions, which were quickly carved in stone, we ended up with the system we have today. Setuptools was a first community project which grew out of recognition of inadequacy of distutil, but, instead of trying to replace it, it was designed to be a drop-in replacement in terms of interface and was made to depend on distutil in order to do anything useful.
This result in setuptools being a lot more convoluted and rigid than desired. Few people wanted to participate in this project, and so it was proclaimed dead several times, setuptools2 was supposed to replace it etc... but the decisions carved in stone wouldn't allow anyone to really dislodge it.
Gradually setuptools grew more hair, another pair of horns and wings by merging with distribution, easy_install, resouces_pkg and a bunch of other smaller evils, making itself ever more indispensable. Somewhat in parallel to that process, pip was starting to pick up speed. Pip promised a lot, but never delivered on those promises (eg. setuptools was never able to uninstall packages, while pip has "uninstall" command, it's broken by design).
And then anyone who made any sense abandoned Python. Python community was left with Python Foundation people or PyPA in this instance, who are not competent to deal with packaging. The entire activity today around packaging in Python may be described as chaos. It's adding random features based on the assumption that existing features work when they don't. Trying to get rid of the only useful tools while replacing them with tools that rely on the tools being replaced etc. It reads like some sort of an absurdist novel if you have to dive deep into it. And yet, it's a technology used by millions, shuffling trillions of goods and services around the world...
- drewcoo 4y agoAre? You? Serious? And are all your up-voters serious, too? Learn your shit, dude! Because right now, your shit owns you. https://peps.python.org/pep-0020/ https://peps.python.org/pep-0020/
- crabbone 4y agoAnd... you think that by writing how good you are at something you actually become good at that thing? Like, I mean, you think that if you write "I, drewcoo, can run 100 meters faster than Usain Bolt" you will indeed run faster than Usain Bolt? What that document confirms is that at one point, when Python was cool, and people liked to talk about Zen Buddhism (probably inspired by Hofstadter's book), someone, semi-jokingly wrote that PEP. And this is all there is to it... You cannot be possibly delusional enough to think that eg. "explicit is better than implicit" is somehow provable or enforceable or can even be properly defined... Like, a lot of Python programmers would agree that context managers do implicit state management or that, in general, decorators create implicit behaviors attached to code of the functions or classes they decorate... and yet Zen of Python PEP still exists, right? So, what makes you think it's some sort of a rule that's never broken by the language it's allegedly applied to?