<html>

  <head>

    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">

  </head>

  <body bgcolor="#FFFFFF" text="#330033">

    <div class="moz-cite-prefix">On 10/28/2014 6:45 AM, Stephen J.

      Turnbull wrote:<br>

    </div>

    <blockquote cite="mid:87bnow48bk.fsf@uwakimon.sk.tsukuba.ac.jp"

      type="cite">

      <pre wrap="">because it's a fork, it's a different name</pre>

    </blockquote>

    I think this is an important point, and first brought to this

    discussion here. A fork is _not_ called Python, but something

    else... but if it is kept extremely compatible and up-to-date in the

    hopes of reintegration once it proves that it solves a problem, and

    that there are sufficient users, then such hopes seem reasonable.<br>

    <br>

    And targeting the new "future compatible" MSVCRT sounds like the

    right approach, although it won't solve today's problems today, but

    it may solve tomorrow's problems for a long time into the future...

    if the MinGW people can be convinced to support that new MSVCRT as

    well.<br>

    <br>

    In addition to all the components that are enabled by MinGW

    (particularly Fortran based extensions), one must remember that the

    current Windows Python also has extensions that interface to MSVC

    libraries that have never been ported to MinGW or Linux, and may

    never be. So an incompatible MinGW-built fork will lose some of

    those extensions... they may not be important to the folks that need

    MinGW, but that would be where & why the community would be

    split if the MinGW fork is not compatible with (some version of

    MSVC).  Of course, the current MSVC-based community is _already_

    having issues with incompatible versions of MSVC (not limiting that

    community to Python, but broader users of MSVC)... enough problems

    that even M$ has noticed that their incompatibilities are

    problematical, and are attempting to address... not just for Python,

    but for many other systems and libraries as well. So gathering

    around and supporting their attempts to achieve that, by using their

    new system early, when feedback can still have a chance of improving

    that new "future compatible" system, will benefit everyone... but

    that time is limited, from what Steve Dower reports of the

    schedule... hoping to be ready for Python 3.5.<br>

    <br>

    So now is an excellent time for this discussion to be happening, and

    if some work can be done to fork, pull the patches together, and

    tweak them to work with the new MSVC, in the Python 3.5 timeframe,

    you can have a phenomenal result, even if it is still a fork at that

    time.<br>

  </body>

</html>