<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <div class="moz-cite-prefix">On 10/10/2014 08:07 AM, Paul Moore
      wrote:<br>
    </div>
    <blockquote
cite="mid:CACac1F_m3_nNxRwy7G=VZThxtKJo5ySO-ZRKa_NuNwpYs98q0g@mail.gmail.com"
      type="cite">
      <pre wrap="">On 10 October 2014 01:29, Victor Stinner <a class="moz-txt-link-rfc2396E" href="mailto:victor.stinner@gmail.com"><victor.stinner@gmail.com></a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">What about the Python stable ABI? Would it be broken if we use a
different compiler?

What about third party Python extensions?

What about external dependencies like gzip, bz2, Tk, Tcl, OpenSSL, etc.?
</pre>
      </blockquote>
      <pre wrap="">
The key point for me is that any supported build on Windows supports
the exact same ABI.
</pre>
    </blockquote>
    <br>
    Just to make something clear that may not be clear to non-Windows
    developers: the C library is implicitly part of the ABI.  So unless
    these other compilers bend over backwards to generate code / have a
    C library that behaves *exactly* like MSVC, their ABI will be
    different, and therefore shared libraries compiled with one compiler
    won't work with the next.  Heck, even shared libraries compiled with
    one version of MSVC won't work with any other version!  (This is
    something apparently being fixed by MSVC 15; apparently they are
    designing the ABI for forwards compatibility.  Huzzah!)<br>
    <br>
    So if CPython officially said "we support MSVC and Compiler X", I
    worry that we'd have third-party modules compiled with either one or
    the other, leaving users unable to mix and match third-party
    extensions as they do today.  ("I want to use library X, which is
    only available compiled by MSVC.  I also want to use library Y,
    which is only available compiled by Compiler X.  What should I do?" 
    "... install Linux?")<br>
    <br>
    <br>
    Here's my perspective.  Having your code compilable by more
    compilers is good.  But a maze of #ifdefs is bad.  We still have
    #ifdef's for Borland C--I'd be very surprised if anyone was
    compiling Python 3 with Borland C.  IMO the benefit from supporting
    other compilers on Windows is negligible, but the costs in
    maintaining these other compilers is tangible.  Or, worse, we accept
    changes to support these other compilers, but the support is
    incomplete, or goes unmaintained and breaks (and nobody notices).<br>
    <br>
    So as a practical matter I think I'd prefer if we continued to only
    support MSVC.  In fact I'd prefer it if we removed support for other
    Windows compilers, instead asking those maintainers to publish their
    own patches / repos, in the way that Stackless does.<br>
    <br>
    <br>
    <i>/arry</i><br>
  </body>
</html>