[lldb-dev] Python 3 and dotest

Todd Fiala via lldb-dev lldb-dev at lists.llvm.org
Tue Oct 13 21:08:58 PDT 2015


On Tue, Oct 13, 2015 at 9:45 AM, Zachary Turner <zturner at google.com> wrote:

> On Mon, Oct 12, 2015 at 7:31 PM Zachary Turner <zturner at google.com> wrote:
>
>> Moving this to the public list because it seems useful to see what other
>> members of the community have to say as well.
>>
>
> BTW , I realized I didn't give any context here and it's hard to follow a
> long quote thread.  Mostly this is just to give a heads up that support for
> Python 3 in LLDB is -- at a minimum -- coming, so I want to find out who
> (if anyone) is interested in this and how people plan to use it (or not use
> it).
>
> I'm sure the first question is probably "Why are you doing this?".  The
> short version is that it's quite literally the only path forward on
> Windows.  There is no way to transition to the next version of the compiler
> without moving to Python 3.5 or greater.  If you want the long version, let
> me know.
>
> The biggest challenge (which is what most of the quote thread is about) is
> going to be having dotest support both Python 2 and Python 3
> simultaneously.  LLDB supporting both at the native level shouldn't be a
> problem, it's mostly about writing Python code inside of dotest that works
> in both 2 and 3.
>
> This will be the first time I've tried porting a large Python codebase to
> Python 3, so I'm open for suggestions on how to minimize the impact of
> this.  Currently I'm of the mind that the onus should be on the person
> checking in a test (or a change to the test suite) to make sure it works in
> both versions of Python.
>

I'd probably throw out here that as a change is being introduced for the
benefit primarily of getting things running on the Windows side, I'm not
sure it's a great idea to put the onus on everyone making sure they run in
both places, at least up front.  (Particularly if we find that, say, the
system python co-existing with another python causes trouble on some
systems).  I think we want to make sure it is realistic for people to be
able to test on two pythons without undue difficulty on that front.  This
one we can probably figure out over time, though, as I'm not expecting
everyone will rewrite existing tests in python 2/3 incompatible ways for
the fun of it.  (Of course, if this makes people more interested in writing
more tests, than that's great, too ;-) )


> We'll eventually have a build bot running each version, so you should know
> when it breaks the other version (assuming you don't test the other version
> beforehand, which you should).
>
> I expect this is going to be unpleasant at best, so if anyone has any
> suggestions, I'm all ears.  The quote thread -- if you happened to read the
> whole thing -- was about an idea to have dotest only support python 3.
> Again, LLDB itself would continue to support python 2.  Just that it would
> require Python 3 to run the test suite.  I imagine there's only ~20 people
> anywhere running the test suite, and a couple of build bots, so this seems
> like a reasonable option to me, but obviously I don't have everyone else's
> perspective :)
>
> Anyway.  Questions, comments, concerns feel free to respond and I'll
> answer as best I can.
>

One area I'm at least a little interested in (previously mentioned) is
improving the test runner with some of the newer library support in the 3.x
releases that might allow for better subprocess handling if the test runner
is run under python 3.x.  I wouldn't go so far as to want to mandate python
3.x on the test runners for it (as would be very difficult to do over here
where we can only depend on the system python), but I would be interested
in adding a 3.x-only route (chosen on python 3.x) when it's available.
This is more about the test runner than the tests themselves.

-- 
-Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20151013/48d4000d/attachment-0001.html>


More information about the lldb-dev mailing list