<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 12, 2015 at 7:31 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Moving this to the public list because it seems useful to see what other members of the community have to say as well.<br><br><div class="gmail_quote"><span class=""><div dir="ltr">On Mon, Oct 12, 2015 at 4:22 PM Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.  <div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 12, 2015 at 3:24 PM Todd Fiala <<a href="mailto:todd.fiala@gmail.com" target="_blank">todd.fiala@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 12, 2015 at 3:14 PM, Zachary Turner <span dir="ltr"><<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.</div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div><div><br></div><div>I kinda need to see what happens though to know the real point of conflict.</div></div></div></div></blockquote></div></blockquote><div><br></div></span><div>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.<br></div><span class=""><div><br></div></span></div></div></blockquote><div><br></div><div>Great, looking forward to something to test!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>I'm only really talking about requiring python 3 for running dotest, which is not something that many people do, so it doesn't seem like that big of a burden.</div><div><br></div><div>The thing I'm concerned about it is that it's going to be a bigger burden for everyone, including Apple, if we *don't* do this.  I mean time will tell, obviously, but I don't expect this to be painless.  And it's goign to be the type of pain that doesn't go away over time, either, it's going to reoccur every time someone checks something in to the test suite.  All that time is going to add up over the long run and be worse than taking the initial hit of installing python 3 on the internal build systems.</div><div><br></div><div>There's also the issue that Todd was saying he could make some improvements to the test suite if it could use Python 3, but I'll defer to him for that since I don't know the details.</div><div><div><div><div><br></div></div></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The async IO handling (via asyncore) would be easier to write in a platform-neutral way with Python 3.5.  (Might be Python 3.3 but I seem to recall they really went gung-ho on the Windows/POSIX parity side in 3.5).  That would benefit.  There are a few other minor places where we do things to avoid incompatibility with Windows, or do something slightly more awkward because we don't have a good answer on Windows.  (Depending on subprocess.Popen.communicate() is one example - that could be replaced with asyncore if we had Windows file handle support there).  Probably the bigger benefit is almost all new work and newer ideas are getting implemented in Python 3.x, where Python 2.x is just getting security fixes.  To the extent that we care about that for the test suite, that's what we're missing out on.</div><div><br></div><div>-Todd</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div class="gmail_quote"><div dir="ltr">On Mon, Oct 12, 2015 at 1:33 PM Greg Clayton <<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Oct 12, 2015, at 10:41 AM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
> Hi Greg,<br>
><br>
> I talked with Todd a little bit about this while you were on vacation, but now that you're back I want to ask you as well.<br>
><br>
> Is it possile to require Python 3 just for running the test suite?  You can see from my previous patch that gets `ScriptInterpreterPython` ready for Python 3 that I did it in a way such that LLDB will support both Python 2 and Python 3, so I don't intend to change that.  But probably sometime this week I'm going to start poking at dotest.  There's a lot of code in there, and I expect it's goign to be a challenge to support both Python 2 and Python 3.  Not only just in terms of writing the code in a way that the version specific differences are cleanly expressed, but also in terms of being able to actually maintain the code so that nobody breaks anyone else when they make changes to the test runner or add new tests.  I can already foresee that if both 2 and 3 are supported in dotest that will have multiple breakages a week on both sides of the fence and waste a lot of time for everyone.<br>
><br>
> Also, from what Todd told me in previous discussions, there are some features in Python 3 that he thinks would make the test suite faster and more robust (ask him for more details), but we can't really use them unless everyone is on board.<br>
><br>
> I know Apple has a lot of code internally that uses Python 2 and that isn't going to change any time soon, but I guess the question is whether that code is in the form of tests or depends on dotest in any way.  I suspect the answer is no, but I could be wrong.  If I'm right, then it seems like we could make everyone's life a lot easier by saying that if you're a developer of LLDB, you need to install Python 3.  If you're a user of LLDB's SB API for some purpose other than writing tests, you can use 2 or 3.<br>
><br>
> AFAICT, swig will generate bindings that are compatible with both 2 and 3, so no issues there either.<br>
><br>
> Thoughts?<br>
<br>
I believe the answer is as you suspect. Installing an extra python is a large undertaking as you already know and we constantly see people hosing up their system by installing an extra python. WWDC is full of people that have done this and they have problems and we usually say "sorry, you are on your own if you installed your own python". So I am not sure what people do to hose things up or if people select the wrong arguments when building/installing python, but it isn't going to be anything that anyone at Apple will spend any time on as we have our hands quite full and windows is the only thing that requires python 3 due to reasons you are all too familiar with. So I would rather MacOS stick with the installed and fully supported python if at all possible.<br>
<br>
Greg</blockquote></div></div></div></div></div></div>
</blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr">-Todd</div></div>
</div></div></blockquote></div></blockquote></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">-Todd</div></div>
</div></div>