3 ms·

It is interesting to see just how conservative the core devs are against even the most benign way forward (including more consistent aliases without immediate d

It is interesting to see just how conservative the core devs are against even the most benign way forward (including more consistent aliases without immediate deprecation). Indeed, not a hill worth dying on either way but it’s a little wild the counter argument is “increased support costs” when, let’s be real, there is no significant increased support beyond the initial scope of work. If core Python ever plans on consistency, introducing these aliases early is the main way for them to achieve it. Even if there is no direct plan for deprecation. Something something about the best time to plant a tree.

nerdponx 3y ago
As much as I like to defend Python against the "Python bad!!" nonsense here on HN, I agree with this, and with similar complaints about naming in the 'datetime' module.
ssl232 3y ago
The time to have done it was the first release of Python 3 when everything else was breaking anyway. The ship has sailed.
Kwpolska 3y ago
Adding new aliases to be consistent with Python's prevalent coding style? Increased support costs, not worth it. Deprecating often-used APIs like datetime.datetime.utcnow() because they're ugly? Sure, we'll do that, that won't cause anyone problems unless their code is wrong. (At least they didn't set the removal date to be +2 releases = +2 years, as they usually do.)
- notatallshaw 3y ago
  The Python standard library is primarily managed by volunteers, and different sections have distinct maintainers, resulting in diverse choices. When there's no strong advocate for a module, implementing changes becomes a challenging task. However, modules with dedicated champions, such as datetime by Paul Ganssle or pathlib by Barney Gale, may undergo significant modifications after consideration and discussion. Not everyone in the broader Python community will be pleased with these alterations, but they aren't made hastily. I suggest we show empathy towards those who willingly take on the responsibilities of being open-source maintainers, it's a fiery task. While I've personally expressed dissatisfaction with the utcnow change on the Python discussion page, I also acknowledge that I'm not responsible for maintaining this module. Consequently, I've updated my code in a completely backwards compatible way: datetime.datetime.utcnow() -> datetime.datetime.now(datetime.UTC).replace(tzinfo=None).
  - Kwpolska 3y ago
    No matter how many maintainers there are, the policy to eagerly deprecate and quickly remove things is something common to all of stdlib. And I think that’s not a good policy for a programming language. If you look at Java, for example, only very few APIs were removed between Java 9 and 20, many of which minor or broken/useless (Pack200, RMI): https://docs.oracle.com/en/java/javase/20/migrate/removed-apis.html https://docs.oracle.com/en/java/javase/20/migrate/removed-ap...
    - notatallshaw 3y ago
      There has been a recent push to remove completely unmaintained modules with PEP 594, but the steering council has made it clear that PEP was an exception and all future module deprecations will have to be done on a case by case basis. The PEP 594 modules were discussed for well over two years before the PEP was accepted, and includes unmaintained modules that were technically deprecated as of Python 2.0. I also rarely see methods removed at all, which is why the utcnow one sticks out so sharply for myself and others. I can't reconcile this with the statement of "policy to eagerly deprecate and quickly remove things", but maybe you have some evidence? Further there is a clear path discussed on the Python board of how to move any pure Python modules to PyPI for any part of the community that wish to maintain them. In the earlier years of Python it was not a serious option to ask everyone to use third party libraries, but now for almost all use cases it is a reasonable option.

nerdponx 3y ago

As much as I like to defend Python against the "Python bad!!" nonsense here on HN, I agree with this, and with similar complaints about naming in the 'datetime' module.

ssl232 3y ago

The time to have done it was the first release of Python 3 when everything else was breaking anyway. The ship has sailed.

Kwpolska 3y ago

Adding new aliases to be consistent with Python's prevalent coding style? Increased support costs, not worth it. Deprecating often-used APIs like datetime.datetime.utcnow() because they're ugly? Sure, we'll do that, that won't cause anyone problems unless their code is wrong. (At least they didn't set the removal date to be +2 releases = +2 years, as they usually do.)

notatallshaw 3y ago
The Python standard library is primarily managed by volunteers, and different sections have distinct maintainers, resulting in diverse choices. When there's no strong advocate for a module, implementing changes becomes a challenging task. However, modules with dedicated champions, such as datetime by Paul Ganssle or pathlib by Barney Gale, may undergo significant modifications after consideration and discussion. Not everyone in the broader Python community will be pleased with these alterations, but they aren't made hastily. I suggest we show empathy towards those who willingly take on the responsibilities of being open-source maintainers, it's a fiery task. While I've personally expressed dissatisfaction with the utcnow change on the Python discussion page, I also acknowledge that I'm not responsible for maintaining this module. Consequently, I've updated my code in a completely backwards compatible way: datetime.datetime.utcnow() -> datetime.datetime.now(datetime.UTC).replace(tzinfo=None).
- Kwpolska 3y ago
  No matter how many maintainers there are, the policy to eagerly deprecate and quickly remove things is something common to all of stdlib. And I think that’s not a good policy for a programming language. If you look at Java, for example, only very few APIs were removed between Java 9 and 20, many of which minor or broken/useless (Pack200, RMI): https://docs.oracle.com/en/java/javase/20/migrate/removed-apis.html https://docs.oracle.com/en/java/javase/20/migrate/removed-ap...
  - notatallshaw 3y ago
    There has been a recent push to remove completely unmaintained modules with PEP 594, but the steering council has made it clear that PEP was an exception and all future module deprecations will have to be done on a case by case basis. The PEP 594 modules were discussed for well over two years before the PEP was accepted, and includes unmaintained modules that were technically deprecated as of Python 2.0. I also rarely see methods removed at all, which is why the utcnow one sticks out so sharply for myself and others. I can't reconcile this with the statement of "policy to eagerly deprecate and quickly remove things", but maybe you have some evidence? Further there is a clear path discussed on the Python board of how to move any pure Python modules to PyPI for any part of the community that wish to maintain them. In the earlier years of Python it was not a serious option to ask everyone to use third party libraries, but now for almost all use cases it is a reasonable option.