[ python-Bugs-777867 ] test_ioctl fails
Bugs item #777867, was opened at 2003-07-25 16:25 Message generated for change (Comment added) made by mdavidoff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777867&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: test_ioctl fails Initial Comment: test_ioctl test test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests ... 223 tests OK. 1 test failed: test_ioctl 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_dbm test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 4 skips unexpected on linux2: test_dbm test_bz2 test_gdbm test_locale make: *** [test] Error 1 My system: * Python from CVS: Python 2.3c1 (#1, Jul 23 2003, 08:31:24) * Debian testing/unstable * Linux pion 2.4.21 #1 Sat Jul 19 10:21:24 EDT 2003 i686 unknown unknown GNU/Linux * gcc (GCC) 3.3.1 20030626 (Debian prerelease) * AMD Athlon XP 1600+ -- Comment By: Monte Davidoff (mdavidoff) Date: 2005-09-23 00:33 Message: Logged In: YES user_id=129 The fix for this bug was included in Patch 1284289: Lib/test/test_ioctl.py -- Fixed bug in import statement for test.test_support. Fixed bug where the test would fail if the test suite was being run in the backgroud. In this case, the TIOCGPGRP ioctl on /dev/tty returns the session ID, not the process group ID. See also bug 780576. -- Comment By: George Yoshida (quiver) Date: 2005-03-19 10:05 Message: Logged In: YES user_id=671362 On a linux box for my work, I had similar fail(test_ioctl and test_ioctl_mutate). My System: * Python : 2.3.3, 2.4 * kernel : 2.4.22 * GCC: 2.95.3 * glibc : 2.2 I don't know why but somehow test_ioctl.py seems to be invoked in the background on 'make test' process, which resuls in 2 fails. Maybe the easiest way to make test_ioctl fail is : $ ./python ./Lib/test/regrtest.py test_ioctl & -- Comment By: Michael Hudson (mwh) Date: 2003-07-28 08:06 Message: Logged In: YES user_id=6656 Heh, yes it certainly would be easier if I (or anyone else) could reproduce this. However, this is the first I've heard of it, and I'd have thought/hoped that there are other people running the release candidates on Debian testing... glibc is very much a guess scapegoat, don't jeopardize your system just for me. I suggested the '-r' thing because it's the sort of thing that can be done in the background. -- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-28 08:00 Message: Logged In: YES user_id=52562 It's always possible that I'm doing something very silly and not reporting it. But, as I am pressed for time, it would be really good if you could get a failure like this running on your own box. Hm. Maybe this means I should just upgrade my glibc. MAIN pion:~$ dpkg --status libc6 | grep ^Version Version: 2.3.1-16 Hm. Okay, I'll add -r to TESTOPTS and run lots of "make test". -- Comment By: Michael Hudson (mwh) Date: 2003-07-28 07:54 Message: Logged In: YES user_id=6656 This is deeply weird. The most likely scenario that some *other* test (or combination of tests, sigh) is tickling a bug in glibc that test_ioctl is revealing. Evidence for/against this could be acquired by adding '-r' to TESTOPTS and running make test a few times. But I still don't understand why running regrtest.py from the shell passes. Unless it's a Heisenbug, or just a flat out bug in the test. Hmm. Ten gets you one that it's test_fork1 that buggers it up. It seems exceedingly unlikely that this points to a real problem in Python's ioctl code. ioctl() is not the easiest thing in the world to write tests for... -- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 05:20 Message: Logged In: YES user_id=52562 Okay, I added "-v" to TESTOPTS in Makefile. test_ioctl test_ioctl (test.test_ioctl.IoctlTests) ... FAIL test_ioctl_mutate (test.test_ioctl.IoctlTests) ... FAIL == FAIL: tes
[ python-Bugs-780576 ] test_ioctl fails
Bugs item #780576, was opened at 2003-07-30 16:04 Message generated for change (Comment added) made by mdavidoff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jean M. Brouwers (jbrouwers) Assigned to: Anthony Baxter (anthonybaxter) Summary: test_ioctl fails Initial Comment: Test case test_ioctl fails when building Python 2.3 on RedHat 8.0, but just one one and not another RedHat 8.0 machine. The initial suspicion was that this failure may be related to this bug report: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=777867 but that was reported on Debian unstable. It could still be a glibc bug that Python is tickling but the glibc libraries are the same one both machines (at least there is no difference in the version numbers from rpm). rpm -qa | grep -i glibc glibc-devel-2.3.2-4.80.6 glibc-kernheaders-2.4-7.20 glibc-common-2.3.2-4.80.6 glibc-2.3.2-4.80.6 -- Comment By: Monte Davidoff (mdavidoff) Date: 2005-09-23 00:35 Message: Logged In: YES user_id=129 The fix for this bug was included in Patch 1284289: Lib/test/test_ioctl.py -- Fixed bug in import statement for test.test_support. Fixed bug where the test would fail if the test suite was being run in the backgroud. In this case, the TIOCGPGRP ioctl on /dev/tty returns the session ID, not the process group ID. See also bug 777867. -- Comment By: Hakanson (hakansonsf) Date: 2004-08-31 15:30 Message: Logged In: YES user_id=1103758 Sorry, that was not helpful: I meant test TIOCGPGRP on a pseudo-tty that the testing process creates. Another alternative would be to test some STREAMS ioctl against a stream/pipe that the process creates. But yes, this quickly gets complicated. -- Comment By: Hakanson (hakansonsf) Date: 2004-08-16 11:08 Message: Logged In: YES user_id=1103758 Maybe test TIOCGPGRP on a file/directory that the test creates anew, instead of /dev/tty. That should definitely match the process group of the current process. -- Comment By: Michael Hudson (mwh) Date: 2004-08-14 06:53 Message: Logged In: YES user_id=6656 Oh, crud. However, if we don't test TIOCGPGRP, what *can* we test? Perhaps we should just test that the call doesn't blow up. -- Comment By: Hakanson (hakansonsf) Date: 2004-08-13 15:57 Message: Logged In: YES user_id=1103758 Folks, I recently completed a build of python-2.3.2 (I realize 2.3.4 is out, but this info should still be relevant) on SPARC/Solaris-9, and as in this bug, the test_ioctl is failing. However, I believe I have found the cause, after running the tests with "-v" added to TESTOPTS in the Makefile. Since I have found no other mention of this particular cause for the failure, perhaps others will find this information helpful. The test is failing because the process group returned from the OS (the getpgrp() system call) does not match the process group associated with /dev/tty (as returned by the TIOCGPGRP ioctl() call). Now it turns out that this is not really an error, because some command shells (ksh, csh, perhaps bash), will assign each new command to a new process group, in order to do job-control (^Z interruption, moving to/from background, etc.). So, at least on this platform, using ksh, the test_ioctl will _always_ fail, since the "make" command gets a process group different from that of the parent shell, and different from /dev/tty's process group (which matches the parent shell). Therefor it would probably be better to test some other ioctl() call than the TIOCGPGRP call, or otherwise rework the test so it doesn't fail under what can be normal circumstances on some platforms. Regards, Marion -- Comment By: Michael Hudson (mwh) Date: 2003-08-05 03:48 Message: Logged In: YES user_id=6656 You're supposed to run ./python ./Lib/test/regrtest.py test_ioctl or maybe ./python ./Lib/test/regrtest.py -v test_ioctl -- Comment By: Foo Man Bar (drauh) Date: 2003-08-05 00:39 Message: Logged In: YES user_id=91293 Blah. I was too hasty: while "./python ./Lib/test/test_ioctl.py" passed after making the modification I mentioned, a re-run of "make test" at the top level says that test_ioctl failed. Before I did the "make test", I did make sure t
[ python-Bugs-777867 ] test_ioctl fails
Bugs item #777867, was opened at 2003-07-26 01:25 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777867&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: test_ioctl fails Initial Comment: test_ioctl test test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests ... 223 tests OK. 1 test failed: test_ioctl 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_dbm test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 4 skips unexpected on linux2: test_dbm test_bz2 test_gdbm test_locale make: *** [test] Error 1 My system: * Python from CVS: Python 2.3c1 (#1, Jul 23 2003, 08:31:24) * Debian testing/unstable * Linux pion 2.4.21 #1 Sat Jul 19 10:21:24 EDT 2003 i686 unknown unknown GNU/Linux * gcc (GCC) 3.3.1 20030626 (Debian prerelease) * AMD Athlon XP 1600+ -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-23 10:37 Message: Logged In: YES user_id=1188172 I verified this. Closing accordingly -- Comment By: Monte Davidoff (mdavidoff) Date: 2005-09-23 09:33 Message: Logged In: YES user_id=129 The fix for this bug was included in Patch 1284289: Lib/test/test_ioctl.py -- Fixed bug in import statement for test.test_support. Fixed bug where the test would fail if the test suite was being run in the backgroud. In this case, the TIOCGPGRP ioctl on /dev/tty returns the session ID, not the process group ID. See also bug 780576. -- Comment By: George Yoshida (quiver) Date: 2005-03-19 19:05 Message: Logged In: YES user_id=671362 On a linux box for my work, I had similar fail(test_ioctl and test_ioctl_mutate). My System: * Python : 2.3.3, 2.4 * kernel : 2.4.22 * GCC: 2.95.3 * glibc : 2.2 I don't know why but somehow test_ioctl.py seems to be invoked in the background on 'make test' process, which resuls in 2 fails. Maybe the easiest way to make test_ioctl fail is : $ ./python ./Lib/test/regrtest.py test_ioctl & -- Comment By: Michael Hudson (mwh) Date: 2003-07-28 17:06 Message: Logged In: YES user_id=6656 Heh, yes it certainly would be easier if I (or anyone else) could reproduce this. However, this is the first I've heard of it, and I'd have thought/hoped that there are other people running the release candidates on Debian testing... glibc is very much a guess scapegoat, don't jeopardize your system just for me. I suggested the '-r' thing because it's the sort of thing that can be done in the background. -- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-28 17:00 Message: Logged In: YES user_id=52562 It's always possible that I'm doing something very silly and not reporting it. But, as I am pressed for time, it would be really good if you could get a failure like this running on your own box. Hm. Maybe this means I should just upgrade my glibc. MAIN pion:~$ dpkg --status libc6 | grep ^Version Version: 2.3.1-16 Hm. Okay, I'll add -r to TESTOPTS and run lots of "make test". -- Comment By: Michael Hudson (mwh) Date: 2003-07-28 16:54 Message: Logged In: YES user_id=6656 This is deeply weird. The most likely scenario that some *other* test (or combination of tests, sigh) is tickling a bug in glibc that test_ioctl is revealing. Evidence for/against this could be acquired by adding '-r' to TESTOPTS and running make test a few times. But I still don't understand why running regrtest.py from the shell passes. Unless it's a Heisenbug, or just a flat out bug in the test. Hmm. Ten gets you one that it's test_fork1 that buggers it up. It seems exceedingly unlikely that this points to a real problem in Python's ioctl code. ioctl() is not the easiest thing in the world to write tests for... -- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 14:20 Message: Logged In: YES user_id=52562 Okay, I added
[ python-Bugs-780576 ] test_ioctl fails
Bugs item #780576, was opened at 2003-07-31 01:04 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jean M. Brouwers (jbrouwers) Assigned to: Anthony Baxter (anthonybaxter) Summary: test_ioctl fails Initial Comment: Test case test_ioctl fails when building Python 2.3 on RedHat 8.0, but just one one and not another RedHat 8.0 machine. The initial suspicion was that this failure may be related to this bug report: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=777867 but that was reported on Debian unstable. It could still be a glibc bug that Python is tickling but the glibc libraries are the same one both machines (at least there is no difference in the version numbers from rpm). rpm -qa | grep -i glibc glibc-devel-2.3.2-4.80.6 glibc-kernheaders-2.4-7.20 glibc-common-2.3.2-4.80.6 glibc-2.3.2-4.80.6 -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-09-23 11:01 Message: Logged In: YES user_id=1188172 Verified. Closing accordingly. -- Comment By: Monte Davidoff (mdavidoff) Date: 2005-09-23 09:35 Message: Logged In: YES user_id=129 The fix for this bug was included in Patch 1284289: Lib/test/test_ioctl.py -- Fixed bug in import statement for test.test_support. Fixed bug where the test would fail if the test suite was being run in the backgroud. In this case, the TIOCGPGRP ioctl on /dev/tty returns the session ID, not the process group ID. See also bug 777867. -- Comment By: Hakanson (hakansonsf) Date: 2004-09-01 00:30 Message: Logged In: YES user_id=1103758 Sorry, that was not helpful: I meant test TIOCGPGRP on a pseudo-tty that the testing process creates. Another alternative would be to test some STREAMS ioctl against a stream/pipe that the process creates. But yes, this quickly gets complicated. -- Comment By: Hakanson (hakansonsf) Date: 2004-08-16 20:08 Message: Logged In: YES user_id=1103758 Maybe test TIOCGPGRP on a file/directory that the test creates anew, instead of /dev/tty. That should definitely match the process group of the current process. -- Comment By: Michael Hudson (mwh) Date: 2004-08-14 15:53 Message: Logged In: YES user_id=6656 Oh, crud. However, if we don't test TIOCGPGRP, what *can* we test? Perhaps we should just test that the call doesn't blow up. -- Comment By: Hakanson (hakansonsf) Date: 2004-08-14 00:57 Message: Logged In: YES user_id=1103758 Folks, I recently completed a build of python-2.3.2 (I realize 2.3.4 is out, but this info should still be relevant) on SPARC/Solaris-9, and as in this bug, the test_ioctl is failing. However, I believe I have found the cause, after running the tests with "-v" added to TESTOPTS in the Makefile. Since I have found no other mention of this particular cause for the failure, perhaps others will find this information helpful. The test is failing because the process group returned from the OS (the getpgrp() system call) does not match the process group associated with /dev/tty (as returned by the TIOCGPGRP ioctl() call). Now it turns out that this is not really an error, because some command shells (ksh, csh, perhaps bash), will assign each new command to a new process group, in order to do job-control (^Z interruption, moving to/from background, etc.). So, at least on this platform, using ksh, the test_ioctl will _always_ fail, since the "make" command gets a process group different from that of the parent shell, and different from /dev/tty's process group (which matches the parent shell). Therefor it would probably be better to test some other ioctl() call than the TIOCGPGRP call, or otherwise rework the test so it doesn't fail under what can be normal circumstances on some platforms. Regards, Marion -- Comment By: Michael Hudson (mwh) Date: 2003-08-05 12:48 Message: Logged In: YES user_id=6656 You're supposed to run ./python ./Lib/test/regrtest.py test_ioctl or maybe ./python ./Lib/test/regrtest.py -v test_ioctl -- Comment By: Foo Man Bar (drauh) Date: 2003-08-05 09:39 Message: Logged In: YES user_id=91293 Blah. I was
[ python-Bugs-1298962 ] MSI installer does not pass values as SecureProperty from UI
Bugs item #1298962, was opened at 2005-09-22 17:27 Message generated for change (Settings changed) made by matthewleslie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Leslie (matthewleslie) Assigned to: Nobody/Anonymous (nobody) >Summary: MSI installer does not pass values as SecureProperty from UI Initial Comment: This appears to be an instance of the problem documented here: http://tinyurl.com/82dt2 aka: http://groups.google.nl/group/microsoft.public.platformsdk.msi/browse_thread/thread/2359de6cc83c3b2f/67ef84f8f0ba99db?lnk=st&q=%22Ignoring+disallowed+property%22+msi&rnum=4&hl=nl#67ef84f8f0ba99db I ran into problems installing as a 'power user' but not an admin on a windows XP box. The program was always installing in C:/ Running msiexec with logging revealed the following lines: MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property X MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property TARGETDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property DLLDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property USERNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property COMPANYNAME MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property SOURCEDIR MSI (s) (48:F8) [18:15:47:990]: Ignoring disallowed property ROOTDRIVE Values were not being passed from the UI to the actual installation script. This is apparently a known issue which can be resolved by using SecureCustomProperties to pass them from the UI to the installer, as documented in the link above. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298962&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1298709 ] _socket module not build under cygwin
Bugs item #1298709, was opened at 2005-09-22 04:59 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298709&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Jason Tishler (jlt63) Summary: _socket module not build under cygwin Initial Comment: Hello, Bulding Python-2.4.2c1 under cygwin gives the following: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -I. -I/home/mtebeka/src/Python-2.4.2c1/./Include -I/home/mtebeka/src/Python-2.4.2c1/Include -I/home/mtebeka/src/Python-2.4.2c1 -c /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c -o build/temp.cygwin-1.5.18-i686-2.4/socketmodule.o /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c: In function `socket_inet_ntop': /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: `INET_ADDRSTRLEN' undeclared (first use in this function) /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: (Each undeclared identifier is reported only once /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: for each function it appears in.) /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: warning: unused variable `ip' -- >Comment By: Jason Tishler (jlt63) Date: 2005-09-23 03:18 Message: Logged In: YES user_id=86216 This is a known Cygwin issues which will be fixed in 1.5.19: http://cygwin.com/ml/cygwin/2005-07/msg01257.html I recommend that Cygwin users temporarily patch their netinet/in.h instead of changing the Python source code. And yes, I still maintain Cygwin Python. :,) -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 20:56 Message: Logged In: YES user_id=33168 Patch is also #1275079. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 20:31 Message: Logged In: YES user_id=33168 Jason, are you still working on Cygwin issues? -- Comment By: Miki Tebeka (tebeka) Date: 2005-09-22 05:22 Message: Logged In: YES user_id=358087 The problem can be sloved by adding the following lines in socketmodule.c beginning. /* FIXME: We should include ws2tcpip.h, however this causes compilation problems */ #if defined(__CYGWIN__) #define INET_ADDRSTRLEN 16 #define INET6_ADDRSTRLEN 46 #endif /* __CYGWIN__ */ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298709&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1138653 ] subprocesss module retains older license header
Bugs item #1138653, was opened at 2005-02-17 23:46 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1138653&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tres Seaver (tseaver) Assigned to: Nobody/Anonymous (nobody) Summary: subprocesss module retains older license header Initial Comment: The header of the file seems to imply that the module is licensed separately from the standard Python license: # subprocess - Subprocesses with accessible I/O streams # # For more information about this module, see PEP 324. # # Copyright (c) 2003-2004 by Peter Astrand <[EMAIL PROTECTED]> # # By obtaining, using, and/or copying this software and/or its # associated documentation, you agree that you have read, understood, # and will comply with the following terms and conditions: # # Permission to use, copy, modify, and distribute this software and # its associated documentation for any purpose and without fee is # hereby granted, provided that the above copyright notice appears in # all copies, and that both that copyright notice and this permission # notice appear in supporting documentation, and that the name of the # author not be used in advertising or publicity pertaining to # distribution of the software without specific, written prior # permission. # # THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, # INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. # IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, INDIRECT OR # CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS # OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, # NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION # WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. -- >Comment By: Peter Åstrand (astrand) Date: 2005-09-23 19:43 Message: Logged In: YES user_id=344921 Fixed in revision 1.8.2.5 (2.4 branch) and 1.21 (HEAD). -- Comment By: Peter Åstrand (astrand) Date: 2005-03-19 08:14 Message: Logged In: YES user_id=344921 >Have you signed a contributor agreement yet, Peter? Yes. >You can replace the above license if you have signed the >contributor agreement with: > >Copyright 2005 by Peter Åstrand. >Licensed to PSF under a Contributor Agreement I guess this will work good when subprocess.py is distributed with the Python distribution, but subprocess.py is also distributed separately, as an addon to Python 2.2/2.3. In this case, it feels better to include the license itself. -- Comment By: Brett Cannon (bcannon) Date: 2005-03-04 03:45 Message: Logged In: YES user_id=357491 Have you signed a contributor agreement yet, Peter? If you have your code has already been relicensed to the PSF under the PSF license. If you haven't you will be asked to eventually and that will retroactively relicense your code over to the PSF, essentially negating all of this pre- existing license. You can replace the above license if you have signed the contributor agreement with: Copyright 2005 by Peter Åstrand. Licensed to PSF under a Contributor Agreement Assuming I am right. =) You can double-check by emailing [EMAIL PROTECTED] or ask at PyCon if you are attending. -- Comment By: Peter Åstrand (astrand) Date: 2005-03-03 22:22 Message: Logged In: YES user_id=344921 How should the license header look like, then? Basically, I've used xmlrpclib.py as an example. Many other modules have no license header at all, but this might be a problem when subprocess.py is distributed separately from Python. Or? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1138653&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1294232 ] Error in metaclass search order
Bugs item #1294232, was opened at 2005-09-17 21:07 Message generated for change (Settings changed) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294232&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Pedro Werneck (pwerneck) Assigned to: Nobody/Anonymous (nobody) Summary: Error in metaclass search order Initial Comment: In a simple class hierarchy, I have class A with metaclass M_A and class B, subclass of A, with metaclass M_B, subclass of M_A, as required. A new class C, subclass of B, must have M_B or a subclass of it as subclass, or a TypeError, metaclass conflict exception is raised. The exception is raised in a multiple class hierarchy (diamond, trees, etc) or in a single class hierarchy when using a metaclass with no relation to M_A and M_B. If M_A or type are used as C metaclass, the interpreter is ignoring dict['__metaclass__'], which has priority over B.__class__ and using M_B, when it was supposed to raise TypeError, with the "metaclass conflict" error message. More details in attached file. -- Comment By: Pedro Werneck (pwerneck) Date: 2005-09-18 20:42 Message: Logged In: YES user_id=696687 Yes. I think this confusion was caused because of the lack of documentation on this topic, especially on the case described here, which seems to break some rules. Since the "Unifying types and classes" essay seems to be the most used Python document about this topic and, I suggest the first rule on determining a metaclass be changed from: "If dict['__metaclass__'] exists, it is used." To something like: "If dict['__metaclass__'] exists and is equal to, or a subclass of, each of the metaclasses of the bases, it is used; if it exists and is a base class of any metaclass of the bases, the most specialized metaclass in the hierarchy is used; if it exists and doesn't satisfies any of these constraints, TypeError is raised." -- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-09-18 19:04 Message: Logged In: YES user_id=9057 I have discussed this at length with Pedro Werneck by email. I personally believe the best path to follow is to document that the entity specified in __metaclass__ inside C class body, can be automagically replaced by the most specialized metaclass among the metaclasses associated to C ancestors. I think that will suffice for the meta-adventurous. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294232&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1296434 ] Call by object reference sometimes call by value
Bugs item #1296434, was opened at 2005-09-20 10:11 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296434&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Alan G (abgrover) Assigned to: Nobody/Anonymous (nobody) Summary: Call by object reference sometimes call by value Initial Comment: The tutorial for 2.4.1, section 4.6 Defining Functions states that formal parameters are introduced into the local symbol table, making all calls call by object reference. The footnote points out that this means that changes to mutable objects will be seen by the caller. This is also illustrated in the example involving calling the list method append. It would be helpful if the example could point out that passing a value such as 1 passes an immutable object (the constant integer value 1), and so it is impossible to write code such as: a = 1 def f(val): val = val + 1 and expect that after the call a == 2, even though val == 2. My experience is that this is a confusing issue for new users, who may not understand that val = val + 1 tosses the object reference value passed, replacing it with a new local object. New users tend to see val as a mutable object, since we just changed the value, didn't we? :) -- >Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-23 18:01 Message: Logged In: YES user_id=593130 I agree that there are problems of beginners misunderstanding Python's object model. However, the proposed fix is not exactly correct. Python *always* calls functions by binding local parameter names to argument objects or lists or dicts thereof. Whenever a name is rebound to a new object, it is *always* unbound from the previous object, as it must be. Mutability is irrelevant. So is localness induced by a function call. Changing locality and mutability, your example is equivalent to a = 1 val = a val = val + 1 a = [1] val = a val = val + [2] # or def f(val): val = val + [2] f(a) *all* of which leave 'a' unchanged, but all of which a beginner might think change 'a'. Perhaps you can suggest a different rewording. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1296434&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1302267 ] A command history for the idle interactive shell
Bugs item #1302267, was opened at 2005-09-24 01:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1302267&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Björn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: A command history for the idle interactive shell Initial Comment: 1. Start IDLE. 2. In the IDLE shell that pops up, write a line of Python code and press enter. 3. Pretend you made a spelling mistake in step two. So you press up and try to fix it but you can't because the cursor is moved and the IDLE shell doesn't work at all like the normal CPython shell. In fact, there is no easy way at all to get back to the last line of input for correcting spelling mistakes. I think there should be one. Maybe ALT+Up could do what Up does in the CPython shell? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1302267&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1302793 ] 2.4.1 windows MSI has no _socket
Bugs item #1302793, was opened at 2005-09-24 17:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1302793&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: IamPaul (heartlesshind) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 windows MSI has no _socket Initial Comment: The precompiled windows binary installer doesn't seem to provide a _socket module eg. >>> import urllib Traceback (most recent call last): File "", line 1, in ? File "c:\Python24\Lib\urllib.py", line 26, in ? import socket File "c:\Python24\Lib\socket.py", line 45, in ? import _socket ImportError: No module named _socket This bears some resemblance to [ 1298709 ] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1302793&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
