Hi, I asked one year ago if we should drop OS/2 support: Andrew MacIntyre, our OS/2 maintainer, answered: http://mail.python.org/pipermail/python-dev/2010-April/099477.html Extract: << The 3.x branch needs quite a bit of work on OS/2 to deal with Unicode, as OS/2 was one of the earlier OSes with full multiple language support and IBM developed a unique API. I'm still struggling to come to terms with this, partly because I myself don't "need" it. >> So one year later, Python 3 does still not support OS/2. -- About VMS: I don't know if anyone is using Python (2 or 3) on VMS, or if Python 3 does work on VMS. I bet that it does just not compile :-) I don't know anyone using VMS or OS/2. -- There are 39 #ifdef VMS and 52 #ifdef OS2. We can keep them and wait until someone work on these OSes to ensure that the test suite pass. But if nobody cares of these OSes and nobody wants to maintain them, it would be easier for the maintenance of the Python source code base to remove specific code. Well, not "remove" directly, but plan to remove it using the PEP 11 procedure (mark OS/2 and VMS as unsupported, and remove the code in Python 3.4). Victor
Victor Stinner wrote:
Hi,
I asked one year ago if we should drop OS/2 support: Andrew MacIntyre, our OS/2 maintainer, answered: http://mail.python.org/pipermail/python-dev/2010-April/099477.html
Extract: << The 3.x branch needs quite a bit of work on OS/2 to deal with Unicode, as OS/2 was one of the earlier OSes with full multiple language support and IBM developed a unique API. I'm still struggling to come to terms with this, partly because I myself don't "need" it. >>
So one year later, Python 3 does still not support OS/2.
--
About VMS: I don't know if anyone is using Python (2 or 3) on VMS, or if Python 3 does work on VMS. I bet that it does just not compile :-)
I don't know anyone using VMS or OS/2.
--
There are 39 #ifdef VMS and 52 #ifdef OS2. We can keep them and wait until someone work on these OSes to ensure that the test suite pass. But if nobody cares of these OSes and nobody wants to maintain them, it would be easier for the maintenance of the Python source code base to remove specific code.
Well, not "remove" directly, but plan to remove it using the PEP 11 procedure (mark OS/2 and VMS as unsupported, and remove the code in Python 3.4).
The Python core team is not really representative of the Python community users, so I think this needs a different approach: Instead of simply deprecating OSes without notice to the general Python community, how about doing a "call for support" for these OSes ? If that doesn't turn up maintainers, then we can take the PEP 11 route. FWIW: There's still a fan-base out there for OS/2 and its successor eComStation: http://en.wikipedia.org/wiki/EComStation http://www.ecomstation.com/ecomstation20.phtml http://www.warpstock.eu/ Same for VMS in form of OpenVMS: http://en.wikipedia.org/wiki/OpenVMS http://h71000.www7.hp.com/index.html?jumpid=/go/openvms http://www.vmspython.org/ -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 19 2011)
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/
On Apr 19, 2011, at 10:36 AM, M.-A. Lemburg wrote:
Victor Stinner wrote:
Hi,
I asked one year ago if we should drop OS/2 support: Andrew MacIntyre, our OS/2 maintainer, answered: http://mail.python.org/pipermail/python-dev/2010-April/099477.html
Extract: << The 3.x branch needs quite a bit of work on OS/2 to deal with Unicode, as OS/2 was one of the earlier OSes with full multiple language support and IBM developed a unique API. I'm still struggling to come to terms with this, partly because I myself don't "need" it. >>
So one year later, Python 3 does still not support OS/2.
--
About VMS: I don't know if anyone is using Python (2 or 3) on VMS, or if Python 3 does work on VMS. I bet that it does just not compile :-)
I don't know anyone using VMS or OS/2.
--
There are 39 #ifdef VMS and 52 #ifdef OS2. We can keep them and wait until someone work on these OSes to ensure that the test suite pass. But if nobody cares of these OSes and nobody wants to maintain them, it would be easier for the maintenance of the Python source code base to remove specific code.
Well, not "remove" directly, but plan to remove it using the PEP 11 procedure (mark OS/2 and VMS as unsupported, and remove the code in Python 3.4).
The Python core team is not really representative of the Python community users, so I think this needs a different approach:
Instead of simply deprecating OSes without notice to the general Python community, how about doing a "call for support" for these OSes ?
If that doesn't turn up maintainers, then we can take the PEP 11 route.
Victor, if you want to post the "call for support" to Python Insider, let me know off list and I will set you up with access. Doug
Doug Hellmann wrote:
On Apr 19, 2011, at 10:36 AM, M.-A. Lemburg wrote:
Victor Stinner wrote:
Hi,
I asked one year ago if we should drop OS/2 support: Andrew MacIntyre, our OS/2 maintainer, answered: http://mail.python.org/pipermail/python-dev/2010-April/099477.html
Extract: << The 3.x branch needs quite a bit of work on OS/2 to deal with Unicode, as OS/2 was one of the earlier OSes with full multiple language support and IBM developed a unique API. I'm still struggling to come to terms with this, partly because I myself don't "need" it. >>
So one year later, Python 3 does still not support OS/2.
--
About VMS: I don't know if anyone is using Python (2 or 3) on VMS, or if Python 3 does work on VMS. I bet that it does just not compile :-)
I don't know anyone using VMS or OS/2.
--
There are 39 #ifdef VMS and 52 #ifdef OS2. We can keep them and wait until someone work on these OSes to ensure that the test suite pass. But if nobody cares of these OSes and nobody wants to maintain them, it would be easier for the maintenance of the Python source code base to remove specific code.
Well, not "remove" directly, but plan to remove it using the PEP 11 procedure (mark OS/2 and VMS as unsupported, and remove the code in Python 3.4).
The Python core team is not really representative of the Python community users, so I think this needs a different approach:
Instead of simply deprecating OSes without notice to the general Python community, how about doing a "call for support" for these OSes ?
If that doesn't turn up maintainers, then we can take the PEP 11 route.
Victor, if you want to post the "call for support" to Python Insider, let me know off list and I will set you up with access.
I can help with that if you like. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 19 2011)
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/
Le mardi 19 avril 2011 à 15:20 -0400, Doug Hellmann a écrit :
The Python core team is not really representative of the Python community users, so I think this needs a different approach:
Instead of simply deprecating OSes without notice to the general Python community, how about doing a "call for support" for these OSes ?
If that doesn't turn up maintainers, then we can take the PEP 11 route.
Victor, if you want to post the "call for support" to Python Insider, let me know off list and I will set you up with access.
If we ask users if they want to keep OS/2 and VMS, I expect that at least someone would like to keep them. But it doesn't solve the maintenance problem: we need maintainers (developers), not users. If a "call for support" can help us to maintain these OSes, nice. But I don't want to touch these OSes (I want to do less work, not more work :-)), and so I don't want to write such call. If you feel concerned by this issue, contact Doug to write the call ;-) Victor
On Tue, 19 Apr 2011 15:20:13 -0400 Doug Hellmann <doug.hellmann@gmail.com> wrote:
Victor, if you want to post the "call for support" to Python Insider, let me know off list and I will set you up with access.
Doesn't it have more chances of succeeding if posted to comp.lang.python, simply? Regards Antoine.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19/04/11 22:48, Antoine Pitrou wrote:
On Tue, 19 Apr 2011 15:20:13 -0400 Doug Hellmann <doug.hellmann@gmail.com> wrote:
Victor, if you want to post the "call for support" to Python Insider, let me know off list and I will set you up with access.
Doesn't it have more chances of succeeding if posted to comp.lang.python, simply?
I think "Python Insider" point was to translate to general public relevant python-dev discussions. This is a perfect example. +1 to include deprecation warnings/errors in 3.3 and remove in 3.4, according to PEP11. A heads-up warning and request for help in "Python Insider" is the way to go, too. - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTbTk0Jlgi5GaxT1NAQJyGAP8CnKuJyOh0pidU/Y4xlE4oSqQzwbVIqYA +Pd95c+oWDf8cRGkc8U/4APHOruyX1YYUpQL9WTlf3NzyoBv0f7JvzQRgc9eKDaj IGU79VhDKEShTB49saPTsUCpIcaQ8bUTeAjXLv67ga44WQ0toghez7dWVJ8iWh6+ R+w/4tK6aRM= =MBBZ -----END PGP SIGNATURE-----
Well, not "remove" directly, but plan to remove it using the PEP 11 procedure (mark OS/2 and VMS as unsupported, and remove the code in Python 3.4).
I think the PEP 11 procedure is just right for this. It *is* a call for maintainers, so if any user is interested in ongoing support, they should step forward. Having then also blog posts about these pending deprecations sounds fine to me - also adding them to the 3.2.x release pages would be appropriate (IMO). It's important that we give users due notice, but lacking any actual contribution, we should also be able to remove the code eventually. So please go ahead and add them to PEP 11. Regards, Martin
Various people wrote:
So please go ahead and add them to PEP 11.
If you want to post the "call for support" to Python Insider, let me know off list and I will set you up with access.
Doesn't it have more chances of succeeding if posted to comp.lang.python, simply?
I say "all of the above". It could be good to find a OS/2 and OpenVMS developer mailing list as well, and post it there. -- Lennart Regebro, Colliberty: http://www.colliberty.com/ Telephone: +48 691 268 328
Le mardi 19 avril 2011 à 23:21 +0200, "Martin v. Löwis" a écrit :
Well, not "remove" directly, but plan to remove it using the PEP 11 procedure (mark OS/2 and VMS as unsupported, and remove the code in Python 3.4).
I think the PEP 11 procedure is just right for this. It *is* a call for maintainers, so if any user is interested in ongoing support, they should step forward.
Having then also blog posts about these pending deprecations sounds fine to me - also adding them to the 3.2.x release pages would be appropriate (IMO). It's important that we give users due notice, but lacking any actual contribution, we should also be able to remove the code eventually.
So please go ahead and add them to PEP 11.
Ok, I added OS/2 and VMS to the PEP 11. I also opened any issue to remember that I should do something to raise an error on build. Victor
Ok, I added OS/2 and VMS to the PEP 11. I also opened any issue to remember that I should do something to raise an error on build.
For OS/2, I propose to syntactically break the makefile; anybody trying to build it should then run into that, and a) can easily overcome the limitation (probably to then run into more severe problems), and b) consider taking over maintenance if they are interested For VMS, I *think* the build process is configure-based (but I may misremember); if so, adding an exit into configure.in would be appropriate. Else an #error in a central header file may do as well. Or perhaps we could always use the #error if we can trust that compilers will honor it. Regards, Martin
participants (7)
-
"Martin v. Löwis" -
Antoine Pitrou -
Doug Hellmann -
Jesus Cea -
Lennart Regebro -
M.-A. Lemburg -
Victor Stinner