Python 3 and dotest

Subprojects LLDB
1

Moving this to the public list because it seems useful to see what other members of the community have to say as well.

It’s worth also pointing out that if we go the route of supporting both then everyone running the test suite will need to test their changes with both Python 2 and Python 3 anyway. For testing LLDB on different OSes we don’t really require this because not everyone has access to different hardware so we can’t mandate that they test their patches on every supported hardware configuration. But realistically speaking, everyone has access to Python 2.x and Python 3.x, so the burden should be on the person submitting patches to ensure that it runs on both.

Currently LLDB won’t compile when using Python 3 headers. I’ve fixed most of the issues, but there are two remaining. First is that FILE* APIs have been removed in Python 3, and second is that some of the SWIG files use functions like PyString_FromStringAndSize which is also removed in Python 3). Once I fix those and get those committed, you should be able to test on OSX and let me know what issues you run into.

2

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. 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 :slight_smile:

Anyway. Questions, comments, concerns feel free to respond and I’ll answer as best I can.

3

Moving this to the public list because it seems useful to see what other
members of the community have to say as well.

It's worth also pointing out that if we go the route of supporting both
then everyone running the test suite will need to test their changes with
both Python 2 and Python 3 anyway. For testing LLDB on different OSes we
don't really require this because not everyone has access to different
hardware so we can't mandate that they test their patches on every
supported hardware configuration. But realistically speaking, everyone has
access to Python 2.x and Python 3.x, so the burden should be on the person
submitting patches to ensure that it runs on both.

Is installing python 3 not as simple as just running a package manager
and selecting python 3? I didn't think anyone would need to be building
their own, but I don't know how it works in the OSX world.

I may fiddle with this on my off time just to see. OS X has some
pathing mechanisms (like user-directory Library, plain Library, and system
Library directory, I think they may call them domains) that stack. So if
something (like a python) installs a python framework in /Library, it can
hide /System/Library. Same with $HOME/Library vs. /Library and
/System/Library, IIRC. (Greg can correct me or I'll double check later).
So it is quite possible that installing a new python just essentially hides
the other one.

I kinda need to see what happens though to know the real point of
conflict.

Currently LLDB won't compile when using Python 3 headers. I've fixed most
of the issues, but there are two remaining. First is that FILE* APIs have
been removed in Python 3, and second is that some of the SWIG files use
functions like PyString_FromStringAndSize which is also removed in Python
3). Once I fix those and get those committed, you should be able to test
on OSX and let me know what issues you run into.

Great, looking forward to something to test!

4

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 :wink: )

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 :slight_smile:

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.

5

I actually disagree with this. Having Python 3 support in LLDB is a big win for the entire project. We all know Python 2.x is effectively dead, and the only reason anyone is still using it is for legacy support. This means that we are hindering the adoption of LLDB for anyone who doesn’t have a large legacy codebase to maintain. Which, for all practical purposes, means anyone starting a new project and considering using LLDB. That’s a huge negative from an open source perspective IMO.

But that’s just a lower bound. There are other people who are ready and willing to move to Python 3, but can’t because certain tools and libraries require them to use Python 2.x. Unfortunately, LLDB is one of those tools. When changes started going into lit on the LLVM side to make it Python 3 compatible, more than one person spoke up to say that they were pleased they could finally remove Python 2 from their systems. We’re also hindering those people from making contributions from LLDB.

Python 3 is the future, Python 2 is the past, so supporting it is a good long term strategy. The only reason Windows should be part of the discussion at all is because it’s the catalyst that makes me want to do the work now, instead of someone else doing the work later.

Believe it or not, there are also benefits for LLDB developers not on Windows, even if they are stuck on 2.7. By moving a newer version of the compiler, we get almost 100% C++11 and C99 conformance. This opens the door for LLDB to use a lot of new language features that people have been either intentionally holding back on or forced to remove because of this one compiler. Off the top of my head, a wildly incomplete list is: constexpr, shared_mutex, complete implementation of C++ standard library, rvalue references, initializer lists, thread_local, thread-safe function local statics, compiler-agnostic attribute syntax, and more. Everyone benefits from that, ironically, by supporting Python 3

TBH I can’t think of a reasonable alternative. There’s going to have to be a buildbot testing LLDB against Python 3, and that buildbot has to stay green, like all other buildbots. So any policies which apply normally to buildbots should apply to this one. We do have a special exception in LLDB specifically as it relates to OS specific differences (for example someone Linux breaks the Windows build and doesn’t know how to fix it), but that case is different for two reasons.

First, not everyone has access to or is an expert on every piece of hardware supported by LLDB, so it’s impossible to expect they would be able to fix every change.

Second, when it is not obvious from the buildbot logs what the problem is on a specific platform, a test can simply be xfailed or skipped to give the platform owner a chance to look into the cause of the failure.

Neither of these holds if we’re talking about the choice of scripting environment. For the first point, it is reasonable to expect that someone can install Python 3 on their machine. This is of course contingent on your findings about what difficulties arise with side-by-side installs on MacOSX, but at the same time OSX is kind of a popular platform, and if there’s really a widespread problem, I have to imagine that the Python developers have thought of this and have a solution. Still though, I’ll reserve judgement until we know more. For the second point, if someone checks in something that prevents the test suite from even running in the first place, there’s nothing you can do to xfail it or skip it because it’s in infrastructure code. Even if it were in a test, not being able to write code that runs in Python 2 and Python 3 is not a reasonable excuse to xfail or skip a test IMO.

Maybe saying “the onus is on the developer to fix it” is too harsh, but in that case the only reasonable alternative I can think of is “the onus is on the developer to either fix it or revert it”. Again, this is just the normal overarching LLVM policy with no special exceptions applied.

As mentioned earlier, I agree this is a potential unknown. So we can reserve judgement on this until we know more.