> On Jul 12, 2019, at 12:45 PM, Robert Ma <rober...@chromium.org> wrote: > > Any thoughts on bytes and Unicode strings, especially the string literals in > the code base?
My experience with this has been you mostly have to pay attention to where your code interfaces with other processes. In webkitpy, I suspect that most of the our work here will probably be where we are calling other commands or reading files. Because we call most commands through either the Executive class or the FileSystem class, I think there is a good chance we can make changes here that effect most of the codebase. Jonathan > > On Fri, Jul 12, 2019 at 3:38 PM Tim Horton <timothy_hor...@apple.com > <mailto:timothy_hor...@apple.com>> wrote: > > >> On Jul 12, 2019, at 12:18 PM, Jonathan Bedard <jbed...@apple.com >> <mailto:jbed...@apple.com>> wrote: >> >> Hello WebKit developers, >> >> Now that the Catalina developer seeds are available, it is official that the >> new Mac developer tools come with Python 3. As a result, we need to continue >> the ongoing discussion about migrating our Python 2.7 scripts to Python 3. >> >> I propose that, over the next 9 months, we do the following: >> >> 1. Make any no-cost Python 3 compatibility changes, in particular >> - print foo -> print(foo) >> - import .foo -> import webkitpy.foo >> 2. Convert any scripts not used in automation to Python 3 ASAP (scripts like >> bisect-builds, block-spammers, compare-results) >> 3. Make most Python 3 compatibility changes which sacrifice efficiency, >> subject to a case-by-case audit. These would be things like: >> - dict.iteritems() -> dict.items() >> - dict.items() -> list(dict.items()) >> 4. Install Python 3 on macOS Sierra and Mojave bots >> 5. Convert peripheral automation scripts to Python 3 1-by-1 (scripts like >> clean-webkit, merge-results-json, webkit-patch) >> 6. Convert testing scripts and webkitpy to Python 3 in a single change >> >> The trouble I foresee us encountering with any scheme which attempts a >> conversion which retains both Python 2.7 and Python 3 compatibility is code >> like this: >> >> for expectation_string, expectation_enum in >> test_expectations.TestExpectations.EXPECTATIONS.iteritems(): >> ... >> >> In this code, the EXPECTATIONS dictionary is thousands of elements long. In >> Python 2.7, iteritems() gives us an iterator instead of creating a new list, >> like items() would. In Python 3, iteritems() doesn’t exist, but items() >> does, and now gives us an iterator instead of creating a new list. The >> trouble here is that, in this case, creating a new list will be very >> expensive, expensive enough that we might manage to impact the testing run. >> There isn’t really an elegant way around this problem if we want to support >> both Python 2.7 and Python 3, other than defining different code paths for >> each language. > > The official Python 3 transition documentation has a fairly elegant solution > to this, actually?? > > https://legacy.python.org/dev/peps/pep-0469/ > <https://legacy.python.org/dev/peps/pep-0469/> > > See "Migrating to the common subset of Python 2 and 3” — you define different > iteritems() helpers in the two cases. Seems pretty reasonable to me. > >> There are other small gotchas as well. For example, ‘%’ is no longer a >> protected character, which can actually change the behavior of regexes. >> That’s why I think it’s better to just try and directly convert things >> instead of attempting to be compatible with both Python 2.7 and Python 3. >> >> Jonathan >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >> https://lists.webkit.org/mailman/listinfo/webkit-dev >> <https://lists.webkit.org/mailman/listinfo/webkit-dev> > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> > https://lists.webkit.org/mailman/listinfo/webkit-dev > <https://lists.webkit.org/mailman/listinfo/webkit-dev>
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
