Python 3.4 and Windows XP: just 45 days until EOL
Hi, how do you feel about dropping Windows XP support for Python 3.4? It would enable us to use some features that are only available on Windows Vista and newer, for example http://bugs.python.org/issue6926 and http://bugs.python.org/issue1763 . PEP 11 says: A new feature release X.Y.0 will support all Windows releases whose extended support phase is not yet expired. For Python 3.4 is going to be a very close call. According to PEP 429 3.4.0 final is scheduled for February 22, 2014. The extended support phase of Windows XP ends merely 45 days later on April 8, 2014. Do we really have to restrict ourselves to an API that is going to become deprecated 45 days after the estimated release of 3.4.0? Christian
On 07/11/2013 04:58 PM, Christian Heimes wrote:
how do you feel about dropping Windows XP support for Python 3.4? It would enable us to use some features that are only available on Windows Vista and newer, for example http://bugs.python.org/issue6926 and http://bugs.python.org/issue1763 .
PEP 11 says: A new feature release X.Y.0 will support all Windows releases whose extended support phase is not yet expired.
For Python 3.4 is going to be a very close call. According to PEP 429 3.4.0 final is scheduled for February 22, 2014. The extended support phase of Windows XP ends merely 45 days later on April 8, 2014. Do we really have to restrict ourselves to an API that is going to become deprecated 45 days after the estimated release of 3.4.0?
Just because Microsoft no longer supports it doesn't mean there aren't still a lot of machines using it. Of course, I suppose those folks can just stick with 3.3. ;) -- ~Ethan~
+1. And maybe amend PEP 11 to specify "whose extended support phase does not expire within 6 months of release"? (I picked 6 for no particular reason.) I don't see any good reason for Python to support an OS that Microsoft doesn't, but once 3.4.0 has been released with XP support it can't really be taken out for 3.4.1. Since 3.4.1 is almost certainly going to be after the end of extended support, better to drop it for .0 Steve
From: Christian Heimes Subject: [Python-Dev] Python 3.4 and Windows XP: just 45 days until EOL
Hi,
how do you feel about dropping Windows XP support for Python 3.4? It would enable us to use some features that are only available on Windows Vista and newer, for example http://bugs.python.org/issue6926 and http://bugs.python.org/issue1763 .
PEP 11 says: A new feature release X.Y.0 will support all Windows releases whose extended support phase is not yet expired.
For Python 3.4 is going to be a very close call. According to PEP 429 3.4.0 final is scheduled for February 22, 2014. The extended support phase of Windows XP ends merely 45 days later on April 8, 2014. Do we really have to restrict ourselves to an API that is going to become deprecated 45 days after the estimated release of 3.4.0?
Christian
Steve Dower writes:
I don't see any good reason for Python to support an OS that Microsoft doesn't,
How about the *users* of that OS? I don't see any good reason to take into account what Microsoft does or doesn't support. If that lack of support leads to Python users dropping XP like hot potatoes, that will be visible in itself. I doubt it will, though. EOL for XP has been coming a long long time, far longer than Microsoft anticipated ;-), yet usage persists (most small businesses I know in Japan are still using XP-based apps, small sample, I admit). If Python support for XP leads to significant pain for the majority of Python users, or the majority on Windows, that's a good reason to drop it, (which needs to be balanced against users who still need support). Regards,
"Stephen J. Turnbull" <stephen@xemacs.org> writes:
I don't see any good reason to take into account what Microsoft does or doesn't support.
It seems you're advocating a position quite ad odds with <URL:http://www.python.org/dev/peps/pep-0011/#id7>. Can you propose an amendment to PEP 11 that would remove that consideration? -- \ “If you do not trust the source do not use this program.” | `\ —Microsoft Vista security dialogue | _o__) | Ben Finney
Ben Finney writes:
"Stephen J. Turnbull" <stephen@xemacs.org> writes:
I don't see any good reason to take into account what Microsoft does or doesn't support.
It seems you're advocating a position quite ad odds with <URL:http://www.python.org/dev/peps/pep-0011/#id7>.
Not at all. The first thing that the PEP says about unsupporting code is: Unsupporting platforms If a certain platform that currently has special code in it is deemed to be without Python users, What a vendor supports is only a heuristic. Existence of users comes first. Note that the policy says that some Windows platforms *will* be supported. It doesn't say others will be unsupported (except implicitly: 3 years after the last version of Visual Studio capable of building releases for that platform goes out of extended support, the build infrastructure will be removed). I don't see a good reason to change the PEP.
On Fri, Jul 12, 2013 at 2:11 AM, Steve Dower <Steve.Dower@microsoft.com> wrote:
+1. And maybe amend PEP 11 to specify "whose extended support phase does not expire within 6 months of release"? (I picked 6 for no particular reason.)
Why have the specification in PEP 11 if we feel we can change the rules arbitrarily when we feel like it? //Lennart
On 12 July 2013 13:27, Lennart Regebro <regebro@gmail.com> wrote:
On Fri, Jul 12, 2013 at 2:11 AM, Steve Dower <Steve.Dower@microsoft.com> wrote:
+1. And maybe amend PEP 11 to specify "whose extended support phase does not expire within 6 months of release"? (I picked 6 for no particular reason.)
Why have the specification in PEP 11 if we feel we can change the rules arbitrarily when we feel like it?
Because process PEPs are documentation of community practice, not an inviolable constraint (e.g. PEP 1 has frequently lagged behind what we *actually* do, and only been updated once we noticed we had drifted away from the nominal procedures). In this case, the question of "What do we do when a Windows version goes EOL shortly after a Python release?" hasn't come up before, so PEP 11 has never had to take it into account. That doesn't mean we *should* change it, it just means the option is one we have available to us. Fixing issue 6926 only requires setting the minimum API version to Windows *XP*, so it isn't actually relevant to the question of whether or not to drop support for XP (only W2k, which I thought we already dropped, but we mustn't have bumped the minimum Windows API version at the time). Issue 1763 looks like it could be better solved through pywin32 than through standard library changes. It certainly doesn't appear to be worth the cost of dropping Windows XP support. Unless there are more compelling examples of APIs that we can't access through Windows XP compatible interfaces, -1 on the change for 3.4. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
I guess it has to be dropped at some stage, but with Windows XP it's a case of "XP is dead. Long live XP!" There are still an awful lot of XP boxes out there, and I'd kind hate to see support dropped completely. We still use it here at home. Wikipedia/Net Applications says that Windows XP has still has a full 37% of market share! (http://en.wikipedia.org/wiki/Usage_share_of_operating_systems ) What about just have these attributes/functions on OSes that support it, for example os.kill on Python 2.6 vs 2.7? -Ben On Fri, Jul 12, 2013 at 11:58 AM, Christian Heimes <christian@python.org>wrote:
Hi,
how do you feel about dropping Windows XP support for Python 3.4? It would enable us to use some features that are only available on Windows Vista and newer, for example http://bugs.python.org/issue6926 and http://bugs.python.org/issue1763 .
PEP 11 says: A new feature release X.Y.0 will support all Windows releases whose extended support phase is not yet expired.
For Python 3.4 is going to be a very close call. According to PEP 429 3.4.0 final is scheduled for February 22, 2014. The extended support phase of Windows XP ends merely 45 days later on April 8, 2014. Do we really have to restrict ourselves to an API that is going to become deprecated 45 days after the estimated release of 3.4.0?
Christian _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/benhoyt%40gmail.com
On Fri, 12 Jul 2013 13:49:54 +1200, Ben Hoyt <benhoyt@gmail.com> wrote:
I guess it has to be dropped at some stage, but with Windows XP it's a case of "XP is dead. Long live XP!" There are still an awful lot of XP boxes out there, and I'd kind hate to see support dropped completely. We still use it here at home.
Wikipedia/Net Applications says that Windows XP has still has a full 37% of market share! (http://en.wikipedia.org/wiki/Usage_share_of_operating_systems )
What about just have these attributes/functions on OSes that support it, for example os.kill on Python 2.6 vs 2.7?
I'm afraid it's not that simple. The issue (as I understand it from Crys) is that we compile using setting that prevent the advanced features being used, and that's really the only way to do it. That is, you can only get the advanced features by using certain settings, and if you use those, the compiled code won't run on XP. So it is not practical to decide only at runtime to support the advanced feature, meaning there would have to be a differently compiled version of Python specifically for Windows XP (and doubtless new XP-specific ifdefs *as well*), and I doubt the core team is going to go there. The older versions of Python won't be going away. Those can still be used on XP. Of course, they won't get bug fixes...just like XP itself. --David
Ah, yeah, that makes sense -- thanks for the further explanation. True about older versions of Python "not going away".
What about just have these attributes/functions on OSes that support it,
for example os.kill on Python 2.6 vs 2.7?
I'm afraid it's not that simple. The issue (as I understand it from Crys) is that we compile using setting that prevent the advanced features being used, and that's really the only way to do it. That is, you can only get the advanced features by using certain settings, and if you use those, the compiled code won't run on XP. So it is not practical to decide only at runtime to support the advanced feature, meaning there would have to be a differently compiled version of Python specifically for Windows XP (and doubtless new XP-specific ifdefs *as well*), and I doubt the core team is going to go there.
The older versions of Python won't be going away. Those can still be used on XP. Of course, they won't get bug fixes...just like XP itself.
On Thu, 11 Jul 2013 22:28:49 -0400 "R. David Murray" <rdmurray@bitdance.com> wrote:
On Fri, 12 Jul 2013 13:49:54 +1200, Ben Hoyt <benhoyt@gmail.com> wrote:
I guess it has to be dropped at some stage, but with Windows XP it's a case of "XP is dead. Long live XP!" There are still an awful lot of XP boxes out there, and I'd kind hate to see support dropped completely. We still use it here at home.
Wikipedia/Net Applications says that Windows XP has still has a full 37% of market share! (http://en.wikipedia.org/wiki/Usage_share_of_operating_systems )
What about just have these attributes/functions on OSes that support it, for example os.kill on Python 2.6 vs 2.7?
I'm afraid it's not that simple. The issue (as I understand it from Crys) is that we compile using setting that prevent the advanced features being used, and that's really the only way to do it. That is, you can only get the advanced features by using certain settings, and if you use those, the compiled code won't run on XP. So it is not practical to decide only at runtime to support the advanced feature,
It's not practical, but we already do it. See check_GetFinalPathNameByHandle in Modules/posixmodule.c. Regards Antoine.
Am 12.07.2013 03:49, schrieb Ben Hoyt:
I guess it has to be dropped at some stage, but with Windows XP it's a case of "XP is dead. Long live XP!" There are still an awful lot of XP boxes out there, and I'd kind hate to see support dropped completely. We still use it here at home.
Wikipedia/Net Applications says that Windows XP has still has a full 37% of market share! (http://en.wikipedia.org/wiki/Usage_share_of_operating_systems)
I'm not planing to shut Windows XP out from Python completely. Users of Python can still use Python 3.3 or 2.7. Python 3.3 will get a final bug fix release after the release of Python 3.4.0 and security fixes until 2017. Windows XP is really, *really* old. It has been released almost 12 years ago. Linux kernel 2.4.0 was released about the same time. Its mainstream support has ended 4 years ago. Do people really expect that they can run the latest version of a program on a decommissioned operating system? Christian
You underestimate the reach of XP. For older or underpowered hardware outside the developed world it is still the de facto choice. And it definitely is the best version of Windows ever. None of the Win98 crap and none of the Vista junk. Telling people to go install Ubuntu is not really fair if others around them don't or if they need certain software. --Guido van Rossum (sent from Android phone) On Jul 12, 2013 4:34 AM, "Christian Heimes" <christian@python.org> wrote:
Am 12.07.2013 03:49, schrieb Ben Hoyt:
I guess it has to be dropped at some stage, but with Windows XP it's a case of "XP is dead. Long live XP!" There are still an awful lot of XP boxes out there, and I'd kind hate to see support dropped completely. We still use it here at home.
Wikipedia/Net Applications says that Windows XP has still has a full 37% of market share! (http://en.wikipedia.org/wiki/Usage_share_of_operating_systems)
I'm not planing to shut Windows XP out from Python completely. Users of Python can still use Python 3.3 or 2.7. Python 3.3 will get a final bug fix release after the release of Python 3.4.0 and security fixes until 2017.
Windows XP is really, *really* old. It has been released almost 12 years ago. Linux kernel 2.4.0 was released about the same time. Its mainstream support has ended 4 years ago. Do people really expect that they can run the latest version of a program on a decommissioned operating system?
Christian _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
On 7/12/2013 8:50 AM, Guido van Rossum wrote:
You underestimate the reach of XP. For older or underpowered hardware outside the developed world it is still the de facto choice. And it definitely is the best version of Windows ever. None of the Win98 crap and none of the Vista junk.
Telling people to go install Ubuntu is not really fair if others around them don't or if they need certain software.
--Guido van Rossum (sent from Android phone)
Well said. +100
On Thu, Jul 11, 2013 at 6:58 PM, Christian Heimes <christian@python.org> wrote:
For Python 3.4 is going to be a very close call. According to PEP 429 3.4.0 final is scheduled for February 22, 2014. The extended support phase of Windows XP ends merely 45 days later on April 8, 2014. Do we really have to restrict ourselves to an API that is going to become deprecated 45 days after the estimated release of 3.4.0?
If your motivation is to ease the use of APIs only available on Windows Vista and later, you've got another year to wait: Windows Server 2003 R2 extended support lasts through until July 2015. http://support.microsoft.com/lifecycle/search/default.aspx?alpha=Windows+Ser... Michael
Am 12.07.13 01:58, schrieb Christian Heimes:
For Python 3.4 is going to be a very close call. According to PEP 429 3.4.0 final is scheduled for February 22, 2014. The extended support phase of Windows XP ends merely 45 days later on April 8, 2014. Do we really have to restrict ourselves to an API that is going to become deprecated 45 days after the estimated release of 3.4.0?
I suggest to stick to the words of the PEP, which means that XP needs to be supported in 3.4. For 3.5, according to the PEP, XP support *may* be dropped - it doesn't have to be dropped. Notice that you cannot yet know for sure that XP support ends on April 8 - even though it's likely that it will. Microsoft might (and, in the past did) extend an earlier end-of-support date (although they probably won't do so for XP anymore). The most significant reason for dropping XP support in Python will likely be the desire to switch to new VC versions: Newer CRTs don't support XP anymore. Regards, Martin
On 12/07/2013 00:58, Christian Heimes wrote:
Hi,
how do you feel about dropping Windows XP support for Python 3.4? It would enable us to use some features that are only available on Windows Vista and newer, for example http://bugs.python.org/issue6926 and http://bugs.python.org/issue1763 .
PEP 11 says: A new feature release X.Y.0 will support all Windows releases whose extended support phase is not yet expired.
For Python 3.4 is going to be a very close call. According to PEP 429 3.4.0 final is scheduled for February 22, 2014. The extended support phase of Windows XP ends merely 45 days later on April 8, 2014. Do we really have to restrict ourselves to an API that is going to become deprecated 45 days after the estimated release of 3.4.0?
I would like to continue support for WinXP. It's still widely, widely used -- MS support notwithstanding. The situation might have been different if Vista had been a viable corporate desktop, but I suspect that many outfits have waited (as we did here) until Win7 before moving forward. Win7 is now our default desktop for new machines, but we're still running a slight majority of WinXP machines. TJG
participants (15)
-
"Martin v. Löwis" -
Antoine Pitrou -
Ben Finney -
Ben Hoyt -
Christian Heimes -
Ethan Furman -
Glenn Linderman -
Guido van Rossum -
Lennart Regebro -
Michael Urman -
Nick Coghlan -
R. David Murray -
Stephen J. Turnbull -
Steve Dower -
Tim Golden