4 ms·

I'm also sad but from a different perspective. If something can be rewritten from scratch fairly quickly and ends up being much faster, it makes you wonder wha

I'm also sad but from a different perspective. If something can be rewritten from scratch fairly quickly and ends up being much faster, it makes you wonder what we (the general “we”) might have done “wrong” with the “decades of effort” before. To be clear: there was nothing wrong with the old toolchains (hence the quotes). And of course, Ruff/uv can do what they do because they build on all that earlier knowledge. My point is just that sometimes it's easier to start over than to fix the old, and that fact itself feels kind of sad to me.

zahlman 2y ago
> My point is just that sometimes it's easier to start over than to fix the old, and that fact itself feels kind of sad to me. Sad, but also liberating. There are surely more projects out there that would benefit from breaking with conventional wisdom to start over.
lmm 2y ago
> there was nothing wrong with the old toolchains (hence the quotes). And of course, Ruff/uv can do what they do because they build on all that earlier knowledge I don't think that's true. I think the old toolchains really were bad, partly because the Python community was uniquely resistant to building on what worked in other ecosystems, and uv in particular largely succeeds because it's the first tool in this space to finally just ignore the nonsense that had somehow become accepted wisdom in Python-land and apply a little bit of outside experience.
- zahlman 2y ago
  > I think the old toolchains really were bad, partly because the Python community was uniquely resistant to building on what worked in other ecosystems I mostly attribute it to backwards compatibility concerns (which I in turn attribute to the traumatic 3.x migration). PyPI continued to accept egg uploads until August 2023 (https://packaging.python.org/en/latest/discussions/package-formats/#what-about-eggs https://packaging.python.org/en/latest/discussions/package-f...). The easy_install program, along the direct command-line use of `setup.py` (as opposed to having Setuptools invoke it behind the scenes), have been deprecated since October 2021 (https://setuptools.pypa.io/en/latest/history.html#v58-3-0); https://setuptools.pypa.io/en/latest/history.html#v58-3-0); but not only are they still supported, Setuptools can't even remove support for `setup.py test` (as they tried to in 72.0 and immediately reverted - https://github.com/pypa/setuptools/issues/4519 https://github.com/pypa/setuptools/issues/4519) without causing major disruption to the ecosystem. One of the packages affected was Requests, which: a) is one of the most downloaded packages on PyPI; b) is pure Python (aside from dependencies) with nothing particular complicated about its metadata (I see no reason it couldn't be done in pyproject.toml and/or setup.cfg); c) wasn't even reliant on that interface to run tests (they use Tox). (For that matter: Requests has been maintained by the PSF since mid-2019 (https://www.reddit.com/r/Python/comments/cgtp87/seems_like_requests_will_be_moved_to_a_github/ https://www.reddit.com/r/Python/comments/cgtp87/seems_like_r...) and the problem could have easily been avoided once the deprecation was announced, but nobody did anything about it. The project still defines most of its metadata in `setup.py`; `pyproject.toml` exists but is only used for pytest and isort config, while `setup.cfg` is used for flake8 config and some requirements metadata that's completely redundant with `setup.py`.) A lot of it also just has to do with lack of attention and focus. https://peps.python.org/pep-0427/ https://peps.python.org/pep-0427/ (defining the wheel format) was proposed in September 2012, and accepted in February 2013. But Setuptools itself wasn't available as a wheel until November 2013 (https://setuptools.pypa.io/en/latest/history.html#id1646 https://setuptools.pypa.io/en/latest/history.html#id1646), and in 2017 there were still reports of people having outdated versions of Pip and not being able to install Setuptools from that wheel (https://setuptools.pypa.io/en/latest/history.html#v34-0-0 https://setuptools.pypa.io/en/latest/history.html#v34-0-0). Setuptools relied on a separate package to actually make wheels until July of last year (https://setuptools.pypa.io/en/latest/history.html#v70-1-0 https://setuptools.pypa.io/en/latest/history.html#v70-1-0) - an effort which was initially proposed in June 2018 (https://github.com/pypa/setuptools/issues/1386 https://github.com/pypa/setuptools/issues/1386). It also took years to notice that Pip and Setuptools had separate implementations for the code that understands the "tags" in wheel filenames and factor it out into `packaging` (https://github.com/pypa/packaging/pull/156 https://github.com/pypa/packaging/pull/156).
  - thrdbndndn 2y ago
    > Requests I hate to say it, but the development of Requests itself has stagnated and really needs some attention. The most notable fiasco recently was the introduction of significant changes to TLS/SSL in version 2.32.0 [1][2], which caused widespread breaking issues and even led to a security vulnerability. Attempts to address these problems in versions .2 and .3 introduced new major issues which still exists in current version [3]. A patch to resolve the new issue was provided by one of the core members of the Requests project as early as June 2024 [4], but for some reason, nothing has been done about it, despite repeated pushes from the community. If you check the commit history, updates have been sparse lately, even though there are still many unresolved issues. [1] https://github.com/psf/requests/issues/6655 https://github.com/psf/requests/issues/6655 [2] https://github.com/psf/requests/pull/6667 https://github.com/psf/requests/pull/6667 [3] https://github.com/psf/requests/issues/6730 https://github.com/psf/requests/issues/6730 [4] https://github.com/psf/requests/pull/6731 https://github.com/psf/requests/pull/6731
    - drcongo 2y ago
      I've mostly ditched requests in favour of httpx these days. https://www.python-httpx.org https://www.python-httpx.org
nicoburns 2y ago
> If something can be rewritten from scratch fairly quickly and ends up being much faster, it makes you wonder what we (the general “we”) might have done “wrong” with the “decades of effort” before. I think the impact of Rust (and Go) shouldn't be underestimated here. Prior to these languages if you wanted fast runtime you were either using C or C++ with all their associated footguns, tricky build systems, and poor support for exposing and consuming libraries. Or you were using something like Java or C# which meant managing another runtime just for tools, which is especially bad for something like UV which manages runtimes - imagine if you were using a python tool to manage your Java versions and a Java tool to manage you Python versions, it would be a mess! With both Go and Rust you have fast languages without memory safety issues that compile to a single, easily-installable binary and have a broad ecosystem of libraries available that mean that half the time you don't even need to write any difficult code and can just glue some modules together, and the other half of the time you only need to write the code you actually want to write and not all the support code for general pupose stuff like reading config files, file watching, etc.

zahlman 2y ago

> My point is just that sometimes it's easier to start over than to fix the old, and that fact itself feels kind of sad to me. Sad, but also liberating. There are surely more projects out there that would benefit from breaking with conventional wisdom to start over.

lmm 2y ago

> there was nothing wrong with the old toolchains (hence the quotes). And of course, Ruff/uv can do what they do because they build on all that earlier knowledge I don't think that's true. I think the old toolchains really were bad, partly because the Python community was uniquely resistant to building on what worked in other ecosystems, and uv in particular largely succeeds because it's the first tool in this space to finally just ignore the nonsense that had somehow become accepted wisdom in Python-land and apply a little bit of outside experience.

zahlman 2y ago
> I think the old toolchains really were bad, partly because the Python community was uniquely resistant to building on what worked in other ecosystems I mostly attribute it to backwards compatibility concerns (which I in turn attribute to the traumatic 3.x migration). PyPI continued to accept egg uploads until August 2023 (https://packaging.python.org/en/latest/discussions/package-formats/#what-about-eggs https://packaging.python.org/en/latest/discussions/package-f...). The easy_install program, along the direct command-line use of `setup.py` (as opposed to having Setuptools invoke it behind the scenes), have been deprecated since October 2021 (https://setuptools.pypa.io/en/latest/history.html#v58-3-0); https://setuptools.pypa.io/en/latest/history.html#v58-3-0); but not only are they still supported, Setuptools can't even remove support for `setup.py test` (as they tried to in 72.0 and immediately reverted - https://github.com/pypa/setuptools/issues/4519 https://github.com/pypa/setuptools/issues/4519) without causing major disruption to the ecosystem. One of the packages affected was Requests, which: a) is one of the most downloaded packages on PyPI; b) is pure Python (aside from dependencies) with nothing particular complicated about its metadata (I see no reason it couldn't be done in pyproject.toml and/or setup.cfg); c) wasn't even reliant on that interface to run tests (they use Tox). (For that matter: Requests has been maintained by the PSF since mid-2019 (https://www.reddit.com/r/Python/comments/cgtp87/seems_like_requests_will_be_moved_to_a_github/ https://www.reddit.com/r/Python/comments/cgtp87/seems_like_r...) and the problem could have easily been avoided once the deprecation was announced, but nobody did anything about it. The project still defines most of its metadata in `setup.py`; `pyproject.toml` exists but is only used for pytest and isort config, while `setup.cfg` is used for flake8 config and some requirements metadata that's completely redundant with `setup.py`.) A lot of it also just has to do with lack of attention and focus. https://peps.python.org/pep-0427/ https://peps.python.org/pep-0427/ (defining the wheel format) was proposed in September 2012, and accepted in February 2013. But Setuptools itself wasn't available as a wheel until November 2013 (https://setuptools.pypa.io/en/latest/history.html#id1646 https://setuptools.pypa.io/en/latest/history.html#id1646), and in 2017 there were still reports of people having outdated versions of Pip and not being able to install Setuptools from that wheel (https://setuptools.pypa.io/en/latest/history.html#v34-0-0 https://setuptools.pypa.io/en/latest/history.html#v34-0-0). Setuptools relied on a separate package to actually make wheels until July of last year (https://setuptools.pypa.io/en/latest/history.html#v70-1-0 https://setuptools.pypa.io/en/latest/history.html#v70-1-0) - an effort which was initially proposed in June 2018 (https://github.com/pypa/setuptools/issues/1386 https://github.com/pypa/setuptools/issues/1386). It also took years to notice that Pip and Setuptools had separate implementations for the code that understands the "tags" in wheel filenames and factor it out into `packaging` (https://github.com/pypa/packaging/pull/156 https://github.com/pypa/packaging/pull/156).
- thrdbndndn 2y ago
  > Requests I hate to say it, but the development of Requests itself has stagnated and really needs some attention. The most notable fiasco recently was the introduction of significant changes to TLS/SSL in version 2.32.0 [1][2], which caused widespread breaking issues and even led to a security vulnerability. Attempts to address these problems in versions .2 and .3 introduced new major issues which still exists in current version [3]. A patch to resolve the new issue was provided by one of the core members of the Requests project as early as June 2024 [4], but for some reason, nothing has been done about it, despite repeated pushes from the community. If you check the commit history, updates have been sparse lately, even though there are still many unresolved issues. [1] https://github.com/psf/requests/issues/6655 https://github.com/psf/requests/issues/6655 [2] https://github.com/psf/requests/pull/6667 https://github.com/psf/requests/pull/6667 [3] https://github.com/psf/requests/issues/6730 https://github.com/psf/requests/issues/6730 [4] https://github.com/psf/requests/pull/6731 https://github.com/psf/requests/pull/6731
  - drcongo 2y ago
    I've mostly ditched requests in favour of httpx these days. https://www.python-httpx.org https://www.python-httpx.org

nicoburns 2y ago

> If something can be rewritten from scratch fairly quickly and ends up being much faster, it makes you wonder what we (the general “we”) might have done “wrong” with the “decades of effort” before. I think the impact of Rust (and Go) shouldn't be underestimated here. Prior to these languages if you wanted fast runtime you were either using C or C++ with all their associated footguns, tricky build systems, and poor support for exposing and consuming libraries. Or you were using something like Java or C# which meant managing another runtime just for tools, which is especially bad for something like UV which manages runtimes - imagine if you were using a python tool to manage your Java versions and a Java tool to manage you Python versions, it would be a mess! With both Go and Rust you have fast languages without memory safety issues that compile to a single, easily-installable binary and have a broad ecosystem of libraries available that mean that half the time you don't even need to write any difficult code and can just glue some modules together, and the other half of the time you only need to write the code you actually want to write and not all the support code for general pupose stuff like reading config files, file watching, etc.