5 ms·

This would be a backwards incompatible change that would cause a lot of issues. For instance, you are not allowed to compare naive and non-naive datetimes, so f

This would be a backwards incompatible change that would cause a lot of issues. For instance, you are not allowed to compare naive and non-naive datetimes, so for instance, `utcnow() > datetime(2023, 11, 19)` would work before, but break following your change.

akersten 3y ago
Removing the functions wholesale isn't a backwards incompatible change?
- ollien 3y ago
  It is one that can be found via static analysis. That may not be true if behavior is changed. In some cases, this may be "ok" (see: Go's recent loop changes), but in others, it may not.
  - IshKebab 3y ago
    Most Python users don't do any form of static analysis though, so both changes would only be found at runtime. But I think changing the behaviour and not the name is still a very bad idea.
    - kevincox 3y ago
      Yes, but "Unknown function datetime.utcnow" is much easier to diagnose than somewhere in your application, possibly inside a third-party library or maybe even in a different service altogether (because the change traversed serialization and deserilialization) throwing an exception because you can't compare two datetimes.
BugsJustFindMe 3y ago
That's going to break following this change anyway.
- sanderjd 3y ago
  But in a much more obvious way. Noisy errors are better than quiet inaccuracy. They screwed up these methods from the start, and removing them is the only way to get rid of the confusion, without introducing subtle breakage.
  - BugsJustFindMe 3y ago
    It would still be a noisy error, just a different one that you can't compare non-naive and naive datetimes.
    - sanderjd 3y ago
      Unless you never compare it anywhere. Whereas it fails immediately if you try to do `datetime.utcnow` and that method doesn't exist.
ak217 3y ago
Breaking following the change is fine. Silently changing the behavior in a way that could cause catastrophic bugs is not. That's why the suggestion to just keep the functions and change their behavior is naive. It would obviously be very unsafe to do so.

akersten 3y ago

Removing the functions wholesale isn't a backwards incompatible change?

ollien 3y ago
It is one that can be found via static analysis. That may not be true if behavior is changed. In some cases, this may be "ok" (see: Go's recent loop changes), but in others, it may not.
- IshKebab 3y ago
  Most Python users don't do any form of static analysis though, so both changes would only be found at runtime. But I think changing the behaviour and not the name is still a very bad idea.
  - kevincox 3y ago
    Yes, but "Unknown function datetime.utcnow" is much easier to diagnose than somewhere in your application, possibly inside a third-party library or maybe even in a different service altogether (because the change traversed serialization and deserilialization) throwing an exception because you can't compare two datetimes.

BugsJustFindMe 3y ago

That's going to break following this change anyway.

sanderjd 3y ago
But in a much more obvious way. Noisy errors are better than quiet inaccuracy. They screwed up these methods from the start, and removing them is the only way to get rid of the confusion, without introducing subtle breakage.
- BugsJustFindMe 3y ago
  It would still be a noisy error, just a different one that you can't compare non-naive and naive datetimes.
  - sanderjd 3y ago
    Unless you never compare it anywhere. Whereas it fails immediately if you try to do `datetime.utcnow` and that method doesn't exist.

ak217 3y ago

Breaking following the change is fine. Silently changing the behavior in a way that could cause catastrophic bugs is not. That's why the suggestion to just keep the functions and change their behavior is naive. It would obviously be very unsafe to do so.