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? -- Thanks, Andrew Svetlov
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. -- Thanks, Andrew Svetlov
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.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.
But Python for OS/2 had a dedicated maintainer. Regards Antoine. -- Software development and contracting: http://pro.pitrou.net
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. -- Software development and contracting: http://pro.pitrou.net
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
-- 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. -- Terry Jan Reedy
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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQCVAwUBUG4LKZlgi5GaxT1NAQKeCAQAg43Y6LgrYwJWP/TSDx4X9t+lSxE/47HF J0cEdFtEhT3hm08qFi3fKhR4p7K8gTVFRxNqVBu89dacjCPUrbbnLVI3tTJjvrst Joqx5RDZv1q3m/OwoFz+kIXEJFEtVNPY/geQlGGYkyoowc/FqFWl/ygpl8rTdjla NvFmdoBGFUY= =DIYs -----END PGP SIGNATURE-----
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