zapped several unsupported bits - now would be a good time to test
(For those of you not on python-checkins...) I've removed a number of obsolete features as specified by PEP 11. In particular, this morning I removed support for --without-universal-newlines and transitional pthread variants dating from the 1997 time frame. SunOS 4 support is also gone. For full details see Misc/NEWS. I've been testing on Mac OS X, but am also testing on Solaris 8 and Mandrake 8.1. If you haven't cvs up'd and rebuilt recently (don't forget to make clean and execute ./configure on Unix-y platforms) please do so and run make test. Thx, Skip
Skip Montanaro wrote:
I've removed a number of obsolete features as specified by PEP 11.
Thanks for doing that. Any proposals as to what should systems should be ignored in Python 2.5? In particular, I'm still in search for the minimum AIX version that we should support. As for removing SunOS4 support: plat-sunos4 can then go, as well. Regards, Martin
Martin> Any proposals as to what should systems should be ignored in Martin> Python 2.5? None from me. Martin> As for removing SunOS4 support: plat-sunos4 can then go, as Martin> well. Good point. I'll cvs remove it during my next round of edits. While I have your attention, are you aware of any specific preprocessor macros keyed to linux1? I see the plat-linux1 directory which has to be removed, but don't see "linux1" in any of the source files. Skip
Skip Montanaro wrote:
While I have your attention, are you aware of any specific preprocessor macros keyed to linux1? I see the plat-linux1 directory which has to be removed, but don't see "linux1" in any of the source files.
Not that I know of. plat-linux? doesn't really fit with the other systems, as the major version of the kernel is much less relevant for applications on Linux than it is on other systems. On Linux, it matters much more whether you have libc 4, 5, or 6 (which, in principle, can be arbitrarily combined with Linux 0, 1, or 2). Regards, Martin
"Martin v. Löwis"
Skip Montanaro wrote:
While I have your attention, are you aware of any specific preprocessor macros keyed to linux1? I see the plat-linux1 directory which has to be removed, but don't see "linux1" in any of the source files.
Not that I know of. plat-linux? doesn't really fit with the other systems, as the major version of the kernel is much less relevant for applications on Linux than it is on other systems. On Linux, it matters much more whether you have libc 4, 5, or 6 (which, in principle, can be arbitrarily combined with Linux 0, 1, or 2).
There were a small bundle of bug reports from a guy with libc5 a week or so back, so there's at least some interest in that. OTOH, I don't feel like putting all that much effort into fixing the problems he reported (most of them were failry shallow, I think). Cheers, mwh -- Just point your web browser at http://www.python.org/search/ and look for "program", "doesn't", "work", or "my". Whenever you find someone else whose program didn't work, don't do what they did. Repeat as needed. -- Tim Peters, on python-help, 16 Jun 1998
Michael Hudson wrote:
There were a small bundle of bug reports from a guy with libc5 a week or so back, so there's at least some interest in that. OTOH, I don't feel like putting all that much effort into fixing the problems he reported (most of them were failry shallow, I think).
So would you propose to "unsupport" Linux with libc 5? By PEP 11 rules, this would become "unsupported" in Python 2.4, with the possibility of revival if a volunteer steps forward. Regards, Martin P.S. I don't like to call this "We deprecate libc5", because we are in no position to decide the future of libc5 (we are not maintaining it in the first place). Instead, we just stop supporting it.
"Martin v. Löwis"
Michael Hudson wrote:
There were a small bundle of bug reports from a guy with libc5 a week or so back, so there's at least some interest in that. OTOH, I don't feel like putting all that much effort into fixing the problems he reported (most of them were failry shallow, I think).
So would you propose to "unsupport" Linux with libc 5?
Yes, for what that's worth. I'm not aware of any code specifically in aid of libc5, though...
By PEP 11 rules, this would become "unsupported" in Python 2.4, with the possibility of revival if a volunteer steps forward.
... so basically this amounts to saying "if you have a problem with python on a libc5 system you'd better have a patch too". Cheers, mwh -- Famous remarks are very seldom quoted correctly. -- Simeon Strunsky
Michael Hudson wrote:
Yes, for what that's worth. I'm not aware of any code specifically in aid of libc5, though...
No. Instead, we would actively have to add some...
By PEP 11 rules, this would become "unsupported" in Python 2.4, with the possibility of revival if a volunteer steps forward.
... so basically this amounts to saying "if you have a problem with python on a libc5 system you'd better have a patch too".
and we would change configure to detect libc5 systems, and refuse to build on such systems (with an exit statement in configure). Users still wanting to build on libc5 could hack around this and remove the exit statement, or they would volunteer to take over Python-on-libc5 maintainership. Regards, Martin
Hello Martin, On Tue, Feb 10, 2004 at 08:10:29PM +0100, "Martin v. Löwis" wrote:
and we would change configure to detect libc5 systems, and refuse to build on such systems (with an exit statement in configure). Users still wanting to build on libc5 could hack around this and remove the exit statement, or they would volunteer to take over Python-on-libc5 maintainership.
This looks like an artificial additional burden for someone who is really trying to install a couple of things on an old machine (like I did recently) and who only cares about Python for setting up a couple of simple things. I can't think of anything in the source that would prevent Python from compiling and running smoothly on almost any version of libc -- maybe there is, but then issue a warning if you like but just let me compile the damn thing so that I can proceed to whatever else I was trying to compile Python for in the first place :-) (We both know pretty well how to compile Python, but replace "Python" with some "libstuff" you don't know and care about but which a program you want keep asking for, and remember all these long hours of fixing small details to get the damn dependencies compiling.) Armin
Armin Rigo wrote:
This looks like an artificial additional burden for someone who is really trying to install a couple of things on an old machine (like I did recently) and who only cares about Python for setting up a couple of simple things. I can't think of anything in the source that would prevent Python from compiling and running smoothly on almost any version of libc -- maybe there is, but then issue a warning if you like but just let me compile the damn thing so that I can proceed to whatever else I was trying to compile Python for in the first place :-)
So are you volunteering to deal with the libc5-related bug reports? Currently, it appears we have 881812, 880996; 463576 was closed as "won't fix". As you can see from these reports, Python won't even build on these systems. Regards, Martin
Hello Martin, On Wed, Feb 11, 2004 at 07:59:44AM +0100, "Martin v. Löwis" wrote:
So are you volunteering to deal with the libc5-related bug reports? Currently, it appears we have 881812, 880996; 463576 was closed as "won't fix". As you can see from these reports, Python won't even build on these systems.
Sorry, I was not aware of these. If it doesn't build then I agree that it should either complain at configure-time, or be fixed... Armin
participants (4)
-
"Martin v. Löwis" -
Armin Rigo -
Michael Hudson -
Skip Montanaro