Mentioned this on the other thread but here’s it again. and might be of use considering 
the sheer amount of code. They’re both mentioned in for migration.

You can run individual rules one by one over the code. That might be ok rather 
than running all the rules at once. Especially for review. Modernize seemed to 
work pretty well but it wasn’t smart enough to detect shebang lines.

From: webkit-dev <> 
On Behalf Of Tim Horton
Sent: Friday, July 12, 2019 12:38 PM
To: Jonathan Bedard <>
Subject: Re: [webkit-dev] Moving to Python 3

On Jul 12, 2019, at 12:18 PM, Jonathan Bedard 
<<>> 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
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 

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??

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.

webkit-dev mailing list<>

webkit-dev mailing list

Reply via email to