4 ms·

What percentage of those lines do you estimate will need changes?

• CJefferson 8y ago
  The problem is which lines. I found code all over the place which broke for unicode reasons (we were reading in the output of GCC, and printing it back out, and it didn't work any more as GCC doesn't output valid UTF8 in some cases). In the end I decided moving to Rust was less work than Python 3 (in terms of being sure my program was reliable and wouldn't error out with unicode errors).
  • ric2b 8y ago
    > I found code all over the place which broke for unicode reasons (we were reading in the output of GCC, and printing it back out, and it didn't work any more as GCC doesn't output valid UTF8 in some cases). That means the code was working with raw bytes, not utf-8 strings, so that's what you should convert to on Python3. That means using `.encode()` and `.decode()` or using bytestrings. Python3 doesn't break string usage, it makes you do it correctly. Expect a lot more of that kind of pain by moving to Rust (not saying it's not worth, you'll indeed get more correct programs done).
    • CJefferson 8y ago
      The problem I had with python is that (because it is dynamically typed), and quite a few methods take both bytes and strings, it can be tricky to track what you have and often things don't break until you feed in a non-UTF8 string. I found it much easier in Rust, as the two types are just distinct, and an incorrect program just fails to compile.
      • orf 8y ago
        In Python 3 they are two distinct types as well.
        • lmm 8y ago
          They're not really "types" when you only find out at runtime.
          • orf 8y ago
            Sure they are.
          • joshuamorton 8y ago
            When handling tricky string issues, my first step is usually to explicitly type annotate the code (using mypy annotations). This makes string handling and tracking much simpler.
• speedplane 8y ago
  100% will need to be tested.
• walrus1066 8y ago
  Imagine that's part of the challenge. Since python is dynamically typed/duck typed, it's hard to audit all usages of a variable. I.e. If I see a py2 string declared, how can I be 100% sure I don't break downstream components by making it a bytes or py3 unicode string? Some might be using it as the former, others the latter. You'd need insane test coverage, of all possible code paths, to be 100% confident.
  • wenc 8y ago
    I was responsible for the Python 2 to 3 migration for various code bases at work. I used 2to3 to check for issues, but did most of the code rewrites by hand. Most of the conversion difficulties were related to Unicode/text/binary string handling in Python 3, and 2to3 didn't catch all of them. This was the biggest challenge of the entire process. Stuff would fail in production because due to improper string handling. Python 2 was remarkably permissive (i.e. loosy goosey), whereas Python 3 is stricter and arguably more correct, but this strictness has a cost. The other class of problems is the restructure of certain std libs, like urllib. We took the opportunity to move away from "urllib" to "requests". This site [1] was invaluable in understanding the migration issues. All in all, apart from breaking Unicode issues, the migration process was fairly easy. [1] http://python3porting.com/problems.html http://python3porting.com/problems.html
• coldtea 8y ago
  Anything dealing with text for starters.