5 ms·
Yeah he's only sort of connected to the project now: "I think a lot of people don't realize how little Reitz actually has to do with Requests development. For
by smcl 4y ago
Yeah he's only sort of connected to the project now:
"I think a lot of people don't realize how little Reitz actually has to do with Requests development. For many years now, actual maintenance has been done almost exclusively by other volunteers. If you look at the maintainers list on PyPI, you'll see he doesn't have PyPI rights to his own project, because he kept breaking stuff, so the real maintainers insisted on revoking his access"
From https://vorpus.org/blog/why-im-not-collaborating-with-kenneth-reitz/ https://vorpus.org/blog/why-im-not-collaborating-with-kennet...
- fnLkq 4y agoMuch of this applies perfectly to CPython and many of the CPython core "developers". I do not recall that the author of this pamphlet has ever done much, but he tends to appear whenever someone is canceled.
- oblio 4y agoWhy there, brave anonymous commenter from a throwaway account, what do you have to say about his core concerns? > At least as far as commits go, his main contributions since then appear to consist of merging some small doc fixes, and monetizing the project by adding donation links, ads, intrusive sponsored links, etc. All of this money goes directly into his pocket, not the project's maintainers. > I also learned that he has a history of selling premium support contracts for Requests, where he took the money and then delegated the actual work to unpaid volunteers. > I don't have any objection to trying to make money from open-source. I've written before about how open-source doesn't get nearly enough investment. I do object to exploiting volunteers, driving out community members, and lying to funders and the broader community. Reitz has a consistent history of doing all these things. They're quite serious and the blog post seems quite convincing.
- faho 4y agoHe's listed as the (co-)author on a number of PEPs: - PEP 533 – Deterministic cleanup for iterators - PEP 518 – Specifying Minimum Build System Requirements for Python Projects - PEP 517 – A build-system independent format for source trees - PEP 465 – A dedicated infix operator for matrix multiplication - PEP 600 – Future ‘manylinux’ Platform Tags for Portable Linux Built Distributions - PEP 8016 – The Steering Council Model - PEP 568 – Generator-sensitivity for Context Variables (and that's as far as I cared to look - unfortunately https://peps.python.org/ https://peps.python.org/ lists the authors by last name and there are multiple people named "Smith") So it seems he has in fact "done much".
- quietbritishjim 4y ago> I do not recall that the author of this pamphlet has ever done much He made the Trio library, which is ridiculously good and also ridiculously hard to implement (just look at this issue [1] for example where he carefully examines the three (!) different async APIs on Windows). Lessons from it are being folded back into the asyncio library in core Python (e.g. exception groups) so everyone benefits even if they don't use Trio directly. [1] https://github.com/python-trio/trio/issues/52 https://github.com/python-trio/trio/issues/52
- EdwardDiego 4y agoAfter that debacle with pipenv and the misleading promotion of it, I'm not surprised he's taking time out from Python dev (or perhaps Python is taking time out from him).
- shantnutiwari 4y agoFor those of us out of the loop: what debacle with pipenv?
- photon-torpedo 4y agoPerhaps see this past discussion: https://news.ycombinator.com/item?id=18612590 https://news.ycombinator.com/item?id=18612590
- shantnutiwari 4y agothat doesnt explain anything -- pipenv was broken? So? Its an open source project, it will have issues now and then.
- cpdean 4y agoFor me the issue was less about the bugs in pipenv, and more about how Kenneth Reitz leveraged his commit rights to other projects' documentation to update them to claim that they all recommended pipenv when pipenv was in its infancy.
- smcl 4y agoSounds like it was a bit more than that, the top comment there looks quite damning: >However, Kenneth abused his position with PyPA (and quickly bumped a what is a beta product to version 18) to imply Pipenv was more stable, more supported and more official than it really was. > And worse still, for anyone saying "but ts open source, you get what you pay for", Kenneth as former Python Overlord at Heroku, encouraged Heroku to place Pipenv above Pip as the default Python package manager in the Python buildpack. This decision impacted paying customers and the Python buildpack used a broken version of Pipenv for a long time. So long, most people I know just went back to Pip. > Then, lastly, when people complained he had a tizzy at reddit and twitter and got PyPA to help backtrack and say "no we didn't support it, nope, its just a thing that happened", all while the main Pipenv Github repository was held under the PyPA GitHub Org.