<div dir="ltr"><div dir="ltr">I agree with you for the most part, including that the code separation has the lowest impact.  But it's worth mentioning that here, <a href="https://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=Visual+Studio+2008&Filter=FilterNO&wa=wsignin1.0">EOL for VC++ 2008 is 2018</a>.  So while technically moving to 3.x is not anyone else's problem until 2020, the fact that it's going our problem 2 years earlier means we will have to do something about it by then.  And at that point, 3.5 is going to be the only option on the table.  We don't need to take action now, but we should start thinking about it.  <span style="line-height:1.5;font-size:13.1999998092651px">Luckily the part we care about isn't much.  there's 4 or 5 python scripts to port and maintain in compatibility mode.  And I suspect (hope) that by that time the people with the out of tree 2.7 code will be starting to do something about it.</span></div><div dir="ltr"><span style="line-height:1.5;font-size:13.1999998092651px"><br></span></div><div>In any case, I'm mostly taking issue with your statement that "<span style="font-size:13.1999998092651px;line-height:19.7999992370605px">Reducing the number of obscure ways that non-Windows developers can break the Windows build is good".  We shouldn't be thinking of Python 3.5 in this context as "the windows build".  It's probably going to be "the build" eventually.</span></div></div><br><div class="gmail_quote">On Wed, Feb 25, 2015 at 8:58 AM Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br><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 Wed, Feb 25, 2015 at 5:58 AM, Vince Harron <span dir="ltr"><<a href="mailto:vharron@google.com" target="_blank">vharron@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"><div>This seems like a lot of work to support Windows users who might want to use pre-compiled python modules.</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>To me, the primary benefit is that you can build LLDB with Python support without building Python from source. More onerous, once you build Python from source, you have to maintain two separate environments: your normal development environment with normal Python on PATH, and one with LLDB's version of Python on PATH and PYTHONPATH.</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>I think we should distribute a VS2015 based version of Python 2.7 binaries and call it a day.<br></div><div><br></div><div>We can worry about 2020 problems in 2020.  =)</div><div><br></div><div>Reasonable people may disagree.</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I disagree. I guess that makes me reasonable. ;)</div><div><br></div><div>The main thing for me is that once we put together a pre-built Python, the instructions to rebuild it will immediately rot. In a matter of months, some user will arrive needing LLDB and Python to be built with a different VS version, and I give it 50/50 odds that the instructions will work.</div><div><br></div><div>Personally, I think the lowest impact change for everyone not affected by this is to split the Python API code out into a shared library. LLDB has more Python source than C++ source interacting with Python. Maintaining Python source compat with 2.7 and 3.5 will be fragile and will require testing more configurations. Reducing the number of obscure ways that non-Windows developers can break the Windows build is good.</div></div></div></div>
</blockquote></div>