4 ms·

> Java's "never remove a deprecated API" was definitely one of their big mistakes. Even a 10-year deprecation cycle is better than none. Can you explain this p

> Java's "never remove a deprecated API" was definitely one of their big mistakes. Even a 10-year deprecation cycle is better than none. Can you explain this position? Python just did a 10-year deprecation cycle on Python 2, but it was really costly for a lot of people. If they'd just not done that it would have been better; the benefits of removing stuff are relatively minor (cleaner language implementation codebase) and the costs are huge (all users need to change, test, handle compatibility, ...).

pas 7y ago
No, no, no. It was not a deprecation cycle. It was a complete stop using this because it's full of unclear semantics, here's the new thing cycle. Py3 should have simply started to warn when you used "bla" without u"..." or b"...", and so on. To clear up the bad code. Then later ... maybe 10 years later, make "..." equivalent to u"...". Maybe.
- amluto 7y ago
  I don’t know what the right solution to the string problem should have been. Python 2’a string handling was bad, and programs used it inconsistently and nonsensically. IMO the real problem is the near complete lack of static checking that you fixed it with. Sure, modern Python + mypy can do a credible job finding wrong-string-type bugs, but legacy Python 2 codebases don’t have the right annotations. I do wish I could tell Python 3 to error out if I accidentally put a str and a bytes in the same dictionary as keys.
  - ttwwmm 7y ago
    The core problem with strings in Python 2 was implicit coercion: you could mix `b''` and `u''` strings pretty freely as long as they only contained ASCII and they would be silently converted as required. Once you leave the ASCII range you start to see data-dependent bugs. To gracefully deprecate this behavior, you could start by generating a warning each time an implicit coercion is done. Next, make implicit coercion raise an exception, but provide a way to suppress it. Finally, remove the ability to suppress the exception. As the GP suggests, you'd do well to similarly deprecate unprefixed strings. This would all be pretty confusing to explain if you were renaming the string types at the same time, as Python 3 did. I think that's an indication that you shouldn't rename the types. You could deprecate `str` and just use the names `bytes` and `unicode`, which go nicely with the `b''` and `u''` mnemonics anyway. Python 3 also changed the type of string used for Python identifiers. You'd need a strategy there as well. It might be convenient to have some type-checking `dict` variants in the stdlib, but I think it's a separate issue from addressing the coercion issue.
  - ComputerGuru 7y ago
    IMHO, it would have been to repurpose the existing format for Unicode (specifically UTF-8) text and have a special notation for binary/ascii text. It’s interpreted code, ffs. It’s not like you have pre-compiled binaries you need to stay ABI compatible with (like Microsoft did when they introduced TCHAR and co).
- deleted 7y ago
  [deleted]
tedunangst 7y ago
Among other problems, there was never a time when you could combine python 2 and 3 in the same program. That wasn't a deprecation; it was simply a break.

pas 7y ago

No, no, no. It was not a deprecation cycle. It was a complete stop using this because it's full of unclear semantics, here's the new thing cycle. Py3 should have simply started to warn when you used "bla" without u"..." or b"...", and so on. To clear up the bad code. Then later ... maybe 10 years later, make "..." equivalent to u"...". Maybe.

amluto 7y ago
I don’t know what the right solution to the string problem should have been. Python 2’a string handling was bad, and programs used it inconsistently and nonsensically. IMO the real problem is the near complete lack of static checking that you fixed it with. Sure, modern Python + mypy can do a credible job finding wrong-string-type bugs, but legacy Python 2 codebases don’t have the right annotations. I do wish I could tell Python 3 to error out if I accidentally put a str and a bytes in the same dictionary as keys.
- ttwwmm 7y ago
  The core problem with strings in Python 2 was implicit coercion: you could mix `b''` and `u''` strings pretty freely as long as they only contained ASCII and they would be silently converted as required. Once you leave the ASCII range you start to see data-dependent bugs. To gracefully deprecate this behavior, you could start by generating a warning each time an implicit coercion is done. Next, make implicit coercion raise an exception, but provide a way to suppress it. Finally, remove the ability to suppress the exception. As the GP suggests, you'd do well to similarly deprecate unprefixed strings. This would all be pretty confusing to explain if you were renaming the string types at the same time, as Python 3 did. I think that's an indication that you shouldn't rename the types. You could deprecate `str` and just use the names `bytes` and `unicode`, which go nicely with the `b''` and `u''` mnemonics anyway. Python 3 also changed the type of string used for Python identifiers. You'd need a strategy there as well. It might be convenient to have some type-checking `dict` variants in the stdlib, but I think it's a separate issue from addressing the coercion issue.
- ComputerGuru 7y ago
  IMHO, it would have been to repurpose the existing format for Unicode (specifically UTF-8) text and have a special notation for binary/ascii text. It’s interpreted code, ffs. It’s not like you have pre-compiled binaries you need to stay ABI compatible with (like Microsoft did when they introduced TCHAR and co).
deleted 7y ago
[deleted]

tedunangst 7y ago

Among other problems, there was never a time when you could combine python 2 and 3 in the same program. That wasn't a deprecation; it was simply a break.