On 10.10.2014 11:26, Larry Hastings wrote:
>
> On 10/10/2014 08:07 AM, Paul Moore wrote:
>> On 10 October 2014 01:29, Victor Stinner <victor.stin...@gmail.com> wrote:
>>> 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.?
>> The key point for me is that any supported build on Windows supports
>> the exact same ABI.
>
> 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!)
>
> 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?")
>
>
> 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).
>
> 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.
I don't think this is special to the Windows platform. We already
do support quite a few compilers in CPython and for multiple
platforms, so keeping support for e.g. MinGW or adding Intel
C support wouldn't really make much difference in the overall
#ifdef picture ;-)
That said, We do need maintainers for this support, so if there
are no people willing to support these compilers in CPython,
we should use the external port hosting approach for these, IMO.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
