Anaconda's compilers are for Linux (gcc 7.2) and Mac (llvm/clang 4.0.1) right now. We would like to have clang target all platforms, but that's a lot of development effort.
We are also exploring ways of keeping package ecosystems in line, so that building and managing a self-consistent set of python 2.7 packages with a new Visual Studio version or msys2 might be easier. No timeline to report, on that, though. Breaking with the python.org ABI is pretty painful. On Wed, Nov 8, 2017 at 4:17 PM, Bryan Van de ven <bry...@anaconda.com> wrote: > > > On Nov 8, 2017, at 10:50, Peter Cock <p.j.a.c...@googlemail.com> wrote: > > > > NumPy (and to a lesser extent SciPy) is in a tough position being at the > > bottom of many scientific Python programming stacks. Whenever you > > drop Python 2 support is going to upset someone. > > Existing versions of NumPy will still exist and continue to work with > Python 2.7. If users want to say with Python 2.7, that's fine, they will > just have to rely on those older/LTS versions. I personally would be happy > for projects at the bottom of stacks to take an activist stance and make > decisions to actively encourage movement to Python 3. > > > It is too ambitious to pledge to drop support for Python 2.7 no later > than > > 2020, coinciding with the Python development team’s timeline for dropping > > support for Python 2.7? > > Developing NumPy is hard, as it is. Everything that can be done to > simplify things for the current maintainers and help attract new > contributors should be done. It is not reasonable to ask a few (largely > volunteer) people to shoulder the burden and difficulties of supporting > Python 2.7 for several additional *years* of their life. > > I agree entirely with Nick Coghlan's comments from another discussion, and > think they apply equally well in this instance: > > """ > While it's entirely admirable that many upstream developers are generous > enough to help their end users work around this inertia, in the long run > doing so is detrimental for everyone concerned, as long term sustaining > engineering for old releases is genuinely demotivating for upstream > developers (it's a good job, but a lousy way to spend your free time) and > for end users, working around institutional inertia this way reduces the > pressure to actually get the situation addressed properly. > """ > > Thanks, > > Bryan > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion