4 ms·

Yes. This is where Linus would step in and say "SHUT THE FUCK UP! We don't break user space, EVER!" Developers who enter into the mindset that the users of thei

Yes. This is where Linus would step in and say "SHUT THE FUCK UP! We don't break user space, EVER!" Developers who enter into the mindset that the users of their code are using it "wrong" are a blight and will always be a blight. Too bad Python has a BDFL and not a Raging DFL.

deleted 13y ago
[deleted]
yxhuvud 13y ago
Linus does NOT break backwards compatibility. That is what this change implies. Which doesn't mean I disagree with changing the behaviour, but I doubt Linus would use that reason for that.
- marcosdumay 13y ago
  It's undocummented, and very complex to use. That mail does not even have sufficient information to understand how to use this "feature". I hightly doubt anybody uses it outside of the datetime codebase. I never saw Linus complaining about changing undocummented and not used behaviour.
  - sirclueless 13y ago
    It is documented. That's the strongest argument against changing it: it's a documented piece of user-facing behavior. The python developers are changing it anyways because they're practical people who have decided it is more likely that people wrote bugs into their code, than that they wrote code that depended correctly on the falsiness of UTC midnight.
    - einhverfr 13y ago
      This is true, but if it is documented it is still sufficiently oddball to be useless. Consider: Midnight UTC, timezone EST: True Midnight UTC, timezone CET: False Midnight UTC, timezone CST: True Midnight UTC, timezone WIT: False Midnight UTC, timezone PST: True Now the problem here is that it may well be documented but it is in fact unsafe to rely on in any context. The behavior is thus irretrievably broken, documented or not. It isn't even expert-friendly. The behavior, documented or not, is irretrievably broken. After all timezones west of GMT will never have false times. If there is a use case for this behavior, I sure can't see it. Unless you like bugs appearing when you change timezones.
nknighthb 13y ago
Some things are really hard on users when they break. Kernels are especially hard, because only one can run on a (non-virtualized) system at a time. System libcs are pretty hard, ditto init systems and some other deep infrastructure. Language interpreters can be annoying, but not to the same degree. It is quite easy to run multiple Python versions on one system. It's also relatively easy to find and fix the broken Python code in a case like this -- it's always sitting there on your drive, open for inspection. And it's not black magic -- anyone with a little programming experience, even if it's not in Python, can easily understand the issue and the fix, and make the appropriate change. Nuance matters, and unlike a boolean, principles are not always binary choices.
einhverfr 13y ago
As another commenter pointed out, nuance is important. However, there are times to break break compatibility and accept that people will struggle. The way to do this right is to give real warning and provide reasonable migration paths. I will give you an example that bit my project hard, caused hours upon hours of wasted time for bugfixes, broke our software, etc. and yet was a good thing: PostgreSQL 8.3's removal of most implicit type casts. Prior to PostgreSQL 8.3, the following query would be valid and evaluate to false: select '2014-01-01' = 2014-01-01; What would happen is the system would look for possible types to compare and find that text matched. It would then treat this as: SELECT '2014-01-01'::text = (2014 - 1 - 1)::text; And further to: SELECT '2014-01-01'::text = '2012'::text which was not what you meant. The team made the right decision to make this change and subsequently broke a lot of apps out there. I think it took us a couple months to be sure we had all the breakage out of LedgerSMB 1.2.x. Painful change. Broke a whole bunch of apps. But it was an important one and we are all better off for it. Now, Linux exists in an ecosystem of mostly source-compatible operating systems. People write portable software that they expect to run on FreeBSD, Linux, and so forth with minimal tweaking. I am not sure "we don't break user space ever" would be a compelling argument against fixing non-POSIX-compliant but existing and documented behavior. But this scenario (and frankly the stupidity in the midnight type handling in Python) is what pre-review is supposed to help prevent in the first place.
Shish2k 13y ago
Given approximately zero people using this datetime behaviour correctly, maybe one or two who tried to use it correctly and failed, and thousands of people who have bugs because they didn't expect it, I'm not sure changing it to be sensible counts as breaking user space in any practical sense...

deleted 13y ago

[deleted]

yxhuvud 13y ago

Linus does NOT break backwards compatibility. That is what this change implies. Which doesn't mean I disagree with changing the behaviour, but I doubt Linus would use that reason for that.

marcosdumay 13y ago
It's undocummented, and very complex to use. That mail does not even have sufficient information to understand how to use this "feature". I hightly doubt anybody uses it outside of the datetime codebase. I never saw Linus complaining about changing undocummented and not used behaviour.
- sirclueless 13y ago
  It is documented. That's the strongest argument against changing it: it's a documented piece of user-facing behavior. The python developers are changing it anyways because they're practical people who have decided it is more likely that people wrote bugs into their code, than that they wrote code that depended correctly on the falsiness of UTC midnight.
  - einhverfr 13y ago
    This is true, but if it is documented it is still sufficiently oddball to be useless. Consider: Midnight UTC, timezone EST: True Midnight UTC, timezone CET: False Midnight UTC, timezone CST: True Midnight UTC, timezone WIT: False Midnight UTC, timezone PST: True Now the problem here is that it may well be documented but it is in fact unsafe to rely on in any context. The behavior is thus irretrievably broken, documented or not. It isn't even expert-friendly. The behavior, documented or not, is irretrievably broken. After all timezones west of GMT will never have false times. If there is a use case for this behavior, I sure can't see it. Unless you like bugs appearing when you change timezones.

nknighthb 13y ago

Some things are really hard on users when they break. Kernels are especially hard, because only one can run on a (non-virtualized) system at a time. System libcs are pretty hard, ditto init systems and some other deep infrastructure. Language interpreters can be annoying, but not to the same degree. It is quite easy to run multiple Python versions on one system. It's also relatively easy to find and fix the broken Python code in a case like this -- it's always sitting there on your drive, open for inspection. And it's not black magic -- anyone with a little programming experience, even if it's not in Python, can easily understand the issue and the fix, and make the appropriate change. Nuance matters, and unlike a boolean, principles are not always binary choices.

einhverfr 13y ago

As another commenter pointed out, nuance is important. However, there are times to break break compatibility and accept that people will struggle. The way to do this right is to give real warning and provide reasonable migration paths. I will give you an example that bit my project hard, caused hours upon hours of wasted time for bugfixes, broke our software, etc. and yet was a good thing: PostgreSQL 8.3's removal of most implicit type casts. Prior to PostgreSQL 8.3, the following query would be valid and evaluate to false: select '2014-01-01' = 2014-01-01; What would happen is the system would look for possible types to compare and find that text matched. It would then treat this as: SELECT '2014-01-01'::text = (2014 - 1 - 1)::text; And further to: SELECT '2014-01-01'::text = '2012'::text which was not what you meant. The team made the right decision to make this change and subsequently broke a lot of apps out there. I think it took us a couple months to be sure we had all the breakage out of LedgerSMB 1.2.x. Painful change. Broke a whole bunch of apps. But it was an important one and we are all better off for it. Now, Linux exists in an ecosystem of mostly source-compatible operating systems. People write portable software that they expect to run on FreeBSD, Linux, and so forth with minimal tweaking. I am not sure "we don't break user space ever" would be a compelling argument against fixing non-POSIX-compliant but existing and documented behavior. But this scenario (and frankly the stupidity in the midnight type handling in Python) is what pre-review is supposed to help prevent in the first place.

Shish2k 13y ago

Given approximately zero people using this datetime behaviour correctly, maybe one or two who tried to use it correctly and failed, and thousands of people who have bugs because they didn't expect it, I'm not sure changing it to be sensible counts as breaking user space in any practical sense...