[Piglit] Port piglit framework to python3, round 2

[Brian Paul]

For getting to Python3, are you thinking a few weeks, a month, longer?

Thanks.

-Brian

On 01/11/2016 01:36 PM, Dylan Baker wrote:
> Sure.
>
> I've been working on a hybrid approach, using the six library (the
> generators currently already work this way). Once my subprocess32
> timeout stuff lands, the code I have will be based on upstream, and I
> just need to finish sorting out the str/byte/unicode changes between
> python 2 and 3.
>
> My thought is that we can use a hybrid approach while there are still
> users needing python 2 support, (I know you guys still have some systems
> using python 2.7 exclusively, as does Red Hat). We can just start
> removing six and have a python 3 exclusive code base when there are no
> consumers left for python 2.
>
> Dylan
>
> On Mon, Jan 11, 2016 at 12:30 PM, Brian Paul <brianp at vmware.com
> <mailto:brianp at vmware.com>> wrote:
>
>     Hi Dylan,
>
>     We're actually interested in getting Piglit running on Python3.  Can
>     you give an update on the status of this?
>
>     Thanks!
>
>     -Brian
>
>
>     On 03/13/2015 04:30 PM, Dylan Baker wrote:
>
>         bump
>
>         On Thu, Mar 05, 2015 at 02:04:00PM -0800, Dylan Baker wrote:
>
>             This is a proposal for another go at moving to python3 for the
>             framework. Due to the amount of work that's gone into piglit
>             over the
>             last few months and years the codebase is very modern, and the
>             transition is pretty straightforward, the only major change
>             is the
>             bytes/unicode/str conversion, which isn't that hard for us
>             since we've
>             already relied on the unicode class for a number of our string
>             interfaces.
>
>             So why python3, and why now?
>
>             The first argument for python3 is features. Feature work is
>             ongoing in
>             python3, while python2 is in long term maintenance mode, and
>             there are
>             features landing in python3 that will either allow us to
>             simplify the
>             piglit code, or to enable useful features with minimal
>             effort. Patch 2
>             provides a sane, portable timeout implementation for piglit to
>             demonstrate this.
>
>             The second argument I can offer is that linux distributions
>             are starting
>             to make the transition to python3 as their default python
>             version. Arch
>             and Fedora have already made this jump. For windows and OSX
>             the python
>             foundation provides pre compiled binaries.
>
>             But what about platforms that don't have python3.3+ available?
>
>             Well, the goal of recently landed changes to the generators
>             was to
>             hybridize the generators to work under either python2.7 or
>             python 3.3+,
>             with the same code base, and this series doesn't change
>             that, nor do I
>             have any plans to do so while there are still python2
>             consumers. The
>             goal being that tests (including generated tests) should be
>             backportable
>             to the python2 branch without any changes being necessary.
>
>             The idea then is that directly before landing this code a
>             python2 branch
>             of piglit would be forked and pushed to the upstream
>             repository.  Those
>             that need python2 would be able to use the python2 branch
>             for testing,
>             while upstream development would continue on master, which
>             used python3.
>
>             Any changes that were strictly necessary to keep the python2
>             branch
>             working with the python3 branch would be backported,
>             presumably by
>             myself, but the goal would be to minimize the number of
>             python changes
>             backported. The one drawback here would be that if the
>             summary format of
>             master (python3) changed it's unlikely that would be
>             backported to
>             python2. Master would still be able to understand python2
>             generated
>             results, but not vice versa.
>
>             So, to sum up:
>
>             1) branch a python2 branch, tests should be able to
>             cherry-picked/merged
>                  cleanly
>             2) python changes necessary to keep the python2 branch
>             running would be
>                  backported
>             3) When python2 is no longer necessary for anyone the branch
>             could be
>                  dropped.
>
>
>
>             _______________________________________________
>             Piglit mailing list
>             Piglit at lists.freedesktop.org
>             <mailto:Piglit at lists.freedesktop.org>
>             https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_piglit&d=AwIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=T0t4QG7chq2ZwJo6wilkFznRSFy-8uDKartPGbomVj8&m=MlidIFJmNNAteLKJpWaTUweYaX0WsNQnZPUH_cagzoQ&s=YOGp-y6wLqMoZ-jZGT7tJ6mGcO1mHBYKdl6wicO8aHs&e=
>
>
>