From noreply@sourceforge.net Sun Dec 1 18:14:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Dec 2002 10:14:24 -0800 Subject: [Patches] [ python-Patches-646547 ] test_poll fails on FreeBSD Message-ID: Patches item #646547, was opened at 2002-12-01 18:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=646547&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Laurie (benl) Assigned to: Nobody/Anonymous (nobody) Summary: test_poll fails on FreeBSD Initial Comment: Starting program: /usr/home/ben/work/python/dist/src/python Lib/test/test_poll.py Running poll test 1 This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. Poll test 1 complete Running poll test 2 timeout = 0 timeout = 1000 'testing...\n' timeout = 2000 'testing...\n' timeout = 4000 'testing...\n' timeout = 8000 'testing...\n' timeout = 16000 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 Program received signal SIGSEGV, Segmentation fault. 0x2813cd04 in strncat () from /usr/lib/libc_r.so.3 (gdb) where #0 0x2813cd04 in strncat () from /usr/lib/libc_r.so.3 #1 0x281799fb in .cerror () from /usr/lib/libc_r.so.3 #2 0x80d4aad in PyCFunction_Call (func=0x81a63ec, arg=0x81a4a6c, kw=0x0) at Objects/methodobject.c:80 #3 0x809d83b in call_function (pp_stack=0xbfbfd2f8, oparg=1) at Python/ceval.c:3249 #4 0x809c066 in eval_frame (f=0x8172e0c) at Python/ceval.c:2009 #5 0x809cf52 in PyEval_EvalCodeEx (co=0x819c7e0, globals=0x813057c, locals=0x0, args=0x8112d5c, argcount=0, kws=0x8112d5c, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2554 #6 0x809f09c in fast_function (func=0x81b82cc, pp_stack=0xbfbfd498, n=0, na=0, nk=0) at Python/ceval.c:3297 #7 0x809d8c1 in call_function (pp_stack=0xbfbfd498, oparg=0) at Python/ceval.c:3266 #8 0x809c066 in eval_frame (f=0x8112c0c) at Python/ceval.c:2009 #9 0x809cf52 in PyEval_EvalCodeEx (co=0x819c820, globals=0x813057c, locals=0x813057c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2554 #10 0x809f03d in PyEval_EvalCode (co=0x819c820, globals=0x813057c, locals=0x813057c) at Python/ceval.c:478 #11 0x80bb093 in run_node (n=0x8118410, filename=0xbfbfd83a "Lib/test/test_poll.py", globals=0x813057c, locals=0x813057c, flags=0xbfbfd6c4) at Python/pythonrun.c:1089 #12 0x80bb04e in run_err_node (n=0x8118410, filename=0xbfbfd83a "Lib/test/test_poll.py", globals=0x813057c, locals=0x813057c, flags=0xbfbfd6c4) at Python/pythonrun.c:1076 #13 0x80baca1 in PyRun_FileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", start=257, globals=0x813057c, locals=0x813057c, closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:1067 #14 0x80b9972 in PyRun_SimpleFileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:698 #15 0x80ba843 in PyRun_AnyFileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:491 #16 0x80535fb in Py_Main (argc=2, argv=0xbfbfd714) at Modules/main.c:385 #17 0x8052ee8 in main (argc=2, argv=0xbfbfd714) at Modules/python.c:8 The function called in PyCFunction_Call is poll_poll(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=646547&group_id=5470 From noreply@sourceforge.net Sun Dec 1 17:10:06 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Dec 2002 09:10:06 -0800 Subject: [Patches] [ python-Patches-644977 ] Allow device name in linuxaudiodev.open Message-ID: Patches item #644977, was opened at 2002-11-27 16:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=644977&group_id=5470 Category: Modules Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Greg Ward (gward) Assigned to: Greg Ward (gward) Summary: Allow device name in linuxaudiodev.open Initial Comment: linuxaudiodev.open() does not allow the caller to specify the device file to open -- it hardcodes "/dev/dsp", which can be only overridden with the AUDIODEV environment variable. Yuck. This patch fixes that while preserving backwards compatibility. ---------------------------------------------------------------------- >Comment By: Greg Ward (gward) Date: 2002-12-01 12:10 Message: Logged In: YES user_id=14422 OK, I won't bother patching test_linuxaudiodev.py. Closing this patch as "accepted" since the important part was checked in. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-27 17:40 Message: Logged In: YES user_id=21627 I'm not sure every possible parameter combination must be tested. I personally would find it annoying if the test sound is played that often - it does not test that much. More important would be to have documentation, any documentation. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2002-11-27 17:14 Message: Logged In: YES user_id=14422 OK, I'm attaching a patch to Lib/test/test_linuxaudiodev.py to test the 'device' arg to open(). This refactors the code a bit and plays the test sound twice (so it will be heard *four* times total when running the complete test suite). ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2002-11-27 17:08 Message: Logged In: YES user_id=14422 The only catch is testing; only idea I have is to play the test sound twice, once with open('w') (the current behaviour) and once with open('/dev/dsp','w'). That sound OK? (Err, pun not intended) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-27 17:05 Message: Logged In: YES user_id=21627 The patch is fine. Please apply it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=644977&group_id=5470 From noreply@sourceforge.net Sun Dec 1 22:34:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Dec 2002 14:34:30 -0800 Subject: [Patches] [ python-Patches-645650 ] Import from Zip Archive Message-ID: Patches item #645650, was opened at 2002-11-29 11:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645650&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Neal Norwitz (nnorwitz) Summary: Import from Zip Archive Initial Comment: This patch supersedes patch 492105. This is an updated version of the patch for imports from a zip file. This version is against current CVS, and includes documentation and tests. The patch builds on Windows, and runs OK. I haven't (yet) run any comprehensive tests, as this is the first time I've set up a build environment, and I'm not sure how to run the tests yet :-( ---------------------------------------------------------------------- >Comment By: Paul Moore (pmoore) Date: 2002-12-01 22:34 Message: Logged In: YES user_id=113328 I've now taken Neal's patch and integrated my changes. I'll check it through again, and run a few more tests, and then upload the result (I've had problems with cvs update, so I'm downloading a new copy of CVS python first). Most things look OK. There are a couple of issues with case- insensitive filesystems. The first is that the cache of os.listdir results is (case- sensitively) keyed on directory name. I don't see this as an issue as (a) I'd expect the case used to remain constant (who's going to change a directory in sys.path at runtime to the same name with a different case???) and (b) it's only an efficiency hit, not an error, in any case. The second issue is more problematic. Zip files on sys.path are recognised (see add_zip_names()) by the extension ".zip" (case sensitively). It's arguable that on case-insensitive filesystems, this check should also be case insensitive. But finding that a file is on a case-insensitive filesystem is, I believe, not possible. And using a case-insensitive test all the time isn't right either. I'd say that we should just *define* the algorithm as only treating files ending in ".zip" (case sensitive) as zip files. It doesn't seem to be a problem in practice. I'll try to find some way to fit that into the documentation... Apart from this issue, I've seen no other problems with the patch. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-11-29 21:11 Message: Logged In: YES user_id=113328 My problem turns out to be an interaction with the new "universal newline support". In find_module, within the switch(path_type), case PY_IMP_LISTDIR, the section of code marked /* Search the list of suffixes: .pyc, .pyd, ... */ tries to do fopen(buf, fdp->mode). But .py files are now mode 'U' (universal newline) which is not a valid mode for fopen (). I've made a fix, but I'm not sure how reliable it is. On a related note, I'm not 100% sure how robust the code is in the presence of case-insensitive filesystems. I'm way out of my depth in this code, so I don't know if I'll be able to fix it, but I'll have a look (and I'll look at your version of the patch, as well). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-29 18:47 Message: Logged In: YES user_id=33168 Paul, thanks for taking this up. I made very little progress on this I have attached my version of the diffs. I had some problems with the original patch which I was never able to correct. For example, I think it was not possible to run python from a local build env't. It appeared that python had to be installed for everything to work. See the problem in bug 586680 (also in site.py). That should probably be addressed and was part of my problem. I tried to simplify the code some, so you should see some differences between the patch I attached and the original. These are not as important as making the patch work properly, both when installed and running from a build env't. I will try to take a look at your problem later, but it may take a while. Let me know if you make progress. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-11-29 11:57 Message: Logged In: YES user_id=113328 Bad news. I've just hit problems with the patched Python - when I start python.exe, it reports "cannot import site" and seems unable to locate the standard library. (This when I run python from the PCBuild directory). I built a clean CVS version, and don't see this problem. Can anyone else reproduce this, or help me diagnose it? I don't understand Jim's changes well enough to see what might be the problem (I updated the patch purely mechanically). ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-11-29 11:40 Message: Logged In: YES user_id=113328 Uploaded file foo.zip, needed (in lib\test directory) for the changes to test_import.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645650&group_id=5470 From noreply@sourceforge.net Sun Dec 1 23:00:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Dec 2002 15:00:43 -0800 Subject: [Patches] [ python-Patches-645650 ] Import from Zip Archive Message-ID: Patches item #645650, was opened at 2002-11-29 12:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645650&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Neal Norwitz (nnorwitz) Summary: Import from Zip Archive Initial Comment: This patch supersedes patch 492105. This is an updated version of the patch for imports from a zip file. This version is against current CVS, and includes documentation and tests. The patch builds on Windows, and runs OK. I haven't (yet) run any comprehensive tests, as this is the first time I've set up a build environment, and I'm not sure how to run the tests yet :-( ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-02 00:00 Message: Logged In: YES user_id=21627 I certainly agree with only treating .zip as indication for zipfiles. On a case insensitive file system, you can put .zip into sys.path and it will still find .ZIP. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-12-01 23:34 Message: Logged In: YES user_id=113328 I've now taken Neal's patch and integrated my changes. I'll check it through again, and run a few more tests, and then upload the result (I've had problems with cvs update, so I'm downloading a new copy of CVS python first). Most things look OK. There are a couple of issues with case- insensitive filesystems. The first is that the cache of os.listdir results is (case- sensitively) keyed on directory name. I don't see this as an issue as (a) I'd expect the case used to remain constant (who's going to change a directory in sys.path at runtime to the same name with a different case???) and (b) it's only an efficiency hit, not an error, in any case. The second issue is more problematic. Zip files on sys.path are recognised (see add_zip_names()) by the extension ".zip" (case sensitively). It's arguable that on case-insensitive filesystems, this check should also be case insensitive. But finding that a file is on a case-insensitive filesystem is, I believe, not possible. And using a case-insensitive test all the time isn't right either. I'd say that we should just *define* the algorithm as only treating files ending in ".zip" (case sensitive) as zip files. It doesn't seem to be a problem in practice. I'll try to find some way to fit that into the documentation... Apart from this issue, I've seen no other problems with the patch. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-11-29 22:11 Message: Logged In: YES user_id=113328 My problem turns out to be an interaction with the new "universal newline support". In find_module, within the switch(path_type), case PY_IMP_LISTDIR, the section of code marked /* Search the list of suffixes: .pyc, .pyd, ... */ tries to do fopen(buf, fdp->mode). But .py files are now mode 'U' (universal newline) which is not a valid mode for fopen (). I've made a fix, but I'm not sure how reliable it is. On a related note, I'm not 100% sure how robust the code is in the presence of case-insensitive filesystems. I'm way out of my depth in this code, so I don't know if I'll be able to fix it, but I'll have a look (and I'll look at your version of the patch, as well). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-29 19:47 Message: Logged In: YES user_id=33168 Paul, thanks for taking this up. I made very little progress on this I have attached my version of the diffs. I had some problems with the original patch which I was never able to correct. For example, I think it was not possible to run python from a local build env't. It appeared that python had to be installed for everything to work. See the problem in bug 586680 (also in site.py). That should probably be addressed and was part of my problem. I tried to simplify the code some, so you should see some differences between the patch I attached and the original. These are not as important as making the patch work properly, both when installed and running from a build env't. I will try to take a look at your problem later, but it may take a while. Let me know if you make progress. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-11-29 12:57 Message: Logged In: YES user_id=113328 Bad news. I've just hit problems with the patched Python - when I start python.exe, it reports "cannot import site" and seems unable to locate the standard library. (This when I run python from the PCBuild directory). I built a clean CVS version, and don't see this problem. Can anyone else reproduce this, or help me diagnose it? I don't understand Jim's changes well enough to see what might be the problem (I updated the patch purely mechanically). ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-11-29 12:40 Message: Logged In: YES user_id=113328 Uploaded file foo.zip, needed (in lib\test directory) for the changes to test_import.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645650&group_id=5470 From noreply@sourceforge.net Sun Dec 1 23:01:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Dec 2002 15:01:58 -0800 Subject: [Patches] [ python-Patches-646547 ] test_poll fails on FreeBSD Message-ID: Patches item #646547, was opened at 2002-12-01 19:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=646547&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Laurie (benl) Assigned to: Nobody/Anonymous (nobody) Summary: test_poll fails on FreeBSD Initial Comment: Starting program: /usr/home/ben/work/python/dist/src/python Lib/test/test_poll.py Running poll test 1 This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. Poll test 1 complete Running poll test 2 timeout = 0 timeout = 1000 'testing...\n' timeout = 2000 'testing...\n' timeout = 4000 'testing...\n' timeout = 8000 'testing...\n' timeout = 16000 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 Program received signal SIGSEGV, Segmentation fault. 0x2813cd04 in strncat () from /usr/lib/libc_r.so.3 (gdb) where #0 0x2813cd04 in strncat () from /usr/lib/libc_r.so.3 #1 0x281799fb in .cerror () from /usr/lib/libc_r.so.3 #2 0x80d4aad in PyCFunction_Call (func=0x81a63ec, arg=0x81a4a6c, kw=0x0) at Objects/methodobject.c:80 #3 0x809d83b in call_function (pp_stack=0xbfbfd2f8, oparg=1) at Python/ceval.c:3249 #4 0x809c066 in eval_frame (f=0x8172e0c) at Python/ceval.c:2009 #5 0x809cf52 in PyEval_EvalCodeEx (co=0x819c7e0, globals=0x813057c, locals=0x0, args=0x8112d5c, argcount=0, kws=0x8112d5c, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2554 #6 0x809f09c in fast_function (func=0x81b82cc, pp_stack=0xbfbfd498, n=0, na=0, nk=0) at Python/ceval.c:3297 #7 0x809d8c1 in call_function (pp_stack=0xbfbfd498, oparg=0) at Python/ceval.c:3266 #8 0x809c066 in eval_frame (f=0x8112c0c) at Python/ceval.c:2009 #9 0x809cf52 in PyEval_EvalCodeEx (co=0x819c820, globals=0x813057c, locals=0x813057c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2554 #10 0x809f03d in PyEval_EvalCode (co=0x819c820, globals=0x813057c, locals=0x813057c) at Python/ceval.c:478 #11 0x80bb093 in run_node (n=0x8118410, filename=0xbfbfd83a "Lib/test/test_poll.py", globals=0x813057c, locals=0x813057c, flags=0xbfbfd6c4) at Python/pythonrun.c:1089 #12 0x80bb04e in run_err_node (n=0x8118410, filename=0xbfbfd83a "Lib/test/test_poll.py", globals=0x813057c, locals=0x813057c, flags=0xbfbfd6c4) at Python/pythonrun.c:1076 #13 0x80baca1 in PyRun_FileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", start=257, globals=0x813057c, locals=0x813057c, closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:1067 #14 0x80b9972 in PyRun_SimpleFileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:698 #15 0x80ba843 in PyRun_AnyFileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:491 #16 0x80535fb in Py_Main (argc=2, argv=0xbfbfd714) at Modules/main.c:385 #17 0x8052ee8 in main (argc=2, argv=0xbfbfd714) at Modules/python.c:8 The function called in PyCFunction_Call is poll_poll(). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-02 00:01 Message: Logged In: YES user_id=21627 Was this meant to be a bug report, or a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=646547&group_id=5470 From noreply@sourceforge.net Mon Dec 2 06:13:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 01 Dec 2002 22:13:49 -0800 Subject: [Patches] [ python-Patches-646547 ] test_poll fails on FreeBSD Message-ID: Patches item #646547, was opened at 2002-12-01 18:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=646547&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Laurie (benl) Assigned to: Nobody/Anonymous (nobody) Summary: test_poll fails on FreeBSD Initial Comment: Starting program: /usr/home/ben/work/python/dist/src/python Lib/test/test_poll.py Running poll test 1 This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. This is a test. Poll test 1 complete Running poll test 2 timeout = 0 timeout = 1000 'testing...\n' timeout = 2000 'testing...\n' timeout = 4000 'testing...\n' timeout = 8000 'testing...\n' timeout = 16000 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 'testing...\n' timeout = -1 Program received signal SIGSEGV, Segmentation fault. 0x2813cd04 in strncat () from /usr/lib/libc_r.so.3 (gdb) where #0 0x2813cd04 in strncat () from /usr/lib/libc_r.so.3 #1 0x281799fb in .cerror () from /usr/lib/libc_r.so.3 #2 0x80d4aad in PyCFunction_Call (func=0x81a63ec, arg=0x81a4a6c, kw=0x0) at Objects/methodobject.c:80 #3 0x809d83b in call_function (pp_stack=0xbfbfd2f8, oparg=1) at Python/ceval.c:3249 #4 0x809c066 in eval_frame (f=0x8172e0c) at Python/ceval.c:2009 #5 0x809cf52 in PyEval_EvalCodeEx (co=0x819c7e0, globals=0x813057c, locals=0x0, args=0x8112d5c, argcount=0, kws=0x8112d5c, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2554 #6 0x809f09c in fast_function (func=0x81b82cc, pp_stack=0xbfbfd498, n=0, na=0, nk=0) at Python/ceval.c:3297 #7 0x809d8c1 in call_function (pp_stack=0xbfbfd498, oparg=0) at Python/ceval.c:3266 #8 0x809c066 in eval_frame (f=0x8112c0c) at Python/ceval.c:2009 #9 0x809cf52 in PyEval_EvalCodeEx (co=0x819c820, globals=0x813057c, locals=0x813057c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2554 #10 0x809f03d in PyEval_EvalCode (co=0x819c820, globals=0x813057c, locals=0x813057c) at Python/ceval.c:478 #11 0x80bb093 in run_node (n=0x8118410, filename=0xbfbfd83a "Lib/test/test_poll.py", globals=0x813057c, locals=0x813057c, flags=0xbfbfd6c4) at Python/pythonrun.c:1089 #12 0x80bb04e in run_err_node (n=0x8118410, filename=0xbfbfd83a "Lib/test/test_poll.py", globals=0x813057c, locals=0x813057c, flags=0xbfbfd6c4) at Python/pythonrun.c:1076 #13 0x80baca1 in PyRun_FileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", start=257, globals=0x813057c, locals=0x813057c, closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:1067 #14 0x80b9972 in PyRun_SimpleFileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:698 #15 0x80ba843 in PyRun_AnyFileExFlags (fp=0x28192680, filename=0xbfbfd83a "Lib/test/test_poll.py", closeit=1, flags=0xbfbfd6c4) at Python/pythonrun.c:491 #16 0x80535fb in Py_Main (argc=2, argv=0xbfbfd714) at Modules/main.c:385 #17 0x8052ee8 in main (argc=2, argv=0xbfbfd714) at Modules/python.c:8 The function called in PyCFunction_Call is poll_poll(). ---------------------------------------------------------------------- >Comment By: Ben Laurie (benl) Date: 2002-12-02 06:13 Message: Logged In: YES user_id=14333 Ooops, you are correct, it is a bug report. Sorry! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-01 23:01 Message: Logged In: YES user_id=21627 Was this meant to be a bug report, or a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=646547&group_id=5470 From noreply@sourceforge.net Mon Dec 2 08:11:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Dec 2002 00:11:42 -0800 Subject: [Patches] [ python-Patches-646824 ] documentation build error Message-ID: Patches item #646824, was opened at 2002-12-02 08:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=646824&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: documentation build error Initial Comment: there is one extra "\end{description}" in Doc/lib/libstdtypes.tex. Patch attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=646824&group_id=5470 From noreply@sourceforge.net Mon Dec 2 12:42:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Dec 2002 04:42:11 -0800 Subject: [Patches] [ python-Patches-645383 ] Give some clue why modules fail... Message-ID: Patches item #645383, was opened at 2002-11-28 18:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645383&group_id=5470 Category: Build Group: Python 2.2.x Status: Open Resolution: None Priority: 5 Submitted By: Ben Laurie (benl) >Assigned to: Michael Hudson (mwh) Summary: Give some clue why modules fail... Initial Comment: --- Python-2.2.2/setup.py Thu Oct 10 00:59:16 2002 +++ Python-2.2.2-ben/setup.py Thu Nov 28 17:45:51 2002 @@ -163,9 +163,9 @@ return try: __import__(ext.name) - except ImportError: - self.announce('WARNING: removing "%s" since importing it failed' % - ext.name) + except ImportError, e: + self.announce('WARNING: removing "%s" since importing it failed: %s' % + (ext.name,str(e))) assert not self.inplace fullname = self.get_ext_fullname(ext.name) ext_filename = os.path.join(self.build_lib, ---------------------------------------------------------------------- Comment By: Ben Laurie (benl) Date: 2002-11-30 21:21 Message: Logged In: YES user_id=14333 1) Sorry, attaching a file for a small patch wasn't the obvious thing to do... 2) The issue isn't the disposal of the module after its failed, its that you get no clue as to why its failed... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-29 11:45 Message: Logged In: YES user_id=6656 1) please don't paste patches into the textarea! 2) would you be happier if we adopted the 2.3 solution of just renaming the failed module rather than deleting it? I've been thinking for a while that that would be worthwhile. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645383&group_id=5470 From noreply@sourceforge.net Mon Dec 2 16:43:27 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Dec 2002 08:43:27 -0800 Subject: [Patches] [ python-Patches-645650 ] Import from Zip Archive Message-ID: Patches item #645650, was opened at 2002-11-29 11:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645650&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Neal Norwitz (nnorwitz) Summary: Import from Zip Archive Initial Comment: This patch supersedes patch 492105. This is an updated version of the patch for imports from a zip file. This version is against current CVS, and includes documentation and tests. The patch builds on Windows, and runs OK. I haven't (yet) run any comprehensive tests, as this is the first time I've set up a build environment, and I'm not sure how to run the tests yet :-( ---------------------------------------------------------------------- >Comment By: Paul Moore (pmoore) Date: 2002-12-02 16:43 Message: Logged In: YES user_id=113328 Aargh. It looks like Neal's patch is wrong - it didn't include the changes to the files in the PC directory. Also it has a lot of strange changes, like replacing PyEval_CallObject with PyObject_Call - I don't see how this relates to zipfiles. I wasted most of this morning trying to juggle too many patches, to no avail. I think I'm going to have to revert to my patch, get it applied to the CVS version, and upload that. Neal, I agree with a lot of the changes you made, but they'll need redoing - can you apply my patch to a clean checkout and redo your tidying up? The patch I'm uploading with this comment builds cleanly for me on Windows 2000, and passes the supplied tests. You need to apply the patch, then put the 2 included zipfiles in the lib/test directory. I'd be very grateful if someone could test this on Unix and/or Mac, and update it where necessary. I've not tested these platforms, but I'm assuming that Jim's original code worked there. There are also other areas which seem strange (the big block of deleted code in sysmodule.c worries me - but I see no failures because of it, so I've left it unchanged) and comments would be very helpful, but in the absence of anything better I'm sticking with "it worked when I tried it"... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-01 23:00 Message: Logged In: YES user_id=21627 I certainly agree with only treating .zip as indication for zipfiles. On a case insensitive file system, you can put .zip into sys.path and it will still find .ZIP. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-12-01 22:34 Message: Logged In: YES user_id=113328 I've now taken Neal's patch and integrated my changes. I'll check it through again, and run a few more tests, and then upload the result (I've had problems with cvs update, so I'm downloading a new copy of CVS python first). Most things look OK. There are a couple of issues with case- insensitive filesystems. The first is that the cache of os.listdir results is (case- sensitively) keyed on directory name. I don't see this as an issue as (a) I'd expect the case used to remain constant (who's going to change a directory in sys.path at runtime to the same name with a different case???) and (b) it's only an efficiency hit, not an error, in any case. The second issue is more problematic. Zip files on sys.path are recognised (see add_zip_names()) by the extension ".zip" (case sensitively). It's arguable that on case-insensitive filesystems, this check should also be case insensitive. But finding that a file is on a case-insensitive filesystem is, I believe, not possible. And using a case-insensitive test all the time isn't right either. I'd say that we should just *define* the algorithm as only treating files ending in ".zip" (case sensitive) as zip files. It doesn't seem to be a problem in practice. I'll try to find some way to fit that into the documentation... Apart from this issue, I've seen no other problems with the patch. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-11-29 21:11 Message: Logged In: YES user_id=113328 My problem turns out to be an interaction with the new "universal newline support". In find_module, within the switch(path_type), case PY_IMP_LISTDIR, the section of code marked /* Search the list of suffixes: .pyc, .pyd, ... */ tries to do fopen(buf, fdp->mode). But .py files are now mode 'U' (universal newline) which is not a valid mode for fopen (). I've made a fix, but I'm not sure how reliable it is. On a related note, I'm not 100% sure how robust the code is in the presence of case-insensitive filesystems. I'm way out of my depth in this code, so I don't know if I'll be able to fix it, but I'll have a look (and I'll look at your version of the patch, as well). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-29 18:47 Message: Logged In: YES user_id=33168 Paul, thanks for taking this up. I made very little progress on this I have attached my version of the diffs. I had some problems with the original patch which I was never able to correct. For example, I think it was not possible to run python from a local build env't. It appeared that python had to be installed for everything to work. See the problem in bug 586680 (also in site.py). That should probably be addressed and was part of my problem. I tried to simplify the code some, so you should see some differences between the patch I attached and the original. These are not as important as making the patch work properly, both when installed and running from a build env't. I will try to take a look at your problem later, but it may take a while. Let me know if you make progress. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-11-29 11:57 Message: Logged In: YES user_id=113328 Bad news. I've just hit problems with the patched Python - when I start python.exe, it reports "cannot import site" and seems unable to locate the standard library. (This when I run python from the PCBuild directory). I built a clean CVS version, and don't see this problem. Can anyone else reproduce this, or help me diagnose it? I don't understand Jim's changes well enough to see what might be the problem (I updated the patch purely mechanically). ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-11-29 11:40 Message: Logged In: YES user_id=113328 Uploaded file foo.zip, needed (in lib\test directory) for the changes to test_import.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645650&group_id=5470 From noreply@sourceforge.net Mon Dec 2 16:55:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 02 Dec 2002 08:55:08 -0800 Subject: [Patches] [ python-Patches-645650 ] Import from Zip Archive Message-ID: Patches item #645650, was opened at 2002-11-29 06:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645650&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Neal Norwitz (nnorwitz) Summary: Import from Zip Archive Initial Comment: This patch supersedes patch 492105. This is an updated version of the patch for imports from a zip file. This version is against current CVS, and includes documentation and tests. The patch builds on Windows, and runs OK. I haven't (yet) run any comprehensive tests, as this is the first time I've set up a build environment, and I'm not sure how to run the tests yet :-( ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-02 11:55 Message: Logged In: YES user_id=33168 Hmmm, I thought I used to have changes to PC. Not sure, though. I'll try to take a look at the diffs and test on unix later this evening. I can also add back in any of my changes after you get everything working. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-12-02 11:43 Message: Logged In: YES user_id=113328 Aargh. It looks like Neal's patch is wrong - it didn't include the changes to the files in the PC directory. Also it has a lot of strange changes, like replacing PyEval_CallObject with PyObject_Call - I don't see how this relates to zipfiles. I wasted most of this morning trying to juggle too many patches, to no avail. I think I'm going to have to revert to my patch, get it applied to the CVS version, and upload that. Neal, I agree with a lot of the changes you made, but they'll need redoing - can you apply my patch to a clean checkout and redo your tidying up? The patch I'm uploading with this comment builds cleanly for me on Windows 2000, and passes the supplied tests. You need to apply the patch, then put the 2 included zipfiles in the lib/test directory. I'd be very grateful if someone could test this on Unix and/or Mac, and update it where necessary. I've not tested these platforms, but I'm assuming that Jim's original code worked there. There are also other areas which seem strange (the big block of deleted code in sysmodule.c worries me - but I see no failures because of it, so I've left it unchanged) and comments would be very helpful, but in the absence of anything better I'm sticking with "it worked when I tried it"... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-01 18:00 Message: Logged In: YES user_id=21627 I certainly agree with only treating .zip as indication for zipfiles. On a case insensitive file system, you can put .zip into sys.path and it will still find .ZIP. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-12-01 17:34 Message: Logged In: YES user_id=113328 I've now taken Neal's patch and integrated my changes. I'll check it through again, and run a few more tests, and then upload the result (I've had problems with cvs update, so I'm downloading a new copy of CVS python first). Most things look OK. There are a couple of issues with case- insensitive filesystems. The first is that the cache of os.listdir results is (case- sensitively) keyed on directory name. I don't see this as an issue as (a) I'd expect the case used to remain constant (who's going to change a directory in sys.path at runtime to the same name with a different case???) and (b) it's only an efficiency hit, not an error, in any case. The second issue is more problematic. Zip files on sys.path are recognised (see add_zip_names()) by the extension ".zip" (case sensitively). It's arguable that on case-insensitive filesystems, this check should also be case insensitive. But finding that a file is on a case-insensitive filesystem is, I believe, not possible. And using a case-insensitive test all the time isn't right either. I'd say that we should just *define* the algorithm as only treating files ending in ".zip" (case sensitive) as zip files. It doesn't seem to be a problem in practice. I'll try to find some way to fit that into the documentation... Apart from this issue, I've seen no other problems with the patch. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-11-29 16:11 Message: Logged In: YES user_id=113328 My problem turns out to be an interaction with the new "universal newline support". In find_module, within the switch(path_type), case PY_IMP_LISTDIR, the section of code marked /* Search the list of suffixes: .pyc, .pyd, ... */ tries to do fopen(buf, fdp->mode). But .py files are now mode 'U' (universal newline) which is not a valid mode for fopen (). I've made a fix, but I'm not sure how reliable it is. On a related note, I'm not 100% sure how robust the code is in the presence of case-insensitive filesystems. I'm way out of my depth in this code, so I don't know if I'll be able to fix it, but I'll have a look (and I'll look at your version of the patch, as well). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-29 13:47 Message: Logged In: YES user_id=33168 Paul, thanks for taking this up. I made very little progress on this I have attached my version of the diffs. I had some problems with the original patch which I was never able to correct. For example, I think it was not possible to run python from a local build env't. It appeared that python had to be installed for everything to work. See the problem in bug 586680 (also in site.py). That should probably be addressed and was part of my problem. I tried to simplify the code some, so you should see some differences between the patch I attached and the original. These are not as important as making the patch work properly, both when installed and running from a build env't. I will try to take a look at your problem later, but it may take a while. Let me know if you make progress. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-11-29 06:57 Message: Logged In: YES user_id=113328 Bad news. I've just hit problems with the patched Python - when I start python.exe, it reports "cannot import site" and seems unable to locate the standard library. (This when I run python from the PCBuild directory). I built a clean CVS version, and don't see this problem. Can anyone else reproduce this, or help me diagnose it? I don't understand Jim's changes well enough to see what might be the problem (I updated the patch purely mechanically). ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-11-29 06:40 Message: Logged In: YES user_id=113328 Uploaded file foo.zip, needed (in lib\test directory) for the changes to test_import.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645650&group_id=5470 From noreply@sourceforge.net Tue Dec 3 09:31:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Dec 2002 01:31:47 -0800 Subject: [Patches] [ python-Patches-645650 ] Import from Zip Archive Message-ID: Patches item #645650, was opened at 2002-11-29 12:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645650&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Neal Norwitz (nnorwitz) Summary: Import from Zip Archive Initial Comment: This patch supersedes patch 492105. This is an updated version of the patch for imports from a zip file. This version is against current CVS, and includes documentation and tests. The patch builds on Windows, and runs OK. I haven't (yet) run any comprehensive tests, as this is the first time I've set up a build environment, and I'm not sure how to run the tests yet :-( ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-03 10:31 Message: Logged In: YES user_id=21627 Paul, there is sentiment on python-dev that this patch is unacceptable, because it is incomprehensible. I can sympathize with these feelings, so we need to take the possibility into account that this won't go into Python 2.3. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-02 17:55 Message: Logged In: YES user_id=33168 Hmmm, I thought I used to have changes to PC. Not sure, though. I'll try to take a look at the diffs and test on unix later this evening. I can also add back in any of my changes after you get everything working. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-12-02 17:43 Message: Logged In: YES user_id=113328 Aargh. It looks like Neal's patch is wrong - it didn't include the changes to the files in the PC directory. Also it has a lot of strange changes, like replacing PyEval_CallObject with PyObject_Call - I don't see how this relates to zipfiles. I wasted most of this morning trying to juggle too many patches, to no avail. I think I'm going to have to revert to my patch, get it applied to the CVS version, and upload that. Neal, I agree with a lot of the changes you made, but they'll need redoing - can you apply my patch to a clean checkout and redo your tidying up? The patch I'm uploading with this comment builds cleanly for me on Windows 2000, and passes the supplied tests. You need to apply the patch, then put the 2 included zipfiles in the lib/test directory. I'd be very grateful if someone could test this on Unix and/or Mac, and update it where necessary. I've not tested these platforms, but I'm assuming that Jim's original code worked there. There are also other areas which seem strange (the big block of deleted code in sysmodule.c worries me - but I see no failures because of it, so I've left it unchanged) and comments would be very helpful, but in the absence of anything better I'm sticking with "it worked when I tried it"... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-02 00:00 Message: Logged In: YES user_id=21627 I certainly agree with only treating .zip as indication for zipfiles. On a case insensitive file system, you can put .zip into sys.path and it will still find .ZIP. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-12-01 23:34 Message: Logged In: YES user_id=113328 I've now taken Neal's patch and integrated my changes. I'll check it through again, and run a few more tests, and then upload the result (I've had problems with cvs update, so I'm downloading a new copy of CVS python first). Most things look OK. There are a couple of issues with case- insensitive filesystems. The first is that the cache of os.listdir results is (case- sensitively) keyed on directory name. I don't see this as an issue as (a) I'd expect the case used to remain constant (who's going to change a directory in sys.path at runtime to the same name with a different case???) and (b) it's only an efficiency hit, not an error, in any case. The second issue is more problematic. Zip files on sys.path are recognised (see add_zip_names()) by the extension ".zip" (case sensitively). It's arguable that on case-insensitive filesystems, this check should also be case insensitive. But finding that a file is on a case-insensitive filesystem is, I believe, not possible. And using a case-insensitive test all the time isn't right either. I'd say that we should just *define* the algorithm as only treating files ending in ".zip" (case sensitive) as zip files. It doesn't seem to be a problem in practice. I'll try to find some way to fit that into the documentation... Apart from this issue, I've seen no other problems with the patch. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-11-29 22:11 Message: Logged In: YES user_id=113328 My problem turns out to be an interaction with the new "universal newline support". In find_module, within the switch(path_type), case PY_IMP_LISTDIR, the section of code marked /* Search the list of suffixes: .pyc, .pyd, ... */ tries to do fopen(buf, fdp->mode). But .py files are now mode 'U' (universal newline) which is not a valid mode for fopen (). I've made a fix, but I'm not sure how reliable it is. On a related note, I'm not 100% sure how robust the code is in the presence of case-insensitive filesystems. I'm way out of my depth in this code, so I don't know if I'll be able to fix it, but I'll have a look (and I'll look at your version of the patch, as well). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-29 19:47 Message: Logged In: YES user_id=33168 Paul, thanks for taking this up. I made very little progress on this I have attached my version of the diffs. I had some problems with the original patch which I was never able to correct. For example, I think it was not possible to run python from a local build env't. It appeared that python had to be installed for everything to work. See the problem in bug 586680 (also in site.py). That should probably be addressed and was part of my problem. I tried to simplify the code some, so you should see some differences between the patch I attached and the original. These are not as important as making the patch work properly, both when installed and running from a build env't. I will try to take a look at your problem later, but it may take a while. Let me know if you make progress. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-11-29 12:57 Message: Logged In: YES user_id=113328 Bad news. I've just hit problems with the patched Python - when I start python.exe, it reports "cannot import site" and seems unable to locate the standard library. (This when I run python from the PCBuild directory). I built a clean CVS version, and don't see this problem. Can anyone else reproduce this, or help me diagnose it? I don't understand Jim's changes well enough to see what might be the problem (I updated the patch purely mechanically). ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-11-29 12:40 Message: Logged In: YES user_id=113328 Uploaded file foo.zip, needed (in lib\test directory) for the changes to test_import.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645650&group_id=5470 From noreply@sourceforge.net Tue Dec 3 14:06:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Dec 2002 06:06:10 -0800 Subject: [Patches] [ python-Patches-645650 ] Import from Zip Archive Message-ID: Patches item #645650, was opened at 2002-11-29 11:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645650&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Neal Norwitz (nnorwitz) Summary: Import from Zip Archive Initial Comment: This patch supersedes patch 492105. This is an updated version of the patch for imports from a zip file. This version is against current CVS, and includes documentation and tests. The patch builds on Windows, and runs OK. I haven't (yet) run any comprehensive tests, as this is the first time I've set up a build environment, and I'm not sure how to run the tests yet :-( ---------------------------------------------------------------------- >Comment By: Paul Moore (pmoore) Date: 2002-12-03 14:06 Message: Logged In: YES user_id=113328 Understood (I've been watching python-dev). I'm happy to keep working on this while a consensus is reached. Actually, I don't think there's much more I can do, I'm hoping that users of other OS's can test this now.... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-03 09:31 Message: Logged In: YES user_id=21627 Paul, there is sentiment on python-dev that this patch is unacceptable, because it is incomprehensible. I can sympathize with these feelings, so we need to take the possibility into account that this won't go into Python 2.3. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-02 16:55 Message: Logged In: YES user_id=33168 Hmmm, I thought I used to have changes to PC. Not sure, though. I'll try to take a look at the diffs and test on unix later this evening. I can also add back in any of my changes after you get everything working. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-12-02 16:43 Message: Logged In: YES user_id=113328 Aargh. It looks like Neal's patch is wrong - it didn't include the changes to the files in the PC directory. Also it has a lot of strange changes, like replacing PyEval_CallObject with PyObject_Call - I don't see how this relates to zipfiles. I wasted most of this morning trying to juggle too many patches, to no avail. I think I'm going to have to revert to my patch, get it applied to the CVS version, and upload that. Neal, I agree with a lot of the changes you made, but they'll need redoing - can you apply my patch to a clean checkout and redo your tidying up? The patch I'm uploading with this comment builds cleanly for me on Windows 2000, and passes the supplied tests. You need to apply the patch, then put the 2 included zipfiles in the lib/test directory. I'd be very grateful if someone could test this on Unix and/or Mac, and update it where necessary. I've not tested these platforms, but I'm assuming that Jim's original code worked there. There are also other areas which seem strange (the big block of deleted code in sysmodule.c worries me - but I see no failures because of it, so I've left it unchanged) and comments would be very helpful, but in the absence of anything better I'm sticking with "it worked when I tried it"... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-01 23:00 Message: Logged In: YES user_id=21627 I certainly agree with only treating .zip as indication for zipfiles. On a case insensitive file system, you can put .zip into sys.path and it will still find .ZIP. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-12-01 22:34 Message: Logged In: YES user_id=113328 I've now taken Neal's patch and integrated my changes. I'll check it through again, and run a few more tests, and then upload the result (I've had problems with cvs update, so I'm downloading a new copy of CVS python first). Most things look OK. There are a couple of issues with case- insensitive filesystems. The first is that the cache of os.listdir results is (case- sensitively) keyed on directory name. I don't see this as an issue as (a) I'd expect the case used to remain constant (who's going to change a directory in sys.path at runtime to the same name with a different case???) and (b) it's only an efficiency hit, not an error, in any case. The second issue is more problematic. Zip files on sys.path are recognised (see add_zip_names()) by the extension ".zip" (case sensitively). It's arguable that on case-insensitive filesystems, this check should also be case insensitive. But finding that a file is on a case-insensitive filesystem is, I believe, not possible. And using a case-insensitive test all the time isn't right either. I'd say that we should just *define* the algorithm as only treating files ending in ".zip" (case sensitive) as zip files. It doesn't seem to be a problem in practice. I'll try to find some way to fit that into the documentation... Apart from this issue, I've seen no other problems with the patch. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-11-29 21:11 Message: Logged In: YES user_id=113328 My problem turns out to be an interaction with the new "universal newline support". In find_module, within the switch(path_type), case PY_IMP_LISTDIR, the section of code marked /* Search the list of suffixes: .pyc, .pyd, ... */ tries to do fopen(buf, fdp->mode). But .py files are now mode 'U' (universal newline) which is not a valid mode for fopen (). I've made a fix, but I'm not sure how reliable it is. On a related note, I'm not 100% sure how robust the code is in the presence of case-insensitive filesystems. I'm way out of my depth in this code, so I don't know if I'll be able to fix it, but I'll have a look (and I'll look at your version of the patch, as well). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-29 18:47 Message: Logged In: YES user_id=33168 Paul, thanks for taking this up. I made very little progress on this I have attached my version of the diffs. I had some problems with the original patch which I was never able to correct. For example, I think it was not possible to run python from a local build env't. It appeared that python had to be installed for everything to work. See the problem in bug 586680 (also in site.py). That should probably be addressed and was part of my problem. I tried to simplify the code some, so you should see some differences between the patch I attached and the original. These are not as important as making the patch work properly, both when installed and running from a build env't. I will try to take a look at your problem later, but it may take a while. Let me know if you make progress. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-11-29 11:57 Message: Logged In: YES user_id=113328 Bad news. I've just hit problems with the patched Python - when I start python.exe, it reports "cannot import site" and seems unable to locate the standard library. (This when I run python from the PCBuild directory). I built a clean CVS version, and don't see this problem. Can anyone else reproduce this, or help me diagnose it? I don't understand Jim's changes well enough to see what might be the problem (I updated the patch purely mechanically). ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-11-29 11:40 Message: Logged In: YES user_id=113328 Uploaded file foo.zip, needed (in lib\test directory) for the changes to test_import.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645650&group_id=5470 From noreply@sourceforge.net Tue Dec 3 14:08:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Dec 2002 06:08:19 -0800 Subject: [Patches] [ python-Patches-645650 ] Import from Zip Archive Message-ID: Patches item #645650, was opened at 2002-11-29 11:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645650&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Neal Norwitz (nnorwitz) Summary: Import from Zip Archive Initial Comment: This patch supersedes patch 492105. This is an updated version of the patch for imports from a zip file. This version is against current CVS, and includes documentation and tests. The patch builds on Windows, and runs OK. I haven't (yet) run any comprehensive tests, as this is the first time I've set up a build environment, and I'm not sure how to run the tests yet :-( ---------------------------------------------------------------------- >Comment By: Paul Moore (pmoore) Date: 2002-12-03 14:08 Message: Logged In: YES user_id=113328 Understood (I've been watching python-dev). I'm happy to keep working on this while a consensus is reached. Actually, I don't think there's much more I can do, I'm hoping that users of other OS's can test this now.... ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-12-03 14:06 Message: Logged In: YES user_id=113328 Understood (I've been watching python-dev). I'm happy to keep working on this while a consensus is reached. Actually, I don't think there's much more I can do, I'm hoping that users of other OS's can test this now.... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-03 09:31 Message: Logged In: YES user_id=21627 Paul, there is sentiment on python-dev that this patch is unacceptable, because it is incomprehensible. I can sympathize with these feelings, so we need to take the possibility into account that this won't go into Python 2.3. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-02 16:55 Message: Logged In: YES user_id=33168 Hmmm, I thought I used to have changes to PC. Not sure, though. I'll try to take a look at the diffs and test on unix later this evening. I can also add back in any of my changes after you get everything working. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-12-02 16:43 Message: Logged In: YES user_id=113328 Aargh. It looks like Neal's patch is wrong - it didn't include the changes to the files in the PC directory. Also it has a lot of strange changes, like replacing PyEval_CallObject with PyObject_Call - I don't see how this relates to zipfiles. I wasted most of this morning trying to juggle too many patches, to no avail. I think I'm going to have to revert to my patch, get it applied to the CVS version, and upload that. Neal, I agree with a lot of the changes you made, but they'll need redoing - can you apply my patch to a clean checkout and redo your tidying up? The patch I'm uploading with this comment builds cleanly for me on Windows 2000, and passes the supplied tests. You need to apply the patch, then put the 2 included zipfiles in the lib/test directory. I'd be very grateful if someone could test this on Unix and/or Mac, and update it where necessary. I've not tested these platforms, but I'm assuming that Jim's original code worked there. There are also other areas which seem strange (the big block of deleted code in sysmodule.c worries me - but I see no failures because of it, so I've left it unchanged) and comments would be very helpful, but in the absence of anything better I'm sticking with "it worked when I tried it"... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-01 23:00 Message: Logged In: YES user_id=21627 I certainly agree with only treating .zip as indication for zipfiles. On a case insensitive file system, you can put .zip into sys.path and it will still find .ZIP. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-12-01 22:34 Message: Logged In: YES user_id=113328 I've now taken Neal's patch and integrated my changes. I'll check it through again, and run a few more tests, and then upload the result (I've had problems with cvs update, so I'm downloading a new copy of CVS python first). Most things look OK. There are a couple of issues with case- insensitive filesystems. The first is that the cache of os.listdir results is (case- sensitively) keyed on directory name. I don't see this as an issue as (a) I'd expect the case used to remain constant (who's going to change a directory in sys.path at runtime to the same name with a different case???) and (b) it's only an efficiency hit, not an error, in any case. The second issue is more problematic. Zip files on sys.path are recognised (see add_zip_names()) by the extension ".zip" (case sensitively). It's arguable that on case-insensitive filesystems, this check should also be case insensitive. But finding that a file is on a case-insensitive filesystem is, I believe, not possible. And using a case-insensitive test all the time isn't right either. I'd say that we should just *define* the algorithm as only treating files ending in ".zip" (case sensitive) as zip files. It doesn't seem to be a problem in practice. I'll try to find some way to fit that into the documentation... Apart from this issue, I've seen no other problems with the patch. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-11-29 21:11 Message: Logged In: YES user_id=113328 My problem turns out to be an interaction with the new "universal newline support". In find_module, within the switch(path_type), case PY_IMP_LISTDIR, the section of code marked /* Search the list of suffixes: .pyc, .pyd, ... */ tries to do fopen(buf, fdp->mode). But .py files are now mode 'U' (universal newline) which is not a valid mode for fopen (). I've made a fix, but I'm not sure how reliable it is. On a related note, I'm not 100% sure how robust the code is in the presence of case-insensitive filesystems. I'm way out of my depth in this code, so I don't know if I'll be able to fix it, but I'll have a look (and I'll look at your version of the patch, as well). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-29 18:47 Message: Logged In: YES user_id=33168 Paul, thanks for taking this up. I made very little progress on this I have attached my version of the diffs. I had some problems with the original patch which I was never able to correct. For example, I think it was not possible to run python from a local build env't. It appeared that python had to be installed for everything to work. See the problem in bug 586680 (also in site.py). That should probably be addressed and was part of my problem. I tried to simplify the code some, so you should see some differences between the patch I attached and the original. These are not as important as making the patch work properly, both when installed and running from a build env't. I will try to take a look at your problem later, but it may take a while. Let me know if you make progress. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-11-29 11:57 Message: Logged In: YES user_id=113328 Bad news. I've just hit problems with the patched Python - when I start python.exe, it reports "cannot import site" and seems unable to locate the standard library. (This when I run python from the PCBuild directory). I built a clean CVS version, and don't see this problem. Can anyone else reproduce this, or help me diagnose it? I don't understand Jim's changes well enough to see what might be the problem (I updated the patch purely mechanically). ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-11-29 11:40 Message: Logged In: YES user_id=113328 Uploaded file foo.zip, needed (in lib\test directory) for the changes to test_import.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645650&group_id=5470 From noreply@sourceforge.net Tue Dec 3 14:31:43 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Dec 2002 06:31:43 -0800 Subject: [Patches] [ python-Patches-645650 ] Import from Zip Archive Message-ID: Patches item #645650, was opened at 2002-11-29 06:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645650&group_id=5470 Category: Core (C code) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Neal Norwitz (nnorwitz) Summary: Import from Zip Archive Initial Comment: This patch supersedes patch 492105. This is an updated version of the patch for imports from a zip file. This version is against current CVS, and includes documentation and tests. The patch builds on Windows, and runs OK. I haven't (yet) run any comprehensive tests, as this is the first time I've set up a build environment, and I'm not sure how to run the tests yet :-( ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-03 09:31 Message: Logged In: YES user_id=33168 Paul, I didn't get a chance to review/test the patch. But as I just said in python-dev, I think it's worthwhile. Guido seems to agree. I'll try to test on Linux soon. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-12-03 09:08 Message: Logged In: YES user_id=113328 Understood (I've been watching python-dev). I'm happy to keep working on this while a consensus is reached. Actually, I don't think there's much more I can do, I'm hoping that users of other OS's can test this now.... ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-12-03 09:06 Message: Logged In: YES user_id=113328 Understood (I've been watching python-dev). I'm happy to keep working on this while a consensus is reached. Actually, I don't think there's much more I can do, I'm hoping that users of other OS's can test this now.... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-03 04:31 Message: Logged In: YES user_id=21627 Paul, there is sentiment on python-dev that this patch is unacceptable, because it is incomprehensible. I can sympathize with these feelings, so we need to take the possibility into account that this won't go into Python 2.3. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-02 11:55 Message: Logged In: YES user_id=33168 Hmmm, I thought I used to have changes to PC. Not sure, though. I'll try to take a look at the diffs and test on unix later this evening. I can also add back in any of my changes after you get everything working. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-12-02 11:43 Message: Logged In: YES user_id=113328 Aargh. It looks like Neal's patch is wrong - it didn't include the changes to the files in the PC directory. Also it has a lot of strange changes, like replacing PyEval_CallObject with PyObject_Call - I don't see how this relates to zipfiles. I wasted most of this morning trying to juggle too many patches, to no avail. I think I'm going to have to revert to my patch, get it applied to the CVS version, and upload that. Neal, I agree with a lot of the changes you made, but they'll need redoing - can you apply my patch to a clean checkout and redo your tidying up? The patch I'm uploading with this comment builds cleanly for me on Windows 2000, and passes the supplied tests. You need to apply the patch, then put the 2 included zipfiles in the lib/test directory. I'd be very grateful if someone could test this on Unix and/or Mac, and update it where necessary. I've not tested these platforms, but I'm assuming that Jim's original code worked there. There are also other areas which seem strange (the big block of deleted code in sysmodule.c worries me - but I see no failures because of it, so I've left it unchanged) and comments would be very helpful, but in the absence of anything better I'm sticking with "it worked when I tried it"... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-01 18:00 Message: Logged In: YES user_id=21627 I certainly agree with only treating .zip as indication for zipfiles. On a case insensitive file system, you can put .zip into sys.path and it will still find .ZIP. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-12-01 17:34 Message: Logged In: YES user_id=113328 I've now taken Neal's patch and integrated my changes. I'll check it through again, and run a few more tests, and then upload the result (I've had problems with cvs update, so I'm downloading a new copy of CVS python first). Most things look OK. There are a couple of issues with case- insensitive filesystems. The first is that the cache of os.listdir results is (case- sensitively) keyed on directory name. I don't see this as an issue as (a) I'd expect the case used to remain constant (who's going to change a directory in sys.path at runtime to the same name with a different case???) and (b) it's only an efficiency hit, not an error, in any case. The second issue is more problematic. Zip files on sys.path are recognised (see add_zip_names()) by the extension ".zip" (case sensitively). It's arguable that on case-insensitive filesystems, this check should also be case insensitive. But finding that a file is on a case-insensitive filesystem is, I believe, not possible. And using a case-insensitive test all the time isn't right either. I'd say that we should just *define* the algorithm as only treating files ending in ".zip" (case sensitive) as zip files. It doesn't seem to be a problem in practice. I'll try to find some way to fit that into the documentation... Apart from this issue, I've seen no other problems with the patch. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-11-29 16:11 Message: Logged In: YES user_id=113328 My problem turns out to be an interaction with the new "universal newline support". In find_module, within the switch(path_type), case PY_IMP_LISTDIR, the section of code marked /* Search the list of suffixes: .pyc, .pyd, ... */ tries to do fopen(buf, fdp->mode). But .py files are now mode 'U' (universal newline) which is not a valid mode for fopen (). I've made a fix, but I'm not sure how reliable it is. On a related note, I'm not 100% sure how robust the code is in the presence of case-insensitive filesystems. I'm way out of my depth in this code, so I don't know if I'll be able to fix it, but I'll have a look (and I'll look at your version of the patch, as well). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-29 13:47 Message: Logged In: YES user_id=33168 Paul, thanks for taking this up. I made very little progress on this I have attached my version of the diffs. I had some problems with the original patch which I was never able to correct. For example, I think it was not possible to run python from a local build env't. It appeared that python had to be installed for everything to work. See the problem in bug 586680 (also in site.py). That should probably be addressed and was part of my problem. I tried to simplify the code some, so you should see some differences between the patch I attached and the original. These are not as important as making the patch work properly, both when installed and running from a build env't. I will try to take a look at your problem later, but it may take a while. Let me know if you make progress. ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-11-29 06:57 Message: Logged In: YES user_id=113328 Bad news. I've just hit problems with the patched Python - when I start python.exe, it reports "cannot import site" and seems unable to locate the standard library. (This when I run python from the PCBuild directory). I built a clean CVS version, and don't see this problem. Can anyone else reproduce this, or help me diagnose it? I don't understand Jim's changes well enough to see what might be the problem (I updated the patch purely mechanically). ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2002-11-29 06:40 Message: Logged In: YES user_id=113328 Uploaded file foo.zip, needed (in lib\test directory) for the changes to test_import.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=645650&group_id=5470 From noreply@sourceforge.net Tue Dec 3 18:09:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Dec 2002 10:09:55 -0800 Subject: [Patches] [ python-Patches-646824 ] documentation build error Message-ID: Patches item #646824, was opened at 2002-12-02 09:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=646824&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: documentation build error Initial Comment: there is one extra "\end{description}" in Doc/lib/libstdtypes.tex. Patch attached. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-03 19:09 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as 1.112. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=646824&group_id=5470 From noreply@sourceforge.net Tue Dec 3 18:32:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Dec 2002 10:32:58 -0800 Subject: [Patches] [ python-Patches-458383 ] Start of a bgen tutorial Message-ID: Patches item #458383, was opened at 2001-09-04 15:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=458383&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Jack Jansen (jackjansen) Summary: Start of a bgen tutorial Initial Comment: Jack, this is (maybe) a start of a bgen tutorial. It explains some of the things I understand now from bgen. It is not finished, also it uses windows specific examples. I'm requesting comments on the general approach. I have also sent it to you via email, but probably you have not seen it. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-03 19:32 Message: Logged In: YES user_id=21627 Closing it as rejected. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 11:36 Message: Logged In: YES user_id=21627 If there is no action on this patch by Nov 1, 2002, I recommend to reject it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2001-11-14 17:02 Message: Logged In: YES user_id=45365 Thomas, I'm leaving your tutorial in the patch section for now. My reason for this is that you give a nice explanation of how bgen generates code, and how you can then build the module (nifty, that one!), but you skip the whole "front end" bit: how bgen parses your C header files, and how you add support for the various C objects to Python. And in my opinion that is the biggest stumbling block for people starting to work with bgen. I'll try and come up with a framework for a tutorial, if I have something I'll let you know so you can shine your light on it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=458383&group_id=5470 From noreply@sourceforge.net Tue Dec 3 18:33:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 03 Dec 2002 10:33:32 -0800 Subject: [Patches] [ python-Patches-641685 ] Use .dylib for shared objects on MacOS X Message-ID: Patches item #641685, was opened at 2002-11-21 01:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=641685&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) >Assigned to: Jack Jansen (jackjansen) Summary: Use .dylib for shared objects on MacOS X Initial Comment: This patch enables python to recognize .dylib as a valid shared library extension on MacOS X/Darwin. Python will also use .dylib as the extension for native-code python modules; .so files are still recognized for backward compatibility. The reason for writing this patch was that setup.py failes to recognize the existince of openssl because there is only a shared library with suffix .dylib. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2002-12-03 13:33 Message: Logged In: YES user_id=11375 Reassigning to Jack. (It doesn't look like find_library_file in setup.jaguar.py is actually used, so maybe you could just delete it.) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-27 08:48 Message: Logged In: YES user_id=11375 I've checked in my setup.py patch, and the Lib/distutils/extension.py portion of Ronald's patch. Is the rest of Ronald's patch OK? Should I check that in, too? Jack reports that there's also a duplicate find_library_file in Mac/OSX/setup.jaguar.py. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-27 04:27 Message: Logged In: YES user_id=580910 I don't have checkin priviliges for the Python CVS repository, so feel free to checkin my patches if they are correct. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-11-26 17:29 Message: Logged In: YES user_id=45365 I think that if we keep .so as an allowed extension for dynamically loaded modules we're okay for both 2.3a0 and 2.2.X. Unless I misunderstand how compatibility between micro-releases is suppoosed to work, should it be forward compatible too? I.e. if 2.2.3 would create dynamic modules with .dylib they won't be useable in 2.2.2. If that is a problem then I think we should keep .so as the default and allow .dylib (for 2.2.X, for 2.3 we should do the right thing). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-26 12:28 Message: Logged In: YES user_id=11375 Noted; updated version of the patch attached that uses os.path.dirname. I'll check it in after testing it on the Mac. Thanks! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-26 11:11 Message: Logged In: YES user_id=21627 Andrew, that part is fine, please check it in. There is on pitfall, though: if one of the std_dirs is a prefix of one of the paths, and the library is found in that path, the function will return the wrong result. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-26 10:37 Message: Logged In: YES user_id=11375 I can't pronounce on the rest of Ronald's patch, but the patch to distutils/extension.py seems obviously correct and should be committed in any case. Ronald, do you have CVS access or should I check it in? ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-25 03:00 Message: Logged In: YES user_id=580910 Somehow I didn't upload the patch when I created this thread. Here it is. ---------------------------------------------------------------------- Comment By: Dan Wolfe (dkwolfe) Date: 2002-11-24 02:16 Message: Logged In: YES user_id=80173 I previously assumed that OS X was capable of linking against .so file. This turns out not to be the case (thanks Ronald for making me a believer!) and Ronald's original patch would have also fixed the problem. I tested both Ronald's and akuchling patches together, along with a minor modification to unixcompiler.py to remove the two dylib blocks from the find_library_file function (no longer needed with Ronald's patches) under 10.2.2, and everything works fine in a framework and regular Unix build. Only thing to worry about is that the modules in the lib-dynload directory now have a .dylib suffix. The readme should probably be updated to tell the user they need to manually remove these files. Also, the test_socket_ssl.py is not run unless a -u network is made part of the test cmd line. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2002-11-22 16:20 Message: Logged In: YES user_id=580910 Please keep in mind that the .so suffix is not a valid shared-library suffix on MacOS X: The linker will not check for 'libfoo.so' if you link with '-lfoo'. It might therefore be prudent to look for the .dylib before looking for a .so (if you want to look for a .so at all). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-22 08:36 Message: Logged In: YES user_id=11375 I've tried my patch now, and with it SSL support is automatically built on MacOS X. Whether or not this fixes the bug, though, I think this patch should be applied to cut down on some code duplication. If someone else can make a quick sanity-check on the patch in case of silly errors, I'll check it in. (Is it a bugfix candidate? Not sure, but I'm leaning toward "yes".) I've also revised the patch to make its behaviour completely compatible with the unpatched version of find_library_file; bug-in-waiting pointed out by Dan Wolfe. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-21 15:43 Message: Logged In: YES user_id=11375 I've attached a copy of my still-untested patch that fixes the code duplication in setup.py. I'll try to test it this evening. ---------------------------------------------------------------------- Comment By: Dan Wolfe (dkwolfe) Date: 2002-11-21 14:19 Message: Logged In: YES user_id=80173 There's a problem regarding Ronald's SSL patches - they make setup assume that every shared library is a .dylib rather than either a .so or .dylib, which breaks compatibility.... After some late night investigation, I found that the source of the problem is distutils. We previously had a problem under Mac OS X where it wasn't finding the .dylib libraries for libz and other similar .dylib libraries - both user and system installed. Someone came up with a patch and this can be found in /distutils/unixcompiler.py around line 278 in the function find_library_file. Basically, it just adds another check to look for .dylib if it can't find the .so file. The unixcompiler.py file inherits from the ccompiler.py file which has a stub routine for this function. For the longest time I thought the function in unixcompiler.py was being called and was pulling my hair out trying to figure out why it wasn't being finding the ssl library since it only looked for .a and .so files... It turns out that setup.py also implements a function by the SAME name, but with different parameters and instead of returning a true/false to indicate whether the library exists, it returns the pathname to the library. This function, unfortunately, was NOT previously modify to support dylibs and as a result only .a and .so files would be searched for. Below is a diff that fixes the problem simply by adding another check for a dylib file and returning the results if it exists. lobo% diff -u /Users/lobo/Desktop/Python-2.2.2/setupold.py /Users/lobo/Desktop/Python-2.2.2/setup.py --- /Users/lobo/Desktop/Python-2.2.2/setupold.py Wed Oct 9 17:59:16 2002 +++ /Users/lobo/Desktop/Python-2.2.2/setup.py Thu Nov 21 09:12:43 2002 @@ -44,6 +44,10 @@ filename = compiler.library_filename(libname, lib_type='shared') result = find_file(filename, std_dirs, paths) if result is not None: return result + + filename = compiler.library_filename(libname, lib_type='dylib') + result = find_file(filename, std_dirs, paths) + if result is not None: return result filename = compiler.library_filename(libname, lib_type='static') result = find_file(filename, std_dirs, paths) I've minimally tested it using the normal non framework installed and it appears to function correctly. Enjoy. (sorry about not uploading a patch but SF crashes IE and Chimera doesn't allow a attachement....) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=641685&group_id=5470 From noreply@sourceforge.net Wed Dec 4 10:19:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Dec 2002 02:19:38 -0800 Subject: [Patches] [ python-Patches-558547 ] SocketServer: don't flush closed wfile Message-ID: Patches item #558547, was opened at 2002-05-21 08:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=558547&group_id=5470 Category: Library (Lib) Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) >Assigned to: Anthony Baxter (anthonybaxter) Summary: SocketServer: don't flush closed wfile Initial Comment: I've found the following patch (well, ok, subclassed, but the patch is the same) makes SocketServer more robust. If wfile is already closed (prior to the finish() method being called), don't try to flush() it. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-04 11:19 Message: Logged In: YES user_id=21627 I think the patch is fine. Please apply it. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-06-06 03:25 Message: Logged In: YES user_id=29957 I'm not _entirely_ sure why it happens that finish() gets called twice - I suspect some form of race condition. Since many/most other similar functions in the python library silently ignore a close()-type operation (e.g. file.close(); file.close()). As far as the 'closed' attribute, well, yes, someone could subclass StreamRequestHandler.setup, and leave StreamRequestHandler.finish as-is. But then, it's only got two methods, so this is highly unlikely. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-02 14:44 Message: Logged In: YES user_id=21627 Can you explain how this problem can ever occur? I.e. why would there be two calls to finish? Also, is there a guarantee that every thing returned by makefile has a .closed attribute? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-21 08:25 Message: Logged In: YES user_id=29957 mm. i typ reel gud sometimes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=558547&group_id=5470 From noreply@sourceforge.net Wed Dec 4 10:25:02 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Dec 2002 02:25:02 -0800 Subject: [Patches] [ python-Patches-551977 ] Regression exceptions for cygwin Message-ID: Patches item #551977, was opened at 2002-05-03 21:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=551977&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) >Assigned to: Jason Tishler (jlt63) Summary: Regression exceptions for cygwin Initial Comment: This patch updates regrtest.py to understand which tests are normally skipped under Cygwin. The list of tests was verified with the Cygwin Python maintainer. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-04 11:25 Message: Logged In: YES user_id=21627 Jason, can you take a look and apply the patch if it looks ok? It appears that the official policy is that all tests that "normally" can't run should be listed as expected skips. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-07 18:23 Message: Logged In: YES user_id=21627 I'm quite unhappy with the entire _expectations mechanism. E.g. the fact that test_email_codecs is skipped has *nothing* to do with the distribution being build on Windows, or with Cygwin; I'd rather see the expected fails to take into account available resources (e.g. absence of the Japanese codecs is a good reason for skipping the tests). ---------------------------------------------------------------------- Comment By: Gerald S. Williams (gsw_agere) Date: 2002-05-07 15:21 Message: Logged In: YES user_id=329402 test_email_codecs is skipped unless the optional Japanese codecs are installed (this is also in the exceptions list for win32 and linux2). Cygwin does not currently support large files, locales, or unicode file system semantics (test_unicode_file is also in the exceptions list for all but win32, test_locale is in most of them, and test_largefile is in *all* of them). test_winreg is a stickier one. This is clearly specific to Windows, and the goal of Cygwin is to present a UNIX-like interface, not a Windows-like interface. There are patches that will enable this support under Cygwin Python, although they pull in quite a bit of the Windows-specific code and would create maintenance issues for Python's codebase. At present this is considered unsupported in Cygwin Python. There are three additional tests that are in all or almost all of the exception lists: test_curses test_socket_ssl test_socketserver These are disabled unless "-u" is used to specifically enable them. It appears that these should also be added to the list. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 10:47 Message: Logged In: YES user_id=21627 I'd like to hear the rationale for skipping test_email_codecs test_largefile test_locale test_unicode_file test_winreg All of those *should* work just fine; if they don't, this indicates a bug in this port. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=551977&group_id=5470 From noreply@sourceforge.net Wed Dec 4 10:26:15 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Dec 2002 02:26:15 -0800 Subject: [Patches] [ python-Patches-551960 ] Add check for setrlimit() support Message-ID: Patches item #551960, was opened at 2002-05-03 20:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=551960&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) >Assigned to: Jason Tishler (jlt63) Summary: Add check for setrlimit() support Initial Comment: The new test_resource test calls resource.setrlimit() to change the file size limits. This fails on Cygwin, which supports setrlimit() and getrlimit(), just not changing that particular setting. (The same would apply to any other platforms that has those functions but not that particular feature.) Since that getrlimit() works, and setrlimit() can be used for other reasons, a check for sys.platform was added to that part of the test. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-04 11:26 Message: Logged In: YES user_id=21627 Jason, can you please review this patch, and apply it if it looks ok? If not, please unassign it. ---------------------------------------------------------------------- Comment By: Gerald S. Williams (gsw_agere) Date: 2002-06-03 14:44 Message: Logged In: YES user_id=329402 Since there are other limits that can be set via setrlimit(), failing the entire test due to a limitation on setrlimit(FSIZE) did not seem appropriate (even though this is currently the only resource limit that is tested). Besides, even though setrlimit(FSIZE) isn't allowed to change the value, it should still be able to set it to the values returned via getrlimit(), and should still report ValueError for extremely large values for either cur or max. So the test is meaningful even on systems that aren't allowed to lower the FSIZE limit. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-06-02 19:53 Message: Logged In: YES user_id=21627 I'm not sure I understand the logic in the modified setrlimit(FSIZE) case. If setting the limit fails, it seems that the entire test should be skipped. Raising TestSkipped might be appropriate, to indicate that the result of the test is not trustworthy. ---------------------------------------------------------------------- Comment By: Gerald S. Williams (gsw_agere) Date: 2002-05-06 15:11 Message: Logged In: YES user_id=329402 Cygwin Python raises ValueError when you call setrlimit() for RLIMIT_FSIZE. That limit is hardcoded at infinity and cannot be changed. I have submitted an alternative patch that looks for ValueError rather than checking sys.platform. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 10:44 Message: Logged In: YES user_id=21627 Don't check for systems, check for features instead. In this specific case, what error does Cygwin report? Could that be used to deal with the missing feature in a more general way? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=551960&group_id=5470 From noreply@sourceforge.net Wed Dec 4 10:27:32 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Dec 2002 02:27:32 -0800 Subject: [Patches] [ python-Patches-549901 ] use readline in pydoc.help if available Message-ID: Patches item #549901, was opened at 2002-04-28 23:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=549901&group_id=5470 Category: Library (Lib) Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Jeremy Yallop (yallop) Assigned to: Nobody/Anonymous (nobody) Summary: use readline in pydoc.help if available Initial Comment: Interactive help (via pydoc.interact in 2.1 onwards) doesn't use GNU readline. This is easily amended by using raw_input() instead of input.readline(). The patch assumes that Helper.input is sys.stdin when Helper.interact() is called but can be fixed trivially if this assumption is invalid.. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-04 11:27 Message: Logged In: YES user_id=21627 Rejecting the patch because of lack of activity. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-13 16:13 Message: Logged In: YES user_id=21627 Jeremy, are you willing to revise your patch, considering Guido's comment? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-07 14:30 Message: Logged In: YES user_id=6380 I like the idea, but not the execution. It should only use raw_input when self.input is sys.stdin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=549901&group_id=5470 From noreply@sourceforge.net Wed Dec 4 10:55:37 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Dec 2002 02:55:37 -0800 Subject: [Patches] [ python-Patches-648322 ] asyncore loop_once and remove poll2 Message-ID: Patches item #648322, was opened at 2002-12-04 10:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=648322&group_id=5470 Category: Library (Lib) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kjetil Jacobsen (kjetilja) Assigned to: Nobody/Anonymous (nobody) Summary: asyncore loop_once and remove poll2 Initial Comment: this patch does two things to asyncore.py, none of them should break any existing code which uses the module: 1) remove the (broken) poll2 function, and rather make a reference from poll2 to poll3 in the module namespace (i.e. if someone actually uses the poll2 function, poll3 will be called instead). 2) add a function loop_once which performs the asyncore loop once instead of until the socket map is empty. asyncore.loop_once has the same function signature as asyncore.loop. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=648322&group_id=5470 From noreply@sourceforge.net Thu Dec 5 02:01:11 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 04 Dec 2002 18:01:11 -0800 Subject: [Patches] [ python-Patches-622537 ] dummy_thread.py implementation Message-ID: Patches item #622537, was opened at 2002-10-13 03:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=622537&group_id=5470 Category: Library (Lib) Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: dummy_thread.py implementation Initial Comment: As mentioned in Zack Weinberg's Python-dev thread, "A few lessons from the tempfile.py rewrite", it was brought up that not having thread in all distributions is a pain because you have to write around instances of it not existing. Guido suggested the compromise of having a dummy_thread.py so that one could do: try: import thread as _thread except ImportError: import dummy_thread as _thread This is specific comment can be found at http://mail.python.org/pipermail/python-dev/2002-August/027985.html . Well, I decided to implement dummy_thread.py . I have tested it against test_thread.py and test_threading.py by editing the files locally to import dummy_thread as thread. All tests did pass. The only thing that is not necessarily straight-forward in the implementation is that for non-blocking lock.acquire() calls, the code actually checks to see if the lock is available; blocking calls just automatically acquire the lock since blocking when there is not real threading would not big good. =) It was also to appease the assert demons in threading.py for Condition objects since Condition._is_owned() did not like having lock.acquire() always succeed. As for adding regression tests, one could just run test_thread.py specifically against dummy_thread.py . The tougher test, though, was getting test_threading.py to work with threading.py importing dummy_thread. I am not, as of this exact moment, uploading any patches to add regression tests since I wrote this on a whim and I am leaving for vacation on 2002-10-14. I will be back by November 1, though, and I can try to come up with how to integrate regression tests then if no one has beaten me to it. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2002-12-04 21:01 Message: Logged In: YES user_id=31435 Deleted all attachments, at Brett's request. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2002-11-27 22:07 Message: Logged In: YES user_id=357491 So all patches and files needed for dummy_thread to be accepted into the stdlib are now uploaded. The various parts of this patch (which all don't need to be accepted which is why I did it the way I have) are as follows: The module: dummy_thread.py is the module. test_dummy_thread.py is the testing suite. New test files: Since I had to basically simulate threads, I wrote the tests as if I was going to test the thread module. So I wrote test_dummy_thread.py in such a way that ``test_main()`` can accept a module to use as the thread implementation. The included test_thread.py uses test_dummy_thread.py to test the thread module. It is more in-depth then the current implementation. If my version of test_thread.py is used, then Lib/test/output/test_thread will need to be removed (my testing suite uses PyUnit). As an aside, dummy_thread.py does pass the current test_thread.py testing suite. Changed modules: added_dummy.diff is a diff that changes Queue, threading, and tempfile to use dummy_thread when thread is not available. They all still pass their tests when using dummy_thread (dummy_thread has one design decision just to pass threading's ``assert`` statements; all info is in the doc strings). pydoc can be changed so as to not use threading if the thread module is not available, but there are no tests for the module, so I will let the person who checks this in make the call whether it should be added. I tried it and everything seemed to work fine so I personally think it is safe for pydoc to stay as it is. Documentation: libdummythread.tex is my attempt at writing the docs for dummy_thread. Since it basically mirrors thread, I state to use thread's docs for API info and explain what dummy_thread is for. doc_dummy.tex adds notes to libthread.tex and libthreading.tex mentioning dummy_thread and in threading's case how to make sure that you only import threading if you want only true threading. Mentioning Queue's use of dummy_thread as backup could be useful, but since there is no lock-up problems I don't see the need. dummy_thread has only one issue with replacing thread in all cases: blocking I/O. Both test_asynchat and test_socket block on their threads because they spawn both server and client threads that block waiting for each other. But both modules import thread explicitly, so there is no worry with these modules running with dummy_thread as their thread implementation. I also couldn't run test_socketserver because I can't run test_normalization. But other then those three tests, all other tests pass both under a regular debug compile and a --without-thread compile; things just run a little slower. =) The 2002-10-13 copy of dummy_thread.py can be deleted (wish SF would let the patch creator delete files). This is my first big patch that touches docs, test, stdlib modules and has a new doc file. Just thought I should warn you. =) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=622537&group_id=5470 From noreply@sourceforge.net Thu Dec 5 14:41:42 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Dec 2002 06:41:42 -0800 Subject: [Patches] [ python-Patches-551977 ] Regression exceptions for cygwin Message-ID: Patches item #551977, was opened at 2002-05-03 11:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=551977&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) >Assigned to: Martin v. Löwis (loewis) Summary: Regression exceptions for cygwin Initial Comment: This patch updates regrtest.py to understand which tests are normally skipped under Cygwin. The list of tests was verified with the Cygwin Python maintainer. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2002-12-05 05:41 Message: Logged In: YES user_id=86216 OK to check in the slightly different, attached patch? The differences between Jerry's and mine are the following: 1. added the following as suggested by Jerry: test_curses test_socket_ssl test_socketserver 2. removed test_bsddb because it is supported now ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-04 01:25 Message: Logged In: YES user_id=21627 Jason, can you take a look and apply the patch if it looks ok? It appears that the official policy is that all tests that "normally" can't run should be listed as expected skips. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-07 08:23 Message: Logged In: YES user_id=21627 I'm quite unhappy with the entire _expectations mechanism. E.g. the fact that test_email_codecs is skipped has *nothing* to do with the distribution being build on Windows, or with Cygwin; I'd rather see the expected fails to take into account available resources (e.g. absence of the Japanese codecs is a good reason for skipping the tests). ---------------------------------------------------------------------- Comment By: Gerald S. Williams (gsw_agere) Date: 2002-05-07 05:21 Message: Logged In: YES user_id=329402 test_email_codecs is skipped unless the optional Japanese codecs are installed (this is also in the exceptions list for win32 and linux2). Cygwin does not currently support large files, locales, or unicode file system semantics (test_unicode_file is also in the exceptions list for all but win32, test_locale is in most of them, and test_largefile is in *all* of them). test_winreg is a stickier one. This is clearly specific to Windows, and the goal of Cygwin is to present a UNIX-like interface, not a Windows-like interface. There are patches that will enable this support under Cygwin Python, although they pull in quite a bit of the Windows-specific code and would create maintenance issues for Python's codebase. At present this is considered unsupported in Cygwin Python. There are three additional tests that are in all or almost all of the exception lists: test_curses test_socket_ssl test_socketserver These are disabled unless "-u" is used to specifically enable them. It appears that these should also be added to the list. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 00:47 Message: Logged In: YES user_id=21627 I'd like to hear the rationale for skipping test_email_codecs test_largefile test_locale test_unicode_file test_winreg All of those *should* work just fine; if they don't, this indicates a bug in this port. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=551977&group_id=5470 From noreply@sourceforge.net Thu Dec 5 14:45:03 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Dec 2002 06:45:03 -0800 Subject: [Patches] [ python-Patches-551977 ] Regression exceptions for cygwin Message-ID: Patches item #551977, was opened at 2002-05-03 21:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=551977&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) >Assigned to: Jason Tishler (jlt63) Summary: Regression exceptions for cygwin Initial Comment: This patch updates regrtest.py to understand which tests are normally skipped under Cygwin. The list of tests was verified with the Cygwin Python maintainer. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-05 15:45 Message: Logged In: YES user_id=21627 Sure. Go ahead! ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-12-05 15:41 Message: Logged In: YES user_id=86216 OK to check in the slightly different, attached patch? The differences between Jerry's and mine are the following: 1. added the following as suggested by Jerry: test_curses test_socket_ssl test_socketserver 2. removed test_bsddb because it is supported now ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-04 11:25 Message: Logged In: YES user_id=21627 Jason, can you take a look and apply the patch if it looks ok? It appears that the official policy is that all tests that "normally" can't run should be listed as expected skips. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-07 18:23 Message: Logged In: YES user_id=21627 I'm quite unhappy with the entire _expectations mechanism. E.g. the fact that test_email_codecs is skipped has *nothing* to do with the distribution being build on Windows, or with Cygwin; I'd rather see the expected fails to take into account available resources (e.g. absence of the Japanese codecs is a good reason for skipping the tests). ---------------------------------------------------------------------- Comment By: Gerald S. Williams (gsw_agere) Date: 2002-05-07 15:21 Message: Logged In: YES user_id=329402 test_email_codecs is skipped unless the optional Japanese codecs are installed (this is also in the exceptions list for win32 and linux2). Cygwin does not currently support large files, locales, or unicode file system semantics (test_unicode_file is also in the exceptions list for all but win32, test_locale is in most of them, and test_largefile is in *all* of them). test_winreg is a stickier one. This is clearly specific to Windows, and the goal of Cygwin is to present a UNIX-like interface, not a Windows-like interface. There are patches that will enable this support under Cygwin Python, although they pull in quite a bit of the Windows-specific code and would create maintenance issues for Python's codebase. At present this is considered unsupported in Cygwin Python. There are three additional tests that are in all or almost all of the exception lists: test_curses test_socket_ssl test_socketserver These are disabled unless "-u" is used to specifically enable them. It appears that these should also be added to the list. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 10:47 Message: Logged In: YES user_id=21627 I'd like to hear the rationale for skipping test_email_codecs test_largefile test_locale test_unicode_file test_winreg All of those *should* work just fine; if they don't, this indicates a bug in this port. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=551977&group_id=5470 From noreply@sourceforge.net Thu Dec 5 15:09:12 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Dec 2002 07:09:12 -0800 Subject: [Patches] [ python-Patches-648998 ] test_command ACL patch Message-ID: Patches item #648998, was opened at 2002-12-05 06:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=648998&group_id=5470 Category: Tests Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jason Tishler (jlt63) Assigned to: Martin v. Löwis (loewis) Summary: test_command ACL patch Initial Comment: Although motived by Cygwin, this patch will prevent test_commands from failing on Unixes that support ACLs. For example, the following is an excerpt from the Solaris ls manpage: ... -rwxrwxrwx+ 1 smith dev 10876 May 16 9:42 part2 The plus sign indicates that there is an ACL associated with the file. ... OK to apply? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=648998&group_id=5470 From noreply@sourceforge.net Thu Dec 5 15:19:58 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Dec 2002 07:19:58 -0800 Subject: [Patches] [ python-Patches-551977 ] Regression exceptions for cygwin Message-ID: Patches item #551977, was opened at 2002-05-03 11:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=551977&group_id=5470 Category: Tests Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Gerald S. Williams (gsw_agere) Assigned to: Jason Tishler (jlt63) Summary: Regression exceptions for cygwin Initial Comment: This patch updates regrtest.py to understand which tests are normally skipped under Cygwin. The list of tests was verified with the Cygwin Python maintainer. ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2002-12-05 06:19 Message: Logged In: YES user_id=86216 Checked in as Lib/test/regrtest.py 1.111. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-05 05:45 Message: Logged In: YES user_id=21627 Sure. Go ahead! ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2002-12-05 05:41 Message: Logged In: YES user_id=86216 OK to check in the slightly different, attached patch? The differences between Jerry's and mine are the following: 1. added the following as suggested by Jerry: test_curses test_socket_ssl test_socketserver 2. removed test_bsddb because it is supported now ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-04 01:25 Message: Logged In: YES user_id=21627 Jason, can you take a look and apply the patch if it looks ok? It appears that the official policy is that all tests that "normally" can't run should be listed as expected skips. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-07 08:23 Message: Logged In: YES user_id=21627 I'm quite unhappy with the entire _expectations mechanism. E.g. the fact that test_email_codecs is skipped has *nothing* to do with the distribution being build on Windows, or with Cygwin; I'd rather see the expected fails to take into account available resources (e.g. absence of the Japanese codecs is a good reason for skipping the tests). ---------------------------------------------------------------------- Comment By: Gerald S. Williams (gsw_agere) Date: 2002-05-07 05:21 Message: Logged In: YES user_id=329402 test_email_codecs is skipped unless the optional Japanese codecs are installed (this is also in the exceptions list for win32 and linux2). Cygwin does not currently support large files, locales, or unicode file system semantics (test_unicode_file is also in the exceptions list for all but win32, test_locale is in most of them, and test_largefile is in *all* of them). test_winreg is a stickier one. This is clearly specific to Windows, and the goal of Cygwin is to present a UNIX-like interface, not a Windows-like interface. There are patches that will enable this support under Cygwin Python, although they pull in quite a bit of the Windows-specific code and would create maintenance issues for Python's codebase. At present this is considered unsupported in Cygwin Python. There are three additional tests that are in all or almost all of the exception lists: test_curses test_socket_ssl test_socketserver These are disabled unless "-u" is used to specifically enable them. It appears that these should also be added to the list. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-06 00:47 Message: Logged In: YES user_id=21627 I'd like to hear the rationale for skipping test_email_codecs test_largefile test_locale test_unicode_file test_winreg All of those *should* work just fine; if they don't, this indicates a bug in this port. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=551977&group_id=5470 From noreply@sourceforge.net Thu Dec 5 16:17:29 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Dec 2002 08:17:29 -0800 Subject: [Patches] [ python-Patches-648998 ] test_command ACL patch Message-ID: Patches item #648998, was opened at 2002-12-05 16:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=648998&group_id=5470 Category: Tests Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Jason Tishler (jlt63) >Assigned to: Jason Tishler (jlt63) Summary: test_command ACL patch Initial Comment: Although motived by Cygwin, this patch will prevent test_commands from failing on Unixes that support ACLs. For example, the following is an excerpt from the Solaris ls manpage: ... -rwxrwxrwx+ 1 smith dev 10876 May 16 9:42 part2 The plus sign indicates that there is an ACL associated with the file. ... OK to apply? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2002-12-05 17:17 Message: Logged In: YES user_id=21627 Looks good. Please apply it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=648998&group_id=5470 From noreply@sourceforge.net Thu Dec 5 16:25:08 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 05 Dec 2002 08:25:08 -0800 Subject: [Patches] [ python-Patches-635933 ] make some type attrs writable Message-ID: Patches item #635933, was opened at 2002-11-09 14:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=635933&group_id=5470 Category: Core (C code) Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: make some type attrs writable Initial Comment: As per discussion on python-dev, this patch makes the following attributes of type objects writable from Python: - __name__ - __bases__ - __mro__ It also relaxes the restriction on not returning __module__ when that's been set to a non-string. This (tiny) part is a 2.2.3 candidate IMHO. It lets the following work: class C(object): pass class D(C): pass class E(object): def meth(self): print 1 d = D() D.__bases__ = (C, E) d.meth() but that's the extent of my testing so far. Needs a test and docs -- if the current behaviour is documented anywhere. Currently, if an assignment to __bases__ would change __base__, it complains (was easiest). Assigned to Guido so he sees it, but anyone else is encouraged to review it! ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2002-12-05 16:25 Message: Logged In: YES user_id=6656 Don't know why this was still open. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-26 14:50 Message: Logged In: YES user_id=6656 OK, I've checked in Objects/typeobject.c revision 2.189 Lib/test/test_descr.py revision 1.163 Misc/NEWS revision 1.545 Doc/whatsnew23.tex revision 1.75 I'll raise the concerns I have about __name__ on python-dev (beats typing into a