[Python-Dev] Python 2.7 patch levels turning two digit (original) (raw)

Donald Stufft donald at stufft.io
Mon Jun 23 23:15:05 CEST 2014

On Jun 23, 2014, at 5:07 PM, M.-A. Lemburg <mal at egenix.com> wrote:

On 23.06.2014 22:20, Donald Stufft wrote:

On Jun 23, 2014, at 3:27 PM, M.-A. Lemburg <mal at egenix.com> wrote:

On 23.06.2014 18:09, Donald Stufft wrote:

On Jun 23, 2014, at 2:09 AM, Martin v. Löwis <martin at 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 (easyinstall, 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 :-)

Ok. I’m just making sure that any proposal to do this includes how it plans to work around/minimize that. I agree with Martin (I think) that trying to fix the entire ecosystem to cope with that change is going to be far more work than folks realize and that it needs to be an explicit part of the discussion when deciding how to solve the problem.

Normally when I see someone suggest that switching compilers in 2.7.x is likely to be less work than releasing a 2.8 It normally appears to me they haven’t looked at the impact on the packaging tooling.

-- 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/

Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://mail.python.org/pipermail/python-dev/attachments/20140623/b8709c16/attachment.sig>

More information about the Python-Dev mailing list