On 17/07/15 14:24, Timothy Arceri wrote:
On Thu, 2015-07-16 at 15:53 -0700, Dylan Baker wrote:
On Thu, Jul 09, 2015 at 02:25:40PM -0700, Dylan Baker wrote:
This series ports the python framework to python 3. This is an updated
version of the previous incarnations of this series, rebased on master.
So what does python3 buy us?
First, it buys us new features, and new features in the future. Python
2.x is in maintenance mode, so no new features. Features that this
series takes advantage of:
- builtin xz support. Everyone gets xz, no modules required, no xz
binary required, it "just works"
- subprocess timeouts. Finally, a reliable, cross platform method for
allowing tests to time out
- 'raise from' gives better error reporting
- no argument super(), which is, admittedly probably not very
interesting to most people, but it's awesome to me.
I have an additional series that can land after these land that take
advantage of these features:
- a new spinner-less, lock-less Log class. With timeouts we don't need to
worry about tests running forever, they'll be killed automatically.
This allows us to simplify the Log class significantly, and since
it's now lock-less we don't spend time in lock contention.
But there are still users that don't have the option of python 3!
Here's my idea for handling this:
Before I push python3 to master, I'll create a new branch,
python2-master. The idea would be that any non framework change could be
cherry picked over to this branch as long as there are uses that need
it, and they will work. Obviously any framework changes that are needed
to make this work will get backported.
This is available at my github:
https://github.com/dcbaker/piglit submit/python3
bump
Has everyone agreed to branching off a python2 version of piglit?
Python3 will definitely bring challenges to us.
It's no problem for our personal development systems, but there are
several systems which still only have python 2.x -- (systems we want to
run or build piglit.)
I wonder it would be possible to keep piglit using either Python 2 and 3
for an transitory period (e.g, 3 months), that would allows us to
gradualy migrate things, as opposed to close shop for several days.
On the other hand, I know it's tricky to make code that runs both on 2
and 3. And we might get exposed to weird bugs either way. I know we'll
have to bite the bullet sooner or later.
So maybe the the Python 2 branch works -- I can get the existing systems
to build and run Python 2 branch. Then slowly start building and using
Python 3 based master branch.
For the record, IMHO, the decision of making Python 3 backwards
incompatible was a huge mistake. If they introduced/deprecated the
new/old semantics incrementally they would get to world to migrate much
faster. Instead they created this huge barrier, effectively keeping the
bulk of the world in Python 2 much longer.
Jose
_______________________________________________
Piglit mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/piglit
