On 23.06.2014 22:20, Donald Stufft wrote: > > On Jun 23, 2014, at 3:27 PM, M.-A. Lemburg <m...@egenix.com> wrote: > >> On 23.06.2014 18:09, Donald Stufft wrote: >>> >>> On Jun 23, 2014, at 2:09 AM, Martin v. Löwis <mar...@v.loewis.de> wrote: >>> >>>>> >>>>> * Should we make use of the potential breakage with 2.7.10 >>>>> to introduce a new Windows compiler version for Python 2.7 ? >>>> >>>> Assuming it is a good idea to continue producing Windows binaries >>>> for 2.7, I think it would be a bad idea to switch compilers. It will >>>> cause severe breakage of 2.7 installations, much more problematic >>>> than switching to two-digit version numbers. >>> >>> I agree with this, we’ve just finally started getting things to the point >>> where >>> it makes a lot of sense for binary distributions for Windows. Breaking all >>> of them on 2.7 would be very bad. > > Err, sorry that “We” was with my pip hat on. > >> >> Not sure what you mean. We've had binary wininst distributions >> for Windows for more than a decade, and egg and msi distributions >> for 8 years :-) > > Nonetheless, changing the compiler will not only break pip, but every > automated installer tool (easy_install, buildout) that i’m aware of. The > blow back for binary installation is going to be huge I think. > >> But without access to the VS 2008 compiler that is needed to >> compile those extensions, it will become increasingly difficult >> for package authors to provide such binary packages, so we have to >> ask ourselves: >> >> What's worse: breaking old Windows binaries for Python 2.7 >> or not having updated and new Windows binaries for Python 2.7 >> at all in a few years ? > > At the risk of getting Guido to post his slide again, I still think the > solution to the old compiler is to just roll a 2.8 with minimal changes. > It could even be a good place to move to the ssl backport changes > too since they were the riskier set of changes in PEP466. > > But either way, if a compiler does change in a 2.7 release we’ll need > to update a lot of tooling to cope with that, so any plan to do that should > include that and a timeline for adoption of that.
Sure, and we'd need to hash out possible solutions to minimize breakage, but first we'll have to see whether we want to consider this step or not. BTW: It's strange that I'm arguing for breaking things. I'm usually on the other side of such arguments :-) -- 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
