Unittests for subprocess module has weird comment: We cannot use os.path.realpath to canonicalize the path, since it doesn't expand Tru64 {memb} strings. See bug 1063571. http://hg.python.org/cpython/file/82ae284cd5f1/Lib/test/test_subprocess.py#l... is link to comment, http://bugs.python.org/issue1063571 — issue in bugtracker.
Is it still up to date? Bug has been created in 2004. I don't see Tru64 in list of available buildbots.
Do we need to care about this platform? And how to make sure what existing code works fine for that? Or maybe we can drop support for Tru64 as well as we already does it for, say, VMS?
On Tue, Sep 4, 2012 at 2:24 AM, Andrew Svetlov andrew.svetlov@gmail.com wrote:
Unittests for subprocess module has weird comment: We cannot use os.path.realpath to canonicalize the path, since it doesn't expand Tru64 {memb} strings. See bug 1063571. http://hg.python.org/cpython/file/82ae284cd5f1/Lib/test/test_subprocess.py#l... is link to comment, http://bugs.python.org/issue1063571 — issue in bugtracker.
And to expand on Andrew's comments, issue #15533 is the current issue that this pertains to--
http://bugs.python.org/issue15533
--Chris
2012/9/4 Andrew Svetlov andrew.svetlov@gmail.com:
I don't see Tru64 in list of available buildbots.
Nope, there is no Tru64 buildbot.
Do we need to care about this platform? And how to make sure what existing code works fine for that?
I don't know this OS. According to Wikipedia, it's a closed source OS which only runs on DEC Alpha CPU. It doesn't look to be maintained: only bugs are fixed since 2010.
Or maybe we can drop support for Tru64 as well as we already does it for, say, VMS?
See the PEP 11 for unsupported platforms. http://www.python.org/dev/peps/pep-0011/#no-longer-supported-platforms
"Name: VMS Unsupported in: Python 3.3 Code removed in: Python 3.4"
Victor
On Tue, Sep 4, 2012 at 5:02 AM, Victor Stinner victor.stinner@gmail.com wrote:
Or maybe we can drop support for Tru64 as well as we already does it for, say, VMS?
See the PEP 11 for unsupported platforms. http://www.python.org/dev/peps/pep-0011/#no-longer-supported-platforms
"Name: VMS Unsupported in: Python 3.3 Code removed in: Python 3.4"
And for Python 2.7 when adding new tests, does this mean we should write those tests in a way that attempts to have them pass on Tru64 (e.g. by following the pattern of another test), or should we not worry about it?
--Chris
Zitat von Chris Jerdonek chris.jerdonek@gmail.com:
And for Python 2.7 when adding new tests
Hmm. Adding new tests to 2.7 is a questionable activity in the first place - it should be done very carefully.
does this mean we should write those tests in a way that attempts to have them pass on Tru64 (e.g. by following the pattern of another test), or should we not worry about it?
2.7 should absolutely be able to support Tru64 (even though it currently may not - that would be a bug). Any potential contributor to fix Tru64 support should find it "easy" to add fixes.
So being cautious and following existing code sounds like a good idea. The world wouldn't end if the test broke on Tru64, though.
Regards, Martin
On Wed, Sep 5, 2012 at 1:15 AM, martin@v.loewis.de wrote:
2.7 should absolutely be able to support Tru64 (even though it currently may not - that would be a bug). Any potential contributor to fix Tru64 support should find it "easy" to add fixes.
So being cautious and following existing code sounds like a good idea. The world wouldn't end if the test broke on Tru64, though.
That's ok. Chris Jerdonek is working on tuning docs for subprocess. He wrote tests to make sure him changes are correct. We can update documentation only for 2.7.
On 09/04/2012 03:15 PM, martin@v.loewis.de wrote:
The world wouldn't end if the test broke on Tru64, though.
FWIW, HP drops support for Tru64 at the end of this year:
http://h30097.www3.hp.com/tru64roadmap.pdf
Of course, this doesn't directly imply Python should stop supporting it--IIRC Python's OS/2 support outlasted IBM's support by many years.
//arry/
On Wed, 05 Sep 2012 15:26:03 -0700 Larry Hastings larry@hastings.org wrote:
On 09/04/2012 03:15 PM, martin@v.loewis.de wrote:
The world wouldn't end if the test broke on Tru64, though.
FWIW, HP drops support for Tru64 at the end of this year:
http://h30097.www3.hp.com/tru64roadmap.pdfOf course, this doesn't directly imply Python should stop supporting it--IIRC Python's OS/2 support outlasted IBM's support by many years.
But Python for OS/2 had a dedicated maintainer.
Regards
Antoine.
Zitat von Larry Hastings larry@hastings.org:
On 09/04/2012 03:15 PM, martin@v.loewis.de wrote:
The world wouldn't end if the test broke on Tru64, though.
FWIW, HP drops support for Tru64 at the end of this year:
http://h30097.www3.hp.com/tru64roadmap.pdf
Of course, this doesn't directly imply Python should stop supporting it--IIRC Python's OS/2 support outlasted IBM's support by many years.
It's perfectly fine (IMO) to drop support for Tru64. The main point of PEP 11 is that this shouldn't be done ad-hoc, but by giving users advance notice. So dropping support between bug fix releases is not ok (but unknowingly breaking test cases for some platform where we don't have a buildbot is ok, of course - whether the platform is little used or not).
It's unfortunate that the presumed removal of Tru64 support in 3.0 didn't get recorded in PEP 11 (which may well be my fault as well); it's also unfortunate that it wasn't carried out completely, so that it's now not clear whether it was carried out at all. If 3.0 wouldn't have worked at all on Tru64 already, removing the remains would be a bug fix. If the removal was only documented but not implemented, support wasn't actually removed, so users may not have received the advance warning that configure should have spit out, in which case removal in 3.4 may appear ad-hoc to them.
In any case, it appears that nobody ever announced removal of Tru64 support for 2.x, which means that it continues to be supported - except that it may not actually work. But if so, we should accept bug fixes that claim to restore support.
Regards, Martin
On Tue, 4 Sep 2012 12:24:10 +0300 Andrew Svetlov andrew.svetlov@gmail.com wrote:
Unittests for subprocess module has weird comment: We cannot use os.path.realpath to canonicalize the path, since it doesn't expand Tru64 {memb} strings. See bug 1063571. http://hg.python.org/cpython/file/82ae284cd5f1/Lib/test/test_subprocess.py#l... is link to comment, http://bugs.python.org/issue1063571 — issue in bugtracker.
Is it still up to date? Bug has been created in 2004. I don't see Tru64 in list of available buildbots.
Do we need to care about this platform?
I don't think so. If some hypothetical Tru64 user cares, they can probably open a bug on the tracker.
Regards
Antoine.
On Tue, Sep 4, 2012 at 3:11 PM, Antoine Pitrou solipsis@pitrou.net wrote:
I don't think so. If some hypothetical Tru64 user cares, they can probably open a bug on the tracker.
Thanks.
Aha, ./Doc/whatsnew/3.0.rst declares dropping support for Tru64. Several files in repo mention it, though.
On Tue, Sep 4, 2012 at 3:19 PM, Andrew Svetlov andrew.svetlov@gmail.com wrote:
On Tue, Sep 4, 2012 at 3:11 PM, Antoine Pitrou solipsis@pitrou.net wrote:
I don't think so. If some hypothetical Tru64 user cares, they can probably open a bug on the tracker.
Thanks.
-- Thanks, Andrew Svetlov
Zitat von Terry Reedy tjreedy@udel.edu:
On 9/4/2012 9:00 AM, Andrew Svetlov wrote:
Aha, ./Doc/whatsnew/3.0.rst declares dropping support for Tru64. Several files in repo mention it, though.
That suggests that it should be added to PEP11. Martin is the PEP editor, so I guess it is his final decision.
I'd be curious if there is any public record on this removal. I'm not sure it actually happened; socketmodule.c still has
#if defined(__digital__) && defined(__unix__)
and configure.in still has two mentionings of Tru64. Also, cmathmodule.c still has support code for Tru64. So if support was removed at all, this wasn't done very carefully.
I'm fine with declaring that the removal was *announced* in 3.0, though, and actually performed in 3.4 (assuming this then actually happens, contributions are welcome).
Regards, Martin
On Tue, 04 Sep 2012 15:19:38 +0300, Andrew Svetlov andrew.svetlov@gmail.com wrote:
On Tue, Sep 4, 2012 at 3:11 PM, Antoine Pitrou solipsis@pitrou.net wrote:
I don't think so. If some hypothetical Tru64 user cares, they can probably open a bug on the tracker.
Thanks.
I used to work on Tru64 systems many years ago.
According to the pages on HP's site (http://h30097.www3.hp.com/) that Google found me (HP acquired the Alpha platform that Tru64 runs on, among other things), the Alpha itself was discontinued in 2007, and Tru64 has reached the end of "Mature Product Support with Sustaining Engineering" this year. From this point on it is just "Mature Product Support". Not sure exactly what that means, other than that Tru64 is definitely a dying platform.
--David
On Tue, Sep 04, 2012 at 02:24:10AM -0700, Andrew Svetlov wrote:
Is it still up to date? Bug has been created in 2004. I don't see Tru64 in list of available buildbots.
Do we need to care about this platform? And how to make sure what existing code works fine for that?
Or maybe we can drop support for Tru64 as well as we already does it for, say, VMS?
The ES40 I've got sitting in the corner waiting for a rainy day just died a little inside. (HP was also kind enough to donate unlimited Tru64 media/licenses a while back.) As for whether or not it should be a platform CPython cares about -- I'd argue it falls in the same boat as IRIX/MIPS: not so much. I'll be damned if Snakebite doesn't have Tru64/Alpha representation though :-)
OpenVMS is an interesting one though; it's still actively supported by HP on Itanium. I've got an Itanium earmarked marked for OpenVMS "for an even rainier day", but I wouldn't know OpenVMS is it smacked me in the head, so, not a high priority at the moment.
Trent.
Zitat von Trent Nelson trent@snakebite.org:
OpenVMS is an interesting one though; it's still actively supported by HP on Itanium. I've got an Itanium earmarked marked for OpenVMS "for an even rainier day", but I wouldn't know OpenVMS is it smacked me in the head, so, not a high priority at the moment.
We had an offer several months ago that patches to 3.3 would "likely" (IIRC) be contributed; this didn't materialize. So the PEP 11 removal of VMS support stands.
Regards, Martin
On 9/4/2012 5:24 AM, Andrew Svetlov wrote:
Unittests for subprocess module has weird comment: We cannot use os.path.realpath to canonicalize the path, since it doesn't expand Tru64 {memb} strings. See bug 1063571. http://hg.python.org/cpython/file/82ae284cd5f1/Lib/test/test_subprocess.py#l... is link to comment, http://bugs.python.org/issue1063571 — issue in bugtracker.
It seems to me that the resolution of that issue should have been to either make os.path.realpath work correctly on Tru64, so we can freely use it as documented. If that is not possible, the doc should say not available ... and the test skipped on Tru64. I realizes that skipping tests is perhaps easier now.
Zitat von Andrew Svetlov andrew.svetlov@gmail.com:
http://hg.python.org/cpython/file/82ae284cd5f1/Lib/test/test_subprocess.py#l... is link to comment, http://bugs.python.org/issue1063571 — issue in bugtracker.
Is it still up to date? Bug has been created in 2004. I don't see Tru64 in list of available buildbots.
Do we need to care about this platform?
That there is no buildbot is no indication. Instead, PEP 11 keeps track of platforms we don't want to support anymore; Tru64 isn't listed. For a long time, there had been proponents of Tru64 on this list which would object to removing support.
And how to make sure what existing code works fine for that?
We don't need to. It's perfectly fine if it breaks - we just can't actively remove code to support the platform.
OTOH, if Tru64 was proposed for "unsupport", we could disable support in 3.4, and remove support in 3.5. Perhaps that would be a good thing to do.
Or maybe we can drop support for Tru64 as well as we already does it for, say, VMS?
No, see PEP 11.
Regards, Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/09/12 00:11, martin@v.loewis.de wrote:
We don't need to. It's perfectly fine if it breaks - we just can't actively remove code to support the platform.
OTOH, if Tru64 was proposed for "unsupport", we could disable support in 3.4, and remove support in 3.5. Perhaps that would be a good thing to do.
In some other email in this thread you said that support was (partially) deprecated in 3.0, so removal in 3.4 would be justified.
In any case, somebody have to take a decision and update PEP-11.
- -- Jesús Cea Avión _/_/ _/_/_/ _/_/_/ 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
On Tue, Sep 04, 2012 at 02:24:10AM -0700, Andrew Svetlov wrote:
Is it still up to date? Bug has been created in 2004. I don't see Tru64 in list of available buildbots.
Do we need to care about this platform? And how to make sure what existing code works fine for that?
There's a Snakebite Tru64 box now, accessible via t5 from the sb menu. 2.7 compiles fine but hangs on some of the subprocess epipe tests, I'll set up a slave once I've addressed that.
One nice thing about Tru64 is that everything is implicitly 64-bit. There's no notion of dual 32-bit/64-bit libs/binaries or a 32-bit memory architecture. The 64-bit `python` on Tru64 is in a much better state than said binaries on AIX and HP-UX (which still need a lot of work).
As for VMS/OpenVMS, still working with HP to get access to media.
Trent.
participants (10)
-
Andrew Svetlov -
Antoine Pitrou -
Chris Jerdonek -
Jesus Cea -
Larry Hastings -
martin＠v.loewis.de -
R. David Murray -
Terry Reedy -
Trent Nelson -
Victor Stinner