4 ms·

Especially now that they are on a crusade against their own stdlib. They regret including most modules… it seems they regret making python altogether instead o

Especially now that they are on a crusade against their own stdlib. They regret including most modules… it seems they regret making python altogether instead of sticking with C? :D

kzrdude 3y ago
This is a typical programmer, you'll regret code as soon as you turn your back on it. :)
- NegativeLatency 3y ago
  Or before!
Qem 3y ago
> They regret including most modules… it seems they regret making python altogether instead of sticking with C? :D I also find it odd. Python would probably be a little known language without the huge batteries included by default. It's invaluable when you're working in a environment where you can't fully control what is installed, what is the case of most people at work. I believe this crusade endangers the language long-term.
- oefrha 3y ago
  You're reading a ridiculous mischaracterization of reality (~20 deprecated modules [1] out of the ~300 PSL modules [2] is "most"?). Of course you find it odd. [1] https://peps.python.org/pep-0594/ https://peps.python.org/pep-0594/ [2] https://docs.python.org/3/library/ https://docs.python.org/3/library/
  - toyg 3y ago
    It's the trend that is a bit worrying. It's definitely been floated more than once that the stdlib should be fundamentally gutted. It has not become a reality yet, but there are some loud voices advocating to just chuck most modules as a principle into pypi.
    - eesmith 3y ago
      "Trend"? Python has dropped quite a few modules over the decades. "gl", "sgi", "fl", "sunaudiodev", "audioop", "stdwin", "rotor", "poly", "whatsound", "gopherlib" .. the list goes on. Some of these were dropped with 1.6 (see "Obsolete Modules" at https://www.python.org/download/releases/1.6/ https://www.python.org/download/releases/1.6/ ). Some with 3.0 (see https://docs.python.org/3.10/whatsnew/2.6.html https://docs.python.org/3.10/whatsnew/2.6.html for then-upcoming removals.)
    - dragonwriter 3y ago
      There are two strong reasons for that: (1) Not letting little used modules that pose maintenance problems drive up the cost of maintaining Python, and (2) Not forcing actively used, actively developed modules to be limited to the core language upgrade cadence (and not forcing users to upgrade the language to get upgrades to the modules.) Ruby I think has a decent approach to this (particularly, one that deals with #2 better than just evicting things entirely from the standard distribution) with “Gemification” of the standard library, where most things that are moved out of the standard library aren’t moved out of the standard distribution, but into a set of gems distributed with the standard distribution but which can be upgraded independently.
    - oefrha 3y ago
      Maybe I've been out of the loop for the past couple of years since I've been writing less Python and don't follow Twitter drama, but IIRC none of the "stdlib is where module goes to die" crowd has ever advocated a fundamental gutting of the existing stable and widely used modules in PSL.
  - bombolo 3y ago
    I was referring to this: https://pyfound.blogspot.com/2023/05/the-python-language-summit-2023-what-is.html https://pyfound.blogspot.com/2023/05/the-python-language-sum... Of course nobody even knew so the default response is to hit that bottom arrow :D
    - arp242 3y ago
      "Had possibly been added before it was fully baked" is not the same as "we should never have added anything like it", and neither is "we have a much better solution but no one uses that because asyncio is in stdlib which we're now stuck with, for better or worse". Your entire reading of that is just wrong.
Znafon 3y ago
This is quite an oversimplification. Some modules have no active maintainers and take time from the small team that work on CPython. Some modules are deprecated and removed to make it possible to allocate time on other improvements, and they went back on some removals when users came forward showing that they were still needed. There is some discussion about the rationale at https://peps.python.org/pep-0594/#rationale https://peps.python.org/pep-0594/#rationale
- bombolo 3y ago
  Did you read the latest news or not? They regret asyncio! (and many other core modules). They won't remove them… but they regret having made them. I think without, people would have just not used python.
  - Redoubts 3y ago
    After using Trio, I would regret asyncio too
  - vamega 3y ago
    Where was this news? I’d like to read this.

Especially now that they are on a crusade against their own stdlib. They regret including most modules… it seems they regret making python altogether instead of sticking with C? :D

kzrdude 3y ago

This is a typical programmer, you'll regret code as soon as you turn your back on it. :)

NegativeLatency 3y ago
Or before!

Qem 3y ago

> They regret including most modules… it seems they regret making python altogether instead of sticking with C? :D I also find it odd. Python would probably be a little known language without the huge batteries included by default. It's invaluable when you're working in a environment where you can't fully control what is installed, what is the case of most people at work. I believe this crusade endangers the language long-term.

oefrha 3y ago
You're reading a ridiculous mischaracterization of reality (~20 deprecated modules [1] out of the ~300 PSL modules [2] is "most"?). Of course you find it odd. [1] https://peps.python.org/pep-0594/ https://peps.python.org/pep-0594/ [2] https://docs.python.org/3/library/ https://docs.python.org/3/library/
- toyg 3y ago
  It's the trend that is a bit worrying. It's definitely been floated more than once that the stdlib should be fundamentally gutted. It has not become a reality yet, but there are some loud voices advocating to just chuck most modules as a principle into pypi.
  - eesmith 3y ago
    "Trend"? Python has dropped quite a few modules over the decades. "gl", "sgi", "fl", "sunaudiodev", "audioop", "stdwin", "rotor", "poly", "whatsound", "gopherlib" .. the list goes on. Some of these were dropped with 1.6 (see "Obsolete Modules" at https://www.python.org/download/releases/1.6/ https://www.python.org/download/releases/1.6/ ). Some with 3.0 (see https://docs.python.org/3.10/whatsnew/2.6.html https://docs.python.org/3.10/whatsnew/2.6.html for then-upcoming removals.)
  - dragonwriter 3y ago
    There are two strong reasons for that: (1) Not letting little used modules that pose maintenance problems drive up the cost of maintaining Python, and (2) Not forcing actively used, actively developed modules to be limited to the core language upgrade cadence (and not forcing users to upgrade the language to get upgrades to the modules.) Ruby I think has a decent approach to this (particularly, one that deals with #2 better than just evicting things entirely from the standard distribution) with “Gemification” of the standard library, where most things that are moved out of the standard library aren’t moved out of the standard distribution, but into a set of gems distributed with the standard distribution but which can be upgraded independently.
  - oefrha 3y ago
    Maybe I've been out of the loop for the past couple of years since I've been writing less Python and don't follow Twitter drama, but IIRC none of the "stdlib is where module goes to die" crowd has ever advocated a fundamental gutting of the existing stable and widely used modules in PSL.
- bombolo 3y ago
  I was referring to this: https://pyfound.blogspot.com/2023/05/the-python-language-summit-2023-what-is.html https://pyfound.blogspot.com/2023/05/the-python-language-sum... Of course nobody even knew so the default response is to hit that bottom arrow :D
  - arp242 3y ago
    "Had possibly been added before it was fully baked" is not the same as "we should never have added anything like it", and neither is "we have a much better solution but no one uses that because asyncio is in stdlib which we're now stuck with, for better or worse". Your entire reading of that is just wrong.

Znafon 3y ago

This is quite an oversimplification. Some modules have no active maintainers and take time from the small team that work on CPython. Some modules are deprecated and removed to make it possible to allocate time on other improvements, and they went back on some removals when users came forward showing that they were still needed. There is some discussion about the rationale at https://peps.python.org/pep-0594/#rationale https://peps.python.org/pep-0594/#rationale

bombolo 3y ago
Did you read the latest news or not? They regret asyncio! (and many other core modules). They won't remove them… but they regret having made them. I think without, people would have just not used python.
- Redoubts 3y ago
  After using Trio, I would regret asyncio too
- vamega 3y ago
  Where was this news? I’d like to read this.