From noreply@sourceforge.net Wed Jan 1 15:08:13 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Jan 2003 07:08:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-660697 ] ossaudiodev issues Message-ID: Bugs item #660697, was opened at 2003-01-01 10:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660697&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Greg Ward (gward) Summary: ossaudiodev issues Initial Comment: Greg, I noticed several things about ossaudiodev. It doesn't seem to be mentioned in Misc/NEWS. Likewise, the deprecation of linuxaudiodev. linuxaudiodev is still in setup.py, but ossaudiodev isn't mentioned in setup.py or Modules/Setup. I added it to setup.py and tried to build, but got 2 compilation errors: SNDCTL_DSP_GETSPDIF and SNDCTL_DSP_SETSPDIF are not defined (Redhat 7.2, Linux 2.4.7-10). After commenting out lines 1019 and 1031 (those with the two constants) and it compiled. The test failed: *** lines 2-7 of actual output doesn't appear in expected output after line 1: + expected rate >= 0, not -1 + expected sample size >= 0, not -2 + nchannels must be 1 or 2, not 3 + unknown audio encoding: 177 + for linear unsigned 16-bit little-endian audio, expected sample size 16, not 8 + for linear unsigned 8-bit audio, expected sample size 8, not 16 I'm not sure the status of ossaudiodev or if you know about these problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660697&group_id=5470 From noreply@sourceforge.net Wed Jan 1 15:26:09 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Jan 2003 07:26:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-660707 ] Problems with reference counting and exec Message-ID: Bugs item #660707, was opened at 2003-01-01 11:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660707&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Daniel (kamek) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with reference counting and exec Initial Comment: When using exec to parse an arbitrary string, Python seems to have some problems on keeping the reference count. The sample below shows a problem when the specified string is not a valid Python expression, and would be better for testing in the Python interpreter (~ preceding lines represents indentation): #BEGIN clas MyClass: ~def __del__(self): ~~print 'Deleting object' def f(): ~# create a new instance ~obj = MyClass() ~# now, raise an exception ~exec "any invalid line" f() #END We get an exception, but in no moment we see the destructor being called. The most curious, then, is that if we raise another exception from the interpreter (just type anything), we get the destructor right before the exception information. There's also a reference count problem that happens even when the line for exec is valid, but I couldn't manage to reproduce it outside of my project yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660707&group_id=5470 From noreply@sourceforge.net Wed Jan 1 19:47:23 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Jan 2003 11:47:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-507442 ] Thread-Support don't work with HP-UX 11 Message-ID: Bugs item #507442, was opened at 2002-01-23 05:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 Category: Installation Group: Python 2.1.2 >Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Stefan Walder (stefanwalder) Assigned to: Neal Norwitz (nnorwitz) Summary: Thread-Support don't work with HP-UX 11 Initial Comment: Hi, I've compiled Python 2.1.2 with the HP Ansi C-Compiler. I've used ./configure --with-threads and added -D_REENTRANT to the Makefile. But the test_thread.py don't work! [ek14] % ../../python test_thread.py creating task 1 Traceback (most recent call last): File "test_thread.py", line 46, in ? newtask() File "test_thread.py", line 41, in newtask thread.start_new_thread(task, (next_ident,)) thread.error: can't start new thread [ek14] % Any idea? More informations? Thanks Stefan Walder ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-01 14:47 Message: Logged In: YES user_id=33168 Stefan, I haven't heard back from you, so I'm closing this bug report. I don't have any problems with Python 2.2 or 2.3 on HPUX11. If you are still having problems, please re-open this bug report. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-03 17:05 Message: Logged In: YES user_id=33168 I'm guessing test_pwd fails because there are over 40000 users on the system. I posted a patch (633013) to fix the nis problem. The test_tempfile is a weird interaction with the test framework and not really a problem I think. I ran 2.2.2 on a different box: B.11.00 A 9000/829. This used gcc 2.95.2. It also didn't have a problem. Neither with the regression tests nor running test_thread standalone. My current thoughts are this is either a 2.1.x problem or is specific to Stefan's box. If we don't hear back from Stefan by Nov 20 or so, I will close this bug report. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-03 16:09 Message: Logged In: YES user_id=33168 I've built python 2.3 --with-threads, with the HP cc (-Ae), modified Makefile to add -D_REENTRANT (although it was already in pyconfig.h). I did this on the Compaq test drive machine: spe169.testdrive.compaq.com. It is HP-UX 11i on rp2470 PA RISC w/2 CPUs. There are some test problems: * test_nis crashes the interpreter (I need to look into this) * test_tempfile fails due to too many open files - the problem is that __del__ tries to delete self.fd which doesn't exist * test_pwd fails w/wrong output: - caught expected exception + fakeuid 4127 did not except pwd.getpwuid() Just running test_thread.py works for me. Is it possible to disable threads at the OS level in HPUX? Can threads be used from C on this platform? I will try 2.2.2 next. I will also try on the snake farm, but that is gcc. Stefan, do you have this problem with python 2.2.2? Are you still having this problem? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-03 03:08 Message: Logged In: YES user_id=21627 Neal, can you try to reproduce this? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 05:20 Message: Logged In: YES user_id=21627 Any news on this? Can you please try Python 2.2 and report how that works? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-02-13 19:04 Message: Logged In: YES user_id=29957 Unless someone with a) fairly deep knowledge of HP/UX, b) access to a HP/UX machine and c) the spare time and effort to debug this steps forward, the chances of this being fixed are zero. (I still think adding a resolution of 'HP/UX' to the bug tracker would allow us to close a whooole lotta bugs) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-02-12 20:45 Message: Logged In: YES user_id=21627 This problem looks very much like a HP-UX bug. It crashes inside the malloc implementation, and not only that: it also crashes inside the thread mutex used by malloc. I would guess there is nothing we can do about this; please ask HP for advise (or just don't use threads if they don't work) ---------------------------------------------------------------------- Comment By: Stefan Walder (stefanwalder) Date: 2002-02-12 15:08 Message: Logged In: YES user_id=436029 Hi, I've thought threads now work! But I think they don't! I use python 2.1.2 with Zope. Now sometimes it works. But when i add a CMF-Object I get a core dump. So I've startetd gdb and here is the log: jojo 22: gdb /opt/zope/bin/python2.1 core HP gdb 2.0 Copyright 1986 - 1999 Free Software Foundation, Inc. Hewlett-Packard Wildebeest 2.0 (based on GDB 4.17-hpwdb-980821) Wildebeest is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for Wildebeest. Type "show warranty" for details. Wildebeest was built for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00. .. Core was generated by `python2.1'. Program terminated with signal 10, Bus error. warning: The shared libraries were not privately mapped; setting a breakpoint in a shared library will not work until you rerun the program. #0 0xc2331920 in pthread_mutex_lock () from /usr/lib/libpthread.1 (gdb) bt #0 0xc2331920 in pthread_mutex_lock () from /usr/lib/libpthread.1 #1 0xc0123ed0 in __thread_mutex_lock () from /usr/lib/libc.2 #2 0xc00a0018 in _sigfillset () from /usr/lib/libc.2 #3 0xc009e22c in _memset () from /usr/lib/libc.2 #4 0xc00a37d8 in malloc () from /usr/lib/libc.2 #5 0x3bad0 in PyFrame_New (tstate=0x0, code=0x0, globals=0x0, locals=0x0) at Objects/frameobject.c:149 #6 0xc0123f94 in __thread_mutex_unlock () from /usr/lib/libc.2 #7 (gdb) I don't know if this is a python or zope Problem and I dont't know if this bug is at the right position. Please help. Thanks Stefan Walder ---------------------------------------------------------------------- Comment By: Stefan Walder (stefanwalder) Date: 2002-01-25 05:41 Message: Logged In: YES user_id=436029 Fileupload config.h ---------------------------------------------------------------------- Comment By: Stefan Walder (stefanwalder) Date: 2002-01-25 05:36 Message: Logged In: YES user_id=436029 Hi loewis, I've uploaded the wanted files. Next week I will test python 2.2. But I need python 2.1.2 because I want to use Zope. Thanks Stefan Walder ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-01-24 14:53 Message: Logged In: YES user_id=21627 I can't check, but in theory, configure should (already, atleast in 2.2): 1. detect to use pthreads on HP-UX 2. therefore, define _REENTRANT in pyconfig.h (config.h for 2.1) 3. automatically link with -lpthread Stefan, can you please attach the (original, unmodified) config.h, Makefile, and config.log to this report? In Python 2.1, the test for pthreads failed, since pthread_create is a macro, and the test failed to include the proper header. This was fixed in configure.in 1.266. So: Stefan, could you also try compiling Python 2.2 on your system, and report whether the thread test case passes there? This might be a duplicate of #416696, which would suggest that properly detection of pthreads on HP-UX really is the cure. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-01-24 09:34 Message: Logged In: NO Anthony, if you want an entry on a bugs page for 2.1.2, its no problem for me to create one. Please mail the exact text that you want to appear there to describe this bug (or any other bug in 2.1.2) to webmaster@python.org and I'll take care of it. --Guido (not logged in) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-01-24 04:38 Message: Logged In: YES user_id=31435 I'm afraid threading on HP-UX never really works, no matter how many times users contribute config patches. They get it to work on their box, we check it in, and the next release it starts all over again. This has been going on for years and years. If you think it suddenly started working in 2.2, wait a few months . Note that the advice that you *may* have to use - D_REENTRANT on HP-UX is recorded in Python's main README file; apparently this is necessary on some unknown proper subset of HP-UX boxes. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-24 03:57 Message: Logged In: YES user_id=29957 Hm. I'm not sure, either - but this could probably get an entry on the bugs page on creosote. Anyone? Is there a "known issues" page somewhere? ---------------------------------------------------------------------- Comment By: Stefan Walder (stefanwalder) Date: 2002-01-24 02:59 Message: Logged In: YES user_id=436029 Hi, I've found a solution. I've added a -D_REENTRANT to the CFLAGS and an -lpthread to the LIBS: OPT= -O -D_REENTRANT DEFS= -DHAVE_CONFIG_H CFLAGS= $(OPT) -I. -I$(srcdir)/Include $(DEFS) LIBS= -lnsl -ldld LIBM= -lm -lpthread LIBC= SYSLIBS= $(LIBM) $(LIBC) Now it works for me. But I don't have any idea to put this changes into the configure script. mfG Stefan Walder ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-01-23 10:22 Message: Logged In: YES user_id=29957 Unfortunately, I don't have access to a HP/UX system, and I couldn't find anyone during the process of doing 2.1.2 that was willing to spend the time figuring out how and why 2.2's threading finally started working on HP/UX. Without someone to do that, I'd say the chances of this ever being addressed are close to zero. Does it work on 2.2? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=507442&group_id=5470 From noreply@sourceforge.net Wed Jan 1 19:59:29 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Jan 2003 11:59:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-660795 ] logging missing from Python 2.3a1 for Windows Message-ID: Bugs item #660795, was opened at 2003-01-01 14:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660795&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Erik Demaine (edemaine) Assigned to: Nobody/Anonymous (nobody) Summary: logging missing from Python 2.3a1 for Windows Initial Comment: The release notes for Python 2.3a1 claim that the "logging" package should be available in Python 2.3a1, but the Windows self-installing EXE claims otherwise. At least, Python23/Lib/logging doesn't exist after installation (in contrast to the tarball). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660795&group_id=5470 From noreply@sourceforge.net Wed Jan 1 20:33:39 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Jan 2003 12:33:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-660811 ] refman: importing x.y.z as m is possible, docs say otherwise Message-ID: Bugs item #660811, was opened at 2003-01-01 21:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660811&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hans Nowak (zephyrfalcon) Assigned to: Nobody/Anonymous (nobody) Summary: refman: importing x.y.z as m is possible, docs say otherwise Initial Comment: In the reference manual, the 'import' documentation (Doc/ref/import.html) claims: "To avoid confusion, you cannot import modules with dotted names as a different local name. So import module as m is legal, but import module.submod as s is not." This doesn't seem to be true (anymore?): [Python 2.2.2] >>> import xml.dom.minidom as m >>> m [Python 2.3] >>> import xml.dom.minidom as m >>> m ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660811&group_id=5470 From noreply@sourceforge.net Wed Jan 1 20:42:03 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Jan 2003 12:42:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-660795 ] logging missing from Python 2.3a1 for Windows Message-ID: Bugs item #660795, was opened at 2003-01-01 14:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660795&group_id=5470 >Category: Windows >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Erik Demaine (edemaine) >Assigned to: Tim Peters (tim_one) Summary: logging missing from Python 2.3a1 for Windows Initial Comment: The release notes for Python 2.3a1 claim that the "logging" package should be available in Python 2.3a1, but the Windows self-installing EXE claims otherwise. At least, Python23/Lib/logging doesn't exist after installation (in contrast to the tarball). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-01 15:42 Message: Logged In: YES user_id=33168 Tim, do you need to do something special to get directories? Did bsddb make it in? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660795&group_id=5470 From noreply@sourceforge.net Wed Jan 1 22:39:06 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Jan 2003 14:39:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-638703 ] optparse module undocumented Message-ID: Bugs item #638703, was opened at 2002-11-14 17:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=638703&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: optparse module undocumented Initial Comment: Some volunteer needs to document the optparse module. The text files from optik may supply a good source for material for the LaTeX version of the docs. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-01 17:39 Message: Logged In: YES user_id=33168 There is a patch here: http://python.org/sf/642236 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-22 09:45 Message: Logged In: YES user_id=33168 Note: patch available at http://python.org/sf/642236 ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2002-11-19 02:42 Message: Logged In: YES user_id=469548 I'm working on this. I'll probably mostly use the text files in the Optik package, but I'll add a true reference section, based on the output of pydoc.help(optparse). I'll have to write some more docstrings into the optparse module to make this useful, however. Please note that I'm new to LaTeX, so it may take some time for me to learn it and then convert the text files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=638703&group_id=5470 From noreply@sourceforge.net Thu Jan 2 00:06:49 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Jan 2003 16:06:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-660872 ] datetimetz constructors behave counterintuitively (2.3a1) Message-ID: Bugs item #660872, was opened at 2003-01-02 00:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660872&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Phillip J. Eby (pje) Assigned to: Nobody/Anonymous (nobody) Summary: datetimetz constructors behave counterintuitively (2.3a1) Initial Comment: datetimetz.fromtimestamp(timestamp,tzinfo) creates a datetime which has the localtime() value of timestamp, with the tzinfo attached as its timezone. But this produces a counterintuitive result. Instead of getting the UTC time represented by timestamp, converted to the tzinfo timezone, one only ends up with a correct value if tzinfo is a perfect match for whatever 'localtime' is. This seems useless as well as counterintuitive, since one must therefore do this: datetimetz.fromtimestamp(stamp,localtime_tz).astimezone(tzinfo) to get what's desired. Or, one can do: datetimetz.utcfromtimestamp(stamp).replace(tzinfo=utc).astimezone(tzinfo) Both of these seem unreasonably complex ways of doing something simple: render this UTC timestamp as a datetime in a specified timezone. Similarly, I would expect datetimetz.now(tzinfo) to return the current time in the zone specified by tzinfo, but again this is not what it does. Similarly, you must do: datetimetz.now(localtime_tz).astimezone(tzinfo) or: datetimetz.utcnow().replace(tzinfo=utc).astimezone(tzinfo) to get the current time in the zone specified by tzinfo. Given that these constructors *know* what the UTC time is, why don't they behave more meaningfully? It seems to me that finding the current time in a timezone, or rendering a timestamp as it would be seen in a timezone, are common enough use cases, but I cannot think of any use cases for what the constructors actually do instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660872&group_id=5470 From noreply@sourceforge.net Thu Jan 2 01:14:14 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Jan 2003 17:14:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-660872 ] datetimetz constructors behave counterintuitively (2.3a1) Message-ID: Bugs item #660872, was opened at 2003-01-01 19:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660872&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Phillip J. Eby (pje) Assigned to: Nobody/Anonymous (nobody) Summary: datetimetz constructors behave counterintuitively (2.3a1) Initial Comment: datetimetz.fromtimestamp(timestamp,tzinfo) creates a datetime which has the localtime() value of timestamp, with the tzinfo attached as its timezone. But this produces a counterintuitive result. Instead of getting the UTC time represented by timestamp, converted to the tzinfo timezone, one only ends up with a correct value if tzinfo is a perfect match for whatever 'localtime' is. This seems useless as well as counterintuitive, since one must therefore do this: datetimetz.fromtimestamp(stamp,localtime_tz).astimezone(tzinfo) to get what's desired. Or, one can do: datetimetz.utcfromtimestamp(stamp).replace(tzinfo=utc).astimezone(tzinfo) Both of these seem unreasonably complex ways of doing something simple: render this UTC timestamp as a datetime in a specified timezone. Similarly, I would expect datetimetz.now(tzinfo) to return the current time in the zone specified by tzinfo, but again this is not what it does. Similarly, you must do: datetimetz.now(localtime_tz).astimezone(tzinfo) or: datetimetz.utcnow().replace(tzinfo=utc).astimezone(tzinfo) to get the current time in the zone specified by tzinfo. Given that these constructors *know* what the UTC time is, why don't they behave more meaningfully? It seems to me that finding the current time in a timezone, or rendering a timestamp as it would be seen in a timezone, are common enough use cases, but I cannot think of any use cases for what the constructors actually do instead. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-01 20:14 Message: Logged In: YES user_id=31435 I always figured the use case for fromtimestamp(stamp, tz) was indeed so the user had a dead-easy way to attach their own local time tzinfo class to a timestamp, and that's all. I would find the behavior you describe counterintuitive instead: if I want a conversion, I'd rather ask for one explicitly (via astimezone()). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660872&group_id=5470 From noreply@sourceforge.net Thu Jan 2 02:37:58 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Jan 2003 18:37:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-660022 ] parameters for int(), str(), etc. Message-ID: Bugs item #660022, was opened at 2002-12-30 10:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660022&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Aahz (aahz) >Assigned to: Raymond Hettinger (rhettinger) Summary: parameters for int(), str(), etc. Initial Comment: The built-in functions int(), str(), float(), long() are documented as requiring a parameter, but the type/class unification has changed them so that they return a false object without a parameter: >>> int() 0 >>> str() '' >>> float() 0.0 >>> long() 0L ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660022&group_id=5470 From noreply@sourceforge.net Thu Jan 2 03:40:14 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Jan 2003 19:40:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-660872 ] datetimetz constructors behave counterintuitively (2.3a1) Message-ID: Bugs item #660872, was opened at 2003-01-02 00:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660872&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Phillip J. Eby (pje) Assigned to: Nobody/Anonymous (nobody) Summary: datetimetz constructors behave counterintuitively (2.3a1) Initial Comment: datetimetz.fromtimestamp(timestamp,tzinfo) creates a datetime which has the localtime() value of timestamp, with the tzinfo attached as its timezone. But this produces a counterintuitive result. Instead of getting the UTC time represented by timestamp, converted to the tzinfo timezone, one only ends up with a correct value if tzinfo is a perfect match for whatever 'localtime' is. This seems useless as well as counterintuitive, since one must therefore do this: datetimetz.fromtimestamp(stamp,localtime_tz).astimezone(tzinfo) to get what's desired. Or, one can do: datetimetz.utcfromtimestamp(stamp).replace(tzinfo=utc).astimezone(tzinfo) Both of these seem unreasonably complex ways of doing something simple: render this UTC timestamp as a datetime in a specified timezone. Similarly, I would expect datetimetz.now(tzinfo) to return the current time in the zone specified by tzinfo, but again this is not what it does. Similarly, you must do: datetimetz.now(localtime_tz).astimezone(tzinfo) or: datetimetz.utcnow().replace(tzinfo=utc).astimezone(tzinfo) to get the current time in the zone specified by tzinfo. Given that these constructors *know* what the UTC time is, why don't they behave more meaningfully? It seems to me that finding the current time in a timezone, or rendering a timestamp as it would be seen in a timezone, are common enough use cases, but I cannot think of any use cases for what the constructors actually do instead. ---------------------------------------------------------------------- >Comment By: Phillip J. Eby (pje) Date: 2003-01-02 03:40 Message: Logged In: YES user_id=56214 But in your use case, if the timezone they attach is in fact equivalent to localtime, then the conversion would be a no-op anyway, right? So how would a conversion in the general case be wrong? At the very least, this is a documentation bug. If these constructors only produce meaningful results for a tzinfo that's exactly equivalent to the system's localtime(), then the docs should say so. Otherwise, someone can write code that appears to work, for example, on their own machine, and then fails when run on a machine with a different concept of localtime(). Now, if you can actually come up with a sensible use case for *wrongly* translating a UTC-based timestamp to a particular timezone, with the degree of wrongness depending on the difference between localtime() and the specified timezone, that might justify the constructor behavior. :) As it is, I find it hard to believe that whatever you come up with will be a more common need than rendering a UTC timestamp as a datetime value in a specified timezone. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-02 01:14 Message: Logged In: YES user_id=31435 I always figured the use case for fromtimestamp(stamp, tz) was indeed so the user had a dead-easy way to attach their own local time tzinfo class to a timestamp, and that's all. I would find the behavior you describe counterintuitive instead: if I want a conversion, I'd rather ask for one explicitly (via astimezone()). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660872&group_id=5470 From noreply@sourceforge.net Thu Jan 2 04:14:36 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Jan 2003 20:14:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-660946 ] import.c compile fails on cygwin Message-ID: Bugs item #660946, was opened at 2003-01-01 23:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660946&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Swartz (z3p) Assigned to: Nobody/Anonymous (nobody) Summary: import.c compile fails on cygwin Initial Comment: Using Python CVS, Python/import.c compile fails. GCC 3.2, Cygwin 1.3.17. Message is below: gcc -c -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Python/import.o Python/import.c Python/import.c:1376:21: windows.h: No such file or directory Python/import.c: In function `case_ok': Python/import.c:1410: `WIN32_FIND_DATA' undeclared (first use in this function) Python/import.c:1410: (Each undeclared identifier is reported only once Python/import.c:1410: for each function it appears in.) Python/import.c:1410: parse error before "data" Python/import.c:1411: `HANDLE' undeclared (first use in this function) Python/import.c:1413: `MAX_PATH' undeclared (first use in this function) Python/import.c:1421: `h' undeclared (first use in this function) Python/import.c:1421: warning: implicit declaration of function `FindFirstFile' Python/import.c:1421: `data' undeclared (first use in this function) Python/import.c:1425: `INVALID_HANDLE_VALUE' undeclared (first use in this function) Python/import.c:1431: warning: implicit declaration of function `FindClose' Python/import.c:1413: warning: unused variable `tempbuf' make: *** [Python/import.o] Error 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660946&group_id=5470 From noreply@sourceforge.net Thu Jan 2 04:31:30 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Jan 2003 20:31:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-660022 ] parameters for int(), str(), etc. Message-ID: Bugs item #660022, was opened at 2002-12-30 10:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660022&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Aahz (aahz) >Assigned to: Nobody/Anonymous (nobody) Summary: parameters for int(), str(), etc. Initial Comment: The built-in functions int(), str(), float(), long() are documented as requiring a parameter, but the type/class unification has changed them so that they return a false object without a parameter: >>> int() 0 >>> str() '' >>> float() 0.0 >>> long() 0L ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-01 23:31 Message: Logged In: YES user_id=80475 There are a lot of these: [(0, False), (0.0, False), (0j, False), (0L, False), ((), False), ([], False), ({}, False), ('', False), (u'', False)] See attached doc patch. Also, consider adding a \versionchanged tag and changing the doc strings. BTW, I think it is more complete and accurate to say that the contructors return an empty container or zero than it is to just say that bool(constructor()) is False. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660022&group_id=5470 From noreply@sourceforge.net Thu Jan 2 04:47:50 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Jan 2003 20:47:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-660872 ] datetimetz constructors behave counterintuitively (2.3a1) Message-ID: Bugs item #660872, was opened at 2003-01-01 19:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660872&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Phillip J. Eby (pje) >Assigned to: Guido van Rossum (gvanrossum) Summary: datetimetz constructors behave counterintuitively (2.3a1) Initial Comment: datetimetz.fromtimestamp(timestamp,tzinfo) creates a datetime which has the localtime() value of timestamp, with the tzinfo attached as its timezone. But this produces a counterintuitive result. Instead of getting the UTC time represented by timestamp, converted to the tzinfo timezone, one only ends up with a correct value if tzinfo is a perfect match for whatever 'localtime' is. This seems useless as well as counterintuitive, since one must therefore do this: datetimetz.fromtimestamp(stamp,localtime_tz).astimezone(tzinfo) to get what's desired. Or, one can do: datetimetz.utcfromtimestamp(stamp).replace(tzinfo=utc).astimezone(tzinfo) Both of these seem unreasonably complex ways of doing something simple: render this UTC timestamp as a datetime in a specified timezone. Similarly, I would expect datetimetz.now(tzinfo) to return the current time in the zone specified by tzinfo, but again this is not what it does. Similarly, you must do: datetimetz.now(localtime_tz).astimezone(tzinfo) or: datetimetz.utcnow().replace(tzinfo=utc).astimezone(tzinfo) to get the current time in the zone specified by tzinfo. Given that these constructors *know* what the UTC time is, why don't they behave more meaningfully? It seems to me that finding the current time in a timezone, or rendering a timestamp as it would be seen in a timezone, are common enough use cases, but I cannot think of any use cases for what the constructors actually do instead. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-01 23:47 Message: Logged In: YES user_id=31435 I think Guido has more energy for this than I have (I'm pretty much burned out on this module), so assigned it to him. At the time fromtimestamp() was added, there wasn't any reasonable way to simply attach a tzinfo object to a datetimetz. About the best you could do is new = datetimetz(old.year, old.month, old.day, old.hour, old.minute, old.second, old.microsecond, tzinfo) So the use case of *simply* getting a local datetimetz out of a timestamp was quite a pain. datetimetz.fromtimestamp grew an optional tzinfo arg to ease that pain. There was no notion of timezone conversion at that time either, so of course none of the methods were intended to do any sort of conversion. Note that the primary constructor-- datetimetz --also takes all of its arguments as being in local time. It would strike me as inconsistent if fromtimestamp() didn't also take its argument as being in local time. Things changed since then, and I at least agree the docs should be clarified. But rather than make the constructors even more complicated, I'd rather drop the optional tzinfo arguments from fromtimestamp() and now(). There are at least two easy ways to attach a tzinfo tz to a datetimetz now: new = old.astimezone(tz) # no conversion if old was naive new = old.replace(tzinfo=tz) # no conversion ever and there's also an explict time zone conversion method. ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2003-01-01 22:40 Message: Logged In: YES user_id=56214 But in your use case, if the timezone they attach is in fact equivalent to localtime, then the conversion would be a no-op anyway, right? So how would a conversion in the general case be wrong? At the very least, this is a documentation bug. If these constructors only produce meaningful results for a tzinfo that's exactly equivalent to the system's localtime(), then the docs should say so. Otherwise, someone can write code that appears to work, for example, on their own machine, and then fails when run on a machine with a different concept of localtime(). Now, if you can actually come up with a sensible use case for *wrongly* translating a UTC-based timestamp to a particular timezone, with the degree of wrongness depending on the difference between localtime() and the specified timezone, that might justify the constructor behavior. :) As it is, I find it hard to believe that whatever you come up with will be a more common need than rendering a UTC timestamp as a datetime value in a specified timezone. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-01 20:14 Message: Logged In: YES user_id=31435 I always figured the use case for fromtimestamp(stamp, tz) was indeed so the user had a dead-easy way to attach their own local time tzinfo class to a timestamp, and that's all. I would find the behavior you describe counterintuitive instead: if I want a conversion, I'd rather ask for one explicitly (via astimezone()). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660872&group_id=5470 From noreply@sourceforge.net Thu Jan 2 05:19:06 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Jan 2003 21:19:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-660961 ] tkinter.dooneevent() crashes Message-ID: Bugs item #660961, was opened at 2003-01-02 05:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660961&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Justin Gullingsrud (jgullingsrud) Assigned to: Nobody/Anonymous (nobody) Summary: tkinter.dooneevent() crashes Initial Comment: On Linux, compiling against Tcl/Tk 8.3.5, running Tkinter.tkinter.dooneevent() segfaults immediately. Traceback: >>> from Tkinter import * >>> tkinter.dooneevent() Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 14004)] Tkapp_DoOneEvent (self=0x0, args=0x4049c02c) at Modules/_tkinter.c:2397 2397 CHECK_TCL_APPARTMENT; (gdb) where #0 Tkapp_DoOneEvent (self=0x0, args=0x4049c02c) at Modules/_tkinter.c:2397 #1 0x080f85c7 in PyCFunction_Call (func=0x404f5fac, arg=0x4049c02c, kw=0x0) at Objects/methodobject.c:90 #2 0x080a8185 in call_function (pp_stack=0xbffff22c, oparg=1) at Python/ceval.c:3249 #3 0x080a654e in eval_frame (f=0x8159f64) at Python/ceval.c:2009 #4 0x080a7095 in PyEval_EvalCodeEx (co=0x404ab620, globals=0x1, locals=0x404b48ac, args=0x8159f64, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2554 #5 0x080a9805 in PyEval_EvalCode (co=0x404ab620, globals=0x404b48ac, locals=0x404b48ac) at Python/ceval.c:478 #6 0x080cff99 in run_node (n=0x4049c2a8, filename=0x80fb12a "", globals=0x404b48ac, locals=0x404b48ac, flags=0xbffff418) at Python/pythonrun.c:1097 #7 0x080cf4fd in PyRun_InteractiveOneFlags (fp=0x40491de0, filename=0x80fb12a "", flags=0xbffff418) at Python/pythonrun.c:601 #8 0x080cf30c in PyRun_InteractiveLoopFlags (fp=0x40491de0, filename=0x80fb12a "", flags=0xbffff418) at Python/pythonrun.c:530 #9 0x080d09c6 in PyRun_AnyFileExFlags (fp=0x40491de0, filename=0x80fb12a "", closeit=0, flags=0xbffff418) at Python/pythonrun.c:493 #10 0x08055614 in Py_Main (argc=0, argv=0xbffff4a4) at Modules/main.c:446 #11 0x080551b9 in main (argc=1, argv=0xbffff4a4) at Modules/python.c:23 #12 0x403944a2 in __libc_start_main () from /lib/libc.so.6 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660961&group_id=5470 From noreply@sourceforge.net Thu Jan 2 05:26:07 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 01 Jan 2003 21:26:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-660795 ] logging missing from Python 2.3a1 for Windows Message-ID: Bugs item #660795, was opened at 2003-01-01 14:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660795&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Erik Demaine (edemaine) >Assigned to: Neal Norwitz (nnorwitz) Summary: logging missing from Python 2.3a1 for Windows Initial Comment: The release notes for Python 2.3a1 claim that the "logging" package should be available in Python 2.3a1, but the Windows self-installing EXE claims otherwise. At least, Python23/Lib/logging doesn't exist after installation (in contrast to the tarball). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-02 00:26 Message: Logged In: YES user_id=31435 Ack. No new directory gets into the Windows installer unless the Wise script is programmed to put it there. This is a longstanding alpha glitch for new packages. If the test suite had even tried to import logging, it would have been caught (I always use the installer to install Python, and run a pile of tests on the installed version, before a release). So I'll add the logging package to the installer. Neal, it would be mondo cool if you could whip up a basic test_logging.py for the test suite, to verify that the package exists and that at least one piece of logging functionality actually works. Assign back to me whether or not you can make time to do that. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-01 15:42 Message: Logged In: YES user_id=33168 Tim, do you need to do something special to get directories? Did bsddb make it in? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660795&group_id=5470 From noreply@sourceforge.net Thu Jan 2 11:29:04 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 03:29:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-629756 ] FAIL: test_crlf_separation (email.test.t Message-ID: Bugs item #629756, was opened at 2002-10-28 11:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629756&group_id=5470 Category: Windows Group: Platform-specific Status: Closed Resolution: Invalid Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Barry A. Warsaw (bwarsaw) Summary: FAIL: test_crlf_separation (email.test.t Initial Comment: just because text file on windows has CR/LF as endline maker and this test expects LF as eol. ---------------------------------------------------------------------- >Comment By: Grzegorz Makarewicz (makaron) Date: 2003-01-02 12:29 Message: Logged In: YES user_id=115179 :( - after unpacking python on linux and copying all files with ordinary copy this test still fails for me (Info zip works fine on windows, gifs and other binary files are uncompressed correctly). Can you run attached file on your windows ? It is stripped down test_crlf_separation which uses StringIO, binary and text open mode. When using text mode as in mentioned test msg.get_payload will return data terminated with \n - but it is tested for \r\n. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-30 20:26 Message: Logged In: YES user_id=12800 It looks like you built this from source on Windows. If you unzip'd the source without turning off any dumb CRLF munging in your zip program, the test file will not be correct and this test will fail. Tim assures me that this test succeeds in Python 2.2 and 2.3a1 and I trust him with my lunch. ---------------------------------------------------------------------- Comment By: Grzegorz Makarewicz (makaron) Date: 2002-10-29 12:28 Message: Logged In: YES user_id=115179 Python 2.2.2 from October 14, 2002, compiled from source on windows 2000 all expected test are passed but not test_email. reproducable by: pushd Lib\test ..\..\python regrtest.py popd -- or cd Lib\test ..\..\python test_email.py traceback: FAILED (failures=1) Traceback (most recent call last): File "test_email.py", line 13, in ? test_main() File "test_email.py", line 10, in test_main run_suite(suite()) File "c:\binw\py222\lib\test\test_support.py", line 175, in run_suite raise TestFailed(err) test_support.TestFailed: Traceback (most recent call last): File "c:\binw\py222\lib\email\test\test_email.py", line 1851, in test_crlf_sep aration eq(part1.get_payload(), 'Simple email with attachment.\r\n\r\n') File "c:\binw\py222\lib\unittest.py", line 286, in failUnlessEqual raise self.failureException, \ AssertionError: 'Simple email with attachment.\n\n' != 'Simple email with attach ment.\r\n\r\n' after applying this patch thist test will pass --- test_email.py Mon Oct 14 17:26:03 2002 +++ test_email.py.new Tue Oct 29 11:25:54 2002 @@ -46,7 +46,7 @@ def openfile(filename): path = os.path.join(os.path.dirname(landmark), 'data', filename) - return open(path, 'r') + return open(path, 'rb') ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-10-28 16:33 Message: Logged In: YES user_id=31435 Assigned to Barry. Grzegorz, please supply more detail, such as which version of Python you're using, and the commands you used to run this test. As the name of the test should imply ("test_crlf_....), the test *expects* CR/LF -- that's it's point. It passes for me under 2.2.2 and current CVS Python, under Win98SE and Win2K. It may not have passed in 2.2.1, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629756&group_id=5470 From noreply@sourceforge.net Thu Jan 2 11:32:44 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 03:32:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-661042 ] urllib2 and proxy Message-ID: Bugs item #661042, was opened at 2003-01-02 12:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661042&group_id=5470 Category: Extension Modules Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jean-Marc Desprez (jmdesprez) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 and proxy Initial Comment: the following code fails to open the url, through a proxy (it tries to connect directly, as if no proxy was supplied) #! /usr/bin/env python import urllib2 if __name__ == "__main__": h_prox = urllib2.ProxyHandler({'http' : 'http://10.4.4.123:3128'}) #opner = urllib2.build_opener(h_prox, urllib2.HTTPHandler) opner = urllib2.build_opener(h_prox) urllib2.install_opener(opner) urllib2.urlopen('http://www.python.org') but it works if I add ' urllib2.HTTPHandler' in build_opener call (commented line) It seems that 'urllib2:build_opener' calls first 'urllib2:OpenerDirector.add_handler' with all default handlers (including HTTPhandler when not supplied in 'build_opener'), and after the user supplied handlers,so the proxy handler is linked in second position in 'OpenerDirector.handle_open['http'], whereas it should be first in the open chain. I checked my theory with a quick and dirty hack in 'add_handler', to force instance of ProxyHandler to be inserted first in the handler_open['http'] list (it works), but I think a more apropriated fix shoud be done in 'build_opener' regards ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661042&group_id=5470 From noreply@sourceforge.net Thu Jan 2 12:29:13 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 04:29:13 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-661057 ] xrange concatenation Message-ID: Feature Requests item #661057, was opened at 2003-01-02 12:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=661057&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: xrange concatenation Initial Comment: xrange is advertised as working like range, but doesn't support concatenation: range(5) + range(6, 9) => [0,1,2,3,4,6,7,8,9] [2] + range(3, 10, 2) => (2, 3, 5, 7, 9] Doing these things with xrange throws an error. It would be nice if xrange supported + for concatenation, so the above examples would work. This should be easy to implement now that there are iterator objects. Paul ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=661057&group_id=5470 From noreply@sourceforge.net Thu Jan 2 14:23:25 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 06:23:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-661086 ] datetime.today() truncates microseconds Message-ID: Bugs item #661086, was opened at 2003-01-02 15:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661086&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Amaury Forgeot d'Arc (amauryf) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.today() truncates microseconds Initial Comment: While exploring the new datetime module, I got results like: >>> datetime.datetime.today() datetime.datetime(2003, 1, 2, 15, 14, 51, 480999) Shouldn't the microseconds be 637000 ? While not very important, this can lead you to believe that the timestamp is accurate to 1e-6 seconds, whereas only milliseconds are relevant (on W2K). since today() is equivalent to fromtimestamp(time.time()), I explored the results of time.time(): >>> time.time(),datetime.datetime.today() returns: (1041516891.4809999, datetime.datetime(2003, 1, 2, 15, 14, 51, 480999)) It seems that the float returned by time.time is truncated to 1e-6. I suggest that it should be rounded instead, so that the last digit (which is significant) is taken into account. Looking into the code, I think that the code to change is in datetimemodule.c: the function datetime_from_timestamp could add 5e-7 to the "us" variable before casting it to int. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661086&group_id=5470 From noreply@sourceforge.net Thu Jan 2 14:59:34 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 06:59:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-660795 ] logging missing from Python 2.3a1 for Windows Message-ID: Bugs item #660795, was opened at 2003-01-01 14:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660795&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Erik Demaine (edemaine) >Assigned to: Tim Peters (tim_one) Summary: logging missing from Python 2.3a1 for Windows Initial Comment: The release notes for Python 2.3a1 claim that the "logging" package should be available in Python 2.3a1, but the Windows self-installing EXE claims otherwise. At least, Python23/Lib/logging doesn't exist after installation (in contrast to the tarball). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-02 09:59 Message: Logged In: YES user_id=33168 Bad timing. I was working w/Vinay on the logging test. He just gave me the ok to checkin. There's a lot in the test, hopefully it works on Windows. Checked in as Lib/test/test_logging.py and Lib/test/output/test_logging. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-02 00:26 Message: Logged In: YES user_id=31435 Ack. No new directory gets into the Windows installer unless the Wise script is programmed to put it there. This is a longstanding alpha glitch for new packages. If the test suite had even tried to import logging, it would have been caught (I always use the installer to install Python, and run a pile of tests on the installed version, before a release). So I'll add the logging package to the installer. Neal, it would be mondo cool if you could whip up a basic test_logging.py for the test suite, to verify that the package exists and that at least one piece of logging functionality actually works. Assign back to me whether or not you can make time to do that. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-01 15:42 Message: Logged In: YES user_id=33168 Tim, do you need to do something special to get directories? Did bsddb make it in? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660795&group_id=5470 From noreply@sourceforge.net Thu Jan 2 15:18:23 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 07:18:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-661086 ] datetime.today() truncates microseconds Message-ID: Bugs item #661086, was opened at 2003-01-02 15:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661086&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Amaury Forgeot d'Arc (amauryf) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.today() truncates microseconds Initial Comment: While exploring the new datetime module, I got results like: >>> datetime.datetime.today() datetime.datetime(2003, 1, 2, 15, 14, 51, 480999) Shouldn't the microseconds be 637000 ? While not very important, this can lead you to believe that the timestamp is accurate to 1e-6 seconds, whereas only milliseconds are relevant (on W2K). since today() is equivalent to fromtimestamp(time.time()), I explored the results of time.time(): >>> time.time(),datetime.datetime.today() returns: (1041516891.4809999, datetime.datetime(2003, 1, 2, 15, 14, 51, 480999)) It seems that the float returned by time.time is truncated to 1e-6. I suggest that it should be rounded instead, so that the last digit (which is significant) is taken into account. Looking into the code, I think that the code to change is in datetimemodule.c: the function datetime_from_timestamp could add 5e-7 to the "us" variable before casting it to int. ---------------------------------------------------------------------- >Comment By: Amaury Forgeot d'Arc (amauryf) Date: 2003-01-02 16:18 Message: Logged In: YES user_id=389140 Sorry for the typo: in my sample, I would like the microseconds to show as 481000 of course. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661086&group_id=5470 From noreply@sourceforge.net Thu Jan 2 15:31:04 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 07:31:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-660946 ] import.c compile fails on cygwin Message-ID: Bugs item #660946, was opened at 2003-01-01 23:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660946&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Paul Swartz (z3p) >Assigned to: Jason Tishler (jlt63) Summary: import.c compile fails on cygwin Initial Comment: Using Python CVS, Python/import.c compile fails. GCC 3.2, Cygwin 1.3.17. Message is below: gcc -c -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Python/import.o Python/import.c Python/import.c:1376:21: windows.h: No such file or directory Python/import.c: In function `case_ok': Python/import.c:1410: `WIN32_FIND_DATA' undeclared (first use in this function) Python/import.c:1410: (Each undeclared identifier is reported only once Python/import.c:1410: for each function it appears in.) Python/import.c:1410: parse error before "data" Python/import.c:1411: `HANDLE' undeclared (first use in this function) Python/import.c:1413: `MAX_PATH' undeclared (first use in this function) Python/import.c:1421: `h' undeclared (first use in this function) Python/import.c:1421: warning: implicit declaration of function `FindFirstFile' Python/import.c:1421: `data' undeclared (first use in this function) Python/import.c:1425: `INVALID_HANDLE_VALUE' undeclared (first use in this function) Python/import.c:1431: warning: implicit declaration of function `FindClose' Python/import.c:1413: warning: unused variable `tempbuf' make: *** [Python/import.o] Error 1 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-02 10:31 Message: Logged In: YES user_id=33168 Jason are you having this problem? Note the first error: windows.h: No such file or directory Should windows.h be included? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660946&group_id=5470 From noreply@sourceforge.net Thu Jan 2 15:31:18 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 07:31:18 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-661057 ] xrange concatenation Message-ID: Feature Requests item #661057, was opened at 2003-01-02 07:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=661057&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: xrange concatenation Initial Comment: xrange is advertised as working like range, but doesn't support concatenation: range(5) + range(6, 9) => [0,1,2,3,4,6,7,8,9] [2] + range(3, 10, 2) => (2, 3, 5, 7, 9] Doing these things with xrange throws an error. It would be nice if xrange supported + for concatenation, so the above examples would work. This should be easy to implement now that there are iterator objects. Paul ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 10:31 Message: Logged In: YES user_id=6380 I guess the docs need to be updated. xrange() is supposed to be as light and fast as possible for a single use case: "for i in xrange(...): ...". Everything else is fluff, and in fact several features have been deprecated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=661057&group_id=5470 From noreply@sourceforge.net Thu Jan 2 15:42:13 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 07:42:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-660961 ] tkinter.dooneevent() crashes Message-ID: Bugs item #660961, was opened at 2003-01-02 00:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660961&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Justin Gullingsrud (jgullingsrud) >Assigned to: Martin v. Löwis (loewis) Summary: tkinter.dooneevent() crashes Initial Comment: On Linux, compiling against Tcl/Tk 8.3.5, running Tkinter.tkinter.dooneevent() segfaults immediately. Traceback: >>> from Tkinter import * >>> tkinter.dooneevent() Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 14004)] Tkapp_DoOneEvent (self=0x0, args=0x4049c02c) at Modules/_tkinter.c:2397 2397 CHECK_TCL_APPARTMENT; (gdb) where #0 Tkapp_DoOneEvent (self=0x0, args=0x4049c02c) at Modules/_tkinter.c:2397 #1 0x080f85c7 in PyCFunction_Call (func=0x404f5fac, arg=0x4049c02c, kw=0x0) at Objects/methodobject.c:90 #2 0x080a8185 in call_function (pp_stack=0xbffff22c, oparg=1) at Python/ceval.c:3249 #3 0x080a654e in eval_frame (f=0x8159f64) at Python/ceval.c:2009 #4 0x080a7095 in PyEval_EvalCodeEx (co=0x404ab620, globals=0x1, locals=0x404b48ac, args=0x8159f64, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2554 #5 0x080a9805 in PyEval_EvalCode (co=0x404ab620, globals=0x404b48ac, locals=0x404b48ac) at Python/ceval.c:478 #6 0x080cff99 in run_node (n=0x4049c2a8, filename=0x80fb12a "", globals=0x404b48ac, locals=0x404b48ac, flags=0xbffff418) at Python/pythonrun.c:1097 #7 0x080cf4fd in PyRun_InteractiveOneFlags (fp=0x40491de0, filename=0x80fb12a "", flags=0xbffff418) at Python/pythonrun.c:601 #8 0x080cf30c in PyRun_InteractiveLoopFlags (fp=0x40491de0, filename=0x80fb12a "", flags=0xbffff418) at Python/pythonrun.c:530 #9 0x080d09c6 in PyRun_AnyFileExFlags (fp=0x40491de0, filename=0x80fb12a "", closeit=0, flags=0xbffff418) at Python/pythonrun.c:493 #10 0x08055614 in Py_Main (argc=0, argv=0xbffff4a4) at Modules/main.c:446 #11 0x080551b9 in main (argc=1, argv=0xbffff4a4) at Modules/python.c:23 #12 0x403944a2 in __libc_start_main () from /lib/libc.so.6 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-02 10:42 Message: Logged In: YES user_id=33168 Martin, you added CHECK_TCL_APPARTMENT for threaded Tcl. Any ideas? I get the crash with Tk 8.3.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660961&group_id=5470 From noreply@sourceforge.net Thu Jan 2 15:54:17 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 07:54:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-661136 ] zipimport does not accept nested pure python imports Message-ID: Bugs item #661136, was opened at 2003-01-02 15:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661136&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sandy Norton (sandynorton) Assigned to: Nobody/Anonymous (nobody) Summary: zipimport does not accept nested pure python imports Initial Comment: I presume this is a big with zipimport. It occurs when you have a nested pure python package structure. It doesn't occcur if there are byte-compiled versions in the zipped directory. as pure python zipped directory =============================== Assume mylib.zip is inserted on the sys.path with the following directory structure: mylib.zip mod.py p1 __init__.py mod.py p2 __init__.py mod.py C:\TMP>ls mylib.zip C:\TMP>p Python 2.3a1 (#38, Jan 1 2003, 16:44:16) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys; sys.path.insert(0, 'c:\tmp\mylib.zip') >>> import mod mod >>> from p1 import mod Traceback (most recent call last): File "", line 1, in ? SystemError: C:\Engines\python\dist\src\Objects\stringobject.c:3295: bad argumen t to internal function >>> from p1.p2 import mod Traceback (most recent call last): File "", line 1, in ? SystemError: C:\Engines\python\dist\src\Objects\stringobject.c:3295: bad argumen t to internal function >>> as plain directory =================== C:\TMP>p Python 2.3a1 (#38, Jan 1 2003, 16:44:16) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.path.insert(0, 'c:\tmp\mylib') >>> import mod mod >>> from p1 import mod mod1 >>> from p1.p2 import mod mod2 >>> as byte-compiled zipped directory ================================= mylib.zip mod.py mod.pyc p1 __init__.py __init__.pyc mod.py mod.pyc p2 __init__.py __init__.pyc mod.py mod.pyc C:\TMP>p Python 2.3a1 (#38, Jan 1 2003, 16:44:16) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys; sys.path.insert(0, 'c:\tmp\mylib.zip') >>> import mod mod >>> import p1.mod mod1 >>> import p1.p2.mod mod2 >>> p1.p2.mod >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661136&group_id=5470 From noreply@sourceforge.net Thu Jan 2 16:03:00 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 08:03:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-660946 ] import.c compile fails on cygwin Message-ID: Bugs item #660946, was opened at 2003-01-01 19:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660946&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Paul Swartz (z3p) Assigned to: Jason Tishler (jlt63) Summary: import.c compile fails on cygwin Initial Comment: Using Python CVS, Python/import.c compile fails. GCC 3.2, Cygwin 1.3.17. Message is below: gcc -c -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Python/import.o Python/import.c Python/import.c:1376:21: windows.h: No such file or directory Python/import.c: In function `case_ok': Python/import.c:1410: `WIN32_FIND_DATA' undeclared (first use in this function) Python/import.c:1410: (Each undeclared identifier is reported only once Python/import.c:1410: for each function it appears in.) Python/import.c:1410: parse error before "data" Python/import.c:1411: `HANDLE' undeclared (first use in this function) Python/import.c:1413: `MAX_PATH' undeclared (first use in this function) Python/import.c:1421: `h' undeclared (first use in this function) Python/import.c:1421: warning: implicit declaration of function `FindFirstFile' Python/import.c:1421: `data' undeclared (first use in this function) Python/import.c:1425: `INVALID_HANDLE_VALUE' undeclared (first use in this function) Python/import.c:1431: warning: implicit declaration of function `FindClose' Python/import.c:1413: warning: unused variable `tempbuf' make: *** [Python/import.o] Error 1 ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-01-02 07:03 Message: Logged In: YES user_id=86216 > Jason are you having this problem? No. > Should windows.h be included? Yes. This is user error. Paul did not install the w32api package: $ cygcheck -c w32api Cygwin Package Information Package Version w32api 2.1-1 $ zcat /etc/setup/w32api.lst.gz | fgrep windows usr/include/w32api/windows.h ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-02 06:31 Message: Logged In: YES user_id=33168 Jason are you having this problem? Note the first error: windows.h: No such file or directory Should windows.h be included? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660946&group_id=5470 From noreply@sourceforge.net Thu Jan 2 16:03:58 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 08:03:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-660795 ] logging missing from Python 2.3a1 for Windows Message-ID: Bugs item #660795, was opened at 2003-01-01 14:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660795&group_id=5470 Category: Windows Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Erik Demaine (edemaine) Assigned to: Tim Peters (tim_one) Summary: logging missing from Python 2.3a1 for Windows Initial Comment: The release notes for Python 2.3a1 claim that the "logging" package should be available in Python 2.3a1, but the Windows self-installing EXE claims otherwise. At least, Python23/Lib/logging doesn't exist after installation (in contrast to the tarball). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-02 11:03 Message: Logged In: YES user_id=31435 Cool! Thanks, Neal. The installer has been fixed (for the next 2.3 release), and a Python installed from it passes the new logging test. Misc/NEWS; new revision: 1.589 PCbuild/python20.wse; new revision: 1.114 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-02 09:59 Message: Logged In: YES user_id=33168 Bad timing. I was working w/Vinay on the logging test. He just gave me the ok to checkin. There's a lot in the test, hopefully it works on Windows. Checked in as Lib/test/test_logging.py and Lib/test/output/test_logging. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-02 00:26 Message: Logged In: YES user_id=31435 Ack. No new directory gets into the Windows installer unless the Wise script is programmed to put it there. This is a longstanding alpha glitch for new packages. If the test suite had even tried to import logging, it would have been caught (I always use the installer to install Python, and run a pile of tests on the installed version, before a release). So I'll add the logging package to the installer. Neal, it would be mondo cool if you could whip up a basic test_logging.py for the test suite, to verify that the package exists and that at least one piece of logging functionality actually works. Assign back to me whether or not you can make time to do that. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-01 15:42 Message: Logged In: YES user_id=33168 Tim, do you need to do something special to get directories? Did bsddb make it in? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660795&group_id=5470 From noreply@sourceforge.net Thu Jan 2 16:21:36 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 08:21:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-660961 ] tkinter.dooneevent() crashes Message-ID: Bugs item #660961, was opened at 2003-01-02 06:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660961&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Justin Gullingsrud (jgullingsrud) Assigned to: Martin v. Löwis (loewis) Summary: tkinter.dooneevent() crashes Initial Comment: On Linux, compiling against Tcl/Tk 8.3.5, running Tkinter.tkinter.dooneevent() segfaults immediately. Traceback: >>> from Tkinter import * >>> tkinter.dooneevent() Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 14004)] Tkapp_DoOneEvent (self=0x0, args=0x4049c02c) at Modules/_tkinter.c:2397 2397 CHECK_TCL_APPARTMENT; (gdb) where #0 Tkapp_DoOneEvent (self=0x0, args=0x4049c02c) at Modules/_tkinter.c:2397 #1 0x080f85c7 in PyCFunction_Call (func=0x404f5fac, arg=0x4049c02c, kw=0x0) at Objects/methodobject.c:90 #2 0x080a8185 in call_function (pp_stack=0xbffff22c, oparg=1) at Python/ceval.c:3249 #3 0x080a654e in eval_frame (f=0x8159f64) at Python/ceval.c:2009 #4 0x080a7095 in PyEval_EvalCodeEx (co=0x404ab620, globals=0x1, locals=0x404b48ac, args=0x8159f64, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2554 #5 0x080a9805 in PyEval_EvalCode (co=0x404ab620, globals=0x404b48ac, locals=0x404b48ac) at Python/ceval.c:478 #6 0x080cff99 in run_node (n=0x4049c2a8, filename=0x80fb12a "", globals=0x404b48ac, locals=0x404b48ac, flags=0xbffff418) at Python/pythonrun.c:1097 #7 0x080cf4fd in PyRun_InteractiveOneFlags (fp=0x40491de0, filename=0x80fb12a "", flags=0xbffff418) at Python/pythonrun.c:601 #8 0x080cf30c in PyRun_InteractiveLoopFlags (fp=0x40491de0, filename=0x80fb12a "", flags=0xbffff418) at Python/pythonrun.c:530 #9 0x080d09c6 in PyRun_AnyFileExFlags (fp=0x40491de0, filename=0x80fb12a "", closeit=0, flags=0xbffff418) at Python/pythonrun.c:493 #10 0x08055614 in Py_Main (argc=0, argv=0xbffff4a4) at Modules/main.c:446 #11 0x080551b9 in main (argc=1, argv=0xbffff4a4) at Modules/python.c:23 #12 0x403944a2 in __libc_start_main () from /lib/libc.so.6 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-02 17:21 Message: Logged In: YES user_id=21627 I didn't realize that doooneevent and mainloop are also methods on the module. For dooneevent, the check is actually bogus and can be removed. For mainloop, the problem is more serious; I'll investigate. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-02 16:42 Message: Logged In: YES user_id=33168 Martin, you added CHECK_TCL_APPARTMENT for threaded Tcl. Any ideas? I get the crash with Tk 8.3.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660961&group_id=5470 From noreply@sourceforge.net Thu Jan 2 16:37:30 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 08:37:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-661086 ] datetime.today() truncates microseconds Message-ID: Bugs item #661086, was opened at 2003-01-02 09:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661086&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Amaury Forgeot d'Arc (amauryf) Assigned to: Nobody/Anonymous (nobody) Summary: datetime.today() truncates microseconds Initial Comment: While exploring the new datetime module, I got results like: >>> datetime.datetime.today() datetime.datetime(2003, 1, 2, 15, 14, 51, 480999) Shouldn't the microseconds be 637000 ? While not very important, this can lead you to believe that the timestamp is accurate to 1e-6 seconds, whereas only milliseconds are relevant (on W2K). since today() is equivalent to fromtimestamp(time.time()), I explored the results of time.time(): >>> time.time(),datetime.datetime.today() returns: (1041516891.4809999, datetime.datetime(2003, 1, 2, 15, 14, 51, 480999)) It seems that the float returned by time.time is truncated to 1e-6. I suggest that it should be rounded instead, so that the last digit (which is significant) is taken into account. Looking into the code, I think that the code to change is in datetimemodule.c: the function datetime_from_timestamp could add 5e-7 to the "us" variable before casting it to int. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-02 11:37 Message: Logged In: YES user_id=31435 I agree it's an irritation, and changed the code to round to the nearest microsecond instead. Thanks for the report! Fixed in Modules/datetimemodule.c; new revision: 1.25 ---------------------------------------------------------------------- Comment By: Amaury Forgeot d'Arc (amauryf) Date: 2003-01-02 10:18 Message: Logged In: YES user_id=389140 Sorry for the typo: in my sample, I would like the microseconds to show as 481000 of course. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661086&group_id=5470 From noreply@sourceforge.net Thu Jan 2 16:41:12 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 08:41:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-661168 ] debug prints lingering in compiler/transformer.py Message-ID: Bugs item #661168, was opened at 2003-01-02 11:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661168&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Greg Ward (gward) Summary: debug prints lingering in compiler/transformer.py Initial Comment: In the stdlib, compiler/transformer.py (rev 1.35, Python 2.3a1) has unnecessary print statements at lines 653 & 660. I'll be happy to comment them out; just reassign the bug to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661168&group_id=5470 From noreply@sourceforge.net Thu Jan 2 16:41:34 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 08:41:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-661168 ] debug prints lingering in compiler/transformer.py Message-ID: Bugs item #661168, was opened at 2003-01-02 11:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661168&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) >Assigned to: Ken Manheimer (klm) Summary: debug prints lingering in compiler/transformer.py Initial Comment: In the stdlib, compiler/transformer.py (rev 1.35, Python 2.3a1) has unnecessary print statements at lines 653 & 660. I'll be happy to comment them out; just reassign the bug to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661168&group_id=5470 From noreply@sourceforge.net Thu Jan 2 16:42:12 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 08:42:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-661168 ] debug prints lingering in compiler/transformer.py Message-ID: Bugs item #661168, was opened at 2003-01-02 11:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661168&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) >Assigned to: Jeremy Hylton (jhylton) Summary: debug prints lingering in compiler/transformer.py Initial Comment: In the stdlib, compiler/transformer.py (rev 1.35, Python 2.3a1) has unnecessary print statements at lines 653 & 660. I'll be happy to comment them out; just reassign the bug to me. ---------------------------------------------------------------------- >Comment By: David Goodger (goodger) Date: 2003-01-02 11:42 Message: Logged In: YES user_id=7733 sorry, my browser is screwing up on "assigned to" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661168&group_id=5470 From noreply@sourceforge.net Thu Jan 2 16:46:16 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 08:46:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-660872 ] datetimetz constructors behave counterintuitively (2.3a1) Message-ID: Bugs item #660872, was opened at 2003-01-01 19:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660872&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Phillip J. Eby (pje) >Assigned to: Tim Peters (tim_one) Summary: datetimetz constructors behave counterintuitively (2.3a1) Initial Comment: datetimetz.fromtimestamp(timestamp,tzinfo) creates a datetime which has the localtime() value of timestamp, with the tzinfo attached as its timezone. But this produces a counterintuitive result. Instead of getting the UTC time represented by timestamp, converted to the tzinfo timezone, one only ends up with a correct value if tzinfo is a perfect match for whatever 'localtime' is. This seems useless as well as counterintuitive, since one must therefore do this: datetimetz.fromtimestamp(stamp,localtime_tz).astimezone(tzinfo) to get what's desired. Or, one can do: datetimetz.utcfromtimestamp(stamp).replace(tzinfo=utc).astimezone(tzinfo) Both of these seem unreasonably complex ways of doing something simple: render this UTC timestamp as a datetime in a specified timezone. Similarly, I would expect datetimetz.now(tzinfo) to return the current time in the zone specified by tzinfo, but again this is not what it does. Similarly, you must do: datetimetz.now(localtime_tz).astimezone(tzinfo) or: datetimetz.utcnow().replace(tzinfo=utc).astimezone(tzinfo) to get the current time in the zone specified by tzinfo. Given that these constructors *know* what the UTC time is, why don't they behave more meaningfully? It seems to me that finding the current time in a timezone, or rendering a timestamp as it would be seen in a timezone, are common enough use cases, but I cannot think of any use cases for what the constructors actually do instead. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 11:46 Message: Logged In: YES user_id=6380 I think that Phillip's proposal is reasonable: when you give a tzinfo argument to datetimetz.fromtimestamp(), it should *convert* to the given tzinfo. I think the proper semantics are specified by this expression: datetimetz.utcfromtimestamp(stamp).replace(tzinfo=utc).astimezone(tzinfo) The rule for now() follows from this. BTW, I think it was a mistake to let astimezone() convert from/to naive times. It should only be used for conversion between tz-aware times; conversion from/to naive time should be done using dt.replace(tzinfo=...). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-01 23:47 Message: Logged In: YES user_id=31435 I think Guido has more energy for this than I have (I'm pretty much burned out on this module), so assigned it to him. At the time fromtimestamp() was added, there wasn't any reasonable way to simply attach a tzinfo object to a datetimetz. About the best you could do is new = datetimetz(old.year, old.month, old.day, old.hour, old.minute, old.second, old.microsecond, tzinfo) So the use case of *simply* getting a local datetimetz out of a timestamp was quite a pain. datetimetz.fromtimestamp grew an optional tzinfo arg to ease that pain. There was no notion of timezone conversion at that time either, so of course none of the methods were intended to do any sort of conversion. Note that the primary constructor-- datetimetz --also takes all of its arguments as being in local time. It would strike me as inconsistent if fromtimestamp() didn't also take its argument as being in local time. Things changed since then, and I at least agree the docs should be clarified. But rather than make the constructors even more complicated, I'd rather drop the optional tzinfo arguments from fromtimestamp() and now(). There are at least two easy ways to attach a tzinfo tz to a datetimetz now: new = old.astimezone(tz) # no conversion if old was naive new = old.replace(tzinfo=tz) # no conversion ever and there's also an explict time zone conversion method. ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2003-01-01 22:40 Message: Logged In: YES user_id=56214 But in your use case, if the timezone they attach is in fact equivalent to localtime, then the conversion would be a no-op anyway, right? So how would a conversion in the general case be wrong? At the very least, this is a documentation bug. If these constructors only produce meaningful results for a tzinfo that's exactly equivalent to the system's localtime(), then the docs should say so. Otherwise, someone can write code that appears to work, for example, on their own machine, and then fails when run on a machine with a different concept of localtime(). Now, if you can actually come up with a sensible use case for *wrongly* translating a UTC-based timestamp to a particular timezone, with the degree of wrongness depending on the difference between localtime() and the specified timezone, that might justify the constructor behavior. :) As it is, I find it hard to believe that whatever you come up with will be a more common need than rendering a UTC timestamp as a datetime value in a specified timezone. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-01 20:14 Message: Logged In: YES user_id=31435 I always figured the use case for fromtimestamp(stamp, tz) was indeed so the user had a dead-easy way to attach their own local time tzinfo class to a timestamp, and that's all. I would find the behavior you describe counterintuitive instead: if I want a conversion, I'd rather ask for one explicitly (via astimezone()). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660872&group_id=5470 From noreply@sourceforge.net Thu Jan 2 16:55:26 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 08:55:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation. Message-ID: Bugs item #555817, was opened at 2002-05-14 10:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Graham Horler (grahamh) >Assigned to: Michael Hudson (mwh) Summary: Flawed fcntl.ioctl implementation. Initial Comment: I'm doing some USB user-space driver programming in Python 2.1.3 under Linux 2.4. When using a particular ioctl (HIDIOCGNAME), the return value as well as the (copy_to_user) binary data is significant. Here is the code from line 547 of hiddev.c (kernel 2.4.19-pre7): if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) { int len; if (!hid->name) return 0; len = strlen(hid->name) + 1; if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd); return copy_to_user((char *) arg, hid->name, len) ? -EFAULT : len; } So here is the problem: fcntl.ioctl() will only give me one or the other value, but not both. I can work around this by initialising the input buffer to all chr(0), and then strip them off after. But there will be a time when an ioctl call *requires* both values. Until now I have appreciated the simple ioctl interface, but now it is shown to be an oversimplification. It may be that POSIX, or some standard somewhere says that ioctl should not be used to do this, but maybe Python should support it anyway. I suggest either: 1. A new function ioctl2(fd, op, arg) that returns a 2-tuple of (return_value, binary_buffer) and does not try to interpret the return value. 2. An optional 4th parameter whose presence (but not value) requests the 2-tuple mentioned in (1). Gotta love Python! ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-01-02 16:55 Message: Logged In: YES user_id=6656 Assign to me in the hope that I'll stop forgetting about it (sigh). I'm about 70% of the way through what's needed I'd guess. Try to finish for 2.3a2... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-13 15:09 Message: Logged In: YES user_id=21627 The patch looks good, in principle, so please correct it, and provide documentation (do mention that you need to pass 1024 bytes to avoid copying). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-13 14:40 Message: Logged In: YES user_id=6656 I'd like to either move this forward or close it. Is/was there agreement that my patch would be OK if brushed up as described below, i.e. add tests, docs, provide better error messages? (actually, I note that my patch's use of Py_BEGIN_ALLOW_THREADS is amusingly broken... gotta love the C preprocessor). ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-06-12 11:38 Message: Logged In: YES user_id=543663 Still here... Thanks for the help people. Things have been a bit crazy ATM, but should be back to working with this again soon, so I'll let you know how it goes. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-16 13:15 Message: Logged In: YES user_id=29957 There's a very simple test_ioctl.py in patch #555883 (the ioctl2() sample implementation). It does a getpgrp(), then a TIOCGPGRP and checks it gets the same stuff. No, it won't work on Windows. I'm going to close off #555883 as Invalid. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 12:41 Message: Logged In: YES user_id=6656 Try the attached. (a) should have docs. This is getting hairy (if this then that, but if this and not that then the other...). (b) I've made no attempt to get this to hand out sane error messages (see above). (c) would be nice to have tests. how on earth do you test ioctl? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 12:03 Message: Logged In: YES user_id=6656 OK, that would seem to be easy enough to implement (well, the handling of writeable buffers, not all the optional hair). I like this: >>> buf = array.array('h', [0]*4) [19139 refs] >>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf) 0 [19139 refs] >>> buf array('h', [47, 137, 841, 615]) [19139 refs] I like this less: >>> import array, fcntl [19089 refs] >>> buf = array.array('h', [0]*3) [19093 refs] >>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf) 0 [19095 refs] >>> del buf Debug memory block at address p=0x401c3cb8: 6 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x401c3cbe are not all FORBIDDENBYTE (0xfb): at tail+0: 0x67 *** OUCH at tail+1: 0x02 *** OUCH at tail+2: 0xfb at tail+3: 0xfb The block was made by call #16015 to debug malloc/realloc. Data at p: 2f 00 89 00 49 03 Fatal Python error: bad trailing pad byte Aborted I'm not sure what we can possibly do about this? Copy into a fixed buffer like we do today, then copy out again after the ioctl? Probably the best option. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-16 11:43 Message: Logged In: YES user_id=21627 I'm in favour of a you-may-mutate-the-buffer flag. A transition strategy would be: - in 2.3, make the flag optional, with default 0 - in 2.4, warn if it is not specified - in 2.5, change the default All the time, if the buffer isn't mutable, specifying the flag should not be required. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-16 11:34 Message: Logged In: YES user_id=29957 Hm. The solaris /proc lib I did in python, I used 'struct' to dismantle C structures, but I did consider using byte arrays. So that's one data point. (ok, it's not ioctls, but it's similar sort of data). I'm loathe to go down the 'argument is mutable' optional flag, but I really would prefer to make this work rather than the ioctl2() approach, which really ain't that nice. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 10:21 Message: Logged In: YES user_id=6656 I'm not *trying* to be a party-pooper, but there's another problem: the point of passing a mutable array is so that fcntl.ioctl can return ioctl(2)'s return code rather than the string it returns now. So if someone does use arrays (or I guess Numeric.arrays?) for ioctls this would very likely cause breakage. I don't know how likely that is. Probably not very. But I know that if this change broke my code, I'd be a bit miffed. All this is a bit annoying, as mutating arrays is clearly the right solution -- where's that time machine? ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-15 23:50 Message: Logged In: YES user_id=543663 I just realised - using array objects and changing in-place oversomes the arbitrary limit of 1024 bytes. We could then achieve the full 16384 byte nirvana - hurrah! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 18:21 Message: Logged In: YES user_id=21627 I would not be concerned about the backwards compatibility, either: if anybody is passing arrays, there is a good chance that the ioctl does not modify the buffer, or that the caller would not worry about the (missing) modification - or else we had seen reports before. So documenting in Misc/NEWS and the documentation that mutable objects supporting the (write) buffer interface may now mutate seems sufficient. ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-15 17:32 Message: Logged In: YES user_id=543663 Thanks Michael, its all incredibly clear now (sorry Martin). I think using arrays sounds a great idea. IMVHO as to backward compatibility, AFAICT its not documented that arrays can be passed to ioctl() anyway (only says int and string no?), so it's only breaking undocumented behaviour. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-15 16:38 Message: Logged In: YES user_id=6656 grahamh: I think Martin understood you fine. Remember that arrays are mutable, whereas strings are not. So the idea would be that you'd write buf = array.array('c', '\000'*256) ret = fcntl.ioctl(fd, IOCTL_NUMBER, buf) then the first "ret" bytes of "buf" would be valid. However this possibly breaks backwards compatibility, as you can already pass arrays into the ioctl function and they are not modified. ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-15 15:44 Message: Logged In: YES user_id=543663 Re Loewis: Not sure what you mean, perhaps an example of the problem from me would help: In C: char buf[256], strbuf[256]; int ret, fd; fd = open(...) ret = ioctl(fd, IOCTL_NUMBER, buf); strncpy(strbuf, buf, ret); This is impossible with the current fcntl module: buf = "X" * struct.calcsize("256s") buf = fcntl.ioctl(fd, IOCTL_NUMBER, buf) # The positive ioctl() return value is lost, and # hence I dont know how much of buf is significant Extract from asm/unistd.h: #define __syscall_return(type, res) \ do { \ if ((unsigned long)(res) >= (unsigned long)(-125)) { \ errno = -(res); \ res = -1; \ } \ return (type) (res); \ } while (0) So positive values are valid, but are being lost. Anthony's patch looks good (thanks, I have not had a chance to test it myself yet), and the above example would be: buf = "X" * struct.calcsize("256s") ret, buf = fcntl.ioctl2(fd, IOCTL_NUMBER, buf) strbuf = buf[:ret] # Result! Now, to test my understanding of your last comment about array objects Loewis, do you mean: - pass in a mutable list that gets changed in place to [ret, buf] - return (ret, buf) if called like this: ioctl(fd, IOC, [buf]) - or something else - please give example. Thanks people. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 13:04 Message: Logged In: YES user_id=21627 Thinking about the problem again, I think the right solution would be to support array objects as arguments to ioctl - those would then be passed into the system call. Am I correctly understanding the problem, that this would not require a new function? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-14 13:06 Message: Logged In: YES user_id=29957 possible patch at http://sourceforge.net/tracker/index.php?func=detail&aid=555883&group_id=5470&atid=305470 I've only lightly tested it, not with any calls that return useful values in the return code (couldn't find any easily, didn't feel like figuring out userspace drivers right now :) Give it a whirl... ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-14 11:10 Message: Logged In: YES user_id=29957 Ouch. I think you're right - and I think that the ioctl2() implementation is probably the only solution. (I'm not so keen on the name, but I guess it kinda follows the 'standard' of other python functions, e.g. popen) I know changing the return of ioctl would be mega-ugly, unless there was a new, optional "return a tuple" argument. I doubt that's the appropriate fix. If the former approach is the appropriate one, it should be simple enough to add an ioctl2() to the C source. I can probably whip it up now... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470 From noreply@sourceforge.net Thu Jan 2 17:08:12 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 09:08:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-661184 ] inspect.getsource bug Message-ID: Bugs item #661184, was opened at 2003-01-02 12:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661184&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michele Simionato (michele_s) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getsource bug Initial Comment: I have found a bug in inspect.getsource. I am using Python 2.2.2 on Red-Hat 7.3. Here is the problem. --begin bug.py import inspect def f(x): return x print inspect.getsource(f) --end bug.py % python bug.py Traceback (most recent call last): File "bug.py", line 3, in ? print inspect.getsource(f) File "/usr/local/lib/python2.2/inspect.py", line 520, in getsource return string.join(lines, '') File "/usr/local/lib/python2.2/string.py", line 131, in join return sep.join(words) TypeError: sequence expected, NoneType found Notice that --begin noproblem.py import inspect def f(x): return x print inspect.getsource(f) --end noproblem.py works: % python noproblem.py def f(x): return x I discovered this bug in trying to retrieve the source code for lambda expressions: --begin lambda.py import inspect f=lambda x: x print inspect.getsource(f) --begin lambda.py (same error message). -- Michele Simionato - Dept. of Physics and Astronomy 210 Allen Hall Pittsburgh PA 15260 U.S.A. Phone: 001-412-624-9041 Fax: 001-412-624-9163 Home-page: http://www.phyast.pitt.edu/~micheles/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661184&group_id=5470 From noreply@sourceforge.net Thu Jan 2 17:38:58 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 09:38:58 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-661203 ] sigprocmask: None argument Message-ID: Feature Requests item #661203, was opened at 2003-01-02 17:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=661203&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Pomraning (pilcrow) Assigned to: Nobody/Anonymous (nobody) Summary: sigprocmask: None argument Initial Comment: signal.sigprocmask ought allow a None argument instead of a signal sequence: a) cur_mask = signal.sigprocmask(any_but_SETMASK, []) # sigprocmask(how, &empty_set, &cur_mask) b) cur_mask = signal.sigprocmask(dummy, None) # sigprocmask(dummy, NULL, &cur_mask) "a" is slightly more work for the kernel, and permits accidental SETMASKing. "b" avoids both, and is comfortably analogous to the familiar, ugly C interface (as opposed to, say, cur_mask = signal.sigprocmask()). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=661203&group_id=5470 From noreply@sourceforge.net Thu Jan 2 18:03:18 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 10:03:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-661168 ] debug prints lingering in compiler/transformer.py Message-ID: Bugs item #661168, was opened at 2003-01-02 11:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661168&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Goodger (goodger) >Assigned to: Michael Hudson (mwh) Summary: debug prints lingering in compiler/transformer.py Initial Comment: In the stdlib, compiler/transformer.py (rev 1.35, Python 2.3a1) has unnecessary print statements at lines 653 & 660. I'll be happy to comment them out; just reassign the bug to me. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-02 13:03 Message: Logged In: YES user_id=33168 I'm guessing these were actually from Michael's patch. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2003-01-02 11:42 Message: Logged In: YES user_id=7733 sorry, my browser is screwing up on "assigned to" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661168&group_id=5470 From noreply@sourceforge.net Thu Jan 2 19:09:05 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 11:09:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-660946 ] import.c compile fails on cygwin Message-ID: Bugs item #660946, was opened at 2003-01-01 23:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660946&group_id=5470 Category: Build Group: None >Status: Open Resolution: Works For Me Priority: 5 Submitted By: Paul Swartz (z3p) Assigned to: Jason Tishler (jlt63) Summary: import.c compile fails on cygwin Initial Comment: Using Python CVS, Python/import.c compile fails. GCC 3.2, Cygwin 1.3.17. Message is below: gcc -c -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Python/import.o Python/import.c Python/import.c:1376:21: windows.h: No such file or directory Python/import.c: In function `case_ok': Python/import.c:1410: `WIN32_FIND_DATA' undeclared (first use in this function) Python/import.c:1410: (Each undeclared identifier is reported only once Python/import.c:1410: for each function it appears in.) Python/import.c:1410: parse error before "data" Python/import.c:1411: `HANDLE' undeclared (first use in this function) Python/import.c:1413: `MAX_PATH' undeclared (first use in this function) Python/import.c:1421: `h' undeclared (first use in this function) Python/import.c:1421: warning: implicit declaration of function `FindFirstFile' Python/import.c:1421: `data' undeclared (first use in this function) Python/import.c:1425: `INVALID_HANDLE_VALUE' undeclared (first use in this function) Python/import.c:1431: warning: implicit declaration of function `FindClose' Python/import.c:1413: warning: unused variable `tempbuf' make: *** [Python/import.o] Error 1 ---------------------------------------------------------------------- >Comment By: Paul Swartz (z3p) Date: 2003-01-02 14:09 Message: Logged In: YES user_id=123843 Paul@MOO% cygcheck -c w32api;zcat /etc/setup/w32api.lst.gz |fgrep windows Cygwin Package Information Package Version w32api 2.1-1 Use -h to see help about each section usr/include/w32api/windows.h usr/include/w32api/windowsx.h Paul@MOO% ls - l /usr/include/w32api/windows.h /usr/src/python/dist/src [14:06] -rwx------+ 1 Paul None 2807 Nov 25 15:21 /usr/include/w32api/windows.h I reinstalled w32api, still the same problem. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-01-02 11:03 Message: Logged In: YES user_id=86216 > Jason are you having this problem? No. > Should windows.h be included? Yes. This is user error. Paul did not install the w32api package: $ cygcheck -c w32api Cygwin Package Information Package Version w32api 2.1-1 $ zcat /etc/setup/w32api.lst.gz | fgrep windows usr/include/w32api/windows.h ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-02 10:31 Message: Logged In: YES user_id=33168 Jason are you having this problem? Note the first error: windows.h: No such file or directory Should windows.h be included? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660946&group_id=5470 From noreply@sourceforge.net Thu Jan 2 19:23:18 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 11:23:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-660946 ] import.c compile fails on cygwin Message-ID: Bugs item #660946, was opened at 2003-01-01 19:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660946&group_id=5470 Category: Build Group: None Status: Open Resolution: Works For Me Priority: 5 Submitted By: Paul Swartz (z3p) Assigned to: Jason Tishler (jlt63) Summary: import.c compile fails on cygwin Initial Comment: Using Python CVS, Python/import.c compile fails. GCC 3.2, Cygwin 1.3.17. Message is below: gcc -c -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Python/import.o Python/import.c Python/import.c:1376:21: windows.h: No such file or directory Python/import.c: In function `case_ok': Python/import.c:1410: `WIN32_FIND_DATA' undeclared (first use in this function) Python/import.c:1410: (Each undeclared identifier is reported only once Python/import.c:1410: for each function it appears in.) Python/import.c:1410: parse error before "data" Python/import.c:1411: `HANDLE' undeclared (first use in this function) Python/import.c:1413: `MAX_PATH' undeclared (first use in this function) Python/import.c:1421: `h' undeclared (first use in this function) Python/import.c:1421: warning: implicit declaration of function `FindFirstFile' Python/import.c:1421: `data' undeclared (first use in this function) Python/import.c:1425: `INVALID_HANDLE_VALUE' undeclared (first use in this function) Python/import.c:1431: warning: implicit declaration of function `FindClose' Python/import.c:1413: warning: unused variable `tempbuf' make: *** [Python/import.o] Error 1 ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-01-02 10:23 Message: Logged In: YES user_id=86216 Did this used to compile for you and now doesn't? Or, is this your first time trying to compile under Cygwin? BTW, what version of gcc are you using? $ cygcheck -c gcc Cygwin Package Information Package Version gcc 3.2-3 This may no longer work with gcc 2.95.3-5. ---------------------------------------------------------------------- Comment By: Paul Swartz (z3p) Date: 2003-01-02 10:09 Message: Logged In: YES user_id=123843 Paul@MOO% cygcheck -c w32api;zcat /etc/setup/w32api.lst.gz |fgrep windows Cygwin Package Information Package Version w32api 2.1-1 Use -h to see help about each section usr/include/w32api/windows.h usr/include/w32api/windowsx.h Paul@MOO% ls - l /usr/include/w32api/windows.h /usr/src/python/dist/src [14:06] -rwx------+ 1 Paul None 2807 Nov 25 15:21 /usr/include/w32api/windows.h I reinstalled w32api, still the same problem. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-01-02 07:03 Message: Logged In: YES user_id=86216 > Jason are you having this problem? No. > Should windows.h be included? Yes. This is user error. Paul did not install the w32api package: $ cygcheck -c w32api Cygwin Package Information Package Version w32api 2.1-1 $ zcat /etc/setup/w32api.lst.gz | fgrep windows usr/include/w32api/windows.h ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-02 06:31 Message: Logged In: YES user_id=33168 Jason are you having this problem? Note the first error: windows.h: No such file or directory Should windows.h be included? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660946&group_id=5470 From noreply@sourceforge.net Thu Jan 2 19:33:10 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 11:33:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-660946 ] import.c compile fails on cygwin Message-ID: Bugs item #660946, was opened at 2003-01-01 23:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660946&group_id=5470 Category: Build Group: None Status: Open Resolution: Works For Me Priority: 5 Submitted By: Paul Swartz (z3p) Assigned to: Jason Tishler (jlt63) Summary: import.c compile fails on cygwin Initial Comment: Using Python CVS, Python/import.c compile fails. GCC 3.2, Cygwin 1.3.17. Message is below: gcc -c -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Python/import.o Python/import.c Python/import.c:1376:21: windows.h: No such file or directory Python/import.c: In function `case_ok': Python/import.c:1410: `WIN32_FIND_DATA' undeclared (first use in this function) Python/import.c:1410: (Each undeclared identifier is reported only once Python/import.c:1410: for each function it appears in.) Python/import.c:1410: parse error before "data" Python/import.c:1411: `HANDLE' undeclared (first use in this function) Python/import.c:1413: `MAX_PATH' undeclared (first use in this function) Python/import.c:1421: `h' undeclared (first use in this function) Python/import.c:1421: warning: implicit declaration of function `FindFirstFile' Python/import.c:1421: `data' undeclared (first use in this function) Python/import.c:1425: `INVALID_HANDLE_VALUE' undeclared (first use in this function) Python/import.c:1431: warning: implicit declaration of function `FindClose' Python/import.c:1413: warning: unused variable `tempbuf' make: *** [Python/import.o] Error 1 ---------------------------------------------------------------------- >Comment By: Paul Swartz (z3p) Date: 2003-01-02 14:33 Message: Logged In: YES user_id=123843 Used to compile, now it doesn't. I compiled it as of Jan 1 2003, 12:04:35. I'm using gcc 3.2-3 Cygwin Package Information Package Version gcc 3.2-3 ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-01-02 14:23 Message: Logged In: YES user_id=86216 Did this used to compile for you and now doesn't? Or, is this your first time trying to compile under Cygwin? BTW, what version of gcc are you using? $ cygcheck -c gcc Cygwin Package Information Package Version gcc 3.2-3 This may no longer work with gcc 2.95.3-5. ---------------------------------------------------------------------- Comment By: Paul Swartz (z3p) Date: 2003-01-02 14:09 Message: Logged In: YES user_id=123843 Paul@MOO% cygcheck -c w32api;zcat /etc/setup/w32api.lst.gz |fgrep windows Cygwin Package Information Package Version w32api 2.1-1 Use -h to see help about each section usr/include/w32api/windows.h usr/include/w32api/windowsx.h Paul@MOO% ls - l /usr/include/w32api/windows.h /usr/src/python/dist/src [14:06] -rwx------+ 1 Paul None 2807 Nov 25 15:21 /usr/include/w32api/windows.h I reinstalled w32api, still the same problem. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-01-02 11:03 Message: Logged In: YES user_id=86216 > Jason are you having this problem? No. > Should windows.h be included? Yes. This is user error. Paul did not install the w32api package: $ cygcheck -c w32api Cygwin Package Information Package Version w32api 2.1-1 $ zcat /etc/setup/w32api.lst.gz | fgrep windows usr/include/w32api/windows.h ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-02 10:31 Message: Logged In: YES user_id=33168 Jason are you having this problem? Note the first error: windows.h: No such file or directory Should windows.h be included? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660946&group_id=5470 From noreply@sourceforge.net Thu Jan 2 20:45:02 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 12:45:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-660946 ] import.c compile fails on cygwin Message-ID: Bugs item #660946, was opened at 2003-01-01 23:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660946&group_id=5470 Category: Build Group: None Status: Open Resolution: Works For Me Priority: 5 Submitted By: Paul Swartz (z3p) Assigned to: Jason Tishler (jlt63) Summary: import.c compile fails on cygwin Initial Comment: Using Python CVS, Python/import.c compile fails. GCC 3.2, Cygwin 1.3.17. Message is below: gcc -c -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Python/import.o Python/import.c Python/import.c:1376:21: windows.h: No such file or directory Python/import.c: In function `case_ok': Python/import.c:1410: `WIN32_FIND_DATA' undeclared (first use in this function) Python/import.c:1410: (Each undeclared identifier is reported only once Python/import.c:1410: for each function it appears in.) Python/import.c:1410: parse error before "data" Python/import.c:1411: `HANDLE' undeclared (first use in this function) Python/import.c:1413: `MAX_PATH' undeclared (first use in this function) Python/import.c:1421: `h' undeclared (first use in this function) Python/import.c:1421: warning: implicit declaration of function `FindFirstFile' Python/import.c:1421: `data' undeclared (first use in this function) Python/import.c:1425: `INVALID_HANDLE_VALUE' undeclared (first use in this function) Python/import.c:1431: warning: implicit declaration of function `FindClose' Python/import.c:1413: warning: unused variable `tempbuf' make: *** [Python/import.o] Error 1 ---------------------------------------------------------------------- >Comment By: Paul Swartz (z3p) Date: 2003-01-02 15:45 Message: Logged In: YES user_id=123843 Adding /usr/include/w32api to the include list in the Makefile seems to work, which makes me think it may be a gcc problem. I'm going to try reinstalling it, I'll see what happens. ---------------------------------------------------------------------- Comment By: Paul Swartz (z3p) Date: 2003-01-02 14:33 Message: Logged In: YES user_id=123843 Used to compile, now it doesn't. I compiled it as of Jan 1 2003, 12:04:35. I'm using gcc 3.2-3 Cygwin Package Information Package Version gcc 3.2-3 ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-01-02 14:23 Message: Logged In: YES user_id=86216 Did this used to compile for you and now doesn't? Or, is this your first time trying to compile under Cygwin? BTW, what version of gcc are you using? $ cygcheck -c gcc Cygwin Package Information Package Version gcc 3.2-3 This may no longer work with gcc 2.95.3-5. ---------------------------------------------------------------------- Comment By: Paul Swartz (z3p) Date: 2003-01-02 14:09 Message: Logged In: YES user_id=123843 Paul@MOO% cygcheck -c w32api;zcat /etc/setup/w32api.lst.gz |fgrep windows Cygwin Package Information Package Version w32api 2.1-1 Use -h to see help about each section usr/include/w32api/windows.h usr/include/w32api/windowsx.h Paul@MOO% ls - l /usr/include/w32api/windows.h /usr/src/python/dist/src [14:06] -rwx------+ 1 Paul None 2807 Nov 25 15:21 /usr/include/w32api/windows.h I reinstalled w32api, still the same problem. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-01-02 11:03 Message: Logged In: YES user_id=86216 > Jason are you having this problem? No. > Should windows.h be included? Yes. This is user error. Paul did not install the w32api package: $ cygcheck -c w32api Cygwin Package Information Package Version w32api 2.1-1 $ zcat /etc/setup/w32api.lst.gz | fgrep windows usr/include/w32api/windows.h ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-02 10:31 Message: Logged In: YES user_id=33168 Jason are you having this problem? Note the first error: windows.h: No such file or directory Should windows.h be included? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660946&group_id=5470 From noreply@sourceforge.net Thu Jan 2 21:14:21 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 13:14:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-660946 ] import.c compile fails on cygwin Message-ID: Bugs item #660946, was opened at 2003-01-01 23:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660946&group_id=5470 Category: Build Group: None >Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Paul Swartz (z3p) Assigned to: Jason Tishler (jlt63) Summary: import.c compile fails on cygwin Initial Comment: Using Python CVS, Python/import.c compile fails. GCC 3.2, Cygwin 1.3.17. Message is below: gcc -c -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. - I./Include -DPy_BUILD_CORE -o Python/import.o Python/import.c Python/import.c:1376:21: windows.h: No such file or directory Python/import.c: In function `case_ok': Python/import.c:1410: `WIN32_FIND_DATA' undeclared (first use in this function) Python/import.c:1410: (Each undeclared identifier is reported only once Python/import.c:1410: for each function it appears in.) Python/import.c:1410: parse error before "data" Python/import.c:1411: `HANDLE' undeclared (first use in this function) Python/import.c:1413: `MAX_PATH' undeclared (first use in this function) Python/import.c:1421: `h' undeclared (first use in this function) Python/import.c:1421: warning: implicit declaration of function `FindFirstFile' Python/import.c:1421: `data' undeclared (first use in this function) Python/import.c:1425: `INVALID_HANDLE_VALUE' undeclared (first use in this function) Python/import.c:1431: warning: implicit declaration of function `FindClose' Python/import.c:1413: warning: unused variable `tempbuf' make: *** [Python/import.o] Error 1 ---------------------------------------------------------------------- >Comment By: Paul Swartz (z3p) Date: 2003-01-02 16:14 Message: Logged In: YES user_id=123843 Yes, reinstalling GCC seemed to do it. I still don't know what broke, but it wasn't Python :) ---------------------------------------------------------------------- Comment By: Paul Swartz (z3p) Date: 2003-01-02 15:45 Message: Logged In: YES user_id=123843 Adding /usr/include/w32api to the include list in the Makefile seems to work, which makes me think it may be a gcc problem. I'm going to try reinstalling it, I'll see what happens. ---------------------------------------------------------------------- Comment By: Paul Swartz (z3p) Date: 2003-01-02 14:33 Message: Logged In: YES user_id=123843 Used to compile, now it doesn't. I compiled it as of Jan 1 2003, 12:04:35. I'm using gcc 3.2-3 Cygwin Package Information Package Version gcc 3.2-3 ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-01-02 14:23 Message: Logged In: YES user_id=86216 Did this used to compile for you and now doesn't? Or, is this your first time trying to compile under Cygwin? BTW, what version of gcc are you using? $ cygcheck -c gcc Cygwin Package Information Package Version gcc 3.2-3 This may no longer work with gcc 2.95.3-5. ---------------------------------------------------------------------- Comment By: Paul Swartz (z3p) Date: 2003-01-02 14:09 Message: Logged In: YES user_id=123843 Paul@MOO% cygcheck -c w32api;zcat /etc/setup/w32api.lst.gz |fgrep windows Cygwin Package Information Package Version w32api 2.1-1 Use -h to see help about each section usr/include/w32api/windows.h usr/include/w32api/windowsx.h Paul@MOO% ls - l /usr/include/w32api/windows.h /usr/src/python/dist/src [14:06] -rwx------+ 1 Paul None 2807 Nov 25 15:21 /usr/include/w32api/windows.h I reinstalled w32api, still the same problem. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-01-02 11:03 Message: Logged In: YES user_id=86216 > Jason are you having this problem? No. > Should windows.h be included? Yes. This is user error. Paul did not install the w32api package: $ cygcheck -c w32api Cygwin Package Information Package Version w32api 2.1-1 $ zcat /etc/setup/w32api.lst.gz | fgrep windows usr/include/w32api/windows.h ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-02 10:31 Message: Logged In: YES user_id=33168 Jason are you having this problem? Note the first error: windows.h: No such file or directory Should windows.h be included? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660946&group_id=5470 From noreply@sourceforge.net Thu Jan 2 21:20:41 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 13:20:41 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-500698 ] Taint a la Perl? Message-ID: Feature Requests item #500698, was opened at 2002-01-07 19:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=500698&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Scott (sketerpot) Assigned to: Nobody/Anonymous (nobody) Summary: Taint a la Perl? Initial Comment: This might just add unnecessary bloat, but since Python is being used in CGI scripts, it can be used to narrow a security hole. One way of breaking security is for a naiive programmer (don't try to deny their existance) to run an arbitrary command from the page viewer. Perl has developed an interesting mechanism for helping with this: taint. The way it works is, when something comes directly from the user, like a key in a form, it is considered to have taint unless specifically untainted. Things like os.exec() would create a warning message if you passed tainted strings to them. As I said, this might just add unnecessary bloat, but for an option that can be left out for most builds of Python I think it would be pretty nice. ---------------------------------------------------------------------- Comment By: Neal McBurnett (nealmcb) Date: 2003-01-02 14:20 Message: Logged In: YES user_id=105956 I really like taint mode. I think this would make Python a better choice for CGI scripts. See http://www.perldoc.com/perl5.8.0/pod/perlsec.html and http://gunther.web66.com/FAQS/taintmode.html for more background. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=500698&group_id=5470 From noreply@sourceforge.net Thu Jan 2 22:05:39 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 14:05:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-661330 ] test_pep263 fails in MacPython-OS9 Message-ID: Bugs item #661330, was opened at 2003-01-02 23:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661330&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 8 Submitted By: Jack Jansen (jackjansen) Assigned to: Martin v. Löwis (loewis) Summary: test_pep263 fails in MacPython-OS9 Initial Comment: Martin, test_pep263 fails in MacPython-OS9. I think this is because the file is actually a binary file but it is checked in as a text file. Because it is checked in as a text file the funny characters (which I assume are in the funny charset that the test tries to test, right?) go through a Latin-1 to MacRoman conversion, which breaks them rather thoroughly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661330&group_id=5470 From noreply@sourceforge.net Thu Jan 2 22:11:05 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 14:11:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-661330 ] test_pep263 fails in MacPython-OS9 Message-ID: Bugs item #661330, was opened at 2003-01-02 23:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661330&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 8 Submitted By: Jack Jansen (jackjansen) Assigned to: Martin v. Löwis (loewis) Summary: test_pep263 fails in MacPython-OS9 Initial Comment: Martin, test_pep263 fails in MacPython-OS9. I think this is because the file is actually a binary file but it is checked in as a text file. Because it is checked in as a text file the funny characters (which I assume are in the funny charset that the test tries to test, right?) go through a Latin-1 to MacRoman conversion, which breaks them rather thoroughly. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-02 23:11 Message: Logged In: YES user_id=21627 Would it help to check it in as a binary file? It would then have Unix line endings, if I check it in... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661330&group_id=5470 From noreply@sourceforge.net Thu Jan 2 22:13:45 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 14:13:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-661340 ] test_httplib fails on the mac Message-ID: Bugs item #661340, was opened at 2003-01-02 23:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661340&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Jeremy Hylton (jhylton) Summary: test_httplib fails on the mac Initial Comment: test_httplib fails on MacPython-OS9. This is because the output contains \r and \n characters, and this fails on MacOS9. There are two problems really: 1. output/test_httplib is checked in as a text file, while it is a binary file (it contains some \r\n data) or even (brrr:-) mixed-mode (it also contains \n lineendings). 2. The output file is opened in text mode (when re-reading the data), so this can probably not be fixed by a simple cvs admin -kb. I think that putting repr()s in the output in stead of raw strings is probably good enough, but you probably know better what is going on here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661340&group_id=5470 From noreply@sourceforge.net Thu Jan 2 22:17:29 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 14:17:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-661330 ] test_pep263 fails in MacPython-OS9 Message-ID: Bugs item #661330, was opened at 2003-01-02 23:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661330&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 8 Submitted By: Jack Jansen (jackjansen) Assigned to: Martin v. Löwis (loewis) Summary: test_pep263 fails in MacPython-OS9 Initial Comment: Martin, test_pep263 fails in MacPython-OS9. I think this is because the file is actually a binary file but it is checked in as a text file. Because it is checked in as a text file the funny characters (which I assume are in the funny charset that the test tries to test, right?) go through a Latin-1 to MacRoman conversion, which breaks them rather thoroughly. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-02 23:17 Message: Logged In: YES user_id=21627 Actually, changing it to binary seems to be the right thing anyway, so I have done that. Can you please report whether this fixes the problem? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-02 23:11 Message: Logged In: YES user_id=21627 Would it help to check it in as a binary file? It would then have Unix line endings, if I check it in... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661330&group_id=5470 From noreply@sourceforge.net Thu Jan 2 22:29:55 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 14:29:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-661354 ] test_strptime fails on the Mac Message-ID: Bugs item #661354, was opened at 2003-01-02 23:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Guido van Rossum (gvanrossum) Summary: test_strptime fails on the Mac Initial Comment: test_strptime fails for MacPython-OS9. It appears to be an error in the test itself, but it could be this error is triggered only on the Mac (because it doesn't have a builtin strptime() function but uses the pure Python strptime implementation). Here is the first stacktrace from the test (a lot of very similar ones follow): Traceback (most recent call last): File "Moes:SWdev:Jack:MacPython:Lib:test:test_strptime.py", line 183, in test_compile compiled = self.time_re.compile("%%%s"% directive) File "Moes:SWdev:Jack:MacPython:Lib:_strptime.py", line 394, in compile return re_compile(self.pattern(format), IGNORECASE) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 179, in compile return _compile(pattern, flags) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 229, in _compile raise error, v # invalid expression error: redefinition of group name 'Z' as group 2; was group 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 From noreply@sourceforge.net Thu Jan 2 22:33:31 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 14:33:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-661357 ] tkFileDialog.SaveAs Message-ID: Bugs item #661357, was opened at 2003-01-02 17:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661357&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Martin v. Löwis (loewis) Summary: tkFileDialog.SaveAs Initial Comment: The SaveAs dialog gets a traceback due to the new object-style Tk interface. Run this test program: from Tkinter import * import tkFileDialog def doit(): savedialog = tkFileDialog.SaveAs(master=root) print savedialog.show(initialdir="/tmp", initialfile="foo.py") root = Tk() button = Button(root, text="Save...", command=doit) button.pack() mainloop() I get this traceback: Traceback (most recent call last): File "/usr/local/lib/python2.3/lib-tk/Tkinter.py", line 1306, in __call__ return apply(self.func, args) File "tkf.py", line 5, in doit print savedialog.show(initialdir="/tmp", initialfile="foo.py") File "/usr/local/lib/python2.3/lib-tk/tkCommonDialog.py", line 54, in show s = self._fixresult(w, s) File "/usr/local/lib/python2.3/lib-tk/tkFileDialog.py", line 58, in _fixresult path, file = os.path.split(result) File "/usr/local/lib/python2.3/posixpath.py", line 65, in split i = p.rfind('/') + 1 AttributeError: '_tkinter.Tcl_Obj' object has no attribute 'rfind' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661357&group_id=5470 From noreply@sourceforge.net Thu Jan 2 22:40:03 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 14:40:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-661354 ] test_strptime fails on the Mac Message-ID: Bugs item #661354, was opened at 2003-01-02 17:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Guido van Rossum (gvanrossum) Summary: test_strptime fails on the Mac Initial Comment: test_strptime fails for MacPython-OS9. It appears to be an error in the test itself, but it could be this error is triggered only on the Mac (because it doesn't have a builtin strptime() function but uses the pure Python strptime implementation). Here is the first stacktrace from the test (a lot of very similar ones follow): Traceback (most recent call last): File "Moes:SWdev:Jack:MacPython:Lib:test:test_strptime.py", line 183, in test_compile compiled = self.time_re.compile("%%%s"% directive) File "Moes:SWdev:Jack:MacPython:Lib:_strptime.py", line 394, in compile return re_compile(self.pattern(format), IGNORECASE) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 179, in compile return _compile(pattern, flags) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 229, in _compile raise error, v # invalid expression error: redefinition of group name 'Z' as group 2; was group 1 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 17:40 Message: Logged In: YES user_id=6380 I've forwarded this to Brett Cannon -- he's the author, maybe he understands what's going on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 From noreply@sourceforge.net Thu Jan 2 22:44:29 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 14:44:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-661354 ] test_strptime fails on the Mac Message-ID: Bugs item #661354, was opened at 2003-01-02 17:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Guido van Rossum (gvanrossum) Summary: test_strptime fails on the Mac Initial Comment: test_strptime fails for MacPython-OS9. It appears to be an error in the test itself, but it could be this error is triggered only on the Mac (because it doesn't have a builtin strptime() function but uses the pure Python strptime implementation). Here is the first stacktrace from the test (a lot of very similar ones follow): Traceback (most recent call last): File "Moes:SWdev:Jack:MacPython:Lib:test:test_strptime.py", line 183, in test_compile compiled = self.time_re.compile("%%%s"% directive) File "Moes:SWdev:Jack:MacPython:Lib:_strptime.py", line 394, in compile return re_compile(self.pattern(format), IGNORECASE) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 179, in compile return _compile(pattern, flags) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 229, in _compile raise error, v # invalid expression error: redefinition of group name 'Z' as group 2; was group 1 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 17:44 Message: Logged In: YES user_id=6380 BTW, there's an #undef HAVE_STRPTIME in timemodule.c, so that *everybody* will *always* be using the Python implementation. The test passes for me on Linux, FWIW. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 17:40 Message: Logged In: YES user_id=6380 I've forwarded this to Brett Cannon -- he's the author, maybe he understands what's going on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 From noreply@sourceforge.net Thu Jan 2 23:54:11 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 15:54:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-661354 ] test_strptime fails on the Mac Message-ID: Bugs item #661354, was opened at 2003-01-02 14:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Guido van Rossum (gvanrossum) Summary: test_strptime fails on the Mac Initial Comment: test_strptime fails for MacPython-OS9. It appears to be an error in the test itself, but it could be this error is triggered only on the Mac (because it doesn't have a builtin strptime() function but uses the pure Python strptime implementation). Here is the first stacktrace from the test (a lot of very similar ones follow): Traceback (most recent call last): File "Moes:SWdev:Jack:MacPython:Lib:test:test_strptime.py", line 183, in test_compile compiled = self.time_re.compile("%%%s"% directive) File "Moes:SWdev:Jack:MacPython:Lib:_strptime.py", line 394, in compile return re_compile(self.pattern(format), IGNORECASE) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 179, in compile return _compile(pattern, flags) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 229, in _compile raise error, v # invalid expression error: redefinition of group name 'Z' as group 2; was group 1 ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-02 15:54 Message: Logged In: YES user_id=357491 As for the bug, obviously a regex is being created where the regex group Z is being specified twice. I will take a look, but I just ran the tests and I am having no problems on OS X 10.2.3. I have some ideas on where this trouble could be produced, though, so I will see if I can find a problem or come up with some code Jack can run to try to help figure out the problem. Are the "very similar ones" that follow this stack trace all from the same line in test_strptime, or all from the same line in _strptime? In other words, are they all the same error being caused by the same test or the same chunk of code in _strptime? Or am I so unlucky that it is just the same redefinition error but with everything else different every time? Oh, and one quick syntax thing; line 394 in test_strptime.py has a string where the ``%`` operator has no space between it and the string being worked on. I know what a stickler you are, Guido, so I thought you should know . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 14:44 Message: Logged In: YES user_id=6380 BTW, there's an #undef HAVE_STRPTIME in timemodule.c, so that *everybody* will *always* be using the Python implementation. The test passes for me on Linux, FWIW. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 14:40 Message: Logged In: YES user_id=6380 I've forwarded this to Brett Cannon -- he's the author, maybe he understands what's going on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 From noreply@sourceforge.net Fri Jan 3 00:01:11 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 16:01:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-661354 ] test_strptime fails on the Mac Message-ID: Bugs item #661354, was opened at 2003-01-02 17:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Guido van Rossum (gvanrossum) Summary: test_strptime fails on the Mac Initial Comment: test_strptime fails for MacPython-OS9. It appears to be an error in the test itself, but it could be this error is triggered only on the Mac (because it doesn't have a builtin strptime() function but uses the pure Python strptime implementation). Here is the first stacktrace from the test (a lot of very similar ones follow): Traceback (most recent call last): File "Moes:SWdev:Jack:MacPython:Lib:test:test_strptime.py", line 183, in test_compile compiled = self.time_re.compile("%%%s"% directive) File "Moes:SWdev:Jack:MacPython:Lib:_strptime.py", line 394, in compile return re_compile(self.pattern(format), IGNORECASE) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 179, in compile return _compile(pattern, flags) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 229, in _compile raise error, v # invalid expression error: redefinition of group name 'Z' as group 2; was group 1 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-02 19:01 Message: Logged In: YES user_id=31435 FYI, it also passes on Windows (98SE and 2K). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-02 18:54 Message: Logged In: YES user_id=357491 As for the bug, obviously a regex is being created where the regex group Z is being specified twice. I will take a look, but I just ran the tests and I am having no problems on OS X 10.2.3. I have some ideas on where this trouble could be produced, though, so I will see if I can find a problem or come up with some code Jack can run to try to help figure out the problem. Are the "very similar ones" that follow this stack trace all from the same line in test_strptime, or all from the same line in _strptime? In other words, are they all the same error being caused by the same test or the same chunk of code in _strptime? Or am I so unlucky that it is just the same redefinition error but with everything else different every time? Oh, and one quick syntax thing; line 394 in test_strptime.py has a string where the ``%`` operator has no space between it and the string being worked on. I know what a stickler you are, Guido, so I thought you should know . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 17:44 Message: Logged In: YES user_id=6380 BTW, there's an #undef HAVE_STRPTIME in timemodule.c, so that *everybody* will *always* be using the Python implementation. The test passes for me on Linux, FWIW. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 17:40 Message: Logged In: YES user_id=6380 I've forwarded this to Brett Cannon -- he's the author, maybe he understands what's going on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 From noreply@sourceforge.net Fri Jan 3 00:38:38 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 16:38:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-661354 ] test_strptime fails on the Mac Message-ID: Bugs item #661354, was opened at 2003-01-02 14:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Guido van Rossum (gvanrossum) Summary: test_strptime fails on the Mac Initial Comment: test_strptime fails for MacPython-OS9. It appears to be an error in the test itself, but it could be this error is triggered only on the Mac (because it doesn't have a builtin strptime() function but uses the pure Python strptime implementation). Here is the first stacktrace from the test (a lot of very similar ones follow): Traceback (most recent call last): File "Moes:SWdev:Jack:MacPython:Lib:test:test_strptime.py", line 183, in test_compile compiled = self.time_re.compile("%%%s"% directive) File "Moes:SWdev:Jack:MacPython:Lib:_strptime.py", line 394, in compile return re_compile(self.pattern(format), IGNORECASE) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 179, in compile return _compile(pattern, flags) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 229, in _compile raise error, v # invalid expression error: redefinition of group name 'Z' as group 2; was group 1 ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-02 16:38 Message: Logged In: YES user_id=357491 OK, with Tim's info I am starting to wonder if this isn't some how an OS 9-specific thing. To make sure, Jack, can you run this code?:: >>> import _strptime >>> _strptime.TimeRE().compile("%Z").pattern The ``TimeRE`` class is what handles the creation of the final regex to use for parsing the input string. the ``.compile()`` method takes the directive format string and outputs the regex pattern object. The above code should spit out a string similar to ``(?#)(?PPST|PDT|)`` (and yes, that emptiness after the last pipe is expected; have to handle chance that no timezone is actually in the input string since it *could* be there). If this has two Z groups, then we have found our problem. If not, then I am goiing to need basically all the tracebacks to figure this one out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-02 16:01 Message: Logged In: YES user_id=31435 FYI, it also passes on Windows (98SE and 2K). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-02 15:54 Message: Logged In: YES user_id=357491 As for the bug, obviously a regex is being created where the regex group Z is being specified twice. I will take a look, but I just ran the tests and I am having no problems on OS X 10.2.3. I have some ideas on where this trouble could be produced, though, so I will see if I can find a problem or come up with some code Jack can run to try to help figure out the problem. Are the "very similar ones" that follow this stack trace all from the same line in test_strptime, or all from the same line in _strptime? In other words, are they all the same error being caused by the same test or the same chunk of code in _strptime? Or am I so unlucky that it is just the same redefinition error but with everything else different every time? Oh, and one quick syntax thing; line 394 in test_strptime.py has a string where the ``%`` operator has no space between it and the string being worked on. I know what a stickler you are, Guido, so I thought you should know . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 14:44 Message: Logged In: YES user_id=6380 BTW, there's an #undef HAVE_STRPTIME in timemodule.c, so that *everybody* will *always* be using the Python implementation. The test passes for me on Linux, FWIW. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 14:40 Message: Logged In: YES user_id=6380 I've forwarded this to Brett Cannon -- he's the author, maybe he understands what's going on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 From noreply@sourceforge.net Fri Jan 3 00:39:42 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 16:39:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-661354 ] test_strptime fails on the Mac Message-ID: Bugs item #661354, was opened at 2003-01-02 14:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Guido van Rossum (gvanrossum) Summary: test_strptime fails on the Mac Initial Comment: test_strptime fails for MacPython-OS9. It appears to be an error in the test itself, but it could be this error is triggered only on the Mac (because it doesn't have a builtin strptime() function but uses the pure Python strptime implementation). Here is the first stacktrace from the test (a lot of very similar ones follow): Traceback (most recent call last): File "Moes:SWdev:Jack:MacPython:Lib:test:test_strptime.py", line 183, in test_compile compiled = self.time_re.compile("%%%s"% directive) File "Moes:SWdev:Jack:MacPython:Lib:_strptime.py", line 394, in compile return re_compile(self.pattern(format), IGNORECASE) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 179, in compile return _compile(pattern, flags) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 229, in _compile raise error, v # invalid expression error: redefinition of group name 'Z' as group 2; was group 1 ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-02 16:39 Message: Logged In: YES user_id=357491 And for Jack's own personal knowledge, test_strptime is only run against _strptime.py. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-02 16:38 Message: Logged In: YES user_id=357491 OK, with Tim's info I am starting to wonder if this isn't some how an OS 9-specific thing. To make sure, Jack, can you run this code?:: >>> import _strptime >>> _strptime.TimeRE().compile("%Z").pattern The ``TimeRE`` class is what handles the creation of the final regex to use for parsing the input string. the ``.compile()`` method takes the directive format string and outputs the regex pattern object. The above code should spit out a string similar to ``(?#)(?PPST|PDT|)`` (and yes, that emptiness after the last pipe is expected; have to handle chance that no timezone is actually in the input string since it *could* be there). If this has two Z groups, then we have found our problem. If not, then I am goiing to need basically all the tracebacks to figure this one out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-02 16:01 Message: Logged In: YES user_id=31435 FYI, it also passes on Windows (98SE and 2K). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-02 15:54 Message: Logged In: YES user_id=357491 As for the bug, obviously a regex is being created where the regex group Z is being specified twice. I will take a look, but I just ran the tests and I am having no problems on OS X 10.2.3. I have some ideas on where this trouble could be produced, though, so I will see if I can find a problem or come up with some code Jack can run to try to help figure out the problem. Are the "very similar ones" that follow this stack trace all from the same line in test_strptime, or all from the same line in _strptime? In other words, are they all the same error being caused by the same test or the same chunk of code in _strptime? Or am I so unlucky that it is just the same redefinition error but with everything else different every time? Oh, and one quick syntax thing; line 394 in test_strptime.py has a string where the ``%`` operator has no space between it and the string being worked on. I know what a stickler you are, Guido, so I thought you should know . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 14:44 Message: Logged In: YES user_id=6380 BTW, there's an #undef HAVE_STRPTIME in timemodule.c, so that *everybody* will *always* be using the Python implementation. The test passes for me on Linux, FWIW. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 14:40 Message: Logged In: YES user_id=6380 I've forwarded this to Brett Cannon -- he's the author, maybe he understands what's going on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 From noreply@sourceforge.net Fri Jan 3 01:18:51 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 17:18:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-661408 ] "make install" fails with --enable-shared Message-ID: Bugs item #661408, was opened at 2003-01-03 01:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661408&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Jarc (prjsf) Assigned to: Nobody/Anonymous (nobody) Summary: "make install" fails with --enable-shared Initial Comment: I configured python 2.3a1 with --enable-shared. When I run "make install", some installation steps try to run the new python executable, but it complains that libpython2.3.so cannot be found. libpython2.3.so.1.0 has been installed by this point, but the symlink has not. Augmenting LD_LIBRARY_PATH during "make install" to include the build directory, which contains libpython2.3.so, allows "make install" to complete successfully. After "make install", I can run ldconfig (or equivalent) myself to create the symlink. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661408&group_id=5470 From noreply@sourceforge.net Fri Jan 3 01:25:26 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 02 Jan 2003 17:25:26 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-500698 ] Taint a la Perl? Message-ID: Feature Requests item #500698, was opened at 2002-01-07 20:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=500698&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Scott (sketerpot) Assigned to: Nobody/Anonymous (nobody) Summary: Taint a la Perl? Initial Comment: This might just add unnecessary bloat, but since Python is being used in CGI scripts, it can be used to narrow a security hole. One way of breaking security is for a naiive programmer (don't try to deny their existance) to run an arbitrary command from the page viewer. Perl has developed an interesting mechanism for helping with this: taint. The way it works is, when something comes directly from the user, like a key in a form, it is considered to have taint unless specifically untainted. Things like os.exec() would create a warning message if you passed tainted strings to them. As I said, this might just add unnecessary bloat, but for an option that can be left out for most builds of Python I think it would be pretty nice. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-01-02 19:25 Message: Logged In: YES user_id=44345 Took awhile for a response to this feature request. ;-) Perl's heavy integration of regular expressions with its taint facility probably wouldn't work all that well in Python. For one, Python has more ways of searching strings than with regular expressions. Second, regular expressions are not nearly as tightly wound into Python as they are in Perl. I think you'd have to add a taint attribute to strings and just rely on the programmer to properly clear that attribute. I think a first cut at an implementation would go much further toward getting the concept seriously considered for addition to Python. ---------------------------------------------------------------------- Comment By: Neal McBurnett (nealmcb) Date: 2003-01-02 15:20 Message: Logged In: YES user_id=105956 I really like taint mode. I think this would make Python a better choice for CGI scripts. See http://www.perldoc.com/perl5.8.0/pod/perlsec.html and http://gunther.web66.com/FAQS/taintmode.html for more background. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=500698&group_id=5470 From noreply@sourceforge.net Fri Jan 3 09:01:49 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 Jan 2003 01:01:49 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-547481 ] In-place reverse() and sort() for slices Message-ID: Feature Requests item #547481, was opened at 2002-04-23 04:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=547481&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Bernhard Bender (bbender) Assigned to: Nobody/Anonymous (nobody) Summary: In-place reverse() and sort() for slices Initial Comment: In order to apply sort() or reverse() to only part of a sequence (a slice), the following code seems to be necessary: # a is a sequence tmp = s[m:n] tmp.sort() # or tmp.reverse() s[m:n] = tmp It would be much nicer to apply sort() or reverse() to the slice directly: a[m:n].sort() However, this does not work, since the slice returns a new sequence object, on which sort() or reverse() will work, instead of working on the slice in-place. After sort() is done, the modified object will be discarded, since it cannot be assigned to anything as sort() and reverse() do not have a return value. Therefore, the line above is accepted by the interpreter even though it is completely useless. My proposal is to change the semantics of applying sort() and reverse() to slices such as to work in-place on the slice, in stead of working on the new object created by the slicing operation. This would be similar to slice assignment, which also does not create a new object. Would this change require a PEP? Bernhard Bender ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-03 04:01 Message: Logged In: YES user_id=80475 I agree with Martin that the idea is unworkable as proposed. As of Py2.3a, the need has been met (to some degree) through extended slice notation. Also, it has been seven months since last hearing from the OP. Marking as closed. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-09 09:23 Message: Logged In: YES user_id=21627 I'm still not clear what it is that you are requesting. It appears that you want x[m:n].reverse() to be the reversed slice. One way to achieve this is to have .reverse return the object it operates on, instead of None (which it currently returns). This has been rejected before. The other option is that x[m:n] does not return a new list, but some kind of "slice object", which has a reverse operation that has a different meaning from the reverse operation of lists. This is a backwards-incompatible change, since people rely on x[m:n] returning a list if x is a list. I can see no third approach to make this work. Can you? ---------------------------------------------------------------------- Comment By: Bernhard Bender (bbender) Date: 2002-04-25 07:45 Message: Logged In: YES user_id=523837 I do not see this as a major change to the language: 1- slicing a[n:m] already has two different semantics (creating a new object or referring to a slice of the original sequence) depending on wether it is on the right or left side of an assigment operator 2- statements like a[n:m].reverse() currently have no net effect on any program, so they should not be used in any well tested software. 3- I am not proposing to change the semantics of any current use of slicing, especially a slice will still return a new object. The only change is for the application of in-place operations like sort() and reverse() that currently make no sense with slices. Therefore, such change to the semantics of slicing should be possible without doing harm to any existing program, especially if an "import from __future__" is use to activate the new semantics. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2002-04-23 17:17 Message: Logged In: YES user_id=35752 This would take some deep magic to make work and would be a fundamental change to the language. lst[m:m] is an expression that returns a new object. The chances of this change being accepted is about zero. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=547481&group_id=5470 From noreply@sourceforge.net Fri Jan 3 09:16:31 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 Jan 2003 01:16:31 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-622230 ] def object.new_method(self): Message-ID: Feature Requests item #622230, was opened at 2002-10-12 01:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=622230&group_id=5470 Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Parisien (mathematician) Assigned to: Nobody/Anonymous (nobody) Summary: def object.new_method(self): Initial Comment: I want to be able to create functions inside objects instead of having to do: class x: pass def new_method(self): pass x.new_method = new_method del new_method I want to do: class x: pass def x.new_method(self): pass Why isn't this possible? Wouldn't it be cool? ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-03 04:16 Message: Logged In: YES user_id=80475 This is an interesting idea but (from your example) the only way to use it is when the names are already known statically when writing the code. And, if you already know x and newmethod, why not write: class x: def new_method(self): pass The only use case I can see is if the source for x is unaccessible in another module: from M import x def x.newmethod(self): pass All in all, this would be a tough sell (and likely require a PEP) because the effort to implement it, document it, explain it and support it isn't warrented by the two line savings over what can already be done. Further, the current one-way-to-do-it is robust, clear, and can work dynamically as well as at coding time. I'm -1 on this one but do think it reflects original creative thought. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-04 05:29 Message: Logged In: YES user_id=21627 It's simply not possible because nobody has though of that. I personally would not consider it cool: Python expresses nesting of definition with indentation, not with full-stop separators. Unless you implement it yourself, I'd expect that it is unlilkely that anybody will act on this request in the coming years. ---------------------------------------------------------------------- Comment By: Dan Parisien (mathematician) Date: 2002-10-12 01:08 Message: Logged In: YES user_id=118203 Repost with attempted better formatting: I don't want to do: class x:     pass def new_method(self):     pass x.new_method = new_method del new_method I want to do: class x:     pass def x.new_method(self):     pass ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=622230&group_id=5470 From noreply@sourceforge.net Fri Jan 3 10:01:53 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 Jan 2003 02:01:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-661521 ] plat-mac not on sys.path Message-ID: Bugs item #661521, was opened at 2003-01-03 11:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661521&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Just van Rossum (jvr) Assigned to: Jack Jansen (jackjansen) Summary: plat-mac not on sys.path Initial Comment: The new plat-mac subdirectory of Lib should be on sys.path by default. It's currently only added for framework builds by means of a *.pth file, but it should be available on any OSX build, even with python -S, so some Makefile/Setup editing is neccesary. I tried to do it myself but I can't; Setup/Makefile editing is a field I definitely do not master. Jack offered to do it, but if anyone else can help us out here before he gets round to it (he's currently caught up with MacPython 2.3a1 for MacOS9), that would be even better. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661521&group_id=5470 From noreply@sourceforge.net Fri Jan 3 10:26:27 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 Jan 2003 02:26:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-661168 ] debug prints lingering in compiler/transformer.py Message-ID: Bugs item #661168, was opened at 2003-01-02 16:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661168&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Michael Hudson (mwh) Summary: debug prints lingering in compiler/transformer.py Initial Comment: In the stdlib, compiler/transformer.py (rev 1.35, Python 2.3a1) has unnecessary print statements at lines 653 & 660. I'll be happy to comment them out; just reassign the bug to me. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-01-03 10:26 Message: Logged In: YES user_id=6656 Actually, they weren't! I've hacked them out anyway: Lib/compiler/transformer.py revision 1.36 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-02 18:03 Message: Logged In: YES user_id=33168 I'm guessing these were actually from Michael's patch. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2003-01-02 16:42 Message: Logged In: YES user_id=7733 sorry, my browser is screwing up on "assigned to" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661168&group_id=5470 From noreply@sourceforge.net Fri Jan 3 10:31:38 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 Jan 2003 02:31:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-661136 ] zipimport does not accept nested pure python imports Message-ID: Bugs item #661136, was opened at 2003-01-02 16:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661136&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sandy Norton (sandynorton) >Assigned to: Just van Rossum (jvr) Summary: zipimport does not accept nested pure python imports Initial Comment: I presume this is a big with zipimport. It occurs when you have a nested pure python package structure. It doesn't occcur if there are byte-compiled versions in the zipped directory. as pure python zipped directory =============================== Assume mylib.zip is inserted on the sys.path with the following directory structure: mylib.zip mod.py p1 __init__.py mod.py p2 __init__.py mod.py C:\TMP>ls mylib.zip C:\TMP>p Python 2.3a1 (#38, Jan 1 2003, 16:44:16) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys; sys.path.insert(0, 'c:\tmp\mylib.zip') >>> import mod mod >>> from p1 import mod Traceback (most recent call last): File "", line 1, in ? SystemError: C:\Engines\python\dist\src\Objects\stringobject.c:3295: bad argumen t to internal function >>> from p1.p2 import mod Traceback (most recent call last): File "", line 1, in ? SystemError: C:\Engines\python\dist\src\Objects\stringobject.c:3295: bad argumen t to internal function >>> as plain directory =================== C:\TMP>p Python 2.3a1 (#38, Jan 1 2003, 16:44:16) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.path.insert(0, 'c:\tmp\mylib') >>> import mod mod >>> from p1 import mod mod1 >>> from p1.p2 import mod mod2 >>> as byte-compiled zipped directory ================================= mylib.zip mod.py mod.pyc p1 __init__.py __init__.pyc mod.py mod.pyc p2 __init__.py __init__.pyc mod.py mod.pyc C:\TMP>p Python 2.3a1 (#38, Jan 1 2003, 16:44:16) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys; sys.path.insert(0, 'c:\tmp\mylib.zip') >>> import mod mod >>> import p1.mod mod1 >>> import p1.p2.mod mod2 >>> p1.p2.mod >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661136&group_id=5470 From noreply@sourceforge.net Fri Jan 3 10:56:22 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 Jan 2003 02:56:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-661357 ] tkFileDialog.SaveAs Message-ID: Bugs item #661357, was opened at 2003-01-02 23:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661357&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Martin v. Löwis (loewis) Summary: tkFileDialog.SaveAs Initial Comment: The SaveAs dialog gets a traceback due to the new object-style Tk interface. Run this test program: from Tkinter import * import tkFileDialog def doit(): savedialog = tkFileDialog.SaveAs(master=root) print savedialog.show(initialdir="/tmp", initialfile="foo.py") root = Tk() button = Button(root, text="Save...", command=doit) button.pack() mainloop() I get this traceback: Traceback (most recent call last): File "/usr/local/lib/python2.3/lib-tk/Tkinter.py", line 1306, in __call__ return apply(self.func, args) File "tkf.py", line 5, in doit print savedialog.show(initialdir="/tmp", initialfile="foo.py") File "/usr/local/lib/python2.3/lib-tk/tkCommonDialog.py", line 54, in show s = self._fixresult(w, s) File "/usr/local/lib/python2.3/lib-tk/tkFileDialog.py", line 58, in _fixresult path, file = os.path.split(result) File "/usr/local/lib/python2.3/posixpath.py", line 65, in split i = p.rfind('/') + 1 AttributeError: '_tkinter.Tcl_Obj' object has no attribute 'rfind' ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 11:56 Message: Logged In: YES user_id=21627 I can't reproduce this. What system and Tcl version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661357&group_id=5470 From noreply@sourceforge.net Fri Jan 3 11:03:01 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 Jan 2003 03:03:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-661408 ] "make install" fails with --enable-shared Message-ID: Bugs item #661408, was opened at 2003-01-03 02:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661408&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Jarc (prjsf) Assigned to: Nobody/Anonymous (nobody) >Summary: "make install" fails with --enable-shared Initial Comment: I configured python 2.3a1 with --enable-shared. When I run "make install", some installation steps try to run the new python executable, but it complains that libpython2.3.so cannot be found. libpython2.3.so.1.0 has been installed by this point, but the symlink has not. Augmenting LD_LIBRARY_PATH during "make install" to include the build directory, which contains libpython2.3.so, allows "make install" to complete successfully. After "make install", I can run ldconfig (or equivalent) myself to create the symlink. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 12:03 Message: Logged In: YES user_id=21627 What operating system is this? What is the precise build step that fails? What is the precise error message? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661408&group_id=5470 From noreply@sourceforge.net Fri Jan 3 11:05:55 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 Jan 2003 03:05:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-660165 ] PyFile_GetLine() doesn't grok unicode Message-ID: Bugs item #660165, was opened at 2002-12-30 22:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660165&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Martin v. Löwis (loewis) Summary: PyFile_GetLine() doesn't grok unicode Initial Comment: PyFile_GetLine() complains when object.readline() returns a Unicode string. This is only used by raw_input() (and possible by 3rd party extensions). Could we change it to either allow Unicode strings, or at least attempt to convert the result to str()? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 12:05 Message: Logged In: YES user_id=21627 What do you think about this patch? I could not find a way to avoid duplication of the string-stripping code; apart from that, it works fine in my test cases. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-31 02:02 Message: Logged In: YES user_id=6380 Wanna cook up a patch? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-31 00:05 Message: Logged In: YES user_id=21627 I'm in favour of allowing raw_input to return Unicode objects. This would follow the principle that you shall convert to a byte string at the latest possible point in processing (i.e. immediately before the byte-oriented storage). It may surprise applications, but it (in itself) isn't an incompatible change (as you now get an exception). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660165&group_id=5470 From noreply@sourceforge.net Fri Jan 3 11:22:48 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 Jan 2003 03:22:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-661136 ] zipimport does not accept nested pure python imports Message-ID: Bugs item #661136, was opened at 2003-01-02 16:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661136&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Sandy Norton (sandynorton) Assigned to: Just van Rossum (jvr) Summary: zipimport does not accept nested pure python imports Initial Comment: I presume this is a big with zipimport. It occurs when you have a nested pure python package structure. It doesn't occcur if there are byte-compiled versions in the zipped directory. as pure python zipped directory =============================== Assume mylib.zip is inserted on the sys.path with the following directory structure: mylib.zip mod.py p1 __init__.py mod.py p2 __init__.py mod.py C:\TMP>ls mylib.zip C:\TMP>p Python 2.3a1 (#38, Jan 1 2003, 16:44:16) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys; sys.path.insert(0, 'c:\tmp\mylib.zip') >>> import mod mod >>> from p1 import mod Traceback (most recent call last): File "", line 1, in ? SystemError: C:\Engines\python\dist\src\Objects\stringobject.c:3295: bad argumen t to internal function >>> from p1.p2 import mod Traceback (most recent call last): File "", line 1, in ? SystemError: C:\Engines\python\dist\src\Objects\stringobject.c:3295: bad argumen t to internal function >>> as plain directory =================== C:\TMP>p Python 2.3a1 (#38, Jan 1 2003, 16:44:16) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.path.insert(0, 'c:\tmp\mylib') >>> import mod mod >>> from p1 import mod mod1 >>> from p1.p2 import mod mod2 >>> as byte-compiled zipped directory ================================= mylib.zip mod.py mod.pyc p1 __init__.py __init__.pyc mod.py mod.pyc p2 __init__.py __init__.pyc mod.py mod.pyc C:\TMP>p Python 2.3a1 (#38, Jan 1 2003, 16:44:16) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys; sys.path.insert(0, 'c:\tmp\mylib.zip') >>> import mod mod >>> import p1.mod mod1 >>> import p1.p2.mod mod2 >>> p1.p2.mod >>> ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-01-03 12:22 Message: Logged In: YES user_id=92689 Ouch, nasty. It's not quite like you describe: the problem occurs for any *empty* source file (that doesn't have a matching .pyc in the archive). So I take it your mod.py wasn't empty but p1/__init__.py and p1/p2/__init__.py were. Fixed in rev. 1.8 of Modules/zipimport.c Thanks for reporting this! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661136&group_id=5470 From noreply@sourceforge.net Fri Jan 3 11:28:22 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 Jan 2003 03:28:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-661357 ] tkFileDialog.SaveAs Message-ID: Bugs item #661357, was opened at 2003-01-02 23:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661357&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Martin v. Löwis (loewis) Summary: tkFileDialog.SaveAs Initial Comment: The SaveAs dialog gets a traceback due to the new object-style Tk interface. Run this test program: from Tkinter import * import tkFileDialog def doit(): savedialog = tkFileDialog.SaveAs(master=root) print savedialog.show(initialdir="/tmp", initialfile="foo.py") root = Tk() button = Button(root, text="Save...", command=doit) button.pack() mainloop() I get this traceback: Traceback (most recent call last): File "/usr/local/lib/python2.3/lib-tk/Tkinter.py", line 1306, in __call__ return apply(self.func, args) File "tkf.py", line 5, in doit print savedialog.show(initialdir="/tmp", initialfile="foo.py") File "/usr/local/lib/python2.3/lib-tk/tkCommonDialog.py", line 54, in show s = self._fixresult(w, s) File "/usr/local/lib/python2.3/lib-tk/tkFileDialog.py", line 58, in _fixresult path, file = os.path.split(result) File "/usr/local/lib/python2.3/posixpath.py", line 65, in split i = p.rfind('/') + 1 AttributeError: '_tkinter.Tcl_Obj' object has no attribute 'rfind' ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 12:28 Message: Logged In: YES user_id=21627 Also, can you please try x=root.tk.call(("tk_getSaveFile","-initialdir","/tmp","-initialfile","foo.py")) print repr(x),str(x),x.typename I always get plain strings as a result of that call. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 11:56 Message: Logged In: YES user_id=21627 I can't reproduce this. What system and Tcl version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661357&group_id=5470 From noreply@sourceforge.net Fri Jan 3 11:37:59 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 Jan 2003 03:37:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-660707 ] Problems with reference counting and exec Message-ID: Bugs item #660707, was opened at 2003-01-01 16:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660707&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 >Status: Closed Resolution: None Priority: 5 Submitted By: Daniel (kamek) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with reference counting and exec Initial Comment: When using exec to parse an arbitrary string, Python seems to have some problems on keeping the reference count. The sample below shows a problem when the specified string is not a valid Python expression, and would be better for testing in the Python interpreter (~ preceding lines represents indentation): #BEGIN clas MyClass: ~def __del__(self): ~~print 'Deleting object' def f(): ~# create a new instance ~obj = MyClass() ~# now, raise an exception ~exec "any invalid line" f() #END We get an exception, but in no moment we see the destructor being called. The most curious, then, is that if we raise another exception from the interpreter (just type anything), we get the destructor right before the exception information. There's also a reference count problem that happens even when the line for exec is valid, but I couldn't manage to reproduce it outside of my project yet. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-01-03 12:37 Message: Logged In: YES user_id=92689 This is expected behavior: an exception causes a traceback, and the traceback object will hold a reference to the frame, which holds a reference to the local variables. So as long as the traceback object lives your __del__ will not be called. It has nothing to do with exec per se. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660707&group_id=5470 From noreply@sourceforge.net Fri Jan 3 11:44:07 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 Jan 2003 03:44:07 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-661057 ] xrange concatenation Message-ID: Feature Requests item #661057, was opened at 2003-01-02 12:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=661057&group_id=5470 Category: Python Library Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: xrange concatenation Initial Comment: xrange is advertised as working like range, but doesn't support concatenation: range(5) + range(6, 9) => [0,1,2,3,4,6,7,8,9] [2] + range(3, 10, 2) => (2, 3, 5, 7, 9] Doing these things with xrange throws an error. It would be nice if xrange supported + for concatenation, so the above examples would work. This should be easy to implement now that there are iterator objects. Paul ---------------------------------------------------------------------- >Comment By: paul rubin (phr) Date: 2003-01-03 11:44 Message: Logged In: YES user_id=72053 The normal behavior of behavior of xrange would not change. The xrange object would simply support an __add__ method just like lists do. When you add xranges together, you'd get a new kind of object which would be an iterator with xranges inside. When you use an xrange in the normal way, it wouldn't slow down at all. It just seems like a needless and inconvenient inconsistency that xrange can't be used like range in this situation. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 15:31 Message: Logged In: YES user_id=6380 I guess the docs need to be updated. xrange() is supposed to be as light and fast as possible for a single use case: "for i in xrange(...): ...". Everything else is fluff, and in fact several features have been deprecated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=661057&group_id=5470 From noreply@sourceforge.net Fri Jan 3 11:58:10 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 Jan 2003 03:58:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-661184 ] inspect.getsource bug Message-ID: Bugs item #661184, was opened at 2003-01-02 18:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661184&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michele Simionato (michele_s) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getsource bug Initial Comment: I have found a bug in inspect.getsource. I am using Python 2.2.2 on Red-Hat 7.3. Here is the problem. --begin bug.py import inspect def f(x): return x print inspect.getsource(f) --end bug.py % python bug.py Traceback (most recent call last): File "bug.py", line 3, in ? print inspect.getsource(f) File "/usr/local/lib/python2.2/inspect.py", line 520, in getsource return string.join(lines, '') File "/usr/local/lib/python2.2/string.py", line 131, in join return sep.join(words) TypeError: sequence expected, NoneType found Notice that --begin noproblem.py import inspect def f(x): return x print inspect.getsource(f) --end noproblem.py works: % python noproblem.py def f(x): return x I discovered this bug in trying to retrieve the source code for lambda expressions: --begin lambda.py import inspect f=lambda x: x print inspect.getsource(f) --begin lambda.py (same error message). -- Michele Simionato - Dept. of Physics and Astronomy 210 Allen Hall Pittsburgh PA 15260 U.S.A. Phone: 001-412-624-9041 Fax: 001-412-624-9163 Home-page: http://www.phyast.pitt.edu/~micheles/ ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-01-03 12:58 Message: Logged In: YES user_id=92689 It seems inspect.py indeed has problems finding one-line functions. I've attached a patch that addresses this, but to also make it work for lambda's I had to remove a few lines that I don't quite understand the purpose of, as it seems to work well without it. I've commented them out. Their purpose seems to be to adjust co.co_firstlineno in case it's off, it's just that I don't know how/when it can be off. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661184&group_id=5470 From noreply@sourceforge.net Fri Jan 3 12:01:15 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 Jan 2003 04:01:15 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-661203 ] sigprocmask: None argument Message-ID: Feature Requests item #661203, was opened at 2003-01-02 17:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=661203&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Pomraning (pilcrow) >Assigned to: Michael Hudson (mwh) Summary: sigprocmask: None argument Initial Comment: signal.sigprocmask ought allow a None argument instead of a signal sequence: a) cur_mask = signal.sigprocmask(any_but_SETMASK, []) # sigprocmask(how, &empty_set, &cur_mask) b) cur_mask = signal.sigprocmask(dummy, None) # sigprocmask(dummy, NULL, &cur_mask) "a" is slightly more work for the kernel, and permits accidental SETMASKing. "b" avoids both, and is comfortably analogous to the familiar, ugly C interface (as opposed to, say, cur_mask = signal.sigprocmask()). ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-01-03 12:01 Message: Logged In: YES user_id=6656 Sounds fair enough. Should warn you that the sigmask stuff is currently not being compiled owing to unpleasantly exciting x-platform behaviour. I ought to do something about that, too. What platform are you on? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=661203&group_id=5470 From noreply@sourceforge.net Fri Jan 3 12:23:45 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 Jan 2003 04:23:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-653301 ] py_compile does not return error code Message-ID: Bugs item #653301, was opened at 2002-12-13 16:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653301&group_id=5470 Category: Build Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Mark Ferris (mferris1) Assigned to: Nobody/Anonymous (nobody) Summary: py_compile does not return error code Initial Comment: Since py_compile.compile() does not return an error code, the compile_all module does not return an error code and my ant build process continues merrily along even though it should failOnError. This appears to be related to an incomplete fix for bug 412436. The download attached to that defect included changes to py_compile.py and compileall.py. It looks like the py_compile.py changes were not implemented. A simple fix that has been working for me is to change the py_compile.py file as follows. This diff was done against version 1.18 of py_compile.py: 69c69 < return 0 --- > return 83d82 < return 1 ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-01-03 13:23 Message: Logged In: YES user_id=92689 It indeed seems the fix for bug #412436 was not checked in completely. I'll add a note there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653301&group_id=5470 From noreply@sourceforge.net Fri Jan 3 12:29:17 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 Jan 2003 04:29:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-412436 ] compileall doesn't notice syntax errors Message-ID: Bugs item #412436, was opened at 2001-03-30 12:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=412436&group_id=5470 Category: Python Library Group: None >Status: Open Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeremy Hylton (jhylton) Summary: compileall doesn't notice syntax errors Initial Comment: compileall.py returns an exit code to indicate the success or failure of compilation. This feature was added in compileall.py revision 1.7 in response to distutils message http://mail.python.org/pipermail/distutils-sig/1999-March/000201.html This is not as useful as it looks because a prior change to py_compile.py (revision 1.13) catches syntax errors, hiding them completely from compileall.py, so compileall.py can't report the failure to its caller. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-01-03 13:29 Message: Logged In: YES user_id=92689 Reopening this bug as it's entirely unclear why the py_compile.py change wasn't checked in. This has resulted in a new bug, #653301. I've attached a patch that's updated for current CVS (rev. 1.23 of py_compile.py). Since py_compile.py is crucial to the install process I'd rather have someone else make the decision to check this in or not. ---------------------------------------------------------------------- Comment By: Peter Maxwell (pm67nz) Date: 2001-09-10 05:31 Message: Logged In: YES user_id=320286 I don't see how this can be fixed in compileall.py since the problem is with py_compile.py. py_compile.compile (up to and including the latest version I see in CVS, revision 1.18) only ever returns None, so the code in compileall.py revision 1.19 that says: ok = py_compile.compile(fullname, None, dfile) and if ok == 0: can't possibly work. Caveat: this comment based on reading code, not running it. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-04-18 03:23 Message: Logged In: YES user_id=31392 Fixed in rev 1.9 of compileall.py. Note that this fix causes a bunch of changes to the test suite, so that files containing syntaxerrors are not compiled by compileall. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-04-13 23:16 Message: Logged In: YES user_id=31392 Will fix following the 2.1 release ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-04-13 16:31 Message: Logged In: YES user_id=31392 I think this is easy enough to fix, but I don't know what unintended side-effects the fix will have. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=412436&group_id=5470 From noreply@sourceforge.net Fri Jan 3 14:31:39 2003 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Fri, 03 Jan 2003 06:31:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-661630 ] mimetypes.read_mime_types no longer returns a dict Message-ID: Bugs item #661630, was opened at 2003-01-04 01:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661630&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Bennetts (spiv) Assigned to: Nobody/Anonymous (nobody) Summary: mimetypes.read_mime_types no longer returns a dict Initial Comment: In 2.3a1, the API of the mimetypes module seems to have changed in a backwards-incompatible way: Python 2.2.2 (#1, Dec 18 2002, 10:36:37) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import mimetypes >>> type(mimetypes.read_mime_types('/etc/mime.types')) Python 2.3a1 (#2, Jan 1 2003, 18:44:29) [GCC 3.2.2 20021212 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import mimetypes >>> type(mimetypes.read_mime_types('/etc/mime.types')) >>> type(mimetypes.read_mime_types('/etc/mime.types')[0]) That is, for some reason the result is now inside a tuple. Obviously this breaks existing code. The documentation for read_mime_types still states "The type map is returned as a dictionary...", so I presume this is a bug, rather than an intentional change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661630&group_id=5470 From noreply@sourceforge.net Fri Jan 3 15:16:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 07:16:30 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-661057 ] xrange concatenation Message-ID: Feature Requests item #661057, was opened at 2003-01-02 07:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=661057&group_id=5470 Category: Python Library Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: xrange concatenation Initial Comment: xrange is advertised as working like range, but doesn't support concatenation: range(5) + range(6, 9) => [0,1,2,3,4,6,7,8,9] [2] + range(3, 10, 2) => (2, 3, 5, 7, 9] Doing these things with xrange throws an error. It would be nice if xrange supported + for concatenation, so the above examples would work. This should be easy to implement now that there are iterator objects. Paul ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-03 10:16 Message: Logged In: YES user_id=6380 You're entitled to that opinion. ---------------------------------------------------------------------- Comment By: paul rubin (phr) Date: 2003-01-03 06:44 Message: Logged In: YES user_id=72053 The normal behavior of behavior of xrange would not change. The xrange object would simply support an __add__ method just like lists do. When you add xranges together, you'd get a new kind of object which would be an iterator with xranges inside. When you use an xrange in the normal way, it wouldn't slow down at all. It just seems like a needless and inconvenient inconsistency that xrange can't be used like range in this situation. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 10:31 Message: Logged In: YES user_id=6380 I guess the docs need to be updated. xrange() is supposed to be as light and fast as possible for a single use case: "for i in xrange(...): ...". Everything else is fluff, and in fact several features have been deprecated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=661057&group_id=5470 From noreply@sourceforge.net Fri Jan 3 15:24:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 07:24:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-661357 ] tkFileDialog.SaveAs Message-ID: Bugs item #661357, was opened at 2003-01-02 17:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661357&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Martin v. Löwis (loewis) Summary: tkFileDialog.SaveAs Initial Comment: The SaveAs dialog gets a traceback due to the new object-style Tk interface. Run this test program: from Tkinter import * import tkFileDialog def doit(): savedialog = tkFileDialog.SaveAs(master=root) print savedialog.show(initialdir="/tmp", initialfile="foo.py") root = Tk() button = Button(root, text="Save...", command=doit) button.pack() mainloop() I get this traceback: Traceback (most recent call last): File "/usr/local/lib/python2.3/lib-tk/Tkinter.py", line 1306, in __call__ return apply(self.func, args) File "tkf.py", line 5, in doit print savedialog.show(initialdir="/tmp", initialfile="foo.py") File "/usr/local/lib/python2.3/lib-tk/tkCommonDialog.py", line 54, in show s = self._fixresult(w, s) File "/usr/local/lib/python2.3/lib-tk/tkFileDialog.py", line 58, in _fixresult path, file = os.path.split(result) File "/usr/local/lib/python2.3/posixpath.py", line 65, in split i = p.rfind('/') + 1 AttributeError: '_tkinter.Tcl_Obj' object has no attribute 'rfind' ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-03 10:24 Message: Logged In: YES user_id=6380 Python 2.3a1 (a tad post-release) Tcl/Tk 8.4 Mandrake Linux 8.1 I believe Linux kernel 2.2.17-21mdk The output from that snippet is /tmp/foo.py path ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 06:28 Message: Logged In: YES user_id=21627 Also, can you please try x=root.tk.call(("tk_getSaveFile","-initialdir","/tmp","-initialfile","foo.py")) print repr(x),str(x),x.typename I always get plain strings as a result of that call. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 05:56 Message: Logged In: YES user_id=21627 I can't reproduce this. What system and Tcl version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661357&group_id=5470 From noreply@sourceforge.net Fri Jan 3 15:33:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 07:33:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-660165 ] PyFile_GetLine() doesn't grok unicode Message-ID: Bugs item #660165, was opened at 2002-12-30 16:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660165&group_id=5470 Category: None Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Martin v. Löwis (loewis) Summary: PyFile_GetLine() doesn't grok unicode Initial Comment: PyFile_GetLine() complains when object.readline() returns a Unicode string. This is only used by raw_input() (and possible by 3rd party extensions). Could we change it to either allow Unicode strings, or at least attempt to convert the result to str()? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-03 10:33 Message: Logged In: YES user_id=6380 Sounds like a good thing to try during alpha testing -- check it in! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 06:05 Message: Logged In: YES user_id=21627 What do you think about this patch? I could not find a way to avoid duplication of the string-stripping code; apart from that, it works fine in my test cases. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-30 20:02 Message: Logged In: YES user_id=6380 Wanna cook up a patch? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-30 18:05 Message: Logged In: YES user_id=21627 I'm in favour of allowing raw_input to return Unicode objects. This would follow the principle that you shall convert to a byte string at the latest possible point in processing (i.e. immediately before the byte-oriented storage). It may surprise applications, but it (in itself) isn't an incompatible change (as you now get an exception). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660165&group_id=5470 From noreply@sourceforge.net Fri Jan 3 16:10:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 08:10:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-661354 ] test_strptime fails on the Mac Message-ID: Bugs item #661354, was opened at 2003-01-02 23:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Guido van Rossum (gvanrossum) Summary: test_strptime fails on the Mac Initial Comment: test_strptime fails for MacPython-OS9. It appears to be an error in the test itself, but it could be this error is triggered only on the Mac (because it doesn't have a builtin strptime() function but uses the pure Python strptime implementation). Here is the first stacktrace from the test (a lot of very similar ones follow): Traceback (most recent call last): File "Moes:SWdev:Jack:MacPython:Lib:test:test_strptime.py", line 183, in test_compile compiled = self.time_re.compile("%%%s"% directive) File "Moes:SWdev:Jack:MacPython:Lib:_strptime.py", line 394, in compile return re_compile(self.pattern(format), IGNORECASE) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 179, in compile return _compile(pattern, flags) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 229, in _compile raise error, v # invalid expression error: redefinition of group name 'Z' as group 2; was group 1 ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-01-03 17:10 Message: Logged In: YES user_id=45365 No two Z groups, but I do get something different than you, with no timezone names: >>> import _strptime >>> _strptime.TimeRE().compile("%Z").pattern '(?#)(?P||)' I've attached the whole output of test_strptime. Enjoy! (hihi:-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-03 01:39 Message: Logged In: YES user_id=357491 And for Jack's own personal knowledge, test_strptime is only run against _strptime.py. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-03 01:38 Message: Logged In: YES user_id=357491 OK, with Tim's info I am starting to wonder if this isn't some how an OS 9-specific thing. To make sure, Jack, can you run this code?:: >>> import _strptime >>> _strptime.TimeRE().compile("%Z").pattern The ``TimeRE`` class is what handles the creation of the final regex to use for parsing the input string. the ``.compile()`` method takes the directive format string and outputs the regex pattern object. The above code should spit out a string similar to ``(?#)(?PPST|PDT|)`` (and yes, that emptiness after the last pipe is expected; have to handle chance that no timezone is actually in the input string since it *could* be there). If this has two Z groups, then we have found our problem. If not, then I am goiing to need basically all the tracebacks to figure this one out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-03 01:01 Message: Logged In: YES user_id=31435 FYI, it also passes on Windows (98SE and 2K). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-03 00:54 Message: Logged In: YES user_id=357491 As for the bug, obviously a regex is being created where the regex group Z is being specified twice. I will take a look, but I just ran the tests and I am having no problems on OS X 10.2.3. I have some ideas on where this trouble could be produced, though, so I will see if I can find a problem or come up with some code Jack can run to try to help figure out the problem. Are the "very similar ones" that follow this stack trace all from the same line in test_strptime, or all from the same line in _strptime? In other words, are they all the same error being caused by the same test or the same chunk of code in _strptime? Or am I so unlucky that it is just the same redefinition error but with everything else different every time? Oh, and one quick syntax thing; line 394 in test_strptime.py has a string where the ``%`` operator has no space between it and the string being worked on. I know what a stickler you are, Guido, so I thought you should know . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 23:44 Message: Logged In: YES user_id=6380 BTW, there's an #undef HAVE_STRPTIME in timemodule.c, so that *everybody* will *always* be using the Python implementation. The test passes for me on Linux, FWIW. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 23:40 Message: Logged In: YES user_id=6380 I've forwarded this to Brett Cannon -- he's the author, maybe he understands what's going on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 From noreply@sourceforge.net Fri Jan 3 16:41:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 08:41:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-596422 ] build dumps core (binutils 2.13/solaris) Message-ID: Bugs item #596422, was opened at 2002-08-17 09:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596422&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Martin v. Löwis (loewis) Summary: build dumps core (binutils 2.13/solaris) Initial Comment: Installing Python 2.2.1 on Solaris causes a core dump during build (just after trying to load struct.so) if I am using binutils 2.13. This happens with either gcc 3.1.1 or gcc 3.2, on either solaris 7 or solaris 8. I suspect it happens on other combinations as well. It works just fine with binutils 2.12.1, so the problem appears to be in binutils, not Python per se. The attached file, contributed by Zack Weinberg (zack@codesourcery.com), tests for the presence of the problem; if it executes to completion, the problem isn't there. Perhaps it might make sense to put a similar test into the Python installation procedure? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-03 11:41 Message: Logged In: YES user_id=33168 Andrew reported (on python-dev) the problem is fixed. Martin, is there anything you want to do for this bug report? You mentioned writing something in the README. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 12:40 Message: Logged In: YES user_id=21627 I still have the plan of adding a comment to README pointing out what binutils releases need to be avoided, but that can be done when we know what binutils release to use. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-11-13 10:59 Message: Logged In: YES user_id=418174 Here is a patch (to binutils) that makes it possible to build Python with binutils 2.13.1. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-11-13 10:54 Message: Logged In: YES user_id=418174 At this point, I do not believe that any changes to Python are necessary. The main point is for people installing Python on Solaris (and perhaps elsewhere) to realize that they must not use binutils 2.13 or 2.13.1. The attached patch will make binutils 2.13.1 work. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 10:40 Message: Logged In: YES user_id=21627 I will wait before making changes until the entire issue is settled (or until the 2.3 release is getting near). Thanks for the update. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-11-13 10:00 Message: Logged In: YES user_id=418174 Binutils 2.13.1 is still not right. I am told that 2.13.2 will be out soon and will fix the problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-20 19:14 Message: Logged In: YES user_id=21627 combreloc is not a compiler option, but a linker option. For GNU binutils, it was first implemented in 2.12. The system linker supports this option since Solaris 7. Older binutils versions ignore -z options that they don't recognize, so there is no need for a version check here. The option arranges to combine multiple relocation sections, sorting them by symbol so that multiple relocations for the same symbol follow each other. The dynamic linker can cache the most-recently looked-up symbol from relocation to relocation, so that combreloc reduces the number of symbol lookups. I somehow doubt the validity of this patch, though: the entire approach was pioneered by Sun for Solaris, so if it causes problems with GNU binutils, it is likely a binutils bug. Therefore, I'd postpone this patch until the issue has been fully studied by binutils maintainers, and would advise against using binutils 2.13 on Solaris for the moment. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-20 18:26 Message: Logged In: YES user_id=6380 Looks harmless to me, but I can't test it. Only the configure.in patch is really needed; we generate configure using autoconf (and then check it in for the benefit of others). Assigning to MvL. Martin, can you test this on Solaris with the indicated GCC release? Or should we just jump the gun??? (Hm, what about older GCC releases -- it needs to be tested there too.) I'd still like to understand what "combreloc" does... ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-09-20 13:19 Message: Logged In: YES user_id=418174 Here's the patch to configure.in ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-09-20 13:17 Message: Logged In: YES user_id=418174 I have learned from Nick Clifton at Red Hat that the source of the problem is a change in the default linker options between 2.12 and 2.13. The specific option that causes the trouble is -zcombreloc, which is the default in 2.13, and which apparently produces a dll that doesn't work under Solaris. Don't know whether this is a Solaris bug or not, but a workaround is clearly indicated. Attached are patch files that can be applied to configure and configure.in (in the Python root directory) to work around the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596422&group_id=5470 From noreply@sourceforge.net Fri Jan 3 16:59:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 08:59:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-596422 ] build dumps core (binutils 2.13/solaris) Message-ID: Bugs item #596422, was opened at 2002-08-17 15:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596422&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Martin v. Löwis (loewis) Summary: build dumps core (binutils 2.13/solaris) Initial Comment: Installing Python 2.2.1 on Solaris causes a core dump during build (just after trying to load struct.so) if I am using binutils 2.13. This happens with either gcc 3.1.1 or gcc 3.2, on either solaris 7 or solaris 8. I suspect it happens on other combinations as well. It works just fine with binutils 2.12.1, so the problem appears to be in binutils, not Python per se. The attached file, contributed by Zack Weinberg (zack@codesourcery.com), tests for the presence of the problem; if it executes to completion, the problem isn't there. Perhaps it might make sense to put a similar test into the Python installation procedure? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 17:59 Message: Logged In: YES user_id=21627 Skip just mentioned he would update the README; if that is done, this can be closed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-03 17:41 Message: Logged In: YES user_id=33168 Andrew reported (on python-dev) the problem is fixed. Martin, is there anything you want to do for this bug report? You mentioned writing something in the README. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 18:40 Message: Logged In: YES user_id=21627 I still have the plan of adding a comment to README pointing out what binutils releases need to be avoided, but that can be done when we know what binutils release to use. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-11-13 16:59 Message: Logged In: YES user_id=418174 Here is a patch (to binutils) that makes it possible to build Python with binutils 2.13.1. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-11-13 16:54 Message: Logged In: YES user_id=418174 At this point, I do not believe that any changes to Python are necessary. The main point is for people installing Python on Solaris (and perhaps elsewhere) to realize that they must not use binutils 2.13 or 2.13.1. The attached patch will make binutils 2.13.1 work. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 16:40 Message: Logged In: YES user_id=21627 I will wait before making changes until the entire issue is settled (or until the 2.3 release is getting near). Thanks for the update. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-11-13 16:00 Message: Logged In: YES user_id=418174 Binutils 2.13.1 is still not right. I am told that 2.13.2 will be out soon and will fix the problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-21 01:14 Message: Logged In: YES user_id=21627 combreloc is not a compiler option, but a linker option. For GNU binutils, it was first implemented in 2.12. The system linker supports this option since Solaris 7. Older binutils versions ignore -z options that they don't recognize, so there is no need for a version check here. The option arranges to combine multiple relocation sections, sorting them by symbol so that multiple relocations for the same symbol follow each other. The dynamic linker can cache the most-recently looked-up symbol from relocation to relocation, so that combreloc reduces the number of symbol lookups. I somehow doubt the validity of this patch, though: the entire approach was pioneered by Sun for Solaris, so if it causes problems with GNU binutils, it is likely a binutils bug. Therefore, I'd postpone this patch until the issue has been fully studied by binutils maintainers, and would advise against using binutils 2.13 on Solaris for the moment. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-21 00:26 Message: Logged In: YES user_id=6380 Looks harmless to me, but I can't test it. Only the configure.in patch is really needed; we generate configure using autoconf (and then check it in for the benefit of others). Assigning to MvL. Martin, can you test this on Solaris with the indicated GCC release? Or should we just jump the gun??? (Hm, what about older GCC releases -- it needs to be tested there too.) I'd still like to understand what "combreloc" does... ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-09-20 19:19 Message: Logged In: YES user_id=418174 Here's the patch to configure.in ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-09-20 19:17 Message: Logged In: YES user_id=418174 I have learned from Nick Clifton at Red Hat that the source of the problem is a change in the default linker options between 2.12 and 2.13. The specific option that causes the trouble is -zcombreloc, which is the default in 2.13, and which apparently produces a dll that doesn't work under Solaris. Don't know whether this is a Solaris bug or not, but a workaround is clearly indicated. Attached are patch files that can be applied to configure and configure.in (in the Python root directory) to work around the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596422&group_id=5470 From noreply@sourceforge.net Fri Jan 3 17:26:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 09:26:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-596422 ] build dumps core (binutils 2.13/solaris) Message-ID: Bugs item #596422, was opened at 2002-08-17 09:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596422&group_id=5470 Category: Build Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Martin v. Löwis (loewis) Summary: build dumps core (binutils 2.13/solaris) Initial Comment: Installing Python 2.2.1 on Solaris causes a core dump during build (just after trying to load struct.so) if I am using binutils 2.13. This happens with either gcc 3.1.1 or gcc 3.2, on either solaris 7 or solaris 8. I suspect it happens on other combinations as well. It works just fine with binutils 2.12.1, so the problem appears to be in binutils, not Python per se. The attached file, contributed by Zack Weinberg (zack@codesourcery.com), tests for the presence of the problem; if it executes to completion, the problem isn't there. Perhaps it might make sense to put a similar test into the Python installation procedure? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-03 12:26 Message: Logged In: YES user_id=33168 Skip checked in the change, so I'm closing. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 11:59 Message: Logged In: YES user_id=21627 Skip just mentioned he would update the README; if that is done, this can be closed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-03 11:41 Message: Logged In: YES user_id=33168 Andrew reported (on python-dev) the problem is fixed. Martin, is there anything you want to do for this bug report? You mentioned writing something in the README. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 12:40 Message: Logged In: YES user_id=21627 I still have the plan of adding a comment to README pointing out what binutils releases need to be avoided, but that can be done when we know what binutils release to use. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-11-13 10:59 Message: Logged In: YES user_id=418174 Here is a patch (to binutils) that makes it possible to build Python with binutils 2.13.1. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-11-13 10:54 Message: Logged In: YES user_id=418174 At this point, I do not believe that any changes to Python are necessary. The main point is for people installing Python on Solaris (and perhaps elsewhere) to realize that they must not use binutils 2.13 or 2.13.1. The attached patch will make binutils 2.13.1 work. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-13 10:40 Message: Logged In: YES user_id=21627 I will wait before making changes until the entire issue is settled (or until the 2.3 release is getting near). Thanks for the update. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-11-13 10:00 Message: Logged In: YES user_id=418174 Binutils 2.13.1 is still not right. I am told that 2.13.2 will be out soon and will fix the problem. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-20 19:14 Message: Logged In: YES user_id=21627 combreloc is not a compiler option, but a linker option. For GNU binutils, it was first implemented in 2.12. The system linker supports this option since Solaris 7. Older binutils versions ignore -z options that they don't recognize, so there is no need for a version check here. The option arranges to combine multiple relocation sections, sorting them by symbol so that multiple relocations for the same symbol follow each other. The dynamic linker can cache the most-recently looked-up symbol from relocation to relocation, so that combreloc reduces the number of symbol lookups. I somehow doubt the validity of this patch, though: the entire approach was pioneered by Sun for Solaris, so if it causes problems with GNU binutils, it is likely a binutils bug. Therefore, I'd postpone this patch until the issue has been fully studied by binutils maintainers, and would advise against using binutils 2.13 on Solaris for the moment. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-20 18:26 Message: Logged In: YES user_id=6380 Looks harmless to me, but I can't test it. Only the configure.in patch is really needed; we generate configure using autoconf (and then check it in for the benefit of others). Assigning to MvL. Martin, can you test this on Solaris with the indicated GCC release? Or should we just jump the gun??? (Hm, what about older GCC releases -- it needs to be tested there too.) I'd still like to understand what "combreloc" does... ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-09-20 13:19 Message: Logged In: YES user_id=418174 Here's the patch to configure.in ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-09-20 13:17 Message: Logged In: YES user_id=418174 I have learned from Nick Clifton at Red Hat that the source of the problem is a change in the default linker options between 2.12 and 2.13. The specific option that causes the trouble is -zcombreloc, which is the default in 2.13, and which apparently produces a dll that doesn't work under Solaris. Don't know whether this is a Solaris bug or not, but a workaround is clearly indicated. Attached are patch files that can be applied to configure and configure.in (in the Python root directory) to work around the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=596422&group_id=5470 From noreply@sourceforge.net Fri Jan 3 17:53:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 09:53:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-661408 ] "make install" fails with --enable-shared Message-ID: Bugs item #661408, was opened at 2003-01-03 01:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661408&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Jarc (prjsf) Assigned to: Nobody/Anonymous (nobody) >Summary: "make install" fails with --enable-shared Initial Comment: I configured python 2.3a1 with --enable-shared. When I run "make install", some installation steps try to run the new python executable, but it complains that libpython2.3.so cannot be found. libpython2.3.so.1.0 has been installed by this point, but the symlink has not. Augmenting LD_LIBRARY_PATH during "make install" to include the build directory, which contains libpython2.3.so, allows "make install" to complete successfully. After "make install", I can run ldconfig (or equivalent) myself to create the symlink. ---------------------------------------------------------------------- >Comment By: Paul Jarc (prjsf) Date: 2003-01-03 17:53 Message: Logged In: YES user_id=412110 This is a custom-built GNU/Linux system, using gcc 2.95.3 and glibc 2.2.5. "make install" ends like this: SRCDIR=. \ ./python ./Tools/idle/setup.py install \ --check-tkinter \ --prefix=/package/misc/spf/python-2.3a1-1 \ --install-scripts=/package/misc/spf/python-2.3a1-1/bin \ --install-platlib=/package/misc/spf/python-2.3a1-1/lib/python2.3/lib-dynload ./python: error while loading shared libraries: libpython2.3.so: cannot open shared object file: No such file or directory make: *** [idleinstall] Error 127 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 11:03 Message: Logged In: YES user_id=21627 What operating system is this? What is the precise build step that fails? What is the precise error message? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661408&group_id=5470 From noreply@sourceforge.net Fri Jan 3 18:06:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 10:06:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-659228 ] 'realpath' function missing from os.path Message-ID: Bugs item #659228, was opened at 2002-12-27 20:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659228&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open >Resolution: Fixed Priority: 5 Submitted By: David MacQuigg (macquigg) >Assigned to: Neal Norwitz (nnorwitz) Summary: 'realpath' function missing from os.path Initial Comment: The 'realpath()' function does not appear when you import all functions: from os.path import * Looks like this due to the name 'realpath' being missing from the '__all__' list in .../Python-2.2.2/Lib/posixpath.py All the other functions appear normally. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-03 13:06 Message: Logged In: YES user_id=33168 Checked in as: macpath.py 1.43 ntpath.py 1.54 os2emxpath.py 1.9 posixpath.py 1.57 I have a question about if this should be backported, so I'm leaving this open for now. I think it should be backported. It is an API change, but only to correct the bug. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659228&group_id=5470 From noreply@sourceforge.net Fri Jan 3 18:15:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 10:15:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-661762 ] macpath.py missing ismount splitunc Message-ID: Bugs item #661762, was opened at 2003-01-03 13:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661762&group_id=5470 Category: Macintosh Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Jack Jansen (jackjansen) Summary: macpath.py missing ismount splitunc Initial Comment: Jack, I noticed that macpath is missing an ismount() function and reference in __all__. I'm not sure it can be implemented. ismount() exists in all 3 other *path files: Lib/ntpath.py Lib/os2emxpath.py Lib/posixpath.py. splitunc() is also missing, but it is also missing from posixpath. I'm not sure if it's appropriate or not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661762&group_id=5470 From noreply@sourceforge.net Fri Jan 3 18:18:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 10:18:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-661630 ] mimetypes.read_mime_types no longer returns a dict Message-ID: Bugs item #661630, was opened at 2003-01-03 09:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661630&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Bennetts (spiv) >Assigned to: Walter Dörwald (doerwalter) Summary: mimetypes.read_mime_types no longer returns a dict Initial Comment: In 2.3a1, the API of the mimetypes module seems to have changed in a backwards-incompatible way: Python 2.2.2 (#1, Dec 18 2002, 10:36:37) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import mimetypes >>> type(mimetypes.read_mime_types('/etc/mime.types')) Python 2.3a1 (#2, Jan 1 2003, 18:44:29) [GCC 3.2.2 20021212 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import mimetypes >>> type(mimetypes.read_mime_types('/etc/mime.types')) >>> type(mimetypes.read_mime_types('/etc/mime.types')[0]) That is, for some reason the result is now inside a tuple. Obviously this breaks existing code. The documentation for read_mime_types still states "The type map is returned as a dictionary...", so I presume this is a bug, rather than an intentional change. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-03 13:18 Message: Logged In: YES user_id=33168 Walter, this seems to be a result of your checkin for patch # 554192. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661630&group_id=5470 From noreply@sourceforge.net Fri Jan 3 18:25:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 10:25:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-659228 ] 'realpath' function missing from os.path Message-ID: Bugs item #659228, was opened at 2002-12-27 18:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659228&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: Fixed Priority: 5 Submitted By: David MacQuigg (macquigg) Assigned to: Neal Norwitz (nnorwitz) Summary: 'realpath' function missing from os.path Initial Comment: The 'realpath()' function does not appear when you import all functions: from os.path import * Looks like this due to the name 'realpath' being missing from the '__all__' list in .../Python-2.2.2/Lib/posixpath.py All the other functions appear normally. ---------------------------------------------------------------------- >Comment By: David MacQuigg (macquigg) Date: 2003-01-03 11:25 Message: Logged In: YES user_id=676422 Seems like a safe backport to me. I can't imagine any code depending on 'realpath' being *missing* from the list functions. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-03 11:06 Message: Logged In: YES user_id=33168 Checked in as: macpath.py 1.43 ntpath.py 1.54 os2emxpath.py 1.9 posixpath.py 1.57 I have a question about if this should be backported, so I'm leaving this open for now. I think it should be backported. It is an API change, but only to correct the bug. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659228&group_id=5470 From noreply@sourceforge.net Fri Jan 3 18:42:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 10:42:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-661136 ] zipimport does not accept nested pure python imports Message-ID: Bugs item #661136, was opened at 2003-01-02 15:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661136&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Sandy Norton (sandynorton) Assigned to: Just van Rossum (jvr) Summary: zipimport does not accept nested pure python imports Initial Comment: I presume this is a big with zipimport. It occurs when you have a nested pure python package structure. It doesn't occcur if there are byte-compiled versions in the zipped directory. as pure python zipped directory =============================== Assume mylib.zip is inserted on the sys.path with the following directory structure: mylib.zip mod.py p1 __init__.py mod.py p2 __init__.py mod.py C:\TMP>ls mylib.zip C:\TMP>p Python 2.3a1 (#38, Jan 1 2003, 16:44:16) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys; sys.path.insert(0, 'c:\tmp\mylib.zip') >>> import mod mod >>> from p1 import mod Traceback (most recent call last): File "", line 1, in ? SystemError: C:\Engines\python\dist\src\Objects\stringobject.c:3295: bad argumen t to internal function >>> from p1.p2 import mod Traceback (most recent call last): File "", line 1, in ? SystemError: C:\Engines\python\dist\src\Objects\stringobject.c:3295: bad argumen t to internal function >>> as plain directory =================== C:\TMP>p Python 2.3a1 (#38, Jan 1 2003, 16:44:16) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.path.insert(0, 'c:\tmp\mylib') >>> import mod mod >>> from p1 import mod mod1 >>> from p1.p2 import mod mod2 >>> as byte-compiled zipped directory ================================= mylib.zip mod.py mod.pyc p1 __init__.py __init__.pyc mod.py mod.pyc p2 __init__.py __init__.pyc mod.py mod.pyc C:\TMP>p Python 2.3a1 (#38, Jan 1 2003, 16:44:16) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys; sys.path.insert(0, 'c:\tmp\mylib.zip') >>> import mod mod >>> import p1.mod mod1 >>> import p1.p2.mod mod2 >>> p1.p2.mod >>> ---------------------------------------------------------------------- >Comment By: Sandy Norton (sandynorton) Date: 2003-01-03 18:42 Message: Logged In: YES user_id=378957 My pleasure. Yes you are right both p1/__init__.py and p1/p2/__init__.py were empty files. Thanks for the quick fix (-: ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-03 11:22 Message: Logged In: YES user_id=92689 Ouch, nasty. It's not quite like you describe: the problem occurs for any *empty* source file (that doesn't have a matching .pyc in the archive). So I take it your mod.py wasn't empty but p1/__init__.py and p1/p2/__init__.py were. Fixed in rev. 1.8 of Modules/zipimport.c Thanks for reporting this! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661136&group_id=5470 From noreply@sourceforge.net Fri Jan 3 18:54:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 10:54:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-661357 ] tkFileDialog.SaveAs Message-ID: Bugs item #661357, was opened at 2003-01-02 23:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661357&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Martin v. Löwis (loewis) Summary: tkFileDialog.SaveAs Initial Comment: The SaveAs dialog gets a traceback due to the new object-style Tk interface. Run this test program: from Tkinter import * import tkFileDialog def doit(): savedialog = tkFileDialog.SaveAs(master=root) print savedialog.show(initialdir="/tmp", initialfile="foo.py") root = Tk() button = Button(root, text="Save...", command=doit) button.pack() mainloop() I get this traceback: Traceback (most recent call last): File "/usr/local/lib/python2.3/lib-tk/Tkinter.py", line 1306, in __call__ return apply(self.func, args) File "tkf.py", line 5, in doit print savedialog.show(initialdir="/tmp", initialfile="foo.py") File "/usr/local/lib/python2.3/lib-tk/tkCommonDialog.py", line 54, in show s = self._fixresult(w, s) File "/usr/local/lib/python2.3/lib-tk/tkFileDialog.py", line 58, in _fixresult path, file = os.path.split(result) File "/usr/local/lib/python2.3/posixpath.py", line 65, in split i = p.rfind('/') + 1 AttributeError: '_tkinter.Tcl_Obj' object has no attribute 'rfind' ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 19:54 Message: Logged In: YES user_id=21627 I see - it appears that the dialogs behave differently on Windows and X in this respect... I can see two alternative strategies: 1. Fix this specific problem, by converting the result of the dialog in _fixresult to string. 2. Enhance the Tk wrapper type, to support all string operations, by lazily converting itself to a string if a string method is requested. Then, .rfind would work on the path object. There is, in principle, a third alternative: 3. Convert path objects to Python strings, as Python does not have a separate path type. However, this somewhat defeats one purpose of using Tcl objects: If the path is passed back to Tcl, Tcl won't need to reparse it if it is still a path. Which of these would you recommend? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-03 16:24 Message: Logged In: YES user_id=6380 Python 2.3a1 (a tad post-release) Tcl/Tk 8.4 Mandrake Linux 8.1 I believe Linux kernel 2.2.17-21mdk The output from that snippet is /tmp/foo.py path ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 12:28 Message: Logged In: YES user_id=21627 Also, can you please try x=root.tk.call(("tk_getSaveFile","-initialdir","/tmp","-initialfile","foo.py")) print repr(x),str(x),x.typename I always get plain strings as a result of that call. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 11:56 Message: Logged In: YES user_id=21627 I can't reproduce this. What system and Tcl version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661357&group_id=5470 From noreply@sourceforge.net Fri Jan 3 19:27:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 11:27:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-660165 ] PyFile_GetLine() doesn't grok unicode Message-ID: Bugs item #660165, was opened at 2002-12-30 22:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660165&group_id=5470 Category: None Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Martin v. Löwis (loewis) Summary: PyFile_GetLine() doesn't grok unicode Initial Comment: PyFile_GetLine() complains when object.readline() returns a Unicode string. This is only used by raw_input() (and possible by 3rd party extensions). Could we change it to either allow Unicode strings, or at least attempt to convert the result to str()? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 20:27 Message: Logged In: YES user_id=21627 Committed as NEWS 1.598 fileobject.c 2.175 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-03 16:33 Message: Logged In: YES user_id=6380 Sounds like a good thing to try during alpha testing -- check it in! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 12:05 Message: Logged In: YES user_id=21627 What do you think about this patch? I could not find a way to avoid duplication of the string-stripping code; apart from that, it works fine in my test cases. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-31 02:02 Message: Logged In: YES user_id=6380 Wanna cook up a patch? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-31 00:05 Message: Logged In: YES user_id=21627 I'm in favour of allowing raw_input to return Unicode objects. This would follow the principle that you shall convert to a byte string at the latest possible point in processing (i.e. immediately before the byte-oriented storage). It may surprise applications, but it (in itself) isn't an incompatible change (as you now get an exception). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660165&group_id=5470 From noreply@sourceforge.net Fri Jan 3 19:39:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 11:39:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-661408 ] "make install" fails with --enable-shared Message-ID: Bugs item #661408, was opened at 2003-01-03 02:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661408&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Jarc (prjsf) >Assigned to: Martin v. Löwis (loewis) >Summary: "make install" fails with --enable-shared Initial Comment: I configured python 2.3a1 with --enable-shared. When I run "make install", some installation steps try to run the new python executable, but it complains that libpython2.3.so cannot be found. libpython2.3.so.1.0 has been installed by this point, but the symlink has not. Augmenting LD_LIBRARY_PATH during "make install" to include the build directory, which contains libpython2.3.so, allows "make install" to complete successfully. After "make install", I can run ldconfig (or equivalent) myself to create the symlink. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 20:39 Message: Logged In: YES user_id=21627 I see. Can you please try the attached patch? ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2003-01-03 18:53 Message: Logged In: YES user_id=412110 This is a custom-built GNU/Linux system, using gcc 2.95.3 and glibc 2.2.5. "make install" ends like this: SRCDIR=. \ ./python ./Tools/idle/setup.py install \ --check-tkinter \ --prefix=/package/misc/spf/python-2.3a1-1 \ --install-scripts=/package/misc/spf/python-2.3a1-1/bin \ --install-platlib=/package/misc/spf/python-2.3a1-1/lib/python2.3/lib-dynload ./python: error while loading shared libraries: libpython2.3.so: cannot open shared object file: No such file or directory make: *** [idleinstall] Error 127 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 12:03 Message: Logged In: YES user_id=21627 What operating system is this? What is the precise build step that fails? What is the precise error message? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661408&group_id=5470 From noreply@sourceforge.net Fri Jan 3 19:44:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 11:44:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-661630 ] mimetypes.read_mime_types no longer returns a dict Message-ID: Bugs item #661630, was opened at 2003-01-03 15:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661630&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Andrew Bennetts (spiv) Assigned to: Walter Dörwald (doerwalter) Summary: mimetypes.read_mime_types no longer returns a dict Initial Comment: In 2.3a1, the API of the mimetypes module seems to have changed in a backwards-incompatible way: Python 2.2.2 (#1, Dec 18 2002, 10:36:37) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import mimetypes >>> type(mimetypes.read_mime_types('/etc/mime.types')) Python 2.3a1 (#2, Jan 1 2003, 18:44:29) [GCC 3.2.2 20021212 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import mimetypes >>> type(mimetypes.read_mime_types('/etc/mime.types')) >>> type(mimetypes.read_mime_types('/etc/mime.types')[0]) That is, for some reason the result is now inside a tuple. Obviously this breaks existing code. The documentation for read_mime_types still states "The type map is returned as a dictionary...", so I presume this is a bug, rather than an intentional change. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-01-03 20:44 Message: Logged In: YES user_id=89016 Fix check in as Lib/mimetypes.py 1.24. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-03 19:18 Message: Logged In: YES user_id=33168 Walter, this seems to be a result of your checkin for patch # 554192. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661630&group_id=5470 From noreply@sourceforge.net Fri Jan 3 20:23:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 12:23:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-661408 ] "make install" fails with --enable-shared Message-ID: Bugs item #661408, was opened at 2003-01-03 01:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661408&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Jarc (prjsf) Assigned to: Martin v. Löwis (loewis) >Summary: "make install" fails with --enable-shared Initial Comment: I configured python 2.3a1 with --enable-shared. When I run "make install", some installation steps try to run the new python executable, but it complains that libpython2.3.so cannot be found. libpython2.3.so.1.0 has been installed by this point, but the symlink has not. Augmenting LD_LIBRARY_PATH during "make install" to include the build directory, which contains libpython2.3.so, allows "make install" to complete successfully. After "make install", I can run ldconfig (or equivalent) myself to create the symlink. ---------------------------------------------------------------------- >Comment By: Paul Jarc (prjsf) Date: 2003-01-03 20:23 Message: Logged In: YES user_id=412110 The first hunk fixes the problem. The second hunk cannot be applied; the Makefile.pre.in from Python-2.3a1 has no scriptsinstall target. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 19:39 Message: Logged In: YES user_id=21627 I see. Can you please try the attached patch? ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2003-01-03 17:53 Message: Logged In: YES user_id=412110 This is a custom-built GNU/Linux system, using gcc 2.95.3 and glibc 2.2.5. "make install" ends like this: SRCDIR=. \ ./python ./Tools/idle/setup.py install \ --check-tkinter \ --prefix=/package/misc/spf/python-2.3a1-1 \ --install-scripts=/package/misc/spf/python-2.3a1-1/bin \ --install-platlib=/package/misc/spf/python-2.3a1-1/lib/python2.3/lib-dynload ./python: error while loading shared libraries: libpython2.3.so: cannot open shared object file: No such file or directory make: *** [idleinstall] Error 127 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 11:03 Message: Logged In: YES user_id=21627 What operating system is this? What is the precise build step that fails? What is the precise error message? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661408&group_id=5470 From noreply@sourceforge.net Fri Jan 3 20:41:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 12:41:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-661408 ] "make install" fails with --enable-shared Message-ID: Bugs item #661408, was opened at 2003-01-03 02:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661408&group_id=5470 Category: Installation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Paul Jarc (prjsf) Assigned to: Martin v. Löwis (loewis) >Summary: "make install" fails with --enable-shared Initial Comment: I configured python 2.3a1 with --enable-shared. When I run "make install", some installation steps try to run the new python executable, but it complains that libpython2.3.so cannot be found. libpython2.3.so.1.0 has been installed by this point, but the symlink has not. Augmenting LD_LIBRARY_PATH during "make install" to include the build directory, which contains libpython2.3.so, allows "make install" to complete successfully. After "make install", I can run ldconfig (or equivalent) myself to create the symlink. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 21:41 Message: Logged In: YES user_id=21627 Ah, right, scriptsinstall is indeed post-2.3a1. Thanks for the report, I have committed the fix as Makefile.pre.in 1.109. ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2003-01-03 21:23 Message: Logged In: YES user_id=412110 The first hunk fixes the problem. The second hunk cannot be applied; the Makefile.pre.in from Python-2.3a1 has no scriptsinstall target. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 20:39 Message: Logged In: YES user_id=21627 I see. Can you please try the attached patch? ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2003-01-03 18:53 Message: Logged In: YES user_id=412110 This is a custom-built GNU/Linux system, using gcc 2.95.3 and glibc 2.2.5. "make install" ends like this: SRCDIR=. \ ./python ./Tools/idle/setup.py install \ --check-tkinter \ --prefix=/package/misc/spf/python-2.3a1-1 \ --install-scripts=/package/misc/spf/python-2.3a1-1/bin \ --install-platlib=/package/misc/spf/python-2.3a1-1/lib/python2.3/lib-dynload ./python: error while loading shared libraries: libpython2.3.so: cannot open shared object file: No such file or directory make: *** [idleinstall] Error 127 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 12:03 Message: Logged In: YES user_id=21627 What operating system is this? What is the precise build step that fails? What is the precise error message? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661408&group_id=5470 From noreply@sourceforge.net Fri Jan 3 20:44:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 12:44:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-661848 ] Add clarification of __all__ to refman? Message-ID: Bugs item #661848, was opened at 2003-01-03 21:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661848&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: Add clarification of __all__ to refman? Initial Comment: It might be a good idea to add a clarification of the intended use of __all__ to the reference manual. On the pyobjc mailing list it was suggested to use it as a means to make "from objc import *" export the most commonly used functionality to your namespace. After discussing this on python-dev Guido proclaimed that this isn't the intended use: "__all__ should contain the entire public API. It's mostly intended to avoid accidentally exporting other things you've *imported* like os, sys, and other library modules." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661848&group_id=5470 From noreply@sourceforge.net Fri Jan 3 22:14:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 14:14:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-661357 ] tkFileDialog.SaveAs Message-ID: Bugs item #661357, was opened at 2003-01-02 17:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661357&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Martin v. Löwis (loewis) Summary: tkFileDialog.SaveAs Initial Comment: The SaveAs dialog gets a traceback due to the new object-style Tk interface. Run this test program: from Tkinter import * import tkFileDialog def doit(): savedialog = tkFileDialog.SaveAs(master=root) print savedialog.show(initialdir="/tmp", initialfile="foo.py") root = Tk() button = Button(root, text="Save...", command=doit) button.pack() mainloop() I get this traceback: Traceback (most recent call last): File "/usr/local/lib/python2.3/lib-tk/Tkinter.py", line 1306, in __call__ return apply(self.func, args) File "tkf.py", line 5, in doit print savedialog.show(initialdir="/tmp", initialfile="foo.py") File "/usr/local/lib/python2.3/lib-tk/tkCommonDialog.py", line 54, in show s = self._fixresult(w, s) File "/usr/local/lib/python2.3/lib-tk/tkFileDialog.py", line 58, in _fixresult path, file = os.path.split(result) File "/usr/local/lib/python2.3/posixpath.py", line 65, in split i = p.rfind('/') + 1 AttributeError: '_tkinter.Tcl_Obj' object has no attribute 'rfind' ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-03 17:14 Message: Logged In: YES user_id=6380 In order of preference, I like 3 the best, 1 fine, and 2 not at all. I don't know what properties Tcl path objects have that would be beneficial to Python, but I expect that they will relatively rarely be bounced right back to Tcl. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 13:54 Message: Logged In: YES user_id=21627 I see - it appears that the dialogs behave differently on Windows and X in this respect... I can see two alternative strategies: 1. Fix this specific problem, by converting the result of the dialog in _fixresult to string. 2. Enhance the Tk wrapper type, to support all string operations, by lazily converting itself to a string if a string method is requested. Then, .rfind would work on the path object. There is, in principle, a third alternative: 3. Convert path objects to Python strings, as Python does not have a separate path type. However, this somewhat defeats one purpose of using Tcl objects: If the path is passed back to Tcl, Tcl won't need to reparse it if it is still a path. Which of these would you recommend? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-03 10:24 Message: Logged In: YES user_id=6380 Python 2.3a1 (a tad post-release) Tcl/Tk 8.4 Mandrake Linux 8.1 I believe Linux kernel 2.2.17-21mdk The output from that snippet is /tmp/foo.py path ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 06:28 Message: Logged In: YES user_id=21627 Also, can you please try x=root.tk.call(("tk_getSaveFile","-initialdir","/tmp","-initialfile","foo.py")) print repr(x),str(x),x.typename I always get plain strings as a result of that call. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 05:56 Message: Logged In: YES user_id=21627 I can't reproduce this. What system and Tcl version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661357&group_id=5470 From noreply@sourceforge.net Fri Jan 3 22:52:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 14:52:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-661354 ] test_strptime fails on the Mac Message-ID: Bugs item #661354, was opened at 2003-01-02 14:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Guido van Rossum (gvanrossum) Summary: test_strptime fails on the Mac Initial Comment: test_strptime fails for MacPython-OS9. It appears to be an error in the test itself, but it could be this error is triggered only on the Mac (because it doesn't have a builtin strptime() function but uses the pure Python strptime implementation). Here is the first stacktrace from the test (a lot of very similar ones follow): Traceback (most recent call last): File "Moes:SWdev:Jack:MacPython:Lib:test:test_strptime.py", line 183, in test_compile compiled = self.time_re.compile("%%%s"% directive) File "Moes:SWdev:Jack:MacPython:Lib:_strptime.py", line 394, in compile return re_compile(self.pattern(format), IGNORECASE) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 179, in compile return _compile(pattern, flags) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 229, in _compile raise error, v # invalid expression error: redefinition of group name 'Z' as group 2; was group 1 ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-03 14:52 Message: Logged In: YES user_id=357491 Congrats, Jack, you have found another edge case I didn't expect; a platform that doesn't know its own possible timezones. =) This means that ``time.tzname`` comes out with an tuple with no values. Does ``time.strftime("%Z")`` output anything? That regex will match absolutely anything. This would explain why there are ending up more than one Z group in the regex (probably happening when creating an LC_* value). So, I will write up a patch later today that will check for this special edge case of a possible regex that will match anything and make sure it doesn't output anything (basically make the Z regex be the empty string). _strptime already leaves the timezone value at -1 if it can't determine what timezone it is so at least that doesn't change anything. I will also add a test to the suite. Oh,, and a question for you, Guido. Would you prefer it if I removed the ``__author__`` and ``__email__`` variables and just added a small comment in the doc string for author and contact info? Or should I just leave them? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-01-03 08:10 Message: Logged In: YES user_id=45365 No two Z groups, but I do get something different than you, with no timezone names: >>> import _strptime >>> _strptime.TimeRE().compile("%Z").pattern '(?#)(?P||)' I've attached the whole output of test_strptime. Enjoy! (hihi:-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-02 16:39 Message: Logged In: YES user_id=357491 And for Jack's own personal knowledge, test_strptime is only run against _strptime.py. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-02 16:38 Message: Logged In: YES user_id=357491 OK, with Tim's info I am starting to wonder if this isn't some how an OS 9-specific thing. To make sure, Jack, can you run this code?:: >>> import _strptime >>> _strptime.TimeRE().compile("%Z").pattern The ``TimeRE`` class is what handles the creation of the final regex to use for parsing the input string. the ``.compile()`` method takes the directive format string and outputs the regex pattern object. The above code should spit out a string similar to ``(?#)(?PPST|PDT|)`` (and yes, that emptiness after the last pipe is expected; have to handle chance that no timezone is actually in the input string since it *could* be there). If this has two Z groups, then we have found our problem. If not, then I am goiing to need basically all the tracebacks to figure this one out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-02 16:01 Message: Logged In: YES user_id=31435 FYI, it also passes on Windows (98SE and 2K). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-02 15:54 Message: Logged In: YES user_id=357491 As for the bug, obviously a regex is being created where the regex group Z is being specified twice. I will take a look, but I just ran the tests and I am having no problems on OS X 10.2.3. I have some ideas on where this trouble could be produced, though, so I will see if I can find a problem or come up with some code Jack can run to try to help figure out the problem. Are the "very similar ones" that follow this stack trace all from the same line in test_strptime, or all from the same line in _strptime? In other words, are they all the same error being caused by the same test or the same chunk of code in _strptime? Or am I so unlucky that it is just the same redefinition error but with everything else different every time? Oh, and one quick syntax thing; line 394 in test_strptime.py has a string where the ``%`` operator has no space between it and the string being worked on. I know what a stickler you are, Guido, so I thought you should know . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 14:44 Message: Logged In: YES user_id=6380 BTW, there's an #undef HAVE_STRPTIME in timemodule.c, so that *everybody* will *always* be using the Python implementation. The test passes for me on Linux, FWIW. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 14:40 Message: Logged In: YES user_id=6380 I've forwarded this to Brett Cannon -- he's the author, maybe he understands what's going on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 From noreply@sourceforge.net Fri Jan 3 23:20:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 15:20:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-661913 ] str.index() exception message not consistent Message-ID: Bugs item #661913, was opened at 2003-01-03 23:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661913&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Inyeol Lee (inyeol) Assigned to: Nobody/Anonymous (nobody) Summary: str.index() exception message not consistent Initial Comment: $ python Python 2.3a1 (#1, Jan 2 2003, 22:36:29) [GCC 2.95.3 20010315 (release)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> 'a'.index('b') Traceback (most recent call last): File "", line 1, in ? ValueError: substring not found in string.index >>> 'a'.rindex('b') Traceback (most recent call last): File "", line 1, in ? ValueError: substring not found in string.rindex >>> u'a'.index('b') Traceback (most recent call last): File "", line 1, in ? ValueError: substring not found >>> str.index()/str.rindex() exception message contains "in string.(r)index", but unicode.index()/unicode.rindex() doesn't. For me, unicode message is more clear, and it is consistent with other string methods which raises exception, for example; >>> 'a'.split('') Traceback (most recent call last): File "", line 1, in ? ValueError: empty separator >>> 2.2.2 has the same issues. Inyeol Lee ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661913&group_id=5470 From noreply@sourceforge.net Sat Jan 4 00:01:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 16:01:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-661354 ] test_strptime fails on the Mac Message-ID: Bugs item #661354, was opened at 2003-01-02 23:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Guido van Rossum (gvanrossum) Summary: test_strptime fails on the Mac Initial Comment: test_strptime fails for MacPython-OS9. It appears to be an error in the test itself, but it could be this error is triggered only on the Mac (because it doesn't have a builtin strptime() function but uses the pure Python strptime implementation). Here is the first stacktrace from the test (a lot of very similar ones follow): Traceback (most recent call last): File "Moes:SWdev:Jack:MacPython:Lib:test:test_strptime.py", line 183, in test_compile compiled = self.time_re.compile("%%%s"% directive) File "Moes:SWdev:Jack:MacPython:Lib:_strptime.py", line 394, in compile return re_compile(self.pattern(format), IGNORECASE) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 179, in compile return _compile(pattern, flags) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 229, in _compile raise error, v # invalid expression error: redefinition of group name 'Z' as group 2; was group 1 ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-01-04 01:01 Message: Logged In: YES user_id=45365 Close, but not an empty tuple but a tuple of empty strings: >>> import time >>> time.tzname ('', '') >>> time.strftime("%Z") '' >>> ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-03 23:52 Message: Logged In: YES user_id=357491 Congrats, Jack, you have found another edge case I didn't expect; a platform that doesn't know its own possible timezones. =) This means that ``time.tzname`` comes out with an tuple with no values. Does ``time.strftime("%Z")`` output anything? That regex will match absolutely anything. This would explain why there are ending up more than one Z group in the regex (probably happening when creating an LC_* value). So, I will write up a patch later today that will check for this special edge case of a possible regex that will match anything and make sure it doesn't output anything (basically make the Z regex be the empty string). _strptime already leaves the timezone value at -1 if it can't determine what timezone it is so at least that doesn't change anything. I will also add a test to the suite. Oh,, and a question for you, Guido. Would you prefer it if I removed the ``__author__`` and ``__email__`` variables and just added a small comment in the doc string for author and contact info? Or should I just leave them? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-01-03 17:10 Message: Logged In: YES user_id=45365 No two Z groups, but I do get something different than you, with no timezone names: >>> import _strptime >>> _strptime.TimeRE().compile("%Z").pattern '(?#)(?P||)' I've attached the whole output of test_strptime. Enjoy! (hihi:-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-03 01:39 Message: Logged In: YES user_id=357491 And for Jack's own personal knowledge, test_strptime is only run against _strptime.py. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-03 01:38 Message: Logged In: YES user_id=357491 OK, with Tim's info I am starting to wonder if this isn't some how an OS 9-specific thing. To make sure, Jack, can you run this code?:: >>> import _strptime >>> _strptime.TimeRE().compile("%Z").pattern The ``TimeRE`` class is what handles the creation of the final regex to use for parsing the input string. the ``.compile()`` method takes the directive format string and outputs the regex pattern object. The above code should spit out a string similar to ``(?#)(?PPST|PDT|)`` (and yes, that emptiness after the last pipe is expected; have to handle chance that no timezone is actually in the input string since it *could* be there). If this has two Z groups, then we have found our problem. If not, then I am goiing to need basically all the tracebacks to figure this one out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-03 01:01 Message: Logged In: YES user_id=31435 FYI, it also passes on Windows (98SE and 2K). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-03 00:54 Message: Logged In: YES user_id=357491 As for the bug, obviously a regex is being created where the regex group Z is being specified twice. I will take a look, but I just ran the tests and I am having no problems on OS X 10.2.3. I have some ideas on where this trouble could be produced, though, so I will see if I can find a problem or come up with some code Jack can run to try to help figure out the problem. Are the "very similar ones" that follow this stack trace all from the same line in test_strptime, or all from the same line in _strptime? In other words, are they all the same error being caused by the same test or the same chunk of code in _strptime? Or am I so unlucky that it is just the same redefinition error but with everything else different every time? Oh, and one quick syntax thing; line 394 in test_strptime.py has a string where the ``%`` operator has no space between it and the string being worked on. I know what a stickler you are, Guido, so I thought you should know . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 23:44 Message: Logged In: YES user_id=6380 BTW, there's an #undef HAVE_STRPTIME in timemodule.c, so that *everybody* will *always* be using the Python implementation. The test passes for me on Linux, FWIW. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 23:40 Message: Logged In: YES user_id=6380 I've forwarded this to Brett Cannon -- he's the author, maybe he understands what's going on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 From noreply@sourceforge.net Sat Jan 4 00:16:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 16:16:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-661357 ] tkFileDialog.SaveAs Message-ID: Bugs item #661357, was opened at 2003-01-02 23:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661357&group_id=5470 Category: Tkinter Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Martin v. Löwis (loewis) Summary: tkFileDialog.SaveAs Initial Comment: The SaveAs dialog gets a traceback due to the new object-style Tk interface. Run this test program: from Tkinter import * import tkFileDialog def doit(): savedialog = tkFileDialog.SaveAs(master=root) print savedialog.show(initialdir="/tmp", initialfile="foo.py") root = Tk() button = Button(root, text="Save...", command=doit) button.pack() mainloop() I get this traceback: Traceback (most recent call last): File "/usr/local/lib/python2.3/lib-tk/Tkinter.py", line 1306, in __call__ return apply(self.func, args) File "tkf.py", line 5, in doit print savedialog.show(initialdir="/tmp", initialfile="foo.py") File "/usr/local/lib/python2.3/lib-tk/tkCommonDialog.py", line 54, in show s = self._fixresult(w, s) File "/usr/local/lib/python2.3/lib-tk/tkFileDialog.py", line 58, in _fixresult path, file = os.path.split(result) File "/usr/local/lib/python2.3/posixpath.py", line 65, in split i = p.rfind('/') + 1 AttributeError: '_tkinter.Tcl_Obj' object has no attribute 'rfind' ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-04 01:16 Message: Logged In: YES user_id=21627 This is fixed with _tkinter.c 1.142 tkFileDialog.py 1.9 To provide full backwards compatibility, neither str() nor unicode() are appropriate, as Tkinter traditionally returns byte strings for ASCII and Unicode strings otherwise. To support that behaviour, I added a .string attribute to Tcl_Objs, which is polymorphically either one or the other string type. For the other builtin Tcl types, this should not be an issue, as they will always have ASCII string representations. One potential advantage of path objects is that they keep internally both the Unicode representation and the "native" byte string representation. Python now only accesses the Unicode representation, which could cause problems as you might not be able to open the file afterwards (unless the Python file system encoding matches the Tcl file system encoding). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-03 23:14 Message: Logged In: YES user_id=6380 In order of preference, I like 3 the best, 1 fine, and 2 not at all. I don't know what properties Tcl path objects have that would be beneficial to Python, but I expect that they will relatively rarely be bounced right back to Tcl. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 19:54 Message: Logged In: YES user_id=21627 I see - it appears that the dialogs behave differently on Windows and X in this respect... I can see two alternative strategies: 1. Fix this specific problem, by converting the result of the dialog in _fixresult to string. 2. Enhance the Tk wrapper type, to support all string operations, by lazily converting itself to a string if a string method is requested. Then, .rfind would work on the path object. There is, in principle, a third alternative: 3. Convert path objects to Python strings, as Python does not have a separate path type. However, this somewhat defeats one purpose of using Tcl objects: If the path is passed back to Tcl, Tcl won't need to reparse it if it is still a path. Which of these would you recommend? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-03 16:24 Message: Logged In: YES user_id=6380 Python 2.3a1 (a tad post-release) Tcl/Tk 8.4 Mandrake Linux 8.1 I believe Linux kernel 2.2.17-21mdk The output from that snippet is /tmp/foo.py path ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 12:28 Message: Logged In: YES user_id=21627 Also, can you please try x=root.tk.call(("tk_getSaveFile","-initialdir","/tmp","-initialfile","foo.py")) print repr(x),str(x),x.typename I always get plain strings as a result of that call. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 11:56 Message: Logged In: YES user_id=21627 I can't reproduce this. What system and Tcl version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661357&group_id=5470 From noreply@sourceforge.net Sat Jan 4 00:50:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 16:50:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-661848 ] Add clarification of __all__ to refman? Message-ID: Bugs item #661848, was opened at 2003-01-03 15:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661848&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) >Assigned to: Raymond Hettinger (rhettinger) Summary: Add clarification of __all__ to refman? Initial Comment: It might be a good idea to add a clarification of the intended use of __all__ to the reference manual. On the pyobjc mailing list it was suggested to use it as a means to make "from objc import *" export the most commonly used functionality to your namespace. After discussing this on python-dev Guido proclaimed that this isn't the intended use: "__all__ should contain the entire public API. It's mostly intended to avoid accidentally exporting other things you've *imported* like os, sys, and other library modules." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661848&group_id=5470 From noreply@sourceforge.net Sat Jan 4 00:55:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 16:55:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-661357 ] tkFileDialog.SaveAs Message-ID: Bugs item #661357, was opened at 2003-01-02 17:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661357&group_id=5470 Category: Tkinter Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Martin v. Löwis (loewis) Summary: tkFileDialog.SaveAs Initial Comment: The SaveAs dialog gets a traceback due to the new object-style Tk interface. Run this test program: from Tkinter import * import tkFileDialog def doit(): savedialog = tkFileDialog.SaveAs(master=root) print savedialog.show(initialdir="/tmp", initialfile="foo.py") root = Tk() button = Button(root, text="Save...", command=doit) button.pack() mainloop() I get this traceback: Traceback (most recent call last): File "/usr/local/lib/python2.3/lib-tk/Tkinter.py", line 1306, in __call__ return apply(self.func, args) File "tkf.py", line 5, in doit print savedialog.show(initialdir="/tmp", initialfile="foo.py") File "/usr/local/lib/python2.3/lib-tk/tkCommonDialog.py", line 54, in show s = self._fixresult(w, s) File "/usr/local/lib/python2.3/lib-tk/tkFileDialog.py", line 58, in _fixresult path, file = os.path.split(result) File "/usr/local/lib/python2.3/posixpath.py", line 65, in split i = p.rfind('/') + 1 AttributeError: '_tkinter.Tcl_Obj' object has no attribute 'rfind' ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-03 19:55 Message: Logged In: YES user_id=6380 I guess that's only an issue on Windows NT descendants? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 19:16 Message: Logged In: YES user_id=21627 This is fixed with _tkinter.c 1.142 tkFileDialog.py 1.9 To provide full backwards compatibility, neither str() nor unicode() are appropriate, as Tkinter traditionally returns byte strings for ASCII and Unicode strings otherwise. To support that behaviour, I added a .string attribute to Tcl_Objs, which is polymorphically either one or the other string type. For the other builtin Tcl types, this should not be an issue, as they will always have ASCII string representations. One potential advantage of path objects is that they keep internally both the Unicode representation and the "native" byte string representation. Python now only accesses the Unicode representation, which could cause problems as you might not be able to open the file afterwards (unless the Python file system encoding matches the Tcl file system encoding). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-03 17:14 Message: Logged In: YES user_id=6380 In order of preference, I like 3 the best, 1 fine, and 2 not at all. I don't know what properties Tcl path objects have that would be beneficial to Python, but I expect that they will relatively rarely be bounced right back to Tcl. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 13:54 Message: Logged In: YES user_id=21627 I see - it appears that the dialogs behave differently on Windows and X in this respect... I can see two alternative strategies: 1. Fix this specific problem, by converting the result of the dialog in _fixresult to string. 2. Enhance the Tk wrapper type, to support all string operations, by lazily converting itself to a string if a string method is requested. Then, .rfind would work on the path object. There is, in principle, a third alternative: 3. Convert path objects to Python strings, as Python does not have a separate path type. However, this somewhat defeats one purpose of using Tcl objects: If the path is passed back to Tcl, Tcl won't need to reparse it if it is still a path. Which of these would you recommend? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-03 10:24 Message: Logged In: YES user_id=6380 Python 2.3a1 (a tad post-release) Tcl/Tk 8.4 Mandrake Linux 8.1 I believe Linux kernel 2.2.17-21mdk The output from that snippet is /tmp/foo.py path ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 06:28 Message: Logged In: YES user_id=21627 Also, can you please try x=root.tk.call(("tk_getSaveFile","-initialdir","/tmp","-initialfile","foo.py")) print repr(x),str(x),x.typename I always get plain strings as a result of that call. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 05:56 Message: Logged In: YES user_id=21627 I can't reproduce this. What system and Tcl version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661357&group_id=5470 From noreply@sourceforge.net Sat Jan 4 01:05:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 17:05:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-661354 ] test_strptime fails on the Mac Message-ID: Bugs item #661354, was opened at 2003-01-02 17:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Jack Jansen (jackjansen) >Assigned to: Jack Jansen (jackjansen) Summary: test_strptime fails on the Mac Initial Comment: test_strptime fails for MacPython-OS9. It appears to be an error in the test itself, but it could be this error is triggered only on the Mac (because it doesn't have a builtin strptime() function but uses the pure Python strptime implementation). Here is the first stacktrace from the test (a lot of very similar ones follow): Traceback (most recent call last): File "Moes:SWdev:Jack:MacPython:Lib:test:test_strptime.py", line 183, in test_compile compiled = self.time_re.compile("%%%s"% directive) File "Moes:SWdev:Jack:MacPython:Lib:_strptime.py", line 394, in compile return re_compile(self.pattern(format), IGNORECASE) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 179, in compile return _compile(pattern, flags) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 229, in _compile raise error, v # invalid expression error: redefinition of group name 'Z' as group 2; was group 1 ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-01-03 19:01 Message: Logged In: YES user_id=45365 Close, but not an empty tuple but a tuple of empty strings: >>> import time >>> time.tzname ('', '') >>> time.strftime("%Z") '' >>> ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-03 17:52 Message: Logged In: YES user_id=357491 Congrats, Jack, you have found another edge case I didn't expect; a platform that doesn't know its own possible timezones. =) This means that ``time.tzname`` comes out with an tuple with no values. Does ``time.strftime("%Z")`` output anything? That regex will match absolutely anything. This would explain why there are ending up more than one Z group in the regex (probably happening when creating an LC_* value). So, I will write up a patch later today that will check for this special edge case of a possible regex that will match anything and make sure it doesn't output anything (basically make the Z regex be the empty string). _strptime already leaves the timezone value at -1 if it can't determine what timezone it is so at least that doesn't change anything. I will also add a test to the suite. Oh,, and a question for you, Guido. Would you prefer it if I removed the ``__author__`` and ``__email__`` variables and just added a small comment in the doc string for author and contact info? Or should I just leave them? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-01-03 11:10 Message: Logged In: YES user_id=45365 No two Z groups, but I do get something different than you, with no timezone names: >>> import _strptime >>> _strptime.TimeRE().compile("%Z").pattern '(?#)(?P||)' I've attached the whole output of test_strptime. Enjoy! (hihi:-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-02 19:39 Message: Logged In: YES user_id=357491 And for Jack's own personal knowledge, test_strptime is only run against _strptime.py. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-02 19:38 Message: Logged In: YES user_id=357491 OK, with Tim's info I am starting to wonder if this isn't some how an OS 9-specific thing. To make sure, Jack, can you run this code?:: >>> import _strptime >>> _strptime.TimeRE().compile("%Z").pattern The ``TimeRE`` class is what handles the creation of the final regex to use for parsing the input string. the ``.compile()`` method takes the directive format string and outputs the regex pattern object. The above code should spit out a string similar to ``(?#)(?PPST|PDT|)`` (and yes, that emptiness after the last pipe is expected; have to handle chance that no timezone is actually in the input string since it *could* be there). If this has two Z groups, then we have found our problem. If not, then I am goiing to need basically all the tracebacks to figure this one out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-02 19:01 Message: Logged In: YES user_id=31435 FYI, it also passes on Windows (98SE and 2K). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-02 18:54 Message: Logged In: YES user_id=357491 As for the bug, obviously a regex is being created where the regex group Z is being specified twice. I will take a look, but I just ran the tests and I am having no problems on OS X 10.2.3. I have some ideas on where this trouble could be produced, though, so I will see if I can find a problem or come up with some code Jack can run to try to help figure out the problem. Are the "very similar ones" that follow this stack trace all from the same line in test_strptime, or all from the same line in _strptime? In other words, are they all the same error being caused by the same test or the same chunk of code in _strptime? Or am I so unlucky that it is just the same redefinition error but with everything else different every time? Oh, and one quick syntax thing; line 394 in test_strptime.py has a string where the ``%`` operator has no space between it and the string being worked on. I know what a stickler you are, Guido, so I thought you should know . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 17:44 Message: Logged In: YES user_id=6380 BTW, there's an #undef HAVE_STRPTIME in timemodule.c, so that *everybody* will *always* be using the Python implementation. The test passes for me on Linux, FWIW. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 17:40 Message: Logged In: YES user_id=6380 I've forwarded this to Brett Cannon -- he's the author, maybe he understands what's going on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 From noreply@sourceforge.net Sat Jan 4 01:07:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 17:07:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-660476 ] readline and threads crashes Message-ID: Bugs item #660476, was opened at 2002-12-31 14:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660476&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None >Priority: 7 Submitted By: Michael Stone (mbrierst) Assigned to: Guido van Rossum (gvanrossum) Summary: readline and threads crashes Initial Comment: Python 2.2.2 with linux kernel 2.2.17 paste into the interpreter: import readline, rlcompleter readline.parse_and_bind('tab: complete') import thread import math def starter(a): for i in range(1000000): a = math.cos(i) thread.start_new_thread(starter, (1,)) now type any letter and hit segfault or "Fatal Python error: ceval: tstate mix-up" will occur, if not the first time, then eventually if you keep hitting tab this might be related to: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=513033 but I'm posting anyway as I'm not sure it's the same, and that one doesn't seem to be getting attention ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-31 15:58 Message: Logged In: YES user_id=6380 Will look after 2.3a1 is released. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-31 15:53 Message: Logged In: YES user_id=33168 I cannot replicate this for 2.3, but I get the crash for 2.2.2. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2002-12-31 15:33 Message: Logged In: YES user_id=670441 I don't claim to have a real good understanding of the python internals, but it seems like someone was doing some obviously wrong thread stuff. The diff below gives a fix that seems to solve my problems. After looking at it more, this does seem to be the same bug listed in the link in original comment. --- readline.c.old Tue Dec 31 15:15:45 2002 +++ readline.c Tue Dec 31 15:09:08 2002 @@ -404,16 +404,14 @@ /* C function to call the Python hooks. */ static int -on_hook(PyObject *func, PyThreadState *tstate) +on_hook(PyObject *func, PyThreadState **tstate) { int result = 0; if (func != NULL) { PyObject *r; - PyThreadState *save_tstate; /* Note that readline is called with the interpreter lock released! */ - save_tstate = PyThreadState_Swap(NULL); - PyEval_RestoreThread(tstate); + PyEval_RestoreThread(*tstate); r = PyObject_CallFunction(func, NULL); if (r == NULL) goto error; @@ -427,8 +425,7 @@ PyErr_Clear(); Py_XDECREF(r); done: - PyEval_SaveThread(); - PyThreadState_Swap(save_tstate); + *tstate = PyEval_SaveThread(); } return result; } @@ -436,14 +433,14 @@ static int on_startup_hook(void) { - return on_hook(startup_hook, startup_hook_tstate); + return on_hook(startup_hook, &startup_hook_tstate); } #ifdef HAVE_RL_PRE_INPUT_HOOK static int on_pre_input_hook(void) { - return on_hook(pre_input_hook, pre_input_hook_tstate); + return on_hook(pre_input_hook, &pre_input_hook_tstate); } #endif @@ -455,10 +452,8 @@ char *result = NULL; if (completer != NULL) { PyObject *r; - PyThreadState *save_tstate; /* Note that readline is called with the interpreter lock released! */ - save_tstate = PyThreadState_Swap(NULL); PyEval_RestoreThread(completer_tstate); r = PyObject_CallFunction(completer, "si", text, state); if (r == NULL) @@ -478,8 +473,7 @@ PyErr_Clear(); Py_XDECREF(r); done: - PyEval_SaveThread(); - PyThreadState_Swap(save_tstate); + completer_tstate = PyEval_SaveThread(); } return result; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660476&group_id=5470 From noreply@sourceforge.net Sat Jan 4 01:07:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 17:07:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-642358 ] metaclass causes __dict__ to be dict Message-ID: Bugs item #642358, was opened at 2002-11-22 11:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=642358&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Jeremy Hylton (jhylton) Assigned to: Guido van Rossum (gvanrossum) Summary: metaclass causes __dict__ to be dict Initial Comment: class Meta(type): def __new__(meta, name, bases, dict): return super(Meta, name).__new__(meta, name, bases, dict) class AClass: __metaclass__ = Meta print type(AClass.__dict__) With 2.2.2, this prints dict-proxy. With 2.3, this prints dict. As you noted, it should always be a dict-proxy to prevent people from getting the __dict__ and the tp slots out of sync. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=642358&group_id=5470 From noreply@sourceforge.net Sat Jan 4 01:08:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 17:08:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-623669 ] __rdiv__ vs new-style classes Message-ID: Bugs item #623669, was opened at 2002-10-15 14:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623669&group_id=5470 Category: Type/class unification Group: Python 2.2.2 Status: Open Resolution: None >Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Guido van Rossum (gvanrossum) Summary: __rdiv__ vs new-style classes Initial Comment: In 2.2.2 and 2.3, consider this: """ class F: def __init__(self): print 'built an F' def __div__(self, other): print 'in F.__div__' return F() def __rdiv__(self, other): print 'in F.__rdiv__' return F() / self class F2(F): def __init__(self): print 'built an F2' 3 / F2() """ This displays what I expect: """ built an F2 in F.__rdiv__ built an F in F.__div__ built an F """ However, change F to derive from object: class F(object): and it's in infinite recursion, starting like so: """ built an F2 in F.__rdiv__ built an F in F.__rdiv__ built an F in F.__rdiv__ built an F in F.__rdiv__ built an F in F.__rdiv__ built an F in F.__rdiv__ built an F in F.__rdiv__ ... """ Despite that F.__rdiv__ creates an explicit F() instance and uses it on the LHS of /, F.__div__ is never invoked; instead the RHS F2.__rdiv__ == F.__rdiv__ always gets the nod. Maybe this is intentional? I confess I've lost track of the rules. Changing the end of F.__rdiv__ to return F().__div__(self) brute-forces the desired outcome, so there is a workaround. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623669&group_id=5470 From noreply@sourceforge.net Sat Jan 4 01:09:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 17:09:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-661184 ] inspect.getsource bug Message-ID: Bugs item #661184, was opened at 2003-01-02 12:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661184&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michele Simionato (michele_s) >Assigned to: Raymond Hettinger (rhettinger) Summary: inspect.getsource bug Initial Comment: I have found a bug in inspect.getsource. I am using Python 2.2.2 on Red-Hat 7.3. Here is the problem. --begin bug.py import inspect def f(x): return x print inspect.getsource(f) --end bug.py % python bug.py Traceback (most recent call last): File "bug.py", line 3, in ? print inspect.getsource(f) File "/usr/local/lib/python2.2/inspect.py", line 520, in getsource return string.join(lines, '') File "/usr/local/lib/python2.2/string.py", line 131, in join return sep.join(words) TypeError: sequence expected, NoneType found Notice that --begin noproblem.py import inspect def f(x): return x print inspect.getsource(f) --end noproblem.py works: % python noproblem.py def f(x): return x I discovered this bug in trying to retrieve the source code for lambda expressions: --begin lambda.py import inspect f=lambda x: x print inspect.getsource(f) --begin lambda.py (same error message). -- Michele Simionato - Dept. of Physics and Astronomy 210 Allen Hall Pittsburgh PA 15260 U.S.A. Phone: 001-412-624-9041 Fax: 001-412-624-9163 Home-page: http://www.phyast.pitt.edu/~micheles/ ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-03 06:58 Message: Logged In: YES user_id=92689 It seems inspect.py indeed has problems finding one-line functions. I've attached a patch that addresses this, but to also make it work for lambda's I had to remove a few lines that I don't quite understand the purpose of, as it seems to work well without it. I've commented them out. Their purpose seems to be to adjust co.co_firstlineno in case it's off, it's just that I don't know how/when it can be off. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661184&group_id=5470 From noreply@sourceforge.net Sat Jan 4 01:10:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 17:10:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-655271 ] Slightly modify locals() doc? Message-ID: Bugs item #655271, was opened at 2002-12-17 11:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=655271&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Terry J. Reedy (tjreedy) >Assigned to: Raymond Hettinger (rhettinger) Summary: Slightly modify locals() doc? Initial Comment: Lib ref manual 2.1 builtin funcs: locals() says "Return a dictionary representing the current local symbol table" This can be (and has been, by experience users) interpreted as "return a *new* dictionary..." It would better describe current behavior if it said: "Update and return the dictionary...." This would make the following less surprising: >>> def f(): ... foo = 'bar' ... a = locals() ... a['foo'] = 'Guido' ... try: print a['a'] ... except: print "'a' is not in a" ... print a['foo'], locals()['foo'], a['foo'], a['a'] ... >>> f() 'a' is not in a Guido bar bar {'a': {...}, 'foo': 'bar'} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=655271&group_id=5470 From noreply@sourceforge.net Sat Jan 4 01:55:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 17:55:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-651149 ] Review libshelve.tex when possible Message-ID: Bugs item #651149, was opened at 2002-12-09 17:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651149&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Skip Montanaro (montanaro) >Assigned to: Raymond Hettinger (rhettinger) Summary: Review libshelve.tex when possible Initial Comment: I added a significant amount of text to libshelve.tex. None of the classes the shelve library exports were described. I also added some stuff about the new binary flag. Probably worth a look from a TeX perspective when you get a chance, but not terribly high priority. Skip ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-03 20:55 Message: Logged In: YES user_id=80475 Done. Posted fixes as libshelve.tex 1.17. Marking as closed. * misspelled databse * optional close brace moved to enclose second optional * replaced e.g. with such as * replace \constant{True} with \code{True} * removed extraneous {} * first param of DbfilenameShelf renamed to "filename" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651149&group_id=5470 From noreply@sourceforge.net Sat Jan 4 02:18:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 18:18:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-655271 ] Slightly modify locals() doc? Message-ID: Bugs item #655271, was opened at 2002-12-17 11:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=655271&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Terry J. Reedy (tjreedy) Assigned to: Raymond Hettinger (rhettinger) Summary: Slightly modify locals() doc? Initial Comment: Lib ref manual 2.1 builtin funcs: locals() says "Return a dictionary representing the current local symbol table" This can be (and has been, by experience users) interpreted as "return a *new* dictionary..." It would better describe current behavior if it said: "Update and return the dictionary...." This would make the following less surprising: >>> def f(): ... foo = 'bar' ... a = locals() ... a['foo'] = 'Guido' ... try: print a['a'] ... except: print "'a' is not in a" ... print a['foo'], locals()['foo'], a['foo'], a['a'] ... >>> f() 'a' is not in a Guido bar bar {'a': {...}, 'foo': 'bar'} ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-03 21:18 Message: Logged In: YES user_id=80475 Applied as libfuncs.tex 1.127 and bltinmodule.c 2.270. Closing bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=655271&group_id=5470 From noreply@sourceforge.net Sat Jan 4 02:26:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 18:26:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-661354 ] test_strptime fails on the Mac Message-ID: Bugs item #661354, was opened at 2003-01-02 23:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: test_strptime fails on the Mac Initial Comment: test_strptime fails for MacPython-OS9. It appears to be an error in the test itself, but it could be this error is triggered only on the Mac (because it doesn't have a builtin strptime() function but uses the pure Python strptime implementation). Here is the first stacktrace from the test (a lot of very similar ones follow): Traceback (most recent call last): File "Moes:SWdev:Jack:MacPython:Lib:test:test_strptime.py", line 183, in test_compile compiled = self.time_re.compile("%%%s"% directive) File "Moes:SWdev:Jack:MacPython:Lib:_strptime.py", line 394, in compile return re_compile(self.pattern(format), IGNORECASE) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 179, in compile return _compile(pattern, flags) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 229, in _compile raise error, v # invalid expression error: redefinition of group name 'Z' as group 2; was group 1 ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-01-04 03:26 Message: Logged In: YES user_id=45365 Nou, dank je wel... :-) ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-01-04 01:01 Message: Logged In: YES user_id=45365 Close, but not an empty tuple but a tuple of empty strings: >>> import time >>> time.tzname ('', '') >>> time.strftime("%Z") '' >>> ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-03 23:52 Message: Logged In: YES user_id=357491 Congrats, Jack, you have found another edge case I didn't expect; a platform that doesn't know its own possible timezones. =) This means that ``time.tzname`` comes out with an tuple with no values. Does ``time.strftime("%Z")`` output anything? That regex will match absolutely anything. This would explain why there are ending up more than one Z group in the regex (probably happening when creating an LC_* value). So, I will write up a patch later today that will check for this special edge case of a possible regex that will match anything and make sure it doesn't output anything (basically make the Z regex be the empty string). _strptime already leaves the timezone value at -1 if it can't determine what timezone it is so at least that doesn't change anything. I will also add a test to the suite. Oh,, and a question for you, Guido. Would you prefer it if I removed the ``__author__`` and ``__email__`` variables and just added a small comment in the doc string for author and contact info? Or should I just leave them? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-01-03 17:10 Message: Logged In: YES user_id=45365 No two Z groups, but I do get something different than you, with no timezone names: >>> import _strptime >>> _strptime.TimeRE().compile("%Z").pattern '(?#)(?P||)' I've attached the whole output of test_strptime. Enjoy! (hihi:-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-03 01:39 Message: Logged In: YES user_id=357491 And for Jack's own personal knowledge, test_strptime is only run against _strptime.py. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-03 01:38 Message: Logged In: YES user_id=357491 OK, with Tim's info I am starting to wonder if this isn't some how an OS 9-specific thing. To make sure, Jack, can you run this code?:: >>> import _strptime >>> _strptime.TimeRE().compile("%Z").pattern The ``TimeRE`` class is what handles the creation of the final regex to use for parsing the input string. the ``.compile()`` method takes the directive format string and outputs the regex pattern object. The above code should spit out a string similar to ``(?#)(?PPST|PDT|)`` (and yes, that emptiness after the last pipe is expected; have to handle chance that no timezone is actually in the input string since it *could* be there). If this has two Z groups, then we have found our problem. If not, then I am goiing to need basically all the tracebacks to figure this one out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-03 01:01 Message: Logged In: YES user_id=31435 FYI, it also passes on Windows (98SE and 2K). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-03 00:54 Message: Logged In: YES user_id=357491 As for the bug, obviously a regex is being created where the regex group Z is being specified twice. I will take a look, but I just ran the tests and I am having no problems on OS X 10.2.3. I have some ideas on where this trouble could be produced, though, so I will see if I can find a problem or come up with some code Jack can run to try to help figure out the problem. Are the "very similar ones" that follow this stack trace all from the same line in test_strptime, or all from the same line in _strptime? In other words, are they all the same error being caused by the same test or the same chunk of code in _strptime? Or am I so unlucky that it is just the same redefinition error but with everything else different every time? Oh, and one quick syntax thing; line 394 in test_strptime.py has a string where the ``%`` operator has no space between it and the string being worked on. I know what a stickler you are, Guido, so I thought you should know . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 23:44 Message: Logged In: YES user_id=6380 BTW, there's an #undef HAVE_STRPTIME in timemodule.c, so that *everybody* will *always* be using the Python implementation. The test passes for me on Linux, FWIW. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 23:40 Message: Logged In: YES user_id=6380 I've forwarded this to Brett Cannon -- he's the author, maybe he understands what's going on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 From noreply@sourceforge.net Sat Jan 4 04:40:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 20:40:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-660095 ] GNU readline version confusion Message-ID: Bugs item #660095, was opened at 2002-12-30 13:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660095&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 3 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: GNU readline version confusion Initial Comment: configure and setup.py don't look for GNU readline the same way. If you have e.g. readline 4.2 installed in /usr and a different version in /usr/local, setup.py uses the version from /usr/local, but the feature testing in configure finds the 4.2 features in /usr/lib/libreadline* anyway. :-( ---------------------------------------------------------------------- Comment By: Ismaeel Abdur-Rasheed (ismaeek) Date: 2003-01-03 23:40 Message: Logged In: YES user_id=680116 additional info: with GNU readline 4.2 installed, python 2.2.2 build using gcc 3.2.1 and native solaris /usr/ccs reports multiply-defined symbols: all are found in /usr/lib/readline.so and one of the following: __dso_handle (from gcc crtbegin.o), _init and _fini (from gcc crti.o), and _lib_version (from /usr/ccs/lib/values-Xa.o) - izzy ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660095&group_id=5470 From noreply@sourceforge.net Sat Jan 4 04:52:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 20:52:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-661981 ] need to skip some build tests for sunos5 Message-ID: Bugs item #661981, was opened at 2003-01-03 23:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661981&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Ismaeel Abdur-Rasheed (ismaeek) Assigned to: Nobody/Anonymous (nobody) Summary: need to skip some build tests for sunos5 Initial Comment: make test reports the following after completion: 173 tests OK. 20 tests skipped: test_al test_bsddb test_cd test_cl test_curses test_dl test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_minidom test_openpty test_pyexpat test_sax test_socket_ssl test_socketserver test_sunaudiodev test_winreg test_winsound Ask someone to teach regrtest.py about which tests are expected to get skipped on sunos5. - izzy ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661981&group_id=5470 From noreply@sourceforge.net Sat Jan 4 06:11:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 03 Jan 2003 22:11:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-661981 ] need to skip some build tests for sunos5 Message-ID: Bugs item #661981, was opened at 2003-01-03 23:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661981&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None >Priority: 3 Submitted By: Ismaeel Abdur-Rasheed (ismaeek) Assigned to: Nobody/Anonymous (nobody) Summary: need to skip some build tests for sunos5 Initial Comment: make test reports the following after completion: 173 tests OK. 20 tests skipped: test_al test_bsddb test_cd test_cl test_curses test_dl test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_minidom test_openpty test_pyexpat test_sax test_socket_ssl test_socketserver test_sunaudiodev test_winreg test_winsound Ask someone to teach regrtest.py about which tests are expected to get skipped on sunos5. - izzy ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-04 01:11 Message: Logged In: YES user_id=31435 The "someone" you need to ask has to be expert in both suos5 and Python. If such a person existed, and had time enough to bother, they already would have done this . In the meantime, skipping a test is a not a test failure, so don't worry about it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661981&group_id=5470 From noreply@sourceforge.net Sat Jan 4 08:33:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 04 Jan 2003 00:33:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-661357 ] tkFileDialog.SaveAs Message-ID: Bugs item #661357, was opened at 2003-01-02 23:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661357&group_id=5470 Category: Tkinter Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Martin v. Löwis (loewis) Summary: tkFileDialog.SaveAs Initial Comment: The SaveAs dialog gets a traceback due to the new object-style Tk interface. Run this test program: from Tkinter import * import tkFileDialog def doit(): savedialog = tkFileDialog.SaveAs(master=root) print savedialog.show(initialdir="/tmp", initialfile="foo.py") root = Tk() button = Button(root, text="Save...", command=doit) button.pack() mainloop() I get this traceback: Traceback (most recent call last): File "/usr/local/lib/python2.3/lib-tk/Tkinter.py", line 1306, in __call__ return apply(self.func, args) File "tkf.py", line 5, in doit print savedialog.show(initialdir="/tmp", initialfile="foo.py") File "/usr/local/lib/python2.3/lib-tk/tkCommonDialog.py", line 54, in show s = self._fixresult(w, s) File "/usr/local/lib/python2.3/lib-tk/tkFileDialog.py", line 58, in _fixresult path, file = os.path.split(result) File "/usr/local/lib/python2.3/posixpath.py", line 65, in split i = p.rfind('/') + 1 AttributeError: '_tkinter.Tcl_Obj' object has no attribute 'rfind' ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-04 09:33 Message: Logged In: YES user_id=21627 On NT+, it is not a problem: tkFileDialog will return Unicode objects, which you can then pass to open(). The problem exists on Unix: If you have a file name with non-ASCII characters, tkFileDialog will still return a Unicode object, but you can't pass that to open, unless the file system default encoding was changed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-04 01:55 Message: Logged In: YES user_id=6380 I guess that's only an issue on Windows NT descendants? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-04 01:16 Message: Logged In: YES user_id=21627 This is fixed with _tkinter.c 1.142 tkFileDialog.py 1.9 To provide full backwards compatibility, neither str() nor unicode() are appropriate, as Tkinter traditionally returns byte strings for ASCII and Unicode strings otherwise. To support that behaviour, I added a .string attribute to Tcl_Objs, which is polymorphically either one or the other string type. For the other builtin Tcl types, this should not be an issue, as they will always have ASCII string representations. One potential advantage of path objects is that they keep internally both the Unicode representation and the "native" byte string representation. Python now only accesses the Unicode representation, which could cause problems as you might not be able to open the file afterwards (unless the Python file system encoding matches the Tcl file system encoding). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-03 23:14 Message: Logged In: YES user_id=6380 In order of preference, I like 3 the best, 1 fine, and 2 not at all. I don't know what properties Tcl path objects have that would be beneficial to Python, but I expect that they will relatively rarely be bounced right back to Tcl. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 19:54 Message: Logged In: YES user_id=21627 I see - it appears that the dialogs behave differently on Windows and X in this respect... I can see two alternative strategies: 1. Fix this specific problem, by converting the result of the dialog in _fixresult to string. 2. Enhance the Tk wrapper type, to support all string operations, by lazily converting itself to a string if a string method is requested. Then, .rfind would work on the path object. There is, in principle, a third alternative: 3. Convert path objects to Python strings, as Python does not have a separate path type. However, this somewhat defeats one purpose of using Tcl objects: If the path is passed back to Tcl, Tcl won't need to reparse it if it is still a path. Which of these would you recommend? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-03 16:24 Message: Logged In: YES user_id=6380 Python 2.3a1 (a tad post-release) Tcl/Tk 8.4 Mandrake Linux 8.1 I believe Linux kernel 2.2.17-21mdk The output from that snippet is /tmp/foo.py path ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 12:28 Message: Logged In: YES user_id=21627 Also, can you please try x=root.tk.call(("tk_getSaveFile","-initialdir","/tmp","-initialfile","foo.py")) print repr(x),str(x),x.typename I always get plain strings as a result of that call. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 11:56 Message: Logged In: YES user_id=21627 I can't reproduce this. What system and Tcl version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661357&group_id=5470 From noreply@sourceforge.net Sat Jan 4 08:34:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 04 Jan 2003 00:34:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-661354 ] test_strptime fails on the Mac Message-ID: Bugs item #661354, was opened at 2003-01-02 14:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: test_strptime fails on the Mac Initial Comment: test_strptime fails for MacPython-OS9. It appears to be an error in the test itself, but it could be this error is triggered only on the Mac (because it doesn't have a builtin strptime() function but uses the pure Python strptime implementation). Here is the first stacktrace from the test (a lot of very similar ones follow): Traceback (most recent call last): File "Moes:SWdev:Jack:MacPython:Lib:test:test_strptime.py", line 183, in test_compile compiled = self.time_re.compile("%%%s"% directive) File "Moes:SWdev:Jack:MacPython:Lib:_strptime.py", line 394, in compile return re_compile(self.pattern(format), IGNORECASE) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 179, in compile return _compile(pattern, flags) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 229, in _compile raise error, v # invalid expression error: redefinition of group name 'Z' as group 2; was group 1 ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-04 00:34 Message: Logged In: YES user_id=357491 Patch #662053 fixes _strptime.py to handle any possibility of a locale not knowing anything about a certain thing (timezone, AM/PM as in Swedish, etc.). Also added two tests to the test suite. Left unassigned and said it was for the LIbrary and not MacOS specifically since it is a general fix. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-01-03 18:26 Message: Logged In: YES user_id=45365 Nou, dank je wel... :-) ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-01-03 16:01 Message: Logged In: YES user_id=45365 Close, but not an empty tuple but a tuple of empty strings: >>> import time >>> time.tzname ('', '') >>> time.strftime("%Z") '' >>> ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-03 14:52 Message: Logged In: YES user_id=357491 Congrats, Jack, you have found another edge case I didn't expect; a platform that doesn't know its own possible timezones. =) This means that ``time.tzname`` comes out with an tuple with no values. Does ``time.strftime("%Z")`` output anything? That regex will match absolutely anything. This would explain why there are ending up more than one Z group in the regex (probably happening when creating an LC_* value). So, I will write up a patch later today that will check for this special edge case of a possible regex that will match anything and make sure it doesn't output anything (basically make the Z regex be the empty string). _strptime already leaves the timezone value at -1 if it can't determine what timezone it is so at least that doesn't change anything. I will also add a test to the suite. Oh,, and a question for you, Guido. Would you prefer it if I removed the ``__author__`` and ``__email__`` variables and just added a small comment in the doc string for author and contact info? Or should I just leave them? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-01-03 08:10 Message: Logged In: YES user_id=45365 No two Z groups, but I do get something different than you, with no timezone names: >>> import _strptime >>> _strptime.TimeRE().compile("%Z").pattern '(?#)(?P||)' I've attached the whole output of test_strptime. Enjoy! (hihi:-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-02 16:39 Message: Logged In: YES user_id=357491 And for Jack's own personal knowledge, test_strptime is only run against _strptime.py. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-02 16:38 Message: Logged In: YES user_id=357491 OK, with Tim's info I am starting to wonder if this isn't some how an OS 9-specific thing. To make sure, Jack, can you run this code?:: >>> import _strptime >>> _strptime.TimeRE().compile("%Z").pattern The ``TimeRE`` class is what handles the creation of the final regex to use for parsing the input string. the ``.compile()`` method takes the directive format string and outputs the regex pattern object. The above code should spit out a string similar to ``(?#)(?PPST|PDT|)`` (and yes, that emptiness after the last pipe is expected; have to handle chance that no timezone is actually in the input string since it *could* be there). If this has two Z groups, then we have found our problem. If not, then I am goiing to need basically all the tracebacks to figure this one out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-02 16:01 Message: Logged In: YES user_id=31435 FYI, it also passes on Windows (98SE and 2K). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-02 15:54 Message: Logged In: YES user_id=357491 As for the bug, obviously a regex is being created where the regex group Z is being specified twice. I will take a look, but I just ran the tests and I am having no problems on OS X 10.2.3. I have some ideas on where this trouble could be produced, though, so I will see if I can find a problem or come up with some code Jack can run to try to help figure out the problem. Are the "very similar ones" that follow this stack trace all from the same line in test_strptime, or all from the same line in _strptime? In other words, are they all the same error being caused by the same test or the same chunk of code in _strptime? Or am I so unlucky that it is just the same redefinition error but with everything else different every time? Oh, and one quick syntax thing; line 394 in test_strptime.py has a string where the ``%`` operator has no space between it and the string being worked on. I know what a stickler you are, Guido, so I thought you should know . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 14:44 Message: Logged In: YES user_id=6380 BTW, there's an #undef HAVE_STRPTIME in timemodule.c, so that *everybody* will *always* be using the Python implementation. The test passes for me on Linux, FWIW. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 14:40 Message: Logged In: YES user_id=6380 I've forwarded this to Brett Cannon -- he's the author, maybe he understands what's going on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 From noreply@sourceforge.net Sat Jan 4 08:38:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 04 Jan 2003 00:38:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-660961 ] tkinter.dooneevent() crashes Message-ID: Bugs item #660961, was opened at 2003-01-02 06:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660961&group_id=5470 Category: Tkinter Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Justin Gullingsrud (jgullingsrud) Assigned to: Martin v. Löwis (loewis) Summary: tkinter.dooneevent() crashes Initial Comment: On Linux, compiling against Tcl/Tk 8.3.5, running Tkinter.tkinter.dooneevent() segfaults immediately. Traceback: >>> from Tkinter import * >>> tkinter.dooneevent() Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 14004)] Tkapp_DoOneEvent (self=0x0, args=0x4049c02c) at Modules/_tkinter.c:2397 2397 CHECK_TCL_APPARTMENT; (gdb) where #0 Tkapp_DoOneEvent (self=0x0, args=0x4049c02c) at Modules/_tkinter.c:2397 #1 0x080f85c7 in PyCFunction_Call (func=0x404f5fac, arg=0x4049c02c, kw=0x0) at Objects/methodobject.c:90 #2 0x080a8185 in call_function (pp_stack=0xbffff22c, oparg=1) at Python/ceval.c:3249 #3 0x080a654e in eval_frame (f=0x8159f64) at Python/ceval.c:2009 #4 0x080a7095 in PyEval_EvalCodeEx (co=0x404ab620, globals=0x1, locals=0x404b48ac, args=0x8159f64, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2554 #5 0x080a9805 in PyEval_EvalCode (co=0x404ab620, globals=0x404b48ac, locals=0x404b48ac) at Python/ceval.c:478 #6 0x080cff99 in run_node (n=0x4049c2a8, filename=0x80fb12a "", globals=0x404b48ac, locals=0x404b48ac, flags=0xbffff418) at Python/pythonrun.c:1097 #7 0x080cf4fd in PyRun_InteractiveOneFlags (fp=0x40491de0, filename=0x80fb12a "", flags=0xbffff418) at Python/pythonrun.c:601 #8 0x080cf30c in PyRun_InteractiveLoopFlags (fp=0x40491de0, filename=0x80fb12a "", flags=0xbffff418) at Python/pythonrun.c:530 #9 0x080d09c6 in PyRun_AnyFileExFlags (fp=0x40491de0, filename=0x80fb12a "", closeit=0, flags=0xbffff418) at Python/pythonrun.c:493 #10 0x08055614 in Py_Main (argc=0, argv=0xbffff4a4) at Modules/main.c:446 #11 0x080551b9 in main (argc=1, argv=0xbffff4a4) at Modules/python.c:23 #12 0x403944a2 in __libc_start_main () from /lib/libc.so.6 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-04 09:38 Message: Logged In: YES user_id=21627 Fixed in _tkinter.c 1.144. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-02 17:21 Message: Logged In: YES user_id=21627 I didn't realize that doooneevent and mainloop are also methods on the module. For dooneevent, the check is actually bogus and can be removed. For mainloop, the problem is more serious; I'll investigate. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-02 16:42 Message: Logged In: YES user_id=33168 Martin, you added CHECK_TCL_APPARTMENT for threaded Tcl. Any ideas? I get the crash with Tk 8.3.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660961&group_id=5470 From noreply@sourceforge.net Sat Jan 4 10:32:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 04 Jan 2003 02:32:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-625728 ] sys.executable in applets Message-ID: Bugs item #625728, was opened at 2002-10-19 23:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625728&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: sys.executable in applets Initial Comment: In applets sys.executable is the interpreter in the applet. Running this will launch a second copy of the applet. As sys.executable is apparently often used to fire up external scripts with system() or popen() this isn't very useful right now (especially within the IDE!). It would be nice if sys.executable could be set to an interpreter that can be used for starting external scripts. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-01-04 11:32 Message: Logged In: YES user_id=92689 This becomes a non-issue once we build applets with bundlebuilder.py, as the "executable" in the applet is a shell script, and sys.executable will actually be the proper executable. For standalone apps built with bundlebuilder.py sys.executable points to the (still vanilla) interpreter that was copied to the bundle, and can be used as a normal interpreter without invoking bundle magic. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625728&group_id=5470 From noreply@sourceforge.net Sat Jan 4 12:00:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 04 Jan 2003 04:00:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-662099 ] urllib2 exceptions need improvement Message-ID: Bugs item #662099, was opened at 2003-01-04 13:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662099&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Viehmann (t-v) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 exceptions need improvement Initial Comment: Hi. Thanks for urllib2. Urllib2 would be even better if Exceptions were more unified, i.e. if there was way to test any URLException for common failure causes, regardless of the protocol. Example: 'File not found' can happen with http/ftp/gopher/... Cheers Thomas ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662099&group_id=5470 From noreply@sourceforge.net Sat Jan 4 14:05:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 04 Jan 2003 06:05:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-661357 ] tkFileDialog.SaveAs Message-ID: Bugs item #661357, was opened at 2003-01-02 17:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661357&group_id=5470 Category: Tkinter Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Martin v. Löwis (loewis) Summary: tkFileDialog.SaveAs Initial Comment: The SaveAs dialog gets a traceback due to the new object-style Tk interface. Run this test program: from Tkinter import * import tkFileDialog def doit(): savedialog = tkFileDialog.SaveAs(master=root) print savedialog.show(initialdir="/tmp", initialfile="foo.py") root = Tk() button = Button(root, text="Save...", command=doit) button.pack() mainloop() I get this traceback: Traceback (most recent call last): File "/usr/local/lib/python2.3/lib-tk/Tkinter.py", line 1306, in __call__ return apply(self.func, args) File "tkf.py", line 5, in doit print savedialog.show(initialdir="/tmp", initialfile="foo.py") File "/usr/local/lib/python2.3/lib-tk/tkCommonDialog.py", line 54, in show s = self._fixresult(w, s) File "/usr/local/lib/python2.3/lib-tk/tkFileDialog.py", line 58, in _fixresult path, file = os.path.split(result) File "/usr/local/lib/python2.3/posixpath.py", line 65, in split i = p.rfind('/') + 1 AttributeError: '_tkinter.Tcl_Obj' object has no attribute 'rfind' ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-04 09:05 Message: Logged In: YES user_id=6380 But that's not a new problem, is it? tkFileDialog has always worked that way. So I don't think it's a problem in practice. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-04 03:33 Message: Logged In: YES user_id=21627 On NT+, it is not a problem: tkFileDialog will return Unicode objects, which you can then pass to open(). The problem exists on Unix: If you have a file name with non-ASCII characters, tkFileDialog will still return a Unicode object, but you can't pass that to open, unless the file system default encoding was changed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-03 19:55 Message: Logged In: YES user_id=6380 I guess that's only an issue on Windows NT descendants? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 19:16 Message: Logged In: YES user_id=21627 This is fixed with _tkinter.c 1.142 tkFileDialog.py 1.9 To provide full backwards compatibility, neither str() nor unicode() are appropriate, as Tkinter traditionally returns byte strings for ASCII and Unicode strings otherwise. To support that behaviour, I added a .string attribute to Tcl_Objs, which is polymorphically either one or the other string type. For the other builtin Tcl types, this should not be an issue, as they will always have ASCII string representations. One potential advantage of path objects is that they keep internally both the Unicode representation and the "native" byte string representation. Python now only accesses the Unicode representation, which could cause problems as you might not be able to open the file afterwards (unless the Python file system encoding matches the Tcl file system encoding). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-03 17:14 Message: Logged In: YES user_id=6380 In order of preference, I like 3 the best, 1 fine, and 2 not at all. I don't know what properties Tcl path objects have that would be beneficial to Python, but I expect that they will relatively rarely be bounced right back to Tcl. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 13:54 Message: Logged In: YES user_id=21627 I see - it appears that the dialogs behave differently on Windows and X in this respect... I can see two alternative strategies: 1. Fix this specific problem, by converting the result of the dialog in _fixresult to string. 2. Enhance the Tk wrapper type, to support all string operations, by lazily converting itself to a string if a string method is requested. Then, .rfind would work on the path object. There is, in principle, a third alternative: 3. Convert path objects to Python strings, as Python does not have a separate path type. However, this somewhat defeats one purpose of using Tcl objects: If the path is passed back to Tcl, Tcl won't need to reparse it if it is still a path. Which of these would you recommend? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-03 10:24 Message: Logged In: YES user_id=6380 Python 2.3a1 (a tad post-release) Tcl/Tk 8.4 Mandrake Linux 8.1 I believe Linux kernel 2.2.17-21mdk The output from that snippet is /tmp/foo.py path ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 06:28 Message: Logged In: YES user_id=21627 Also, can you please try x=root.tk.call(("tk_getSaveFile","-initialdir","/tmp","-initialfile","foo.py")) print repr(x),str(x),x.typename I always get plain strings as a result of that call. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 05:56 Message: Logged In: YES user_id=21627 I can't reproduce this. What system and Tcl version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661357&group_id=5470 From noreply@sourceforge.net Sat Jan 4 20:19:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 04 Jan 2003 12:19:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-661357 ] tkFileDialog.SaveAs Message-ID: Bugs item #661357, was opened at 2003-01-02 23:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661357&group_id=5470 Category: Tkinter Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Martin v. Löwis (loewis) Summary: tkFileDialog.SaveAs Initial Comment: The SaveAs dialog gets a traceback due to the new object-style Tk interface. Run this test program: from Tkinter import * import tkFileDialog def doit(): savedialog = tkFileDialog.SaveAs(master=root) print savedialog.show(initialdir="/tmp", initialfile="foo.py") root = Tk() button = Button(root, text="Save...", command=doit) button.pack() mainloop() I get this traceback: Traceback (most recent call last): File "/usr/local/lib/python2.3/lib-tk/Tkinter.py", line 1306, in __call__ return apply(self.func, args) File "tkf.py", line 5, in doit print savedialog.show(initialdir="/tmp", initialfile="foo.py") File "/usr/local/lib/python2.3/lib-tk/tkCommonDialog.py", line 54, in show s = self._fixresult(w, s) File "/usr/local/lib/python2.3/lib-tk/tkFileDialog.py", line 58, in _fixresult path, file = os.path.split(result) File "/usr/local/lib/python2.3/posixpath.py", line 65, in split i = p.rfind('/') + 1 AttributeError: '_tkinter.Tcl_Obj' object has no attribute 'rfind' ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-04 21:19 Message: Logged In: YES user_id=21627 Right, this is not a new problem. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-04 15:05 Message: Logged In: YES user_id=6380 But that's not a new problem, is it? tkFileDialog has always worked that way. So I don't think it's a problem in practice. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-04 09:33 Message: Logged In: YES user_id=21627 On NT+, it is not a problem: tkFileDialog will return Unicode objects, which you can then pass to open(). The problem exists on Unix: If you have a file name with non-ASCII characters, tkFileDialog will still return a Unicode object, but you can't pass that to open, unless the file system default encoding was changed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-04 01:55 Message: Logged In: YES user_id=6380 I guess that's only an issue on Windows NT descendants? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-04 01:16 Message: Logged In: YES user_id=21627 This is fixed with _tkinter.c 1.142 tkFileDialog.py 1.9 To provide full backwards compatibility, neither str() nor unicode() are appropriate, as Tkinter traditionally returns byte strings for ASCII and Unicode strings otherwise. To support that behaviour, I added a .string attribute to Tcl_Objs, which is polymorphically either one or the other string type. For the other builtin Tcl types, this should not be an issue, as they will always have ASCII string representations. One potential advantage of path objects is that they keep internally both the Unicode representation and the "native" byte string representation. Python now only accesses the Unicode representation, which could cause problems as you might not be able to open the file afterwards (unless the Python file system encoding matches the Tcl file system encoding). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-03 23:14 Message: Logged In: YES user_id=6380 In order of preference, I like 3 the best, 1 fine, and 2 not at all. I don't know what properties Tcl path objects have that would be beneficial to Python, but I expect that they will relatively rarely be bounced right back to Tcl. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 19:54 Message: Logged In: YES user_id=21627 I see - it appears that the dialogs behave differently on Windows and X in this respect... I can see two alternative strategies: 1. Fix this specific problem, by converting the result of the dialog in _fixresult to string. 2. Enhance the Tk wrapper type, to support all string operations, by lazily converting itself to a string if a string method is requested. Then, .rfind would work on the path object. There is, in principle, a third alternative: 3. Convert path objects to Python strings, as Python does not have a separate path type. However, this somewhat defeats one purpose of using Tcl objects: If the path is passed back to Tcl, Tcl won't need to reparse it if it is still a path. Which of these would you recommend? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-03 16:24 Message: Logged In: YES user_id=6380 Python 2.3a1 (a tad post-release) Tcl/Tk 8.4 Mandrake Linux 8.1 I believe Linux kernel 2.2.17-21mdk The output from that snippet is /tmp/foo.py path ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 12:28 Message: Logged In: YES user_id=21627 Also, can you please try x=root.tk.call(("tk_getSaveFile","-initialdir","/tmp","-initialfile","foo.py")) print repr(x),str(x),x.typename I always get plain strings as a result of that call. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-03 11:56 Message: Logged In: YES user_id=21627 I can't reproduce this. What system and Tcl version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661357&group_id=5470 From noreply@sourceforge.net Sat Jan 4 20:19:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 04 Jan 2003 12:19:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-654558 ] make error reporting better like cgi Message-ID: Bugs item #654558, was opened at 2002-12-16 06:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654558&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Hunter Peress (hfastedge) Assigned to: Nobody/Anonymous (nobody) >Summary: make error reporting better like cgi Initial Comment: do something bad in something that uses cgitb, it will show you actual values of the variables at that point in the error message....and a host of useful info. I think this should be done normally as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654558&group_id=5470 From noreply@sourceforge.net Sat Jan 4 21:23:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 04 Jan 2003 13:23:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-625728 ] sys.executable in applets Message-ID: Bugs item #625728, was opened at 2002-10-19 23:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625728&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) >Assigned to: Just van Rossum (jvr) Summary: sys.executable in applets Initial Comment: In applets sys.executable is the interpreter in the applet. Running this will launch a second copy of the applet. As sys.executable is apparently often used to fire up external scripts with system() or popen() this isn't very useful right now (especially within the IDE!). It would be nice if sys.executable could be set to an interpreter that can be used for starting external scripts. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-01-04 22:23 Message: Logged In: YES user_id=45365 Agreed. I'm assigning it to you, then you can close the bug report once you've modified BuildApplet to use bundlebuilder in MacPython-OSX. :-) ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-04 11:32 Message: Logged In: YES user_id=92689 This becomes a non-issue once we build applets with bundlebuilder.py, as the "executable" in the applet is a shell script, and sys.executable will actually be the proper executable. For standalone apps built with bundlebuilder.py sys.executable points to the (still vanilla) interpreter that was copied to the bundle, and can be used as a normal interpreter without invoking bundle magic. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625728&group_id=5470 From noreply@sourceforge.net Sun Jan 5 00:32:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 04 Jan 2003 16:32:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-662099 ] urllib2 exceptions need improvement Message-ID: Bugs item #662099, was opened at 2003-01-04 07:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662099&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Viehmann (t-v) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 exceptions need improvement Initial Comment: Hi. Thanks for urllib2. Urllib2 would be even better if Exceptions were more unified, i.e. if there was way to test any URLException for common failure causes, regardless of the protocol. Example: 'File not found' can happen with http/ftp/gopher/... Cheers Thomas ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-04 19:32 Message: Logged In: YES user_id=33168 Perhaps I'm missing something, but I don't understand what you want. All the exceptions in urllib2 derive from URLError, which itself derives from IOError. There are a few cases where IOError is raised. All other cases raise URLError, HTTPError, or GopherError. Isn't IOError (or possibly URLError) what you are looking for? So you would do: try: # your code here except IOError: # handle any urllib2 exception ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662099&group_id=5470 From noreply@sourceforge.net Sun Jan 5 03:08:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 04 Jan 2003 19:08:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-660811 ] refman: importing x.y.z as m is possible, docs say otherwise Message-ID: Bugs item #660811, was opened at 2003-01-01 15:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660811&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hans Nowak (zephyrfalcon) Assigned to: Nobody/Anonymous (nobody) Summary: refman: importing x.y.z as m is possible, docs say otherwise Initial Comment: In the reference manual, the 'import' documentation (Doc/ref/import.html) claims: "To avoid confusion, you cannot import modules with dotted names as a different local name. So import module as m is legal, but import module.submod as s is not." This doesn't seem to be true (anymore?): [Python 2.2.2] >>> import xml.dom.minidom as m >>> m [Python 2.3] >>> import xml.dom.minidom as m >>> m ---------------------------------------------------------------------- Comment By: Christopher Blunck (blunck2) Date: 2003-01-04 22:08 Message: Logged In: YES user_id=531881 see patch 662454 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660811&group_id=5470 From noreply@sourceforge.net Sun Jan 5 04:11:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 04 Jan 2003 20:11:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-659188 ] no docs for HTMLParser.handle_pi Message-ID: Bugs item #659188, was opened at 2002-12-27 18:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659188&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Arild Fines (arildfines) Assigned to: Nobody/Anonymous (nobody) Summary: no docs for HTMLParser.handle_pi Initial Comment: The current documentation(2.2.2) has no documentation for the handle_pi(handle processing instruction) method in the HTMLParser.HTMLParser class. ---------------------------------------------------------------------- Comment By: Christopher Blunck (blunck2) Date: 2003-01-04 23:11 Message: Logged In: YES user_id=531881 see patch 662464 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659188&group_id=5470 From noreply@sourceforge.net Sun Jan 5 04:42:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 04 Jan 2003 20:42:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-211586 ] 1.6b1: PythonPath Message-ID: Bugs item #211586, was opened at 2000-08-10 11:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=211586&group_id=5470 Category: Windows Group: Platform-specific Status: Closed Resolution: Works For Me Priority: 7 Submitted By: Nobody/Anonymous (nobody) Assigned to: Mark Hammond (mhammond) Summary: 1.6b1: PythonPath Initial Comment: version: Python 1.6b1 os: Win2k i added an additional path to the PythonPath registry entry, but python ignores the additional path. (i used the windows installer, after deinstalling 1.5.2) ---------------------------------------------------------------------- Comment By: Miles D. Duke (milesduke) Date: 2003-01-04 23:42 Message: Logged In: YES user_id=680878 I'm not sure this is operator error. The same thing still happens for me using Python 2.2.2. I am running Windows Me. I set the python path using the PythonWin GUI first build 152, then build 150. If I browsed the python path in the pythonwin GUI I could see my modules, but Python would not acknowledge it. I uninstalled everything and stepped back to Python 1.5.1. I was able to modify the registry key and it worked. I could import modules in python. I then uninstalled 1.5.1, installed 2.2.2, and modified the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2 .2, which appeared to be the rright place, and then added HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2 .2.2, just in case. But starting a new version of the python command line, it still could not import my modules until I manually appended my directory to sys.path. (Another observation -- sys.path in python 1.5.1 had my custom directory in the middle, even though I had appended to the end of the registry value. sys.path seemed much shorter in python 2.2.2) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2000-08-25 19:15 Message: Can only assume operator error - I use this feature personally, win32all uses it, and ActivePython uses it. It works! ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2000-08-14 12:40 Message: i couldn't reproduce the problem with Windows ME (see also bug #111486). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=211586&group_id=5470 From noreply@sourceforge.net Sun Jan 5 04:45:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 04 Jan 2003 20:45:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-642391 ] tempfile.mktemp() for directories Message-ID: Bugs item #642391, was opened at 2002-11-22 11:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=642391&group_id=5470 Category: Documentation Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Thomas Guettler (guettli) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile.mktemp() for directories Initial Comment: Hi! It would help newbies if you write in the documentation of tempfile.mktemp() That this function can be used to create unique filenames *or directories*. Something like this: mktemp() can be used to create filenames which can me used to create temporary files or directories. I know this, you know it, but newbies don't. Thank you for python and it's documentation! thomas ---------------------------------------------------------------------- Comment By: Christopher Blunck (blunck2) Date: 2003-01-04 23:45 Message: Logged In: YES user_id=531881 see patch 662475 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=642391&group_id=5470 From noreply@sourceforge.net Sun Jan 5 05:08:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 04 Jan 2003 21:08:53 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-635144 ] New UniDiffer class Message-ID: Feature Requests item #635144, was opened at 2002-11-07 14:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=635144&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martijn Pieters (mjpieters) >Assigned to: Raymond Hettinger (rhettinger) Summary: New UniDiffer class Initial Comment: Attached is a new UniDiffer module, based on the difflib.Differ class, which outputs GNU diff unified context format compatible lines. The class includes doctest tests and is intended to be merged directly into the difflib module. Jim Fulton saiz this can be added to the Python Library under the current Python license. ---------------------------------------------------------------------- Comment By: Martijn Pieters (mjpieters) Date: 2002-11-08 14:14 Message: Logged In: YES user_id=116747 'Nother version. One bug fix, one new feature. - When two hunks were between 2 * context + 1 and 3* context lines aparart, the starting context for the second hunk would be partially lost. - Handle missing newline on the last line like GNU diff does. This currently only supports UNIX-style lineendings. Documentation reflects this. ---------------------------------------------------------------------- Comment By: Martijn Pieters (mjpieters) Date: 2002-11-08 11:18 Message: Logged In: YES user_id=116747 And another little bug found: if set a is empty and set b is not, resulting in all added lines, an empty diff would be returned. Attached latest version fixes this. ---------------------------------------------------------------------- Comment By: Martijn Pieters (mjpieters) Date: 2002-11-07 16:34 Message: Logged In: YES user_id=116747 Another update: when there were more than [context] lines in between two updates, but less than 2 * [context], the two chunks should not be split. This version fixes that problem; we look ahead an extra [context] lines before cutting the chunk. Also, timestamps in headers are now show the seconds fraction as well, just like GNU diff. ---------------------------------------------------------------------- Comment By: Martijn Pieters (mjpieters) Date: 2002-11-07 15:00 Message: Logged In: YES user_id=116747 New version attached, fixing a context bug. There was a small bug in the previous version where, if context was set to 0, the all lines until the end of the last chunk were shown. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=635144&group_id=5470 From noreply@sourceforge.net Sun Jan 5 11:16:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 05 Jan 2003 03:16:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-662099 ] urllib2 exceptions need improvement Message-ID: Bugs item #662099, was opened at 2003-01-04 13:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662099&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Viehmann (t-v) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 exceptions need improvement Initial Comment: Hi. Thanks for urllib2. Urllib2 would be even better if Exceptions were more unified, i.e. if there was way to test any URLException for common failure causes, regardless of the protocol. Example: 'File not found' can happen with http/ftp/gopher/... Cheers Thomas ---------------------------------------------------------------------- >Comment By: Thomas Viehmann (t-v) Date: 2003-01-05 12:16 Message: Logged In: YES user_id=680463 Maybe I was unclear (and maybe it's possible already to do what I want but I'm just to blind to see it). So here is what I want: Attempt one: I'd something like a HTTP status code returned for all protocols, with the library making up the appropriate ones as necessary, if there is none. (So that I can test a gopher-URLError for "e.code==404" Attempt two: When trying to retrieve an URL, I'd like to have a method to detect "Not found", so I would like the following code fragment, which (modulo mistakes introduced in copying this from my code) works with http, to work with gopher (someday ftp or rsync?) as well. try: f = urllib2.open(anurl) except urllib2.URLError,e: if e.code == 404: print "Not found" ... # e.g. try alternative location else: print "Something more serious...." raise e Does this make it more clear? Similar to urllib/urllib2 providing common method to retrieve data for multiple protocols, there should be way to be able to identify errors that are not protocol-specific. (And the letter I did not find.) Thanks Thomas ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 01:32 Message: Logged In: YES user_id=33168 Perhaps I'm missing something, but I don't understand what you want. All the exceptions in urllib2 derive from URLError, which itself derives from IOError. There are a few cases where IOError is raised. All other cases raise URLError, HTTPError, or GopherError. Isn't IOError (or possibly URLError) what you are looking for? So you would do: try: # your code here except IOError: # handle any urllib2 exception ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662099&group_id=5470 From noreply@sourceforge.net Sun Jan 5 11:18:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 05 Jan 2003 03:18:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-662099 ] urllib2 exceptions need improvement Message-ID: Bugs item #662099, was opened at 2003-01-04 13:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662099&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Viehmann (t-v) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 exceptions need improvement Initial Comment: Hi. Thanks for urllib2. Urllib2 would be even better if Exceptions were more unified, i.e. if there was way to test any URLException for common failure causes, regardless of the protocol. Example: 'File not found' can happen with http/ftp/gopher/... Cheers Thomas ---------------------------------------------------------------------- >Comment By: Thomas Viehmann (t-v) Date: 2003-01-05 12:18 Message: Logged In: YES user_id=680463 It should be the latter, not the letter, in the previous followup. ---------------------------------------------------------------------- Comment By: Thomas Viehmann (t-v) Date: 2003-01-05 12:16 Message: Logged In: YES user_id=680463 Maybe I was unclear (and maybe it's possible already to do what I want but I'm just to blind to see it). So here is what I want: Attempt one: I'd something like a HTTP status code returned for all protocols, with the library making up the appropriate ones as necessary, if there is none. (So that I can test a gopher-URLError for "e.code==404" Attempt two: When trying to retrieve an URL, I'd like to have a method to detect "Not found", so I would like the following code fragment, which (modulo mistakes introduced in copying this from my code) works with http, to work with gopher (someday ftp or rsync?) as well. try: f = urllib2.open(anurl) except urllib2.URLError,e: if e.code == 404: print "Not found" ... # e.g. try alternative location else: print "Something more serious...." raise e Does this make it more clear? Similar to urllib/urllib2 providing common method to retrieve data for multiple protocols, there should be way to be able to identify errors that are not protocol-specific. (And the letter I did not find.) Thanks Thomas ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 01:32 Message: Logged In: YES user_id=33168 Perhaps I'm missing something, but I don't understand what you want. All the exceptions in urllib2 derive from URLError, which itself derives from IOError. There are a few cases where IOError is raised. All other cases raise URLError, HTTPError, or GopherError. Isn't IOError (or possibly URLError) what you are looking for? So you would do: try: # your code here except IOError: # handle any urllib2 exception ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662099&group_id=5470 From noreply@sourceforge.net Sun Jan 5 11:25:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 05 Jan 2003 03:25:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-661330 ] test_pep263 fails in MacPython-OS9 Message-ID: Bugs item #661330, was opened at 2003-01-02 23:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661330&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 8 Submitted By: Jack Jansen (jackjansen) >Assigned to: Jack Jansen (jackjansen) Summary: test_pep263 fails in MacPython-OS9 Initial Comment: Martin, test_pep263 fails in MacPython-OS9. I think this is because the file is actually a binary file but it is checked in as a text file. Because it is checked in as a text file the funny characters (which I assume are in the funny charset that the test tries to test, right?) go through a Latin-1 to MacRoman conversion, which breaks them rather thoroughly. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-02 23:17 Message: Logged In: YES user_id=21627 Actually, changing it to binary seems to be the right thing anyway, so I have done that. Can you please report whether this fixes the problem? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-02 23:11 Message: Logged In: YES user_id=21627 Would it help to check it in as a binary file? It would then have Unix line endings, if I check it in... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661330&group_id=5470 From noreply@sourceforge.net Sun Jan 5 17:10:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 05 Jan 2003 09:10:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-662701 ] sys.version[:3] gives incorrect version Message-ID: Bugs item #662701, was opened at 2003-01-05 19:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662701&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pearu Peterson (pearu) Assigned to: Nobody/Anonymous (nobody) Summary: sys.version[:3] gives incorrect version Initial Comment: sys.version[:3] is used in several places [*] for Python version and in most cases it is OK. However, when Python is build/installed, say, with make all install VERSION=2.2.2 then sys.version[:3] does not represent Python version correctly anymore. For example, the path to Python Lib is then /lib/python2.2.2/ but e.g. distutils finds it as /lib/python2.2/ which obviously causes either an exception or a silent incorrect behaviour [**] when trying to use distutils. Note about fix: I don't have it but simply replacing sys.version[:3] with sys.version.split()[0] will not work. Best regards, Pearu [*] Running grep "sys.version\[:3\]" {*,*/*,*/*/*}.py in the Python Lib tree shows 8 matches for Python 2.2.2. [**] .. e.g. when one has other Python installed with VERSION=2.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662701&group_id=5470 From noreply@sourceforge.net Sun Jan 5 19:59:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 05 Jan 2003 11:59:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-662787 ] test_signal hang on some Solaris boxes Message-ID: Bugs item #662787, was opened at 2003-01-05 14:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Martin v. Löwis (loewis) Summary: test_signal hang on some Solaris boxes Initial Comment: Martin, I'm assigning this to you because you checked in the patch which caused this problem. I think your input on fixes will also be valuable. When semaphore support was added to Python/thread_pthread.h in 2.39 originally from patch 525532, it broke tests on some Solaris boxes. I know this affects Solaris 8, not sure if any other versions are affected. I believe on or more of the following Solaris 8 patches (108528, 108827) fixes the problem: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108528&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108827&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on Patches can be gotten from here: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access One way to fix the hang is to add #undef USE_SEMAPHORES at line 113 of Python/thread_pthread.h (ie, after USE_SEMAPHORES may be set). I don't know of any other way to fix this problem. I don't know if we can test for this in configure and set USE_SEMAPHORES appropriately (or if it's worth it). We can always disable USE_SEMAPHORES and allow the user to use it by manually setting the macro. We keep the code as is, and document the problem. Suggestions? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 From noreply@sourceforge.net Sun Jan 5 20:25:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 05 Jan 2003 12:25:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-412436 ] compileall doesn't notice syntax errors Message-ID: Bugs item #412436, was opened at 2001-03-30 05:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=412436&group_id=5470 Category: Python Library Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeremy Hylton (jhylton) Summary: compileall doesn't notice syntax errors Initial Comment: compileall.py returns an exit code to indicate the success or failure of compilation. This feature was added in compileall.py revision 1.7 in response to distutils message http://mail.python.org/pipermail/distutils-sig/1999-March/000201.html This is not as useful as it looks because a prior change to py_compile.py (revision 1.13) catches syntax errors, hiding them completely from compileall.py, so compileall.py can't report the failure to its caller. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 15:25 Message: Logged In: YES user_id=33168 I definitely think Just's change to py_compile.py (return 0 or 1 from compile()) should be checked in. This doesn't hurt and is backwards compatible. I think a NEWS entry and doc updates (Doc/lib/libpycompile.tex) should be done as well. The change to compileall.py is also probably ok, but I didn't look as closely (the patch failed to apply for me in 2.3). ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-03 07:29 Message: Logged In: YES user_id=92689 Reopening this bug as it's entirely unclear why the py_compile.py change wasn't checked in. This has resulted in a new bug, #653301. I've attached a patch that's updated for current CVS (rev. 1.23 of py_compile.py). Since py_compile.py is crucial to the install process I'd rather have someone else make the decision to check this in or not. ---------------------------------------------------------------------- Comment By: Peter Maxwell (pm67nz) Date: 2001-09-09 23:31 Message: Logged In: YES user_id=320286 I don't see how this can be fixed in compileall.py since the problem is with py_compile.py. py_compile.compile (up to and including the latest version I see in CVS, revision 1.18) only ever returns None, so the code in compileall.py revision 1.19 that says: ok = py_compile.compile(fullname, None, dfile) and if ok == 0: can't possibly work. Caveat: this comment based on reading code, not running it. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-04-17 21:23 Message: Logged In: YES user_id=31392 Fixed in rev 1.9 of compileall.py. Note that this fix causes a bunch of changes to the test suite, so that files containing syntaxerrors are not compiled by compileall. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-04-13 17:16 Message: Logged In: YES user_id=31392 Will fix following the 2.1 release ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-04-13 10:31 Message: Logged In: YES user_id=31392 I think this is easy enough to fix, but I don't know what unintended side-effects the fix will have. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=412436&group_id=5470 From noreply@sourceforge.net Sun Jan 5 20:38:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 05 Jan 2003 12:38:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-662787 ] test_signal hang on some Solaris boxes Message-ID: Bugs item #662787, was opened at 2003-01-05 14:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Martin v. Löwis (loewis) Summary: test_signal hang on some Solaris boxes Initial Comment: Martin, I'm assigning this to you because you checked in the patch which caused this problem. I think your input on fixes will also be valuable. When semaphore support was added to Python/thread_pthread.h in 2.39 originally from patch 525532, it broke tests on some Solaris boxes. I know this affects Solaris 8, not sure if any other versions are affected. I believe on or more of the following Solaris 8 patches (108528, 108827) fixes the problem: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108528&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108827&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on Patches can be gotten from here: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access One way to fix the hang is to add #undef USE_SEMAPHORES at line 113 of Python/thread_pthread.h (ie, after USE_SEMAPHORES may be set). I don't know of any other way to fix this problem. I don't know if we can test for this in configure and set USE_SEMAPHORES appropriately (or if it's worth it). We can always disable USE_SEMAPHORES and allow the user to use it by manually setting the macro. We keep the code as is, and document the problem. Suggestions? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 15:38 Message: Logged In: YES user_id=33168 Attaching output of truss (like strace for Solaris) which doesn't provide me with any more info. Hopefully this will help someone else. 2 files attached, one with complete output from; truss ./python -E -tt ./Lib/test/regrtest.py test_queue test_signal the other is just the end. It should correspond to these lines from the test: signal.alarm(20) # Entire test lasts at most 20 sec. signal.signal(5, handlerA) signal.signal(2, handlerB) signal.signal(3, signal.SIG_IGN) signal.signal(signal.SIGALRM, signal.default_int_handler) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 From noreply@sourceforge.net Sun Jan 5 20:54:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 05 Jan 2003 12:54:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-467924 ] Improve the ZipFile Interface Message-ID: Bugs item #467924, was opened at 2001-10-04 17:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=467924&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Improve the ZipFile Interface Initial Comment: There exist two methods to write to a ZipFile write(self, filename, arcname=None, compress_type=None) writestr(self, zinfo, bytes) but only one to read from it read(self, name) Additionally, the two 'write's behave differently with respect to compression. --- (a) 'read' does not fit to 'write', since 'write' takes a file and adds it to a ZipFile, but 'read' is not the reverse operation. 'read' should be called 'readstr' since it much better matches to 'writestr'. (b) It is confusing what 'write' and 'read' actually mean. Does 'write' write a file, or into the ZipFile? It would be more obvious if ZipFile has 4 methods which pair-wise fit together: writestr (self, zinfo, bytes) # same as now readstr (self, name) # returns bytes (as string), currently called 'read' # 'read' could still live but should be deprecated add (self, filename, arcname=None, compress_type=None) # currently 'write' # 'write' could still live but should be deprecated extract (self, name, filename, arcname=None) # new, desired functionality (c) BOTH, 'writestr' and 'add' should by default use the 'compress_type' that was passed to the constructor of 'ZipFile'. Currently, 'write' does it, 'writestr' via zinfo does it not. 'ZipInfo' sets the compression strict to 'ZIP_STORED' :-( It should not do that! It rather should: - allow more parameters in the signature of the constructor to also pass the compression type (and some other attributes, too) - default to 'None', so that 'writestr' can see this, and then take the default from the 'ZipFile' instance. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-01-05 21:54 Message: Logged In: YES user_id=92689 In Python 2.3, writestr() has an enhanced signature: the first arg may now also be an archive name, in which case the correct default settings are used (ie. the compression value is taken from the file). See patch #651621. extract() could be moderately useful (although I don't understand the 'arcname' arg, how's that different from 'name'?) but would have to deal with file modes (bin/text). The file mode isn't in the archive so would have to (optionally) be supplied by the caller. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=467924&group_id=5470 From noreply@sourceforge.net Sun Jan 5 20:57:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 05 Jan 2003 12:57:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-662787 ] test_signal hang on some Solaris boxes Message-ID: Bugs item #662787, was opened at 2003-01-05 14:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Martin v. Löwis (loewis) Summary: test_signal hang on some Solaris boxes Initial Comment: Martin, I'm assigning this to you because you checked in the patch which caused this problem. I think your input on fixes will also be valuable. When semaphore support was added to Python/thread_pthread.h in 2.39 originally from patch 525532, it broke tests on some Solaris boxes. I know this affects Solaris 8, not sure if any other versions are affected. I believe on or more of the following Solaris 8 patches (108528, 108827) fixes the problem: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108528&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108827&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on Patches can be gotten from here: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access One way to fix the hang is to add #undef USE_SEMAPHORES at line 113 of Python/thread_pthread.h (ie, after USE_SEMAPHORES may be set). I don't know of any other way to fix this problem. I don't know if we can test for this in configure and set USE_SEMAPHORES appropriately (or if it's worth it). We can always disable USE_SEMAPHORES and allow the user to use it by manually setting the macro. We keep the code as is, and document the problem. Suggestions? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 15:57 Message: Logged In: YES user_id=33168 For (possibly) more info, see: http://lists.lysator.liu.se/pipermail/snake-farm/2003-January/000617.html ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 15:38 Message: Logged In: YES user_id=33168 Attaching output of truss (like strace for Solaris) which doesn't provide me with any more info. Hopefully this will help someone else. 2 files attached, one with complete output from; truss ./python -E -tt ./Lib/test/regrtest.py test_queue test_signal the other is just the end. It should correspond to these lines from the test: signal.alarm(20) # Entire test lasts at most 20 sec. signal.signal(5, handlerA) signal.signal(2, handlerB) signal.signal(3, signal.SIG_IGN) signal.signal(signal.SIGALRM, signal.default_int_handler) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 From noreply@sourceforge.net Sun Jan 5 21:01:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 05 Jan 2003 13:01:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-412436 ] compileall doesn't notice syntax errors Message-ID: Bugs item #412436, was opened at 2001-03-30 12:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=412436&group_id=5470 Category: Python Library Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeremy Hylton (jhylton) Summary: compileall doesn't notice syntax errors Initial Comment: compileall.py returns an exit code to indicate the success or failure of compilation. This feature was added in compileall.py revision 1.7 in response to distutils message http://mail.python.org/pipermail/distutils-sig/1999-March/000201.html This is not as useful as it looks because a prior change to py_compile.py (revision 1.13) catches syntax errors, hiding them completely from compileall.py, so compileall.py can't report the failure to its caller. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-01-05 22:01 Message: Logged In: YES user_id=92689 The change to compileall.py has been in CVS for a long time. The strange thing is that the accompanying py_compile.py patch wasn't checked in. All I did was update that change for current CVS. Jeremy? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 21:25 Message: Logged In: YES user_id=33168 I definitely think Just's change to py_compile.py (return 0 or 1 from compile()) should be checked in. This doesn't hurt and is backwards compatible. I think a NEWS entry and doc updates (Doc/lib/libpycompile.tex) should be done as well. The change to compileall.py is also probably ok, but I didn't look as closely (the patch failed to apply for me in 2.3). ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-03 13:29 Message: Logged In: YES user_id=92689 Reopening this bug as it's entirely unclear why the py_compile.py change wasn't checked in. This has resulted in a new bug, #653301. I've attached a patch that's updated for current CVS (rev. 1.23 of py_compile.py). Since py_compile.py is crucial to the install process I'd rather have someone else make the decision to check this in or not. ---------------------------------------------------------------------- Comment By: Peter Maxwell (pm67nz) Date: 2001-09-10 05:31 Message: Logged In: YES user_id=320286 I don't see how this can be fixed in compileall.py since the problem is with py_compile.py. py_compile.compile (up to and including the latest version I see in CVS, revision 1.18) only ever returns None, so the code in compileall.py revision 1.19 that says: ok = py_compile.compile(fullname, None, dfile) and if ok == 0: can't possibly work. Caveat: this comment based on reading code, not running it. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-04-18 03:23 Message: Logged In: YES user_id=31392 Fixed in rev 1.9 of compileall.py. Note that this fix causes a bunch of changes to the test suite, so that files containing syntaxerrors are not compiled by compileall. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-04-13 23:16 Message: Logged In: YES user_id=31392 Will fix following the 2.1 release ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-04-13 16:31 Message: Logged In: YES user_id=31392 I think this is easy enough to fix, but I don't know what unintended side-effects the fix will have. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=412436&group_id=5470 From noreply@sourceforge.net Sun Jan 5 21:25:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 05 Jan 2003 13:25:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-645594 ] for lin in file: file.tell() tells wrong Message-ID: Bugs item #645594, was opened at 2002-11-29 10:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=645594&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: for lin in file: file.tell() tells wrong Initial Comment: Consider following piece of code: f = file("test.txt", "rb") pos = f.tell() for line in f: print "%u: '%s'" % (pos, line) pos = f.tell() During the code execution we have following result: 0 'Line 1' 63 'Line 2' 63 'Line 3' ... 63 'Line 9' However, following piece of code works fine: f = file("test.txt", "rb") while True: pos = f.tell() line = f.readline() if line == "": break print "%u: '%s'" % (pos, line) It prints: 0 'Line 1' 7 'Line 2' 14 'Line 3' ... 56 'Line 9' It seems a file iterator makes file.tell() to tell positions of some internal blocks used by the iterator. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-01-05 22:25 Message: Logged In: YES user_id=92689 This bug is very similar to #524804, which was closed as "won't fix". Unless it's recategorized as a documentation bug, I suggest to close this one as a duplicate. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2002-12-04 12:24 Message: Logged In: YES user_id=388573 File.next() uses readahead buffer (8192 bytes for now). Calling file.seek() drops the buffer, but other operations don't. I think it's possible for file.tell() to return right result (I'll try to make a patch). But all these quirks should be documented. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-11-29 23:07 Message: Logged In: YES user_id=45365 Actually, all file operations behave the same (well, all: I tried one: readline():-): they behave as if the whole file has been read. I.e. file.readline() within a "for line in file" will return an empty string. If a file iterator behaves as if it has read the complete file at once on instantiation (never mind what it actually does: if it *behaves* as if this happens) I think this should just be documented and that's it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-29 17:57 Message: Logged In: YES user_id=31435 Possibly. Maybe something fancier could be done too, to give "expected" results. although I don't know how to approach that on Windows for text-mode files (byte arithmetic on seek/tell results doesn't work at all for those). I'd take it to Python-Dev. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-29 17:01 Message: Logged In: YES user_id=21627 Shouldn't tell raise an exception then? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-29 16:42 Message: Logged In: YES user_id=31435 "for x in file" does do its own chunking under the covers, for speed, and seek() and tell() are indeed not to be used on a file being iterated over in this way. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2002-11-29 15:46 Message: Logged In: YES user_id=388573 I'll try to dig in. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-29 15:30 Message: Logged In: YES user_id=21627 Would you like to investigate this further? There is no need to, but if you find a solution and a patch, there is a better chance that this is fixed before 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=645594&group_id=5470 From noreply@sourceforge.net Sun Jan 5 21:28:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 05 Jan 2003 13:28:10 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-662827 ] optional pad character for zfill and center Message-ID: Feature Requests item #662827, was opened at 2003-01-05 21:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=662827&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: optional pad character for zfill and center Initial Comment: >>> 'padme'.zfill(10, '*') '*****padme' >>> 'padme'.center(10, '*') '**padme***' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=662827&group_id=5470 From noreply@sourceforge.net Sun Jan 5 21:40:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 05 Jan 2003 13:40:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-661330 ] test_pep263 fails in MacPython-OS9 Message-ID: Bugs item #661330, was opened at 2003-01-02 23:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661330&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: test_pep263 fails in MacPython-OS9 Initial Comment: Martin, test_pep263 fails in MacPython-OS9. I think this is because the file is actually a binary file but it is checked in as a text file. Because it is checked in as a text file the funny characters (which I assume are in the funny charset that the test tries to test, right?) go through a Latin-1 to MacRoman conversion, which breaks them rather thoroughly. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-01-05 22:40 Message: Logged In: YES user_id=45365 Yes, that fixed it. Thanks! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-02 23:17 Message: Logged In: YES user_id=21627 Actually, changing it to binary seems to be the right thing anyway, so I have done that. Can you please report whether this fixes the problem? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-02 23:11 Message: Logged In: YES user_id=21627 Would it help to check it in as a binary file? It would then have Unix line endings, if I check it in... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661330&group_id=5470 From noreply@sourceforge.net Sun Jan 5 22:03:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 05 Jan 2003 14:03:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-638703 ] optparse module undocumented Message-ID: Bugs item #638703, was opened at 2002-11-14 17:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=638703&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: optparse module undocumented Initial Comment: Some volunteer needs to document the optparse module. The text files from optik may supply a good source for material for the LaTeX version of the docs. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 17:03 Message: Logged In: YES user_id=33168 Fred, I tested the patch, the doc builds ok with it. It looked very extensive, but I briefly looked it over. Would you like me to check it in? BTW, do the datetime docs build for you? They don't for me. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-01 17:39 Message: Logged In: YES user_id=33168 There is a patch here: http://python.org/sf/642236 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-22 09:45 Message: Logged In: YES user_id=33168 Note: patch available at http://python.org/sf/642236 ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2002-11-19 02:42 Message: Logged In: YES user_id=469548 I'm working on this. I'll probably mostly use the text files in the Optik package, but I'll add a true reference section, based on the output of pydoc.help(optparse). I'll have to write some more docstrings into the optparse module to make this useful, however. Please note that I'm new to LaTeX, so it may take some time for me to learn it and then convert the text files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=638703&group_id=5470 From noreply@sourceforge.net Sun Jan 5 22:03:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 05 Jan 2003 14:03:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-662840 ] configure script fails with wchat_t size. Message-ID: Bugs item #662840, was opened at 2003-01-05 22:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662840&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nadav Horesh (nadavhoresh) Assigned to: Nobody/Anonymous (nobody) Summary: configure script fails with wchat_t size. Initial Comment: Python version 2.3a1 System RH 7.3 Compiler: gcc 3.2.1 The configure script bails out when trying to determain the size of wchar_t. The configure runs OK with gcc 2.96. . . . checking wchar.h usability... yes checking wchar.h presence... yes checking for wchar.h... yes checking for wchar_t... yes checking size of wchar_t... configure: error: cannot compute sizeof (wchar_t), 77 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662840&group_id=5470 From noreply@sourceforge.net Sun Jan 5 22:08:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 05 Jan 2003 14:08:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-625725 ] Reorganize MacPython resources on OSX Message-ID: Bugs item #625725, was opened at 2002-10-19 23:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625725&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Reorganize MacPython resources on OSX Initial Comment: The resource file for Python on OSX should be reorganized. Some of the resources are only used by specific modules such as EasyDialogs, these should go into private resource files. Some are used by the interpreter itself (The "Estr" resource that maps error numbers to strings comes to mind). The most obvious place for these would be the resource file of the framework, but these may also be useful in non-framework builds (where you now get the uninformative 'MacOS.Error: Error -1234'). ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-01-05 23:08 Message: Logged In: YES user_id=92689 The Estr resource: is this resource generated, and if so how? Would it be an idea to generate a Python module instead? The macresource module also has issues: eg. for EasyDialogs it looks for "dialogs.rsrc" in os.path.dirname(EasyDialogs.__file__), which doesn't work when EasyDialogs is loaded from a zip file. If it would (additionally) look on sys.path it could work for standalone apps created by bundlebuilder: it should simply be included in .app/Contents/Resources/ then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625725&group_id=5470 From noreply@sourceforge.net Sun Jan 5 23:11:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 05 Jan 2003 15:11:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-662787 ] test_signal hang on some Solaris boxes Message-ID: Bugs item #662787, was opened at 2003-01-05 20:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Martin v. Löwis (loewis) Summary: test_signal hang on some Solaris boxes Initial Comment: Martin, I'm assigning this to you because you checked in the patch which caused this problem. I think your input on fixes will also be valuable. When semaphore support was added to Python/thread_pthread.h in 2.39 originally from patch 525532, it broke tests on some Solaris boxes. I know this affects Solaris 8, not sure if any other versions are affected. I believe on or more of the following Solaris 8 patches (108528, 108827) fixes the problem: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108528&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108827&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on Patches can be gotten from here: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access One way to fix the hang is to add #undef USE_SEMAPHORES at line 113 of Python/thread_pthread.h (ie, after USE_SEMAPHORES may be set). I don't know of any other way to fix this problem. I don't know if we can test for this in configure and set USE_SEMAPHORES appropriately (or if it's worth it). We can always disable USE_SEMAPHORES and allow the user to use it by manually setting the macro. We keep the code as is, and document the problem. Suggestions? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 00:11 Message: Logged In: YES user_id=21627 Could you identify a revision of these patches for which the problem disappears? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 21:57 Message: Logged In: YES user_id=33168 For (possibly) more info, see: http://lists.lysator.liu.se/pipermail/snake-farm/2003-January/000617.html ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 21:38 Message: Logged In: YES user_id=33168 Attaching output of truss (like strace for Solaris) which doesn't provide me with any more info. Hopefully this will help someone else. 2 files attached, one with complete output from; truss ./python -E -tt ./Lib/test/regrtest.py test_queue test_signal the other is just the end. It should correspond to these lines from the test: signal.alarm(20) # Entire test lasts at most 20 sec. signal.signal(5, handlerA) signal.signal(2, handlerB) signal.signal(3, signal.SIG_IGN) signal.signal(signal.SIGALRM, signal.default_int_handler) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 From noreply@sourceforge.net Sun Jan 5 23:12:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 05 Jan 2003 15:12:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-662840 ] configure script fails with wchat_t size. Message-ID: Bugs item #662840, was opened at 2003-01-05 23:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662840&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nadav Horesh (nadavhoresh) Assigned to: Nobody/Anonymous (nobody) Summary: configure script fails with wchat_t size. Initial Comment: Python version 2.3a1 System RH 7.3 Compiler: gcc 3.2.1 The configure script bails out when trying to determain the size of wchar_t. The configure runs OK with gcc 2.96. . . . checking wchar.h usability... yes checking wchar.h presence... yes checking for wchar.h... yes checking for wchar_t... yes checking size of wchar_t... configure: error: cannot compute sizeof (wchar_t), 77 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 00:12 Message: Logged In: YES user_id=21627 Can you please attach the resulting config.log? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662840&group_id=5470 From noreply@sourceforge.net Sun Jan 5 23:14:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 05 Jan 2003 15:14:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-662701 ] sys.version[:3] gives incorrect version Message-ID: Bugs item #662701, was opened at 2003-01-05 18:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662701&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pearu Peterson (pearu) Assigned to: Nobody/Anonymous (nobody) Summary: sys.version[:3] gives incorrect version Initial Comment: sys.version[:3] is used in several places [*] for Python version and in most cases it is OK. However, when Python is build/installed, say, with make all install VERSION=2.2.2 then sys.version[:3] does not represent Python version correctly anymore. For example, the path to Python Lib is then /lib/python2.2.2/ but e.g. distutils finds it as /lib/python2.2/ which obviously causes either an exception or a silent incorrect behaviour [**] when trying to use distutils. Note about fix: I don't have it but simply replacing sys.version[:3] with sys.version.split()[0] will not work. Best regards, Pearu [*] Running grep "sys.version\[:3\]" {*,*/*,*/*/*}.py in the Python Lib tree shows 8 matches for Python 2.2.2. [**] .. e.g. when one has other Python installed with VERSION=2.2 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 00:14 Message: Logged In: YES user_id=21627 I would suggest that 'make all install VERSION=2.2.2' is not supported, so this does not need to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662701&group_id=5470 From noreply@sourceforge.net Sun Jan 5 23:38:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 05 Jan 2003 15:38:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-662787 ] test_signal hang on some Solaris boxes Message-ID: Bugs item #662787, was opened at 2003-01-05 14:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Martin v. Löwis (loewis) Summary: test_signal hang on some Solaris boxes Initial Comment: Martin, I'm assigning this to you because you checked in the patch which caused this problem. I think your input on fixes will also be valuable. When semaphore support was added to Python/thread_pthread.h in 2.39 originally from patch 525532, it broke tests on some Solaris boxes. I know this affects Solaris 8, not sure if any other versions are affected. I believe on or more of the following Solaris 8 patches (108528, 108827) fixes the problem: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108528&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108827&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on Patches can be gotten from here: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access One way to fix the hang is to add #undef USE_SEMAPHORES at line 113 of Python/thread_pthread.h (ie, after USE_SEMAPHORES may be set). I don't know of any other way to fix this problem. I don't know if we can test for this in configure and set USE_SEMAPHORES appropriately (or if it's worth it). We can always disable USE_SEMAPHORES and allow the user to use it by manually setting the macro. We keep the code as is, and document the problem. Suggestions? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 18:38 Message: Logged In: YES user_id=33168 What do you mean by revision of the patches? CVS revision of thread_pthread.h? I believe 2.38 worked and 2.39 broke. I can test that if you'd like. Do you want me to go back to the revision before the patch for all files affected? Since 2.39 only added the semaphores, in essence, by doing the #undef that should have the same effect as reverting thread_pthread.h to 2.38. Or are you talking about the Solaris patches? If so, they are only a guess, we could compare the patch level on all the Solaris boxes we have access to and see which ones work and which don't. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-05 18:11 Message: Logged In: YES user_id=21627 Could you identify a revision of these patches for which the problem disappears? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 15:57 Message: Logged In: YES user_id=33168 For (possibly) more info, see: http://lists.lysator.liu.se/pipermail/snake-farm/2003-January/000617.html ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 15:38 Message: Logged In: YES user_id=33168 Attaching output of truss (like strace for Solaris) which doesn't provide me with any more info. Hopefully this will help someone else. 2 files attached, one with complete output from; truss ./python -E -tt ./Lib/test/regrtest.py test_queue test_signal the other is just the end. It should correspond to these lines from the test: signal.alarm(20) # Entire test lasts at most 20 sec. signal.signal(5, handlerA) signal.signal(2, handlerB) signal.signal(3, signal.SIG_IGN) signal.signal(signal.SIGALRM, signal.default_int_handler) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 From noreply@sourceforge.net Sun Jan 5 23:40:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 05 Jan 2003 15:40:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-662701 ] sys.version[:3] gives incorrect version Message-ID: Bugs item #662701, was opened at 2003-01-05 19:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662701&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pearu Peterson (pearu) Assigned to: Nobody/Anonymous (nobody) Summary: sys.version[:3] gives incorrect version Initial Comment: sys.version[:3] is used in several places [*] for Python version and in most cases it is OK. However, when Python is build/installed, say, with make all install VERSION=2.2.2 then sys.version[:3] does not represent Python version correctly anymore. For example, the path to Python Lib is then /lib/python2.2.2/ but e.g. distutils finds it as /lib/python2.2/ which obviously causes either an exception or a silent incorrect behaviour [**] when trying to use distutils. Note about fix: I don't have it but simply replacing sys.version[:3] with sys.version.split()[0] will not work. Best regards, Pearu [*] Running grep "sys.version\[:3\]" {*,*/*,*/*/*}.py in the Python Lib tree shows 8 matches for Python 2.2.2. [**] .. e.g. when one has other Python installed with VERSION=2.2 ---------------------------------------------------------------------- >Comment By: Pearu Peterson (pearu) Date: 2003-01-06 01:40 Message: Logged In: YES user_id=88489 A note: according to Python README Installation section, make make altinstall VERSION=2.2.2 is "legal". From reading the generated Makefile, the above seems to be identical to 'make all install VERSION=2.2.2', but I haven't actually tried it out, though, so I might be wrong. If fixing this issue is too difficult, that's fine with me. One can always use --prefix= as a workaround when configuring Python. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 01:14 Message: Logged In: YES user_id=21627 I would suggest that 'make all install VERSION=2.2.2' is not supported, so this does not need to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662701&group_id=5470 From noreply@sourceforge.net Mon Jan 6 02:34:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 05 Jan 2003 18:34:29 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-662923 ] iterator for dbm keys Message-ID: Feature Requests item #662923, was opened at 2003-01-06 02:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=662923&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: iterator for dbm keys Initial Comment: if d is a dbm (gdbm, bsddb, shelve, etc.) object, then "for k in d" should iterate through the keys of d, like you can do with dicts. Alternatively, add a new operation, d.xkeys(), which returns an iterator that steps through all the keys in d. d.keys() is often inappropriate since dbm databases can be extremely large and d.keys() tries to read all the keys into memory at once. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=662923&group_id=5470 From noreply@sourceforge.net Mon Jan 6 06:59:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 05 Jan 2003 22:59:52 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-618024 ] urlparse fails on imap:// Message-ID: Feature Requests item #618024, was opened at 2002-10-03 07:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=618024&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Asle Pedersen (apederse) Assigned to: Neal Norwitz (nnorwitz) Summary: urlparse fails on imap:// Initial Comment: urlparse does not parse imap:// urls (RFC 2192). I am not all sure but this seem to be an appropriate patch: urlparse.uses_relative.append('imap') urlparse.uses_netloc.append('imap') urlparse.non_hierarchical.append('imap') urlparse.uses_params.append('imap') urlparse.uses_query.append('imap') ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-06 01:59 Message: Logged In: YES user_id=33168 Checked in as: * Lib/urlparse.py 1.36 * Lib/test/test_urlparse.py 1.10 * Misc/NEWS 1.603 ---------------------------------------------------------------------- Comment By: Piers Lauder (pierslauder) Date: 2002-11-22 01:05 Message: Logged In: YES user_id=196212 Just to reiterate - this change is fine by me, so please make the suggested changes to the urlparse module's classification schemes. ---------------------------------------------------------------------- Comment By: Piers Lauder (pierslauder) Date: 2002-11-05 05:44 Message: Logged In: YES user_id=196212 I've never tried to use the imap URL form, and I'm unaware of which IETF RFC documents its allowable syntax. Seems ok, but why not "urlparse.uses_fragment.append('imap')" as well? (Searching google...) This looks like the document that defines it: http://ftp.ics.uci.edu/pub/ietf/uri/rfc2192.txt "IMAP URL Scheme" No mention of '#', so I guess no fragments :-) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-04 20:30 Message: Logged In: YES user_id=33168 Piers, is this right? If so, I can make the change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=618024&group_id=5470 From noreply@sourceforge.net Mon Jan 6 09:54:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 01:54:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-662701 ] sys.version[:3] gives incorrect version Message-ID: Bugs item #662701, was opened at 2003-01-05 18:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662701&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pearu Peterson (pearu) Assigned to: Nobody/Anonymous (nobody) Summary: sys.version[:3] gives incorrect version Initial Comment: sys.version[:3] is used in several places [*] for Python version and in most cases it is OK. However, when Python is build/installed, say, with make all install VERSION=2.2.2 then sys.version[:3] does not represent Python version correctly anymore. For example, the path to Python Lib is then /lib/python2.2.2/ but e.g. distutils finds it as /lib/python2.2/ which obviously causes either an exception or a silent incorrect behaviour [**] when trying to use distutils. Note about fix: I don't have it but simply replacing sys.version[:3] with sys.version.split()[0] will not work. Best regards, Pearu [*] Running grep "sys.version\[:3\]" {*,*/*,*/*/*}.py in the Python Lib tree shows 8 matches for Python 2.2.2. [**] .. e.g. when one has other Python installed with VERSION=2.2 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 10:54 Message: Logged In: YES user_id=21627 I see. What you have been doing is indeed documented as supported. Unfortunately, there is currently no way in which distutils could find out what VERSION is. So if this is intended to work, we need to expose VERSION somewhere. ---------------------------------------------------------------------- Comment By: Pearu Peterson (pearu) Date: 2003-01-06 00:40 Message: Logged In: YES user_id=88489 A note: according to Python README Installation section, make make altinstall VERSION=2.2.2 is "legal". From reading the generated Makefile, the above seems to be identical to 'make all install VERSION=2.2.2', but I haven't actually tried it out, though, so I might be wrong. If fixing this issue is too difficult, that's fine with me. One can always use --prefix= as a workaround when configuring Python. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 00:14 Message: Logged In: YES user_id=21627 I would suggest that 'make all install VERSION=2.2.2' is not supported, so this does not need to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662701&group_id=5470 From noreply@sourceforge.net Mon Jan 6 11:02:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 03:02:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-625725 ] Reorganize MacPython resources on OSX Message-ID: Bugs item #625725, was opened at 2002-10-19 23:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625725&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) >Assigned to: Just van Rossum (jvr) Summary: Reorganize MacPython resources on OSX Initial Comment: The resource file for Python on OSX should be reorganized. Some of the resources are only used by specific modules such as EasyDialogs, these should go into private resource files. Some are used by the interpreter itself (The "Estr" resource that maps error numbers to strings comes to mind). The most obvious place for these would be the resource file of the framework, but these may also be useful in non-framework builds (where you now get the uninformative 'MacOS.Error: Error -1234'). ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-01-06 12:02 Message: Logged In: YES user_id=45365 Okay with me, as long as you look on sys.path *after* checking the __file__. So the order would be 1) Check wheter it happens to be available already 2) Check whether __file__ gives a clue 3) check sys.path An alternative solution would be that bundlebuilder takes the .rsrc file for each module automatically and combines them all (including errors.rsrc)into the resource file that is automatically opened when the .app starts (I think it's .rsrc, check the apple docs). A Python module in stead of the Estr resource I'm not too thrilled about: there are a lot of error messages, and if it was a Python module then they would all be in-core once you import the module. I'm assigning this over to you, close it when you're done (the rest of the reorganization is finished). ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-05 23:08 Message: Logged In: YES user_id=92689 The Estr resource: is this resource generated, and if so how? Would it be an idea to generate a Python module instead? The macresource module also has issues: eg. for EasyDialogs it looks for "dialogs.rsrc" in os.path.dirname(EasyDialogs.__file__), which doesn't work when EasyDialogs is loaded from a zip file. If it would (additionally) look on sys.path it could work for standalone apps created by bundlebuilder: it should simply be included in .app/Contents/Resources/ then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625725&group_id=5470 From noreply@sourceforge.net Mon Jan 6 11:24:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 03:24:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-625725 ] Reorganize MacPython resources on OSX Message-ID: Bugs item #625725, was opened at 2002-10-19 23:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625725&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: Reorganize MacPython resources on OSX Initial Comment: The resource file for Python on OSX should be reorganized. Some of the resources are only used by specific modules such as EasyDialogs, these should go into private resource files. Some are used by the interpreter itself (The "Estr" resource that maps error numbers to strings comes to mind). The most obvious place for these would be the resource file of the framework, but these may also be useful in non-framework builds (where you now get the uninformative 'MacOS.Error: Error -1234'). ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-01-06 12:24 Message: Logged In: YES user_id=92689 Ok, I checked in a change to macresource.py to this effect (it simply adds sys.path to searchdirs, after os.path.dirname(__file__). Apart from Estr, how about trying to use nibs instead of res files? I think this is meant to work for OS9 as well, but would require interfacing some *FromNib API's in Carbon.Win and Carbon.Dlg. Just a thought. Either way, we should use a strict naming convention, eg. EasyDialogs.py's resources should be in a file called EasyDialogs.rsrc (and/or EasyDialogs.nib if we take the above route). ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-01-06 12:02 Message: Logged In: YES user_id=45365 Okay with me, as long as you look on sys.path *after* checking the __file__. So the order would be 1) Check wheter it happens to be available already 2) Check whether __file__ gives a clue 3) check sys.path An alternative solution would be that bundlebuilder takes the .rsrc file for each module automatically and combines them all (including errors.rsrc)into the resource file that is automatically opened when the .app starts (I think it's .rsrc, check the apple docs). A Python module in stead of the Estr resource I'm not too thrilled about: there are a lot of error messages, and if it was a Python module then they would all be in-core once you import the module. I'm assigning this over to you, close it when you're done (the rest of the reorganization is finished). ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-05 23:08 Message: Logged In: YES user_id=92689 The Estr resource: is this resource generated, and if so how? Would it be an idea to generate a Python module instead? The macresource module also has issues: eg. for EasyDialogs it looks for "dialogs.rsrc" in os.path.dirname(EasyDialogs.__file__), which doesn't work when EasyDialogs is loaded from a zip file. If it would (additionally) look on sys.path it could work for standalone apps created by bundlebuilder: it should simply be included in .app/Contents/Resources/ then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625725&group_id=5470 From noreply@sourceforge.net Mon Jan 6 11:33:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 03:33:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-625725 ] Reorganize MacPython resources on OSX Message-ID: Bugs item #625725, was opened at 2002-10-19 23:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625725&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: Reorganize MacPython resources on OSX Initial Comment: The resource file for Python on OSX should be reorganized. Some of the resources are only used by specific modules such as EasyDialogs, these should go into private resource files. Some are used by the interpreter itself (The "Estr" resource that maps error numbers to strings comes to mind). The most obvious place for these would be the resource file of the framework, but these may also be useful in non-framework builds (where you now get the uninformative 'MacOS.Error: Error -1234'). ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-01-06 12:33 Message: Logged In: YES user_id=92689 Wait, there already is Carbon.IBCarbon, cool! Shall I try to find out what it takes to convert EasyDialogs to use it? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-06 12:24 Message: Logged In: YES user_id=92689 Ok, I checked in a change to macresource.py to this effect (it simply adds sys.path to searchdirs, after os.path.dirname(__file__). Apart from Estr, how about trying to use nibs instead of res files? I think this is meant to work for OS9 as well, but would require interfacing some *FromNib API's in Carbon.Win and Carbon.Dlg. Just a thought. Either way, we should use a strict naming convention, eg. EasyDialogs.py's resources should be in a file called EasyDialogs.rsrc (and/or EasyDialogs.nib if we take the above route). ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-01-06 12:02 Message: Logged In: YES user_id=45365 Okay with me, as long as you look on sys.path *after* checking the __file__. So the order would be 1) Check wheter it happens to be available already 2) Check whether __file__ gives a clue 3) check sys.path An alternative solution would be that bundlebuilder takes the .rsrc file for each module automatically and combines them all (including errors.rsrc)into the resource file that is automatically opened when the .app starts (I think it's .rsrc, check the apple docs). A Python module in stead of the Estr resource I'm not too thrilled about: there are a lot of error messages, and if it was a Python module then they would all be in-core once you import the module. I'm assigning this over to you, close it when you're done (the rest of the reorganization is finished). ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-05 23:08 Message: Logged In: YES user_id=92689 The Estr resource: is this resource generated, and if so how? Would it be an idea to generate a Python module instead? The macresource module also has issues: eg. for EasyDialogs it looks for "dialogs.rsrc" in os.path.dirname(EasyDialogs.__file__), which doesn't work when EasyDialogs is loaded from a zip file. If it would (additionally) look on sys.path it could work for standalone apps created by bundlebuilder: it should simply be included in .app/Contents/Resources/ then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625725&group_id=5470 From noreply@sourceforge.net Mon Jan 6 12:04:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 04:04:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-625725 ] Reorganize MacPython resources on OSX Message-ID: Bugs item #625725, was opened at 2002-10-19 23:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625725&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: Reorganize MacPython resources on OSX Initial Comment: The resource file for Python on OSX should be reorganized. Some of the resources are only used by specific modules such as EasyDialogs, these should go into private resource files. Some are used by the interpreter itself (The "Estr" resource that maps error numbers to strings comes to mind). The most obvious place for these would be the resource file of the framework, but these may also be useful in non-framework builds (where you now get the uninformative 'MacOS.Error: Error -1234'). ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-01-06 13:04 Message: Logged In: YES user_id=45365 Yes, if you want to put some effort into this: please do! ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-06 12:33 Message: Logged In: YES user_id=92689 Wait, there already is Carbon.IBCarbon, cool! Shall I try to find out what it takes to convert EasyDialogs to use it? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-06 12:24 Message: Logged In: YES user_id=92689 Ok, I checked in a change to macresource.py to this effect (it simply adds sys.path to searchdirs, after os.path.dirname(__file__). Apart from Estr, how about trying to use nibs instead of res files? I think this is meant to work for OS9 as well, but would require interfacing some *FromNib API's in Carbon.Win and Carbon.Dlg. Just a thought. Either way, we should use a strict naming convention, eg. EasyDialogs.py's resources should be in a file called EasyDialogs.rsrc (and/or EasyDialogs.nib if we take the above route). ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-01-06 12:02 Message: Logged In: YES user_id=45365 Okay with me, as long as you look on sys.path *after* checking the __file__. So the order would be 1) Check wheter it happens to be available already 2) Check whether __file__ gives a clue 3) check sys.path An alternative solution would be that bundlebuilder takes the .rsrc file for each module automatically and combines them all (including errors.rsrc)into the resource file that is automatically opened when the .app starts (I think it's .rsrc, check the apple docs). A Python module in stead of the Estr resource I'm not too thrilled about: there are a lot of error messages, and if it was a Python module then they would all be in-core once you import the module. I'm assigning this over to you, close it when you're done (the rest of the reorganization is finished). ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-05 23:08 Message: Logged In: YES user_id=92689 The Estr resource: is this resource generated, and if so how? Would it be an idea to generate a Python module instead? The macresource module also has issues: eg. for EasyDialogs it looks for "dialogs.rsrc" in os.path.dirname(EasyDialogs.__file__), which doesn't work when EasyDialogs is loaded from a zip file. If it would (additionally) look on sys.path it could work for standalone apps created by bundlebuilder: it should simply be included in .app/Contents/Resources/ then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625725&group_id=5470 From noreply@sourceforge.net Mon Jan 6 12:13:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 04:13:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-662787 ] test_signal hang on some Solaris boxes Message-ID: Bugs item #662787, was opened at 2003-01-05 20:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Martin v. Löwis (loewis) Summary: test_signal hang on some Solaris boxes Initial Comment: Martin, I'm assigning this to you because you checked in the patch which caused this problem. I think your input on fixes will also be valuable. When semaphore support was added to Python/thread_pthread.h in 2.39 originally from patch 525532, it broke tests on some Solaris boxes. I know this affects Solaris 8, not sure if any other versions are affected. I believe on or more of the following Solaris 8 patches (108528, 108827) fixes the problem: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108528&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108827&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on Patches can be gotten from here: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access One way to fix the hang is to add #undef USE_SEMAPHORES at line 113 of Python/thread_pthread.h (ie, after USE_SEMAPHORES may be set). I don't know of any other way to fix this problem. I don't know if we can test for this in configure and set USE_SEMAPHORES appropriately (or if it's worth it). We can always disable USE_SEMAPHORES and allow the user to use it by manually setting the macro. We keep the code as is, and document the problem. Suggestions? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 13:13 Message: Logged In: YES user_id=21627 I meant revisions of the Sun patches. On one system, I have 108528-16 and 108827-34, and test_signal still hangs. I found that the blocking occurs when test_queue.py is run before, and have distilled this into the following example: import sys import thread import time import signal fsema = thread.allocate_lock() def tfunc(): time.sleep(.1) fsema.release() fsema.acquire() thread.start_new_thread(tfunc,()) fsema.acquire() fsema.release() signal.alarm(3) signal.pause() It appears that the alarm is simply lost; the pause call does not return. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-06 00:38 Message: Logged In: YES user_id=33168 What do you mean by revision of the patches? CVS revision of thread_pthread.h? I believe 2.38 worked and 2.39 broke. I can test that if you'd like. Do you want me to go back to the revision before the patch for all files affected? Since 2.39 only added the semaphores, in essence, by doing the #undef that should have the same effect as reverting thread_pthread.h to 2.38. Or are you talking about the Solaris patches? If so, they are only a guess, we could compare the patch level on all the Solaris boxes we have access to and see which ones work and which don't. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 00:11 Message: Logged In: YES user_id=21627 Could you identify a revision of these patches for which the problem disappears? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 21:57 Message: Logged In: YES user_id=33168 For (possibly) more info, see: http://lists.lysator.liu.se/pipermail/snake-farm/2003-January/000617.html ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 21:38 Message: Logged In: YES user_id=33168 Attaching output of truss (like strace for Solaris) which doesn't provide me with any more info. Hopefully this will help someone else. 2 files attached, one with complete output from; truss ./python -E -tt ./Lib/test/regrtest.py test_queue test_signal the other is just the end. It should correspond to these lines from the test: signal.alarm(20) # Entire test lasts at most 20 sec. signal.signal(5, handlerA) signal.signal(2, handlerB) signal.signal(3, signal.SIG_IGN) signal.signal(signal.SIGALRM, signal.default_int_handler) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 From noreply@sourceforge.net Mon Jan 6 12:17:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 04:17:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-663074 ] codec registry and Python embedding problem Message-ID: Bugs item #663074, was opened at 2003-01-06 13:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663074&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: M.-A. Lemburg (lemburg) Summary: codec registry and Python embedding problem Initial Comment: Found by Hartmut Ring: #include int main() { for (int i=0; i<2; i++) { Py_Initialize(); PyRun_SimpleString("a = u'\xe4'.encode('Latin-1')"); Py_Finalize(); } return 0; } First try runs fine, second try gives: Traceback (most recent call last): File "", line 1, in ? LookupError: no codec search functions registered: can't find encoding ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663074&group_id=5470 From noreply@sourceforge.net Mon Jan 6 12:18:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 04:18:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-663074 ] codec registry and Python embedding problem Message-ID: Bugs item #663074, was opened at 2003-01-06 13:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663074&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: M.-A. Lemburg (lemburg) Summary: codec registry and Python embedding problem Initial Comment: Found by Hartmut Ring: #include int main() { for (int i=0; i<2; i++) { Py_Initialize(); PyRun_SimpleString("a = u'\xe4'.encode('Latin-1')"); Py_Finalize(); } return 0; } First try runs fine, second try gives: Traceback (most recent call last): File "", line 1, in ? LookupError: no codec search functions registered: can't find encoding ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-06 13:18 Message: Logged In: YES user_id=38388 This is due to a flag used in codecs.c: /* Flag used for lazy import of the standard encodings package */ static int import_encodings_called = 0; The solution is to reset this flag in Py_Finalize(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663074&group_id=5470 From noreply@sourceforge.net Mon Jan 6 12:29:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 04:29:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-662787 ] test_signal hang on some Solaris boxes Message-ID: Bugs item #662787, was opened at 2003-01-05 20:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Martin v. Löwis (loewis) Summary: test_signal hang on some Solaris boxes Initial Comment: Martin, I'm assigning this to you because you checked in the patch which caused this problem. I think your input on fixes will also be valuable. When semaphore support was added to Python/thread_pthread.h in 2.39 originally from patch 525532, it broke tests on some Solaris boxes. I know this affects Solaris 8, not sure if any other versions are affected. I believe on or more of the following Solaris 8 patches (108528, 108827) fixes the problem: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108528&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108827&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on Patches can be gotten from here: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access One way to fix the hang is to add #undef USE_SEMAPHORES at line 113 of Python/thread_pthread.h (ie, after USE_SEMAPHORES may be set). I don't know of any other way to fix this problem. I don't know if we can test for this in configure and set USE_SEMAPHORES appropriately (or if it's worth it). We can always disable USE_SEMAPHORES and allow the user to use it by manually setting the macro. We keep the code as is, and document the problem. Suggestions? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 13:29 Message: Logged In: YES user_id=21627 It would be good to find a system that has 108528-17 installed. I see that this fixes 4498831 system timer stops sending signals ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 13:13 Message: Logged In: YES user_id=21627 I meant revisions of the Sun patches. On one system, I have 108528-16 and 108827-34, and test_signal still hangs. I found that the blocking occurs when test_queue.py is run before, and have distilled this into the following example: import sys import thread import time import signal fsema = thread.allocate_lock() def tfunc(): time.sleep(.1) fsema.release() fsema.acquire() thread.start_new_thread(tfunc,()) fsema.acquire() fsema.release() signal.alarm(3) signal.pause() It appears that the alarm is simply lost; the pause call does not return. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-06 00:38 Message: Logged In: YES user_id=33168 What do you mean by revision of the patches? CVS revision of thread_pthread.h? I believe 2.38 worked and 2.39 broke. I can test that if you'd like. Do you want me to go back to the revision before the patch for all files affected? Since 2.39 only added the semaphores, in essence, by doing the #undef that should have the same effect as reverting thread_pthread.h to 2.38. Or are you talking about the Solaris patches? If so, they are only a guess, we could compare the patch level on all the Solaris boxes we have access to and see which ones work and which don't. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 00:11 Message: Logged In: YES user_id=21627 Could you identify a revision of these patches for which the problem disappears? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 21:57 Message: Logged In: YES user_id=33168 For (possibly) more info, see: http://lists.lysator.liu.se/pipermail/snake-farm/2003-January/000617.html ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 21:38 Message: Logged In: YES user_id=33168 Attaching output of truss (like strace for Solaris) which doesn't provide me with any more info. Hopefully this will help someone else. 2 files attached, one with complete output from; truss ./python -E -tt ./Lib/test/regrtest.py test_queue test_signal the other is just the end. It should correspond to these lines from the test: signal.alarm(20) # Entire test lasts at most 20 sec. signal.signal(5, handlerA) signal.signal(2, handlerB) signal.signal(3, signal.SIG_IGN) signal.signal(signal.SIGALRM, signal.default_int_handler) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 From noreply@sourceforge.net Mon Jan 6 12:57:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 04:57:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-661848 ] Add clarification of __all__ to refman? Message-ID: Bugs item #661848, was opened at 2003-01-03 15:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661848&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Raymond Hettinger (rhettinger) Summary: Add clarification of __all__ to refman? Initial Comment: It might be a good idea to add a clarification of the intended use of __all__ to the reference manual. On the pyobjc mailing list it was suggested to use it as a means to make "from objc import *" export the most commonly used functionality to your namespace. After discussing this on python-dev Guido proclaimed that this isn't the intended use: "__all__ should contain the entire public API. It's mostly intended to avoid accidentally exporting other things you've *imported* like os, sys, and other library modules." ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-06 07:57 Message: Logged In: YES user_id=80475 Fixed. See Doc/ref/ref6.tex 1.59 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661848&group_id=5470 From noreply@sourceforge.net Mon Jan 6 12:57:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 04:57:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-631055 ] __all__ as determiner of a module's api Message-ID: Bugs item #631055, was opened at 2002-10-30 09:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=631055&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Patrick K. O'Brien (pobrien) Assigned to: Raymond Hettinger (rhettinger) Summary: __all__ as determiner of a module's api Initial Comment: __all__ as a determiner of a module's api needs to be more fully documented. The only references I found were at http://www.python.org/doc/current/ref/import.html and http://www.python.org/doc/essays/packages.html. I also think the various uses of __all__ might be worthy of a small PEP, since I can't find any supporting documentation for the use of __all__ as anything more than controlling import *, which to me is not exactly the same thing as defining the public api for a module. It could be, and if it is meant to be then tools, such as IDLE, Boa, PythonWin and PyCrust should take __all__ into account when displaying autocompletion lists for modules. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-06 07:57 Message: Logged In: YES user_id=80475 Fixed. See Doc/ref/ref6.tex 1.59 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=631055&group_id=5470 From noreply@sourceforge.net Mon Jan 6 13:10:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 05:10:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-629756 ] FAIL: test_crlf_separation (email.test.t Message-ID: Bugs item #629756, was opened at 2002-10-28 11:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629756&group_id=5470 Category: Windows Group: Platform-specific >Status: Open Resolution: Invalid Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Barry A. Warsaw (bwarsaw) Summary: FAIL: test_crlf_separation (email.test.t Initial Comment: just because text file on windows has CR/LF as endline maker and this test expects LF as eol. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-01-06 14:10 Message: Logged In: YES user_id=45365 Barry, I'm opening this one again, because on the Macintosh I still have one more problem with test_crlf_separation. The change you made in the repository (mark the file as binary) was half the fix, but I needed to do another thing as well: open the test file in binary mode. On Windows and Unix you can open the file in text mode (for Windows there's no problem at all, for Unix there will be '\r' at the end of each line, but that is handled), but not so on the mac ('\r\n' in the file will be converted to '\n\r' upon reading, which results in \r at the beginning of each line). I checked in a fix for this (test_email.py, rev. 1.28.2.1), let me know whether you agree with this, then I'll check it in on the trunk too. ---------------------------------------------------------------------- Comment By: Grzegorz Makarewicz (makaron) Date: 2003-01-02 12:29 Message: Logged In: YES user_id=115179 :( - after unpacking python on linux and copying all files with ordinary copy this test still fails for me (Info zip works fine on windows, gifs and other binary files are uncompressed correctly). Can you run attached file on your windows ? It is stripped down test_crlf_separation which uses StringIO, binary and text open mode. When using text mode as in mentioned test msg.get_payload will return data terminated with \n - but it is tested for \r\n. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-30 20:26 Message: Logged In: YES user_id=12800 It looks like you built this from source on Windows. If you unzip'd the source without turning off any dumb CRLF munging in your zip program, the test file will not be correct and this test will fail. Tim assures me that this test succeeds in Python 2.2 and 2.3a1 and I trust him with my lunch. ---------------------------------------------------------------------- Comment By: Grzegorz Makarewicz (makaron) Date: 2002-10-29 12:28 Message: Logged In: YES user_id=115179 Python 2.2.2 from October 14, 2002, compiled from source on windows 2000 all expected test are passed but not test_email. reproducable by: pushd Lib\test ..\..\python regrtest.py popd -- or cd Lib\test ..\..\python test_email.py traceback: FAILED (failures=1) Traceback (most recent call last): File "test_email.py", line 13, in ? test_main() File "test_email.py", line 10, in test_main run_suite(suite()) File "c:\binw\py222\lib\test\test_support.py", line 175, in run_suite raise TestFailed(err) test_support.TestFailed: Traceback (most recent call last): File "c:\binw\py222\lib\email\test\test_email.py", line 1851, in test_crlf_sep aration eq(part1.get_payload(), 'Simple email with attachment.\r\n\r\n') File "c:\binw\py222\lib\unittest.py", line 286, in failUnlessEqual raise self.failureException, \ AssertionError: 'Simple email with attachment.\n\n' != 'Simple email with attach ment.\r\n\r\n' after applying this patch thist test will pass --- test_email.py Mon Oct 14 17:26:03 2002 +++ test_email.py.new Tue Oct 29 11:25:54 2002 @@ -46,7 +46,7 @@ def openfile(filename): path = os.path.join(os.path.dirname(landmark), 'data', filename) - return open(path, 'r') + return open(path, 'rb') ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-10-28 16:33 Message: Logged In: YES user_id=31435 Assigned to Barry. Grzegorz, please supply more detail, such as which version of Python you're using, and the commands you used to run this test. As the name of the test should imply ("test_crlf_....), the test *expects* CR/LF -- that's it's point. It passes for me under 2.2.2 and current CVS Python, under Win98SE and Win2K. It may not have passed in 2.2.1, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629756&group_id=5470 From noreply@sourceforge.net Mon Jan 6 13:33:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 05:33:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-592859 ] os.chmod is underdocumented :-) Message-ID: Bugs item #592859, was opened at 2002-08-08 17:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592859&group_id=5470 Category: Documentation Group: Python 2.2.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Bjorn Pettersen (bpettersen) Assigned to: Raymond Hettinger (rhettinger) Summary: os.chmod is underdocumented :-) Initial Comment: Currently it says: "Change the mode of path to the numeric mode." I spent some time trying to figure out what mode should be on Windows before I looked in MSDN and did a grep over the Python Lib. Could we add: "Constants defined for the numeric mode parameter are defined in the stat module. E.g. to make a file writable: os.chmod(filename, S_IWUSR|S_IWGRP|S_IWOTH) or simply os.chmod(filename, S_IWRITE) on Windows. " It would probably be a good idea to list the names for the permission bits in the stat docs also... -- bjorn ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-06 08:33 Message: Logged In: YES user_id=80475 Fixed. See Doc/lib/libos.tex 1.108 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2002-08-08 20:44 Message: Logged In: YES user_id=80475 I agree that the current docs are as clear as mud. Will draft a clarification. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=592859&group_id=5470 From noreply@sourceforge.net Mon Jan 6 13:44:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 05:44:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-662787 ] test_signal hang on some Solaris boxes Message-ID: Bugs item #662787, was opened at 2003-01-05 14:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Martin v. Löwis (loewis) Summary: test_signal hang on some Solaris boxes Initial Comment: Martin, I'm assigning this to you because you checked in the patch which caused this problem. I think your input on fixes will also be valuable. When semaphore support was added to Python/thread_pthread.h in 2.39 originally from patch 525532, it broke tests on some Solaris boxes. I know this affects Solaris 8, not sure if any other versions are affected. I believe on or more of the following Solaris 8 patches (108528, 108827) fixes the problem: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108528&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108827&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on Patches can be gotten from here: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access One way to fix the hang is to add #undef USE_SEMAPHORES at line 113 of Python/thread_pthread.h (ie, after USE_SEMAPHORES may be set). I don't know of any other way to fix this problem. I don't know if we can test for this in configure and set USE_SEMAPHORES appropriately (or if it's worth it). We can always disable USE_SEMAPHORES and allow the user to use it by manually setting the macro. We keep the code as is, and document the problem. Suggestions? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-06 08:44 Message: Logged In: YES user_id=33168 I thought I could not duplicate the hang on our sun, but now it's happening. Your test program also hangs. How do you determine the revision of a patch on solaris? I'm using showrev -p | grep patch-#. I'm not sure that is correct. The way I read it, it says I have 108528-16 and 108827-12. In the snake farm proton has: 108528-12 and 108827-12 fafner has: 108528-13 and 108827-19 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 07:29 Message: Logged In: YES user_id=21627 It would be good to find a system that has 108528-17 installed. I see that this fixes 4498831 system timer stops sending signals ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 07:13 Message: Logged In: YES user_id=21627 I meant revisions of the Sun patches. On one system, I have 108528-16 and 108827-34, and test_signal still hangs. I found that the blocking occurs when test_queue.py is run before, and have distilled this into the following example: import sys import thread import time import signal fsema = thread.allocate_lock() def tfunc(): time.sleep(.1) fsema.release() fsema.acquire() thread.start_new_thread(tfunc,()) fsema.acquire() fsema.release() signal.alarm(3) signal.pause() It appears that the alarm is simply lost; the pause call does not return. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 18:38 Message: Logged In: YES user_id=33168 What do you mean by revision of the patches? CVS revision of thread_pthread.h? I believe 2.38 worked and 2.39 broke. I can test that if you'd like. Do you want me to go back to the revision before the patch for all files affected? Since 2.39 only added the semaphores, in essence, by doing the #undef that should have the same effect as reverting thread_pthread.h to 2.38. Or are you talking about the Solaris patches? If so, they are only a guess, we could compare the patch level on all the Solaris boxes we have access to and see which ones work and which don't. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-05 18:11 Message: Logged In: YES user_id=21627 Could you identify a revision of these patches for which the problem disappears? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 15:57 Message: Logged In: YES user_id=33168 For (possibly) more info, see: http://lists.lysator.liu.se/pipermail/snake-farm/2003-January/000617.html ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 15:38 Message: Logged In: YES user_id=33168 Attaching output of truss (like strace for Solaris) which doesn't provide me with any more info. Hopefully this will help someone else. 2 files attached, one with complete output from; truss ./python -E -tt ./Lib/test/regrtest.py test_queue test_signal the other is just the end. It should correspond to these lines from the test: signal.alarm(20) # Entire test lasts at most 20 sec. signal.signal(5, handlerA) signal.signal(2, handlerB) signal.signal(3, signal.SIG_IGN) signal.signal(signal.SIGALRM, signal.default_int_handler) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 From noreply@sourceforge.net Mon Jan 6 13:46:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 05:46:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-602627 ] pydoc -g dumps core on Solaris 2.8 Message-ID: Bugs item #602627, was opened at 2002-08-30 16:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602627&group_id=5470 Category: Demos and Tools Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc -g dumps core on Solaris 2.8 Initial Comment: Python 2.2.1, Solaris 2.8, gcc 3.2, binutils 2.12.1 When I execute "pydoc -g", it pops up a dialog box saying "Starting server" and "Search for", and then dumps core before I have time to type anything. The same problem happens on Solaris 2.7 The traceback: Core was generated by `/usr/gnu/bin/python /usr/gnu/bin/pydoc -g'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libsocket.so.1...done. Loaded symbols for /usr/lib/libsocket.so.1 Reading symbols from /usr/lib/libnsl.so.1...done. Loaded symbols for /usr/lib/libnsl.so.1 Reading symbols from /usr/lib/libdl.so.1...done. Loaded symbols for /usr/lib/libdl.so.1 Reading symbols from /usr/lib/libpthread.so.1...done. Loaded symbols for /usr/lib/libpthread.so.1 Reading symbols from /usr/lib/libthread.so.1...done. Loaded symbols for /usr/lib/libthread.so.1 Reading symbols from /usr/gnu/lib/libreadline.so.4...done. Loaded symbols for /usr/gnu/lib/libreadline.so.4 Reading symbols from /usr/lib/libcurses.so.1...done. Loaded symbols for /usr/lib/libcurses.so.1 Reading symbols from /usr/lib/libcrypt_i.so.1...done. Loaded symbols for /usr/lib/libcrypt_i.so.1 Reading symbols from /usr/gnu/lib/libtk8.3.so...done. Loaded symbols for /usr/gnu/lib/libtk8.3.so Reading symbols from /usr/gnu/lib/libtcl8.3.so...done. Loaded symbols for /usr/gnu/lib/libtcl8.3.so Reading symbols from /usr/lib/libX11.so.4...done. Loaded symbols for /usr/lib/libX11.so.4 Reading symbols from /usr/lib/libm.so.1...done. Loaded symbols for /usr/lib/libm.so.1 Reading symbols from /usr/lib/libc.so.1...done. Loaded symbols for /usr/lib/libc.so.1 Reading symbols from /usr/gnu/lib/libgcc_s.so.1...done. Loaded symbols for /usr/gnu/lib/libgcc_s.so.1 Reading symbols from /usr/lib/libmp.so.2...done. Loaded symbols for /usr/lib/libmp.so.2 Reading symbols from /usr/lib/libgen.so.1...done. Loaded symbols for /usr/lib/libgen.so.1 Reading symbols from /usr/openwin/lib/libXext.so.0...done. Loaded symbols for /usr/openwin/lib/libXext.so.0 Reading symbols from /usr/openwin/lib/libdga.so.1...done. Loaded symbols for /usr/openwin/lib/libdga.so.1 Reading symbols from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1...done. Loaded symbols for /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1 Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/strop.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/strop.so Reading symbols from /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2...done. Loaded symbols for /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2 Reading symbols from /usr/openwin/lib/locale/common/xlibi18n.so.2...done. Loaded symbols for /usr/openwin/lib/locale/common/xlibi18n.so.2 Reading symbols from /usr/openwin/lib/locale/common/ximlocal.so.2...done. Loaded symbols for /usr/openwin/lib/locale/common/ximlocal.so.2 Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/time.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/time.so Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/errno.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/errno.so Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/_socket.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/_socket.so Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/select.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/select.so #0 0xff0b2be0 in Tk_FreeGC () from /usr/gnu/lib/libtk8.3.so (gdb) bt #0 0xff0b2be0 in Tk_FreeGC () from /usr/gnu/lib/libtk8.3.so #1 0xff0da71c in TkButtonWorldChanged () from /usr/gnu/lib/libtk8.3.so #2 0xff0da66c in ConfigureButton () from /usr/gnu/lib/libtk8.3.so #3 0xff0d9dc8 in ButtonWidgetObjCmd () from /usr/gnu/lib/libtk8.3.so #4 0xfefe0b50 in EvalObjv () from /usr/gnu/lib/libtcl8.3.so #5 0xfefe0c80 in Tcl_EvalObjv () from /usr/gnu/lib/libtcl8.3.so #6 0x0008deb8 in Tkapp_Call (self=0x159c88, args=0x2c60d8) at Modules/_tkinter.c:619 #7 0x00049e28 in fast_cfunction (func=0x159c88, pp_stack=0xfe908780, na=1089160) at Python/ceval.c:3131 #8 0x00047ea0 in eval_frame (f=0x1cc7c0) at Python/ceval.c:2007 #9 0x00048b30 in PyEval_EvalCodeEx (co=0x220340, globals=0x1cc7c0, locals=0x0, args=0x8, argcount=1, kws=0x1c1dd8, kwcount=1, defs=0x1d76ec, defcount=1, closure=0x0) at Python/ceval.c:2585 #10 0x00049f20 in fast_function (func=0x1, pp_stack=0x8, n=1842656, na=1, nk=1) at Python/ceval.c:3161 #11 0x00047de0 in eval_frame (f=0x1c1c80) at Python/ceval.c:2024 #12 0x00048b30 in PyEval_EvalCodeEx (co=0x1983a8, globals=0x1c1c80, locals=0x0, args=0x30fd50, argcount=2, kws=0x30fd58, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #13 0x00049f20 in fast_function (func=0x0, pp_stack=0x30fd50, n=3210584, na=2, nk=0) at Python/ceval.c:3161 #14 0x00047de0 in eval_frame (f=0x30fc00) at Python/ceval.c:2024 #15 0x00048b30 in PyEval_EvalCodeEx (co=0x12f788, globals=0x30fc00, locals=0x0, args=0x1c0bc8, argcount=1, kws=0x1c0bcc, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #16 0x00049f20 in fast_function (func=0x0, pp_stack=0x1c0bc8, n=1838028, na=1, nk=0) at Python/ceval.c:3161 #17 0x00047de0 in eval_frame (f=0x1c0a70) at Python/ceval.c:2024 #18 0x00048b30 in PyEval_EvalCodeEx (co=0x300058, globals=0x1c0a70, locals=0x0, args=0x301a6c, argcount=3, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #19 0x000aaa9c in function_call (func=0x2fc3c0, arg=0x301a60, kw=0x0) at Objects/funcobject.c:374 #20 0x00095d00 in PyObject_Call (func=0x2fc3c0, arg=0x301a60, kw=0x0) at Objects/abstract.c:1684 #21 0x0009e644 in instancemethod_call (func=0x2fc3c0, arg=0x301a60, kw=0x0) at Objects/classobject.c:2276 #22 0x00095d00 in PyObject_Call (func=0x2fc3c0, arg=0x301a60, kw=0x0) at Objects/abstract.c:1684 #23 0x00049fe4 in do_call (func=0x2c5718, pp_stack=0xfe908fd8, na=3, nk=3152480) at Python/ceval.c:3262 #24 0x00047d28 in eval_frame (f=0x1cc5f8) at Python/ceval.c:2027 #25 0x00048b30 in PyEval_EvalCodeEx (co=0x12f398, globals=0x1cc5f8, locals=0x0, args=0x2cba54, argcount=3, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #26 0x000aaa9c in function_call (func=0x301bf0, arg=0x2cba48, kw=0x0) at Objects/funcobject.c:374 #27 0x00095d00 in PyObject_Call (func=0x301bf0, arg=0x2cba48, kw=0x0) at Objects/abstract.c:1684 #28 0x0009e644 in instancemethod_call (func=0x301bf0, arg=0x2cba48, kw=0x0) at Objects/classobject.c:2276 #29 0x00095d00 in PyObject_Call (func=0x301bf0, arg=0x2e3bb0, kw=0x0) at Objects/abstract.c:1684 #30 0x00049c94 in PyEval_CallObjectWithKeywords (func=0x2da810, arg=0x2e3bb0, kw=0x0) at Python/ceval.c:3049 #31 0x00097d9c in PyInstance_New (klass=0x2da810, arg=0x2e3bb0, kw=0x0) at Objects/classobject.c:557 #32 0x00095d00 in PyObject_Call (func=0x2da810, arg=0x2e3bb0, kw=0x0) at Objects/abstract.c:1684 #33 0x00049fe4 in do_call (func=0x316828, pp_stack=0xfe9094a0, na=2, nk=3029936) at Python/ceval.c:3262 #34 0x00047d28 in eval_frame (f=0x1a3d20) at Python/ceval.c:2027 #35 0x00048b30 in PyEval_EvalCodeEx (co=0x12fab0, globals=0x1a3d20, locals=0x0, args=0x186414, argcount=3, kws=0x2b1228, kwcount=0, defs=0x1cd87c, defcount=2, closure=0x0) at Python/ceval.c:2585 #36 0x000aaa9c in function_call (func=0x1d1dc8, arg=0x186408, kw=0x2d6238) at Objects/funcobject.c:374 #37 0x00095d00 in PyObject_Call (func=0x1d1dc8, arg=0x186408, kw=0x2d6238) at Objects/abstract.c:1684 #38 0x00049c94 in PyEval_CallObjectWithKeywords (func=0x1d1dc8, arg=0x186408, kw=0x2d6238) at Python/ceval.c:3049 #39 0x000bcb3c in builtin_apply (self=0x0, args=0x1d1dc8) at Python/bltinmodule.c:95 #40 0x000ba398 in PyCFunction_Call (func=0x101d18, arg=0x1c4910, kw=0x0) at Objects/methodobject.c:69 #41 0x00047ec8 in eval_frame (f=0x1a4078) at Python/ceval.c:2004 #42 0x00048b30 in PyEval_EvalCodeEx (co=0x2c86c8, globals=0x1a4078, locals=0x0, args=0x1612d4, argcount=1, kws=0x1612d8, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #43 0x00049f20 in fast_function (func=0x0, pp_stack=0x1612d4, n=1446616, na=1, nk=0) at Python/ceval.c:3161 #44 0x00047de0 in eval_frame (f=0x161180) at Python/ceval.c:2024 #45 0x00048b30 in PyEval_EvalCodeEx (co=0x2c8cd0, globals=0x161180, locals=0x0, args=0x265e4c, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #46 0x000aaa9c in function_call (func=0x2d6518, arg=0x265e40, kw=0x0) at Objects/funcobject.c:374 #47 0x00095d00 in PyObject_Call (func=0x2d6518, arg=0x265e40, kw=0x0) at Objects/abstract.c:1684 #48 0x0009e644 in instancemethod_call (func=0x2d6518, arg=0x265e40, kw=0x0) at Objects/classobject.c:2276 #49 0x00095d00 in PyObject_Call (func=0x2d6518, arg=0x100368, kw=0x0) at Objects/abstract.c:1684 #50 0x00049c94 in PyEval_CallObjectWithKeywords (func=0x2d7350, arg=0x100368, kw=0x0) at Python/ceval.c:3049 #51 0x0007f508 in t_bootstrap (boot_raw=0x28bdf8) at Modules/threadmodule.c:190 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-06 08:46 Message: Logged In: YES user_id=33168 Andrew, could I get you to look at bug 662787? http://python.org/sf/662787 We are having problems with solaris boxes and could use some help. Thanks. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-09-17 10:54 Message: Logged In: YES user_id=418174 I rebuilt python from scratch by saying "make configure", then going into Makefile and removing "-O3" from the definition of the OPT macro, then saying "make". The resulting python still dumps core when executing "./python Lib/pydoc.py -g". Of course there could still be a platform or optimization dependency in tcl, or tk, or some other library. Suggestions? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-13 21:30 Message: Logged In: YES user_id=33168 I built python 2.2.1+ w/gcc 2.95.3 and did not have the problem. So I think this may be specific to gcc 3.2. Can you try building w/lower optimization or turning off optimization? -O1, -O0 or no -O option? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602627&group_id=5470 From noreply@sourceforge.net Mon Jan 6 14:28:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 06:28:28 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-661203 ] sigprocmask: None argument Message-ID: Feature Requests item #661203, was opened at 2003-01-02 17:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=661203&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Pomraning (pilcrow) Assigned to: Michael Hudson (mwh) Summary: sigprocmask: None argument Initial Comment: signal.sigprocmask ought allow a None argument instead of a signal sequence: a) cur_mask = signal.sigprocmask(any_but_SETMASK, []) # sigprocmask(how, &empty_set, &cur_mask) b) cur_mask = signal.sigprocmask(dummy, None) # sigprocmask(dummy, NULL, &cur_mask) "a" is slightly more work for the kernel, and permits accidental SETMASKing. "b" avoids both, and is comfortably analogous to the familiar, ugly C interface (as opposed to, say, cur_mask = signal.sigprocmask()). ---------------------------------------------------------------------- >Comment By: Michael Pomraning (pilcrow) Date: 2003-01-06 14:28 Message: Logged In: YES user_id=679184 linux 2.4; x86. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-03 12:01 Message: Logged In: YES user_id=6656 Sounds fair enough. Should warn you that the sigmask stuff is currently not being compiled owing to unpleasantly exciting x-platform behaviour. I ought to do something about that, too. What platform are you on? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=661203&group_id=5470 From noreply@sourceforge.net Mon Jan 6 14:46:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 06:46:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-662787 ] test_signal hang on some Solaris boxes Message-ID: Bugs item #662787, was opened at 2003-01-05 20:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Martin v. Löwis (loewis) Summary: test_signal hang on some Solaris boxes Initial Comment: Martin, I'm assigning this to you because you checked in the patch which caused this problem. I think your input on fixes will also be valuable. When semaphore support was added to Python/thread_pthread.h in 2.39 originally from patch 525532, it broke tests on some Solaris boxes. I know this affects Solaris 8, not sure if any other versions are affected. I believe on or more of the following Solaris 8 patches (108528, 108827) fixes the problem: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108528&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108827&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on Patches can be gotten from here: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access One way to fix the hang is to add #undef USE_SEMAPHORES at line 113 of Python/thread_pthread.h (ie, after USE_SEMAPHORES may be set). I don't know of any other way to fix this problem. I don't know if we can test for this in configure and set USE_SEMAPHORES appropriately (or if it's worth it). We can always disable USE_SEMAPHORES and allow the user to use it by manually setting the macro. We keep the code as is, and document the problem. Suggestions? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 15:46 Message: Logged In: YES user_id=21627 showrev -p is good, as is patchadd -p (this also shows the patches you could backup to). I notice that my Solaris 9 machine does not experience the problem, so Sun has fixed something. It would be good if a Solaris 8 machine could be brought up-to-date with regard to patches (they recommend -18 and -35 respectively, at the moment). On that machine, either those two patches selectively, or an entire patch cluster (8_Recommended.zip) should be installed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-06 14:44 Message: Logged In: YES user_id=33168 I thought I could not duplicate the hang on our sun, but now it's happening. Your test program also hangs. How do you determine the revision of a patch on solaris? I'm using showrev -p | grep patch-#. I'm not sure that is correct. The way I read it, it says I have 108528-16 and 108827-12. In the snake farm proton has: 108528-12 and 108827-12 fafner has: 108528-13 and 108827-19 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 13:29 Message: Logged In: YES user_id=21627 It would be good to find a system that has 108528-17 installed. I see that this fixes 4498831 system timer stops sending signals ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 13:13 Message: Logged In: YES user_id=21627 I meant revisions of the Sun patches. On one system, I have 108528-16 and 108827-34, and test_signal still hangs. I found that the blocking occurs when test_queue.py is run before, and have distilled this into the following example: import sys import thread import time import signal fsema = thread.allocate_lock() def tfunc(): time.sleep(.1) fsema.release() fsema.acquire() thread.start_new_thread(tfunc,()) fsema.acquire() fsema.release() signal.alarm(3) signal.pause() It appears that the alarm is simply lost; the pause call does not return. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-06 00:38 Message: Logged In: YES user_id=33168 What do you mean by revision of the patches? CVS revision of thread_pthread.h? I believe 2.38 worked and 2.39 broke. I can test that if you'd like. Do you want me to go back to the revision before the patch for all files affected? Since 2.39 only added the semaphores, in essence, by doing the #undef that should have the same effect as reverting thread_pthread.h to 2.38. Or are you talking about the Solaris patches? If so, they are only a guess, we could compare the patch level on all the Solaris boxes we have access to and see which ones work and which don't. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 00:11 Message: Logged In: YES user_id=21627 Could you identify a revision of these patches for which the problem disappears? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 21:57 Message: Logged In: YES user_id=33168 For (possibly) more info, see: http://lists.lysator.liu.se/pipermail/snake-farm/2003-January/000617.html ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 21:38 Message: Logged In: YES user_id=33168 Attaching output of truss (like strace for Solaris) which doesn't provide me with any more info. Hopefully this will help someone else. 2 files attached, one with complete output from; truss ./python -E -tt ./Lib/test/regrtest.py test_queue test_signal the other is just the end. It should correspond to these lines from the test: signal.alarm(20) # Entire test lasts at most 20 sec. signal.signal(5, handlerA) signal.signal(2, handlerB) signal.signal(3, signal.SIG_IGN) signal.signal(signal.SIGALRM, signal.default_int_handler) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 From noreply@sourceforge.net Mon Jan 6 17:10:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 09:10:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-602627 ] pydoc -g dumps core on Solaris 2.8 Message-ID: Bugs item #602627, was opened at 2002-08-30 20:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602627&group_id=5470 Category: Demos and Tools Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc -g dumps core on Solaris 2.8 Initial Comment: Python 2.2.1, Solaris 2.8, gcc 3.2, binutils 2.12.1 When I execute "pydoc -g", it pops up a dialog box saying "Starting server" and "Search for", and then dumps core before I have time to type anything. The same problem happens on Solaris 2.7 The traceback: Core was generated by `/usr/gnu/bin/python /usr/gnu/bin/pydoc -g'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libsocket.so.1...done. Loaded symbols for /usr/lib/libsocket.so.1 Reading symbols from /usr/lib/libnsl.so.1...done. Loaded symbols for /usr/lib/libnsl.so.1 Reading symbols from /usr/lib/libdl.so.1...done. Loaded symbols for /usr/lib/libdl.so.1 Reading symbols from /usr/lib/libpthread.so.1...done. Loaded symbols for /usr/lib/libpthread.so.1 Reading symbols from /usr/lib/libthread.so.1...done. Loaded symbols for /usr/lib/libthread.so.1 Reading symbols from /usr/gnu/lib/libreadline.so.4...done. Loaded symbols for /usr/gnu/lib/libreadline.so.4 Reading symbols from /usr/lib/libcurses.so.1...done. Loaded symbols for /usr/lib/libcurses.so.1 Reading symbols from /usr/lib/libcrypt_i.so.1...done. Loaded symbols for /usr/lib/libcrypt_i.so.1 Reading symbols from /usr/gnu/lib/libtk8.3.so...done. Loaded symbols for /usr/gnu/lib/libtk8.3.so Reading symbols from /usr/gnu/lib/libtcl8.3.so...done. Loaded symbols for /usr/gnu/lib/libtcl8.3.so Reading symbols from /usr/lib/libX11.so.4...done. Loaded symbols for /usr/lib/libX11.so.4 Reading symbols from /usr/lib/libm.so.1...done. Loaded symbols for /usr/lib/libm.so.1 Reading symbols from /usr/lib/libc.so.1...done. Loaded symbols for /usr/lib/libc.so.1 Reading symbols from /usr/gnu/lib/libgcc_s.so.1...done. Loaded symbols for /usr/gnu/lib/libgcc_s.so.1 Reading symbols from /usr/lib/libmp.so.2...done. Loaded symbols for /usr/lib/libmp.so.2 Reading symbols from /usr/lib/libgen.so.1...done. Loaded symbols for /usr/lib/libgen.so.1 Reading symbols from /usr/openwin/lib/libXext.so.0...done. Loaded symbols for /usr/openwin/lib/libXext.so.0 Reading symbols from /usr/openwin/lib/libdga.so.1...done. Loaded symbols for /usr/openwin/lib/libdga.so.1 Reading symbols from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1...done. Loaded symbols for /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1 Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/strop.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/strop.so Reading symbols from /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2...done. Loaded symbols for /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2 Reading symbols from /usr/openwin/lib/locale/common/xlibi18n.so.2...done. Loaded symbols for /usr/openwin/lib/locale/common/xlibi18n.so.2 Reading symbols from /usr/openwin/lib/locale/common/ximlocal.so.2...done. Loaded symbols for /usr/openwin/lib/locale/common/ximlocal.so.2 Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/time.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/time.so Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/errno.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/errno.so Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/_socket.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/_socket.so Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/select.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/select.so #0 0xff0b2be0 in Tk_FreeGC () from /usr/gnu/lib/libtk8.3.so (gdb) bt #0 0xff0b2be0 in Tk_FreeGC () from /usr/gnu/lib/libtk8.3.so #1 0xff0da71c in TkButtonWorldChanged () from /usr/gnu/lib/libtk8.3.so #2 0xff0da66c in ConfigureButton () from /usr/gnu/lib/libtk8.3.so #3 0xff0d9dc8 in ButtonWidgetObjCmd () from /usr/gnu/lib/libtk8.3.so #4 0xfefe0b50 in EvalObjv () from /usr/gnu/lib/libtcl8.3.so #5 0xfefe0c80 in Tcl_EvalObjv () from /usr/gnu/lib/libtcl8.3.so #6 0x0008deb8 in Tkapp_Call (self=0x159c88, args=0x2c60d8) at Modules/_tkinter.c:619 #7 0x00049e28 in fast_cfunction (func=0x159c88, pp_stack=0xfe908780, na=1089160) at Python/ceval.c:3131 #8 0x00047ea0 in eval_frame (f=0x1cc7c0) at Python/ceval.c:2007 #9 0x00048b30 in PyEval_EvalCodeEx (co=0x220340, globals=0x1cc7c0, locals=0x0, args=0x8, argcount=1, kws=0x1c1dd8, kwcount=1, defs=0x1d76ec, defcount=1, closure=0x0) at Python/ceval.c:2585 #10 0x00049f20 in fast_function (func=0x1, pp_stack=0x8, n=1842656, na=1, nk=1) at Python/ceval.c:3161 #11 0x00047de0 in eval_frame (f=0x1c1c80) at Python/ceval.c:2024 #12 0x00048b30 in PyEval_EvalCodeEx (co=0x1983a8, globals=0x1c1c80, locals=0x0, args=0x30fd50, argcount=2, kws=0x30fd58, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #13 0x00049f20 in fast_function (func=0x0, pp_stack=0x30fd50, n=3210584, na=2, nk=0) at Python/ceval.c:3161 #14 0x00047de0 in eval_frame (f=0x30fc00) at Python/ceval.c:2024 #15 0x00048b30 in PyEval_EvalCodeEx (co=0x12f788, globals=0x30fc00, locals=0x0, args=0x1c0bc8, argcount=1, kws=0x1c0bcc, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #16 0x00049f20 in fast_function (func=0x0, pp_stack=0x1c0bc8, n=1838028, na=1, nk=0) at Python/ceval.c:3161 #17 0x00047de0 in eval_frame (f=0x1c0a70) at Python/ceval.c:2024 #18 0x00048b30 in PyEval_EvalCodeEx (co=0x300058, globals=0x1c0a70, locals=0x0, args=0x301a6c, argcount=3, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #19 0x000aaa9c in function_call (func=0x2fc3c0, arg=0x301a60, kw=0x0) at Objects/funcobject.c:374 #20 0x00095d00 in PyObject_Call (func=0x2fc3c0, arg=0x301a60, kw=0x0) at Objects/abstract.c:1684 #21 0x0009e644 in instancemethod_call (func=0x2fc3c0, arg=0x301a60, kw=0x0) at Objects/classobject.c:2276 #22 0x00095d00 in PyObject_Call (func=0x2fc3c0, arg=0x301a60, kw=0x0) at Objects/abstract.c:1684 #23 0x00049fe4 in do_call (func=0x2c5718, pp_stack=0xfe908fd8, na=3, nk=3152480) at Python/ceval.c:3262 #24 0x00047d28 in eval_frame (f=0x1cc5f8) at Python/ceval.c:2027 #25 0x00048b30 in PyEval_EvalCodeEx (co=0x12f398, globals=0x1cc5f8, locals=0x0, args=0x2cba54, argcount=3, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #26 0x000aaa9c in function_call (func=0x301bf0, arg=0x2cba48, kw=0x0) at Objects/funcobject.c:374 #27 0x00095d00 in PyObject_Call (func=0x301bf0, arg=0x2cba48, kw=0x0) at Objects/abstract.c:1684 #28 0x0009e644 in instancemethod_call (func=0x301bf0, arg=0x2cba48, kw=0x0) at Objects/classobject.c:2276 #29 0x00095d00 in PyObject_Call (func=0x301bf0, arg=0x2e3bb0, kw=0x0) at Objects/abstract.c:1684 #30 0x00049c94 in PyEval_CallObjectWithKeywords (func=0x2da810, arg=0x2e3bb0, kw=0x0) at Python/ceval.c:3049 #31 0x00097d9c in PyInstance_New (klass=0x2da810, arg=0x2e3bb0, kw=0x0) at Objects/classobject.c:557 #32 0x00095d00 in PyObject_Call (func=0x2da810, arg=0x2e3bb0, kw=0x0) at Objects/abstract.c:1684 #33 0x00049fe4 in do_call (func=0x316828, pp_stack=0xfe9094a0, na=2, nk=3029936) at Python/ceval.c:3262 #34 0x00047d28 in eval_frame (f=0x1a3d20) at Python/ceval.c:2027 #35 0x00048b30 in PyEval_EvalCodeEx (co=0x12fab0, globals=0x1a3d20, locals=0x0, args=0x186414, argcount=3, kws=0x2b1228, kwcount=0, defs=0x1cd87c, defcount=2, closure=0x0) at Python/ceval.c:2585 #36 0x000aaa9c in function_call (func=0x1d1dc8, arg=0x186408, kw=0x2d6238) at Objects/funcobject.c:374 #37 0x00095d00 in PyObject_Call (func=0x1d1dc8, arg=0x186408, kw=0x2d6238) at Objects/abstract.c:1684 #38 0x00049c94 in PyEval_CallObjectWithKeywords (func=0x1d1dc8, arg=0x186408, kw=0x2d6238) at Python/ceval.c:3049 #39 0x000bcb3c in builtin_apply (self=0x0, args=0x1d1dc8) at Python/bltinmodule.c:95 #40 0x000ba398 in PyCFunction_Call (func=0x101d18, arg=0x1c4910, kw=0x0) at Objects/methodobject.c:69 #41 0x00047ec8 in eval_frame (f=0x1a4078) at Python/ceval.c:2004 #42 0x00048b30 in PyEval_EvalCodeEx (co=0x2c86c8, globals=0x1a4078, locals=0x0, args=0x1612d4, argcount=1, kws=0x1612d8, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #43 0x00049f20 in fast_function (func=0x0, pp_stack=0x1612d4, n=1446616, na=1, nk=0) at Python/ceval.c:3161 #44 0x00047de0 in eval_frame (f=0x161180) at Python/ceval.c:2024 #45 0x00048b30 in PyEval_EvalCodeEx (co=0x2c8cd0, globals=0x161180, locals=0x0, args=0x265e4c, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #46 0x000aaa9c in function_call (func=0x2d6518, arg=0x265e40, kw=0x0) at Objects/funcobject.c:374 #47 0x00095d00 in PyObject_Call (func=0x2d6518, arg=0x265e40, kw=0x0) at Objects/abstract.c:1684 #48 0x0009e644 in instancemethod_call (func=0x2d6518, arg=0x265e40, kw=0x0) at Objects/classobject.c:2276 #49 0x00095d00 in PyObject_Call (func=0x2d6518, arg=0x100368, kw=0x0) at Objects/abstract.c:1684 #50 0x00049c94 in PyEval_CallObjectWithKeywords (func=0x2d7350, arg=0x100368, kw=0x0) at Python/ceval.c:3049 #51 0x0007f508 in t_bootstrap (boot_raw=0x28bdf8) at Modules/threadmodule.c:190 ---------------------------------------------------------------------- >Comment By: Andrew Koenig (arkoenig) Date: 2003-01-06 17:10 Message: Logged In: YES user_id=418174 I rebuilt python with -O0 and it still crashes. The new traceback is attached. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-06 13:46 Message: Logged In: YES user_id=33168 Andrew, could I get you to look at bug 662787? http://python.org/sf/662787 We are having problems with solaris boxes and could use some help. Thanks. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-09-17 14:54 Message: Logged In: YES user_id=418174 I rebuilt python from scratch by saying "make configure", then going into Makefile and removing "-O3" from the definition of the OPT macro, then saying "make". The resulting python still dumps core when executing "./python Lib/pydoc.py -g". Of course there could still be a platform or optimization dependency in tcl, or tk, or some other library. Suggestions? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-14 01:30 Message: Logged In: YES user_id=33168 I built python 2.2.1+ w/gcc 2.95.3 and did not have the problem. So I think this may be specific to gcc 3.2. Can you try building w/lower optimization or turning off optimization? -O1, -O0 or no -O option? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602627&group_id=5470 From noreply@sourceforge.net Mon Jan 6 15:38:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 07:38:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-629756 ] FAIL: test_crlf_separation (email.test.t Message-ID: Bugs item #629756, was opened at 2002-10-28 05:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629756&group_id=5470 Category: Windows Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Grzegorz Makarewicz (makaron) Assigned to: Barry A. Warsaw (bwarsaw) Summary: FAIL: test_crlf_separation (email.test.t Initial Comment: just because text file on windows has CR/LF as endline maker and this test expects LF as eol. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-06 10:38 Message: Logged In: YES user_id=12800 Jack, the change actually /is/ made on the trunk, exactly as you proposed. :) Closing this one again. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-01-06 08:10 Message: Logged In: YES user_id=45365 Barry, I'm opening this one again, because on the Macintosh I still have one more problem with test_crlf_separation. The change you made in the repository (mark the file as binary) was half the fix, but I needed to do another thing as well: open the test file in binary mode. On Windows and Unix you can open the file in text mode (for Windows there's no problem at all, for Unix there will be '\r' at the end of each line, but that is handled), but not so on the mac ('\r\n' in the file will be converted to '\n\r' upon reading, which results in \r at the beginning of each line). I checked in a fix for this (test_email.py, rev. 1.28.2.1), let me know whether you agree with this, then I'll check it in on the trunk too. ---------------------------------------------------------------------- Comment By: Grzegorz Makarewicz (makaron) Date: 2003-01-02 06:29 Message: Logged In: YES user_id=115179 :( - after unpacking python on linux and copying all files with ordinary copy this test still fails for me (Info zip works fine on windows, gifs and other binary files are uncompressed correctly). Can you run attached file on your windows ? It is stripped down test_crlf_separation which uses StringIO, binary and text open mode. When using text mode as in mentioned test msg.get_payload will return data terminated with \n - but it is tested for \r\n. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-30 14:26 Message: Logged In: YES user_id=12800 It looks like you built this from source on Windows. If you unzip'd the source without turning off any dumb CRLF munging in your zip program, the test file will not be correct and this test will fail. Tim assures me that this test succeeds in Python 2.2 and 2.3a1 and I trust him with my lunch. ---------------------------------------------------------------------- Comment By: Grzegorz Makarewicz (makaron) Date: 2002-10-29 06:28 Message: Logged In: YES user_id=115179 Python 2.2.2 from October 14, 2002, compiled from source on windows 2000 all expected test are passed but not test_email. reproducable by: pushd Lib\test ..\..\python regrtest.py popd -- or cd Lib\test ..\..\python test_email.py traceback: FAILED (failures=1) Traceback (most recent call last): File "test_email.py", line 13, in ? test_main() File "test_email.py", line 10, in test_main run_suite(suite()) File "c:\binw\py222\lib\test\test_support.py", line 175, in run_suite raise TestFailed(err) test_support.TestFailed: Traceback (most recent call last): File "c:\binw\py222\lib\email\test\test_email.py", line 1851, in test_crlf_sep aration eq(part1.get_payload(), 'Simple email with attachment.\r\n\r\n') File "c:\binw\py222\lib\unittest.py", line 286, in failUnlessEqual raise self.failureException, \ AssertionError: 'Simple email with attachment.\n\n' != 'Simple email with attach ment.\r\n\r\n' after applying this patch thist test will pass --- test_email.py Mon Oct 14 17:26:03 2002 +++ test_email.py.new Tue Oct 29 11:25:54 2002 @@ -46,7 +46,7 @@ def openfile(filename): path = os.path.join(os.path.dirname(landmark), 'data', filename) - return open(path, 'r') + return open(path, 'rb') ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-10-28 10:33 Message: Logged In: YES user_id=31435 Assigned to Barry. Grzegorz, please supply more detail, such as which version of Python you're using, and the commands you used to run this test. As the name of the test should imply ("test_crlf_....), the test *expects* CR/LF -- that's it's point. It passes for me under 2.2.2 and current CVS Python, under Win98SE and Win2K. It may not have passed in 2.2.1, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=629756&group_id=5470 From noreply@sourceforge.net Mon Jan 6 15:42:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 07:42:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-638703 ] optparse module undocumented Message-ID: Bugs item #638703, was opened at 2002-11-14 17:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=638703&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: optparse module undocumented Initial Comment: Some volunteer needs to document the optparse module. The text files from optik may supply a good source for material for the LaTeX version of the docs. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-06 10:42 Message: Logged In: YES user_id=3066 Accepted the patch, with instructions for Neal to proceed with checkin. The datetime docs grew a markup error since I'd last formatted them myself; now fixed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 17:03 Message: Logged In: YES user_id=33168 Fred, I tested the patch, the doc builds ok with it. It looked very extensive, but I briefly looked it over. Would you like me to check it in? BTW, do the datetime docs build for you? They don't for me. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-01 17:39 Message: Logged In: YES user_id=33168 There is a patch here: http://python.org/sf/642236 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-22 09:45 Message: Logged In: YES user_id=33168 Note: patch available at http://python.org/sf/642236 ---------------------------------------------------------------------- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2002-11-19 02:42 Message: Logged In: YES user_id=469548 I'm working on this. I'll probably mostly use the text files in the Optik package, but I'll add a true reference section, based on the output of pydoc.help(optparse). I'll have to write some more docstrings into the optparse module to make this useful, however. Please note that I'm new to LaTeX, so it may take some time for me to learn it and then convert the text files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=638703&group_id=5470 From noreply@sourceforge.net Mon Jan 6 17:54:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 09:54:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-663234 ] Missing logging package on windows Message-ID: Bugs item #663234, was opened at 2003-01-06 12:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663234&group_id=5470 Category: Windows Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Brian Dorsey (briandorsey) Assigned to: Tim Peters (tim_one) Summary: Missing logging package on windows Initial Comment: The logging package appears to be missing from the windows installer in Python 2.3a1. C:\>python Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import logging Traceback (most recent call last): File "", line 1, in ? ImportError: No module named logging Searching the install.log file, I see only two references to 'logging': File Copy: C:\Python23\Doc\lib\logging-example.html | 12-31-2002 | 14:40:04 | | 6096 | 116c2867 File Copy: C:\Python23\Doc\lib\module-logging.html | 12- 31-2002 | 14:40:04 | | 5679 | 56c54f8e I tried the install on two computers with the same effect, one had python2.2 already installed (win2kserver) and one didn't have any version of python (win2kpro). As a workaround, I was able to grab the logging directory from CVS and import and use the package in a simple program. Take care, -Brian ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-06 12:54 Message: Logged In: YES user_id=31435 Sorry about that! It was an oversight in the Wise installer, and has already been fixed (for 2.3a2). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663234&group_id=5470 From noreply@sourceforge.net Mon Jan 6 17:46:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 09:46:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-663234 ] Missing logging package on windows Message-ID: Bugs item #663234, was opened at 2003-01-06 09:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663234&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brian Dorsey (briandorsey) Assigned to: Tim Peters (tim_one) Summary: Missing logging package on windows Initial Comment: The logging package appears to be missing from the windows installer in Python 2.3a1. C:\>python Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import logging Traceback (most recent call last): File "", line 1, in ? ImportError: No module named logging Searching the install.log file, I see only two references to 'logging': File Copy: C:\Python23\Doc\lib\logging-example.html | 12-31-2002 | 14:40:04 | | 6096 | 116c2867 File Copy: C:\Python23\Doc\lib\module-logging.html | 12- 31-2002 | 14:40:04 | | 5679 | 56c54f8e I tried the install on two computers with the same effect, one had python2.2 already installed (win2kserver) and one didn't have any version of python (win2kpro). As a workaround, I was able to grab the logging directory from CVS and import and use the package in a simple program. Take care, -Brian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663234&group_id=5470 From noreply@sourceforge.net Mon Jan 6 22:02:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 14:02:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-623669 ] __rdiv__ vs new-style classes Message-ID: Bugs item #623669, was opened at 2002-10-15 14:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623669&group_id=5470 Category: Type/class unification Group: Python 2.2.2 Status: Open Resolution: None Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Guido van Rossum (gvanrossum) Summary: __rdiv__ vs new-style classes Initial Comment: In 2.2.2 and 2.3, consider this: """ class F: def __init__(self): print 'built an F' def __div__(self, other): print 'in F.__div__' return F() def __rdiv__(self, other): print 'in F.__rdiv__' return F() / self class F2(F): def __init__(self): print 'built an F2' 3 / F2() """ This displays what I expect: """ built an F2 in F.__rdiv__ built an F in F.__div__ built an F """ However, change F to derive from object: class F(object): and it's in infinite recursion, starting like so: """ built an F2 in F.__rdiv__ built an F in F.__rdiv__ built an F in F.__rdiv__ built an F in F.__rdiv__ built an F in F.__rdiv__ built an F in F.__rdiv__ built an F in F.__rdiv__ ... """ Despite that F.__rdiv__ creates an explicit F() instance and uses it on the LHS of /, F.__div__ is never invoked; instead the RHS F2.__rdiv__ == F.__rdiv__ always gets the nod. Maybe this is intentional? I confess I've lost track of the rules. Changing the end of F.__rdiv__ to return F().__div__(self) brute-forces the desired outcome, so there is a workaround. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-06 17:02 Message: Logged In: YES user_id=6380 I've got a dilemma. The cause of the recursion is in line 3509 of typeobject.c, in the SLOT1BINFULL() macro. The section starting with if (do_other && \ (introduced by rev 2.82 of thatfile) tries to call the right operand's __rdiv__ *before* the left operand's __div__ is called in the specific case where both operands are new-style classes that implement __div__ and __rdiv__. This is intended to "do the right thing" in cases where D derives from C and overrides some operation, and you call C()/D(); without that code section, C.__div__ would be invoked before D.__rdiv__, and since D() is a C instance, C.__div__ would probably return a result -- just not the result that D.__rdiv__ would have given. The endless recursion reported above is caused by the fact that D satisfies all the criteria, but D.__rdiv__ is really just C.__rdiv__, which calls C()/D() recursively. My dilemma is that this feature is not documented, and classic classes don't work this way (C.__div__ would be called). There are also no unit tests for the feature. So ripping it out would be the quickest way to avoid the recursion. OTOH, binary_op1() in abstract.c contains similar code that catches a similar case where the base class C is a built-in type (e.g. int). (Also undocumented and also without unit tests.) But checking that D's __rdiv__ is really the same as C's __rdiv__ before calling it is fairly expensive and convoluted (imagine the case where there's an intermediate class C1, so that D derives from C1 derives from C, and C1 overrides C.__rdiv__). And even then one could construct cases that would fool the test. I'm going to think about this some more... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623669&group_id=5470 From noreply@sourceforge.net Tue Jan 7 03:46:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 19:46:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-662787 ] test_signal hang on some Solaris boxes Message-ID: Bugs item #662787, was opened at 2003-01-05 19:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Martin v. Löwis (loewis) Summary: test_signal hang on some Solaris boxes Initial Comment: Martin, I'm assigning this to you because you checked in the patch which caused this problem. I think your input on fixes will also be valuable. When semaphore support was added to Python/thread_pthread.h in 2.39 originally from patch 525532, it broke tests on some Solaris boxes. I know this affects Solaris 8, not sure if any other versions are affected. I believe on or more of the following Solaris 8 patches (108528, 108827) fixes the problem: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108528&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108827&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on Patches can be gotten from here: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access One way to fix the hang is to add #undef USE_SEMAPHORES at line 113 of Python/thread_pthread.h (ie, after USE_SEMAPHORES may be set). I don't know of any other way to fix this problem. I don't know if we can test for this in configure and set USE_SEMAPHORES appropriately (or if it's worth it). We can always disable USE_SEMAPHORES and allow the user to use it by manually setting the macro. We keep the code as is, and document the problem. Suggestions? ---------------------------------------------------------------------- Comment By: Inyeol Lee (inyeol) Date: 2003-01-07 03:46 Message: Logged In: YES user_id=595280 Neal, This is the patch version of my Solaris8 system you've requested; Patch: 108528-07 Patch: 108528-13 Patch: 108827-07 Patch: 108827-15 Inyeol Lee ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 14:46 Message: Logged In: YES user_id=21627 showrev -p is good, as is patchadd -p (this also shows the patches you could backup to). I notice that my Solaris 9 machine does not experience the problem, so Sun has fixed something. It would be good if a Solaris 8 machine could be brought up-to-date with regard to patches (they recommend -18 and -35 respectively, at the moment). On that machine, either those two patches selectively, or an entire patch cluster (8_Recommended.zip) should be installed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-06 13:44 Message: Logged In: YES user_id=33168 I thought I could not duplicate the hang on our sun, but now it's happening. Your test program also hangs. How do you determine the revision of a patch on solaris? I'm using showrev -p | grep patch-#. I'm not sure that is correct. The way I read it, it says I have 108528-16 and 108827-12. In the snake farm proton has: 108528-12 and 108827-12 fafner has: 108528-13 and 108827-19 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 12:29 Message: Logged In: YES user_id=21627 It would be good to find a system that has 108528-17 installed. I see that this fixes 4498831 system timer stops sending signals ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 12:13 Message: Logged In: YES user_id=21627 I meant revisions of the Sun patches. On one system, I have 108528-16 and 108827-34, and test_signal still hangs. I found that the blocking occurs when test_queue.py is run before, and have distilled this into the following example: import sys import thread import time import signal fsema = thread.allocate_lock() def tfunc(): time.sleep(.1) fsema.release() fsema.acquire() thread.start_new_thread(tfunc,()) fsema.acquire() fsema.release() signal.alarm(3) signal.pause() It appears that the alarm is simply lost; the pause call does not return. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 23:38 Message: Logged In: YES user_id=33168 What do you mean by revision of the patches? CVS revision of thread_pthread.h? I believe 2.38 worked and 2.39 broke. I can test that if you'd like. Do you want me to go back to the revision before the patch for all files affected? Since 2.39 only added the semaphores, in essence, by doing the #undef that should have the same effect as reverting thread_pthread.h to 2.38. Or are you talking about the Solaris patches? If so, they are only a guess, we could compare the patch level on all the Solaris boxes we have access to and see which ones work and which don't. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-05 23:11 Message: Logged In: YES user_id=21627 Could you identify a revision of these patches for which the problem disappears? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 20:57 Message: Logged In: YES user_id=33168 For (possibly) more info, see: http://lists.lysator.liu.se/pipermail/snake-farm/2003-January/000617.html ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 20:38 Message: Logged In: YES user_id=33168 Attaching output of truss (like strace for Solaris) which doesn't provide me with any more info. Hopefully this will help someone else. 2 files attached, one with complete output from; truss ./python -E -tt ./Lib/test/regrtest.py test_queue test_signal the other is just the end. It should correspond to these lines from the test: signal.alarm(20) # Entire test lasts at most 20 sec. signal.signal(5, handlerA) signal.signal(2, handlerB) signal.signal(3, signal.SIG_IGN) signal.signal(signal.SIGALRM, signal.default_int_handler) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 From noreply@sourceforge.net Tue Jan 7 06:18:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 22:18:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-565710 ] ImportError: No module named _socket Message-ID: Bugs item #565710, was opened at 2002-06-07 18:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=565710&group_id=5470 Category: None Group: Python 2.2.1 Status: Closed Resolution: Fixed Priority: 6 Submitted By: Philipp Kolmann (pkolmann) Assigned to: Barry A. Warsaw (bwarsaw) Summary: ImportError: No module named _socket Initial Comment: Hi, I just wanted to try out Mailman on a Sun Solaris machine and compiled therefore Python 2.2. It did compile ok, but there seems to be a problem with the socket library: bash-2.03$ python /opt/PYthon/lib/python2.2/socket.py Traceback (most recent call last): File "/opt/PYthon/lib/python2.2/socket.py", line 41, in ? from _socket import * ImportError: No module named _socket Could you help me with this problem. Thanks a lot Philipp Kolmann ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2003-01-07 17:18 Message: Logged In: YES user_id=59803 Just ran into this one with Python 2.2.2 on Solaris 2.7. The solution was to edit Modules/Setup and uncomment the lines after the "# Socket module compiled with SSL support" comment. I'm adding this note so that anyone else finding this bug doesn't have to go through the same blundering steps I did to figure out the solution. Python 2.3a1 worked flawlessly. Whatever you changed, worked. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-01 01:54 Message: Logged In: YES user_id=12800 Ok, if Python 2.3's setup.py provides the ImportError diagnostics, then agree that's most of what you need. You'll see the ld.so error so that should be a strong indication that you're linking against a library in a non-standard location. I also seem to recall that Python 2.3 doesn't remove the .so, but instead moves it aside so that's also enough because then you can use ldd and other tools to figure out what it should have been linking to. I'm not sure it's worth porting all this back to Python 2.2.2, so I'm closing this issue. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-01 01:39 Message: Logged In: YES user_id=21627 As for the setup.py option - I think what users really needs is to find out why importing the module fails, i.e. the complete ImportError diagnostics; the 2.3 setup.py is supposed to report all this. It probably would not have helped in this case, where the user did not notice the error message at build time. However, adding an option to setup.py would not have helped, either - the user would not have used it. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-10-01 00:13 Message: Logged In: YES user_id=12800 Cool, thanks Martin. I plan to commit the one line change to setup.py for both Python 2.3 and 2.2.2. I'll try to add an option to setup.py to not throw away un-importable .so's as Guido suggests (I'd also like it to print the ImportError to stderr if possible). ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-30 16:37 Message: Logged In: YES user_id=21627 I have now been convinced that this is a good solution. While it may be overkill in some cases (e.g. if libcrypto isn't shared), I have to take my earlier view that setup.py only needs to deal with the common case, and special cases can be dealt with in Modules/Setup. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-28 00:22 Message: Logged In: YES user_id=12800 Note that setup.py doesn't need to explicitly add the -R option. It just needs to add runtime_library_dirs=ssl_libs and distutils will do the right thing crossplatform (verified on Solaris and Linux). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-27 23:39 Message: Logged In: YES user_id=6380 OK, I think I now understand -- the question is, should we add -R to find the SSL library or not? I think yes, at least if we know the platform supports -R. BTW setup.py badly needs an option to prevent it from throwing away failing .so files! Assigning to Martin so he can explain the problem with -R again if he disagrees with my pronouncement; I looked at 551553 but didn't understand the problem. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-27 14:47 Message: Logged In: YES user_id=12800 BTW, this is a duplicate of 551353, which is currently closed (and I'm keeping it closed since we don't need two open bugs on the same issue). However, in 551353 Martin outlines some approaches that a user can take so that the .so files are properly found at runtime. I must disagree that Python can't do better. We hashed out a similar issue with the bsddb library which installs in /usr/local/BerkeleyDB.X.Y by default, also not on the default ld search path. In that case we agreed to add the setup.py magic to compile in the runtime path to the library, and I think we should do the same with the ssl library. setup.py already finds the dynamic libraries so it can just as easily add the -R flag. Too many people get bit by this problem and there are basically no diagnostics to help someone figure out what needs to be done to fix the problem. In 551353, Martin says that sometimes adding -R isn't right, but I think for most people it will be right. For those that adding -R does the wrong thing, they can hack the code, and I believe that adding -R will make life better for the majority of users. I assigned this to Guido for pronouncement. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-09-27 14:35 Message: Logged In: YES user_id=12800 This is an ld.so problem. I can reproduce this on the SF compile farm's Solaris8/Sparc box. Python 2.2's brain damaged dynlib build procedure removes any .so it can't import, which makes it very difficult to tell what the problem is, if it's not evident in the compilation output. In this particular case, rebuilding _socket.so by hand, and then importing it clearly shows that the dynamic linker can't find libssl.so.xxx and libcrypto.so.xxx. On this Solaris box, these libraries reside in /usr/local/ssl/lib but that's not on the default ld.so search path and the build script doesn't use the -R option to compile in the location of those libraries. The fix is to add "runtime_library_dirs = ssl_libs," to the Extension constructor for socketmodule.c in the top level setup.py. I've tested this with Python 2.2 maint, but I'll bet it'll hit Python 2.3 too. Attached is a patch that ought to fix the problem for Solaris. It appears to do no harm on Linux. Under the same rationale we came up with for the bsddb module, I think this should be added, otherwise the socket module will just plain be busted for (some? all? most?) Solaris systems. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-06-11 19:14 Message: Logged In: YES user_id=6656 But the usual reason for the _socket module not to build on solaris is ssl issues. Without more info it's hard to say anything more (hint, hint, Philipp). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-11 05:30 Message: Logged In: YES user_id=6380 MWH: I don't see the connection with SSL. More likely somehow the socket module didn't get built. Quite possibly his whole installation is hosed. Reducing the priority since local configuration errors are usually not something that Python can do anything about. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-06-07 23:33 Message: Logged In: YES user_id=6656 The problem is probably ssl support. Try editing Modules/Setup and uncommenting the line: #_socket socketmodule.c If you *need* ssl support, then you'll have to dig deeper... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=565710&group_id=5470 From noreply@sourceforge.net Tue Jan 7 14:08:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 06:08:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-663701 ] sets module review Message-ID: Bugs item #663701, was opened at 2003-01-07 15:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663701&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sebastien Keim (s_keim) Assigned to: Nobody/Anonymous (nobody) Summary: sets module review Initial Comment: * the ^ operator doesnt print well in pdf generated documentation (both in what's new and in library reference) * shouldn't the _as_immutable and _as_temporaly_immutable be spelled __as_immutable__ and __as_temporaly_immutable__ for consistency with other hook methods? * cmp() suck: 
bash-2.05$ ./python 
Python 2.3a1 (#1, Jan  4 2003, 10:17:56) 
[GCC 2.95.3 20010315 (release)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import sets
>>> s = sets.Set
>>> a = s([0])
>>> b = s([1])
>>> cmp(a,b)
1
>>> 
bash-2.05$ ./python 
Python 2.3a1 (#1, Jan  4 2003, 10:17:56) 
[GCC 2.95.3 20010315 (release)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import sets
>>> a=sets.Set([0])
>>> b=sets.Set([1])
>>> cmp(a,b)
-1
* Because we can have set1!=set2 and both (set1 behavior? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663701&group_id=5470 From noreply@sourceforge.net Tue Jan 7 15:58:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 07:58:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-663782 ] test_socket test_unicode_file fail on 2.3a1 on winNT Message-ID: Bugs item #663782, was opened at 2003-01-07 17:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663782&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_socket test_unicode_file fail on 2.3a1 on winNT Initial Comment: This happens after installing 2.3a1 on winNT 4 sp6. D:\apps\Python23>python D:\apps\Python23\Lib\test\test_socket.py testCrucialConstants (__main__.GeneralModuleTests) ... ok testDefaultTimeout (__main__.GeneralModuleTests) ... ok testGetServByName (__main__.GeneralModuleTests) ... ok testGetSockOpt (__main__.GeneralModuleTests) ... ok testHostnameRes (__main__.GeneralModuleTests) ... ok testInterpreterCrash (__main__.GeneralModuleTests) ... ok testNtoH (__main__.GeneralModuleTests) ... ok testRefCountGetNameInfo (__main__.GeneralModuleTests) ... ok testSendAfterClose (__main__.GeneralModuleTests) ... ok testSetSockOpt (__main__.GeneralModuleTests) ... ok testSockName (__main__.GeneralModuleTests) ... ok testSocketError (__main__.GeneralModuleTests) ... ok testFromFd (__main__.BasicTCPTest) ... ok testOverFlowRecv (__main__.BasicTCPTest) ... ok testOverFlowRecvFrom (__main__.BasicTCPTest) ... ok testRecv (__main__.BasicTCPTest) ... ok testRecvFrom (__main__.BasicTCPTest) ... ok testSendAll (__main__.BasicTCPTest) ... ok testShutdown (__main__.BasicTCPTest) ... ok testRecvFrom (__main__.BasicUDPTest) ... ok testSendtoAndRecv (__main__.BasicUDPTest) ... ok testAccept (__main__.NonBlockingTCPTests) ... FAIL ERROR testConnect (__main__.NonBlockingTCPTests) ... ok testRecv (__main__.NonBlockingTCPTests) ... ok testSetBlocking (__main__.NonBlockingTCPTests) ... ok testFullRead (__main__.FileObjectClassTestCase) ... ok testReadline (__main__.FileObjectClassTestCase) ... ok testSmallRead (__main__.FileObjectClassTestCase) ... ok testUnbufferedRead (__main__.FileObjectClassTestCase) ... ok testFullRead (__main__.UnbufferedFileObjectClassTestCase) ... ok testReadline (__main__.UnbufferedFileObjectClassTestCase) ... ok testSmallRead (__main__.UnbufferedFileObjectClassTestCase) ... ok testUnbufferedRead (__main__.UnbufferedFileObjectClassTestCase) ... ok testUnbufferedReadline (__main__.UnbufferedFileObjectClassTestCase) ... ok testFullRead (__main__.LineBufferedFileObjectClassTestCase) ... ok testReadline (__main__.LineBufferedFileObjectClassTestCase) ... ok testSmallRead (__main__.LineBufferedFileObjectClassTestCase) ... ok testUnbufferedRead (__main__.LineBufferedFileObjectClassTestCase) ... ok testFullRead (__main__.SmallBufferedFileObjectClassTestCase) ... ok testReadline (__main__.SmallBufferedFileObjectClassTestCase) ... ok testSmallRead (__main__.SmallBufferedFileObjectClassTestCase) ... ok testUnbufferedRead (__main__.SmallBufferedFileObjectClassTestCase) ... ok ====================================================================== ERROR: testAccept (__main__.NonBlockingTCPTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\apps\Python23\Lib\test\test_socket.py", line 117, in _tearDown self.fail(msg) File "D:\apps\Python23\lib\unittest.py", line 260, in fail raise self.failureException, msg AssertionError: (10061, 'Connection refused') ====================================================================== FAIL: testAccept (__main__.NonBlockingTCPTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\apps\Python23\Lib\test\test_socket.py", line 475, in testAccept self.fail("Error trying to do non-blocking accept.") File "D:\apps\Python23\lib\unittest.py", line 260, in fail raise self.failureException, msg AssertionError: Error trying to do non-blocking accept. ---------------------------------------------------------------------- Ran 42 tests in 2.204s FAILED (failures=1, errors=1) Traceback (most recent call last): File "D:\apps\Python23\Lib\test\test_socket.py", line 632, in ? test_main() File "D:\apps\Python23\Lib\test\test_socket.py", line 629, in test_main test_support.run_suite(suite) File "D:\apps\Python23\lib\test\test_support.py", line 217, in run_suite raise TestFailed(msg) test.test_support.TestFailed: errors occurred; run in verbose mode for details D:\apps\Python23>python D:\apps\Python23\Lib\test\test_unicode_file.py File doesn't exist (encoded string) after creating it Traceback (most recent call last): File "D:\apps\Python23\Lib\test\test_unicode_file.py", line 37, in ? if os.stat(TESTFN_ENCODED) != os.stat(TESTFN_UNICODE): OSError: [Errno 2] No such file or directory: '@test-??' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663782&group_id=5470 From noreply@sourceforge.net Tue Jan 7 17:00:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 09:00:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-663397 ] Tru64 Unix macro problems Message-ID: Bugs item #663397, was opened at 2003-01-06 15:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663397&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: Tru64 Unix macro problems Initial Comment: Commands used for installing Python 2.3a1: ./configure --prefix=/usr/local_cci/Python-2.3a1 make make install Compilation of C++ code (Boost.Python library) fails. Here is a minimal example: % cat trouble.cpp #include #include #include % cxx -std strict_ansi -msg_disable 450 - I/usr/local_cci/Python-2.3a1/include/python2.3 -c trouble.cpp cxx: Warning: /usr/local_cci/Python- 2.3a1/include/python2.3/pyconfig.h, line 797: incompatible redefinition of macro "_OSF_SOURCE" (declared at line 206 of "/usr/include/standards.h") #define _OSF_SOURCE 1 --------^ cxx: Warning: /usr/local_cci/Python- 2.3a1/include/python2.3/pyconfig.h, line 804: incompatible redefinition of macro "_POSIX_C_SOURCE" (declared at line 198 of "/usr/include/standards.h") #define _POSIX_C_SOURCE 200112L --------^ cxx: Warning: /usr/local_cci/Python- 2.3a1/include/python2.3/pyconfig.h, line 816: incompatible redefinition of macro "_XOPEN_SOURCE" (declared at line 188 of "/usr/include/standards.h") #define _XOPEN_SOURCE 600 --------^ cxx: Error: /usr/include/sys/stat.h, line 204: identifier "blksize_t" is undefined __F64_STAT --------^ cxx: Error: /usr/include/sys/stat.h, line 204: identifier "blkcnt_t" is undefined __F64_STAT --------^ cxx: Info: 2 errors detected in the compilation of "trouble.cpp". I am glad to open an account on our machine if this could help in correcting the problem. Thanks, Ralf ---------------------------------------------------------------------- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-01-07 09:00 Message: Logged In: YES user_id=71407 - If all libraries took that attitude it would be impossible to combine them. - The macros in question are not documented in the Tru64 cc and cxx man pages. Therefore the user should not interfere with these macros. Even if the hacks in pyconfig.h work under certain circumstances, they are likely to cause complications with future versions of the compilers. - The restriction does not exist in Python <= 2.2. Why is it necessary to introduce the restriction now? - The new restriction will frustrate many users of the current Boost 1.29.0 release. - It is conceivable that other extension systems are also affected negatively. All these negative points could easily be eliminated with a more careful approach like this (pseudocode): #ifdef _OSF // maybe not the right symbol # include #endif #ifndef _OSF_SOURCE # define _OSF_SOURCE whatever #endif ... etc. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-07 04:59 Message: Logged In: YES user_id=21627 That's an error in your code. You must always include Python.h as the first header file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663397&group_id=5470 From noreply@sourceforge.net Mon Jan 6 20:02:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 12:02:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-662840 ] configure script fails with wchat_t size. Message-ID: Bugs item #662840, was opened at 2003-01-05 22:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662840&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nadav Horesh (nadavhoresh) Assigned to: Nobody/Anonymous (nobody) Summary: configure script fails with wchat_t size. Initial Comment: Python version 2.3a1 System RH 7.3 Compiler: gcc 3.2.1 The configure script bails out when trying to determain the size of wchar_t. The configure runs OK with gcc 2.96. . . . checking wchar.h usability... yes checking wchar.h presence... yes checking for wchar.h... yes checking for wchar_t... yes checking size of wchar_t... configure: error: cannot compute sizeof (wchar_t), 77 ---------------------------------------------------------------------- >Comment By: Nadav Horesh (nadavhoresh) Date: 2003-01-06 20:02 Message: Logged In: YES user_id=75473 Further info: On the same system (RH7.3+gcc3.2.1+PIII) I compliled python 2.2.2 without any problems. On another system: RH8.0 + gcc3.2.1 + dual PIII --- the configure script concluded without errors. I didn't try to compile though. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-05 23:12 Message: Logged In: YES user_id=21627 Can you please attach the resulting config.log? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662840&group_id=5470 From noreply@sourceforge.net Tue Jan 7 21:28:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 13:28:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-660476 ] readline and threads crashes Message-ID: Bugs item #660476, was opened at 2002-12-31 19:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660476&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Closed Resolution: Accepted Priority: 7 Submitted By: Michael Stone (mbrierst) Assigned to: Guido van Rossum (gvanrossum) Summary: readline and threads crashes Initial Comment: Python 2.2.2 with linux kernel 2.2.17 paste into the interpreter: import readline, rlcompleter readline.parse_and_bind('tab: complete') import thread import math def starter(a): for i in range(1000000): a = math.cos(i) thread.start_new_thread(starter, (1,)) now type any letter and hit segfault or "Fatal Python error: ceval: tstate mix-up" will occur, if not the first time, then eventually if you keep hitting tab this might be related to: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=513033 but I'm posting anyway as I'm not sure it's the same, and that one doesn't seem to be getting attention ---------------------------------------------------------------------- >Comment By: Michael Stone (mbrierst) Date: 2003-01-07 21:28 Message: Logged In: YES user_id=670441 great, but you should close the other bug that is the same as well. http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=513033 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-07 20:45 Message: Logged In: YES user_id=6380 Fixed. Thanks! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-07 20:33 Message: Logged In: YES user_id=6380 Thanks! The fix looks good and works. Checked in as readline.c 2.58. Will check into 2.2 maintenance branch too. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-07 18:59 Message: Logged In: YES user_id=6380 I can reproduce this in both 2.2.2 and 2.3CVS, on Linux. I've looked at the other bug report, and I agree that the explanation there is correct. The recipe to reproduce it matches that description. I'll review the patch shortly. Boy I am embarrassed that this has sat on SF since last March!!! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-31 20:58 Message: Logged In: YES user_id=6380 Will look after 2.3a1 is released. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-31 20:53 Message: Logged In: YES user_id=33168 I cannot replicate this for 2.3, but I get the crash for 2.2.2. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2002-12-31 20:33 Message: Logged In: YES user_id=670441 I don't claim to have a real good understanding of the python internals, but it seems like someone was doing some obviously wrong thread stuff. The diff below gives a fix that seems to solve my problems. After looking at it more, this does seem to be the same bug listed in the link in original comment. --- readline.c.old Tue Dec 31 15:15:45 2002 +++ readline.c Tue Dec 31 15:09:08 2002 @@ -404,16 +404,14 @@ /* C function to call the Python hooks. */ static int -on_hook(PyObject *func, PyThreadState *tstate) +on_hook(PyObject *func, PyThreadState **tstate) { int result = 0; if (func != NULL) { PyObject *r; - PyThreadState *save_tstate; /* Note that readline is called with the interpreter lock released! */ - save_tstate = PyThreadState_Swap(NULL); - PyEval_RestoreThread(tstate); + PyEval_RestoreThread(*tstate); r = PyObject_CallFunction(func, NULL); if (r == NULL) goto error; @@ -427,8 +425,7 @@ PyErr_Clear(); Py_XDECREF(r); done: - PyEval_SaveThread(); - PyThreadState_Swap(save_tstate); + *tstate = PyEval_SaveThread(); } return result; } @@ -436,14 +433,14 @@ static int on_startup_hook(void) { - return on_hook(startup_hook, startup_hook_tstate); + return on_hook(startup_hook, &startup_hook_tstate); } #ifdef HAVE_RL_PRE_INPUT_HOOK static int on_pre_input_hook(void) { - return on_hook(pre_input_hook, pre_input_hook_tstate); + return on_hook(pre_input_hook, &pre_input_hook_tstate); } #endif @@ -455,10 +452,8 @@ char *result = NULL; if (completer != NULL) { PyObject *r; - PyThreadState *save_tstate; /* Note that readline is called with the interpreter lock released! */ - save_tstate = PyThreadState_Swap(NULL); PyEval_RestoreThread(completer_tstate); r = PyObject_CallFunction(completer, "si", text, state); if (r == NULL) @@ -478,8 +473,7 @@ PyErr_Clear(); Py_XDECREF(r); done: - PyEval_SaveThread(); - PyThreadState_Swap(save_tstate); + completer_tstate = PyEval_SaveThread(); } return result; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660476&group_id=5470 From noreply@sourceforge.net Mon Jan 6 22:01:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 14:01:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-662840 ] configure script fails with wchat_t size. Message-ID: Bugs item #662840, was opened at 2003-01-05 23:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662840&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nadav Horesh (nadavhoresh) Assigned to: Nobody/Anonymous (nobody) Summary: configure script fails with wchat_t size. Initial Comment: Python version 2.3a1 System RH 7.3 Compiler: gcc 3.2.1 The configure script bails out when trying to determain the size of wchar_t. The configure runs OK with gcc 2.96. . . . checking wchar.h usability... yes checking wchar.h presence... yes checking for wchar.h... yes checking for wchar_t... yes checking size of wchar_t... configure: error: cannot compute sizeof (wchar_t), 77 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 23:01 Message: Logged In: YES user_id=21627 I see. The problem lies in these lines configure:15806: ./conftest ./configure: line 1: 6876 Segmentation fault ./conftest$ac_exeext Now, it is not clear why the test program (printed below these lines) could possible cause a segmentation fault - unless there is a bug in the compiler. So I would conclude this to be a gcc bug, on this configuration. It would be possible to track this further down, but that would require access to the machine, using a debugger, etc. ---------------------------------------------------------------------- Comment By: Nadav Horesh (nadavhoresh) Date: 2003-01-06 21:02 Message: Logged In: YES user_id=75473 Further info: On the same system (RH7.3+gcc3.2.1+PIII) I compliled python 2.2.2 without any problems. On another system: RH8.0 + gcc3.2.1 + dual PIII --- the configure script concluded without errors. I didn't try to compile though. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 00:12 Message: Logged In: YES user_id=21627 Can you please attach the resulting config.log? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662840&group_id=5470 From noreply@sourceforge.net Mon Jan 6 22:22:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 14:22:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-625725 ] Reorganize MacPython resources on OSX Message-ID: Bugs item #625725, was opened at 2002-10-19 23:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625725&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: Reorganize MacPython resources on OSX Initial Comment: The resource file for Python on OSX should be reorganized. Some of the resources are only used by specific modules such as EasyDialogs, these should go into private resource files. Some are used by the interpreter itself (The "Estr" resource that maps error numbers to strings comes to mind). The most obvious place for these would be the resource file of the framework, but these may also be useful in non-framework builds (where you now get the uninformative 'MacOS.Error: Error -1234'). ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-01-06 23:22 Message: Logged In: YES user_id=92689 Ok, I've played around a bit and it's certainly doable: I have a simple dialog running from a nib. It would still be a fairly major rewrite of EasyDialogs as DialogRef's are not supported in IBCarbon: must use straight windows. One thing that's missing is the ability to load nibs from a path, as opposed to finding them by name from an app bundle: for this we need to create Carbon.IBCarbon.CreateNibReferenceWithCFBundle(), and for that to work we need CFBundle support in Carbon.CF. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-01-06 13:04 Message: Logged In: YES user_id=45365 Yes, if you want to put some effort into this: please do! ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-06 12:33 Message: Logged In: YES user_id=92689 Wait, there already is Carbon.IBCarbon, cool! Shall I try to find out what it takes to convert EasyDialogs to use it? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-06 12:24 Message: Logged In: YES user_id=92689 Ok, I checked in a change to macresource.py to this effect (it simply adds sys.path to searchdirs, after os.path.dirname(__file__). Apart from Estr, how about trying to use nibs instead of res files? I think this is meant to work for OS9 as well, but would require interfacing some *FromNib API's in Carbon.Win and Carbon.Dlg. Just a thought. Either way, we should use a strict naming convention, eg. EasyDialogs.py's resources should be in a file called EasyDialogs.rsrc (and/or EasyDialogs.nib if we take the above route). ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-01-06 12:02 Message: Logged In: YES user_id=45365 Okay with me, as long as you look on sys.path *after* checking the __file__. So the order would be 1) Check wheter it happens to be available already 2) Check whether __file__ gives a clue 3) check sys.path An alternative solution would be that bundlebuilder takes the .rsrc file for each module automatically and combines them all (including errors.rsrc)into the resource file that is automatically opened when the .app starts (I think it's .rsrc, check the apple docs). A Python module in stead of the Estr resource I'm not too thrilled about: there are a lot of error messages, and if it was a Python module then they would all be in-core once you import the module. I'm assigning this over to you, close it when you're done (the rest of the reorganization is finished). ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-05 23:08 Message: Logged In: YES user_id=92689 The Estr resource: is this resource generated, and if so how? Would it be an idea to generate a Python module instead? The macresource module also has issues: eg. for EasyDialogs it looks for "dialogs.rsrc" in os.path.dirname(EasyDialogs.__file__), which doesn't work when EasyDialogs is loaded from a zip file. If it would (additionally) look on sys.path it could work for standalone apps created by bundlebuilder: it should simply be included in .app/Contents/Resources/ then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625725&group_id=5470 From noreply@sourceforge.net Mon Jan 6 23:00:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 15:00:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-623669 ] __rdiv__ vs new-style classes Message-ID: Bugs item #623669, was opened at 2002-10-15 14:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623669&group_id=5470 Category: Type/class unification Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Tim Peters (tim_one) Assigned to: Guido van Rossum (gvanrossum) Summary: __rdiv__ vs new-style classes Initial Comment: In 2.2.2 and 2.3, consider this: """ class F: def __init__(self): print 'built an F' def __div__(self, other): print 'in F.__div__' return F() def __rdiv__(self, other): print 'in F.__rdiv__' return F() / self class F2(F): def __init__(self): print 'built an F2' 3 / F2() """ This displays what I expect: """ built an F2 in F.__rdiv__ built an F in F.__div__ built an F """ However, change F to derive from object: class F(object): and it's in infinite recursion, starting like so: """ built an F2 in F.__rdiv__ built an F in F.__rdiv__ built an F in F.__rdiv__ built an F in F.__rdiv__ built an F in F.__rdiv__ built an F in F.__rdiv__ built an F in F.__rdiv__ ... """ Despite that F.__rdiv__ creates an explicit F() instance and uses it on the LHS of /, F.__div__ is never invoked; instead the RHS F2.__rdiv__ == F.__rdiv__ always gets the nod. Maybe this is intentional? I confess I've lost track of the rules. Changing the end of F.__rdiv__ to return F().__div__(self) brute-forces the desired outcome, so there is a workaround. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-06 18:00 Message: Logged In: YES user_id=6380 OK, I've checked in a fix that checks whether other actually overrides the __rdiv__ method (rather than ingeriting it from self.__class__). Sigh, this was hard work. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-06 17:02 Message: Logged In: YES user_id=6380 I've got a dilemma. The cause of the recursion is in line 3509 of typeobject.c, in the SLOT1BINFULL() macro. The section starting with if (do_other && \ (introduced by rev 2.82 of thatfile) tries to call the right operand's __rdiv__ *before* the left operand's __div__ is called in the specific case where both operands are new-style classes that implement __div__ and __rdiv__. This is intended to "do the right thing" in cases where D derives from C and overrides some operation, and you call C()/D(); without that code section, C.__div__ would be invoked before D.__rdiv__, and since D() is a C instance, C.__div__ would probably return a result -- just not the result that D.__rdiv__ would have given. The endless recursion reported above is caused by the fact that D satisfies all the criteria, but D.__rdiv__ is really just C.__rdiv__, which calls C()/D() recursively. My dilemma is that this feature is not documented, and classic classes don't work this way (C.__div__ would be called). There are also no unit tests for the feature. So ripping it out would be the quickest way to avoid the recursion. OTOH, binary_op1() in abstract.c contains similar code that catches a similar case where the base class C is a built-in type (e.g. int). (Also undocumented and also without unit tests.) But checking that D's __rdiv__ is really the same as C's __rdiv__ before calling it is fairly expensive and convoluted (imagine the case where there's an intermediate class C1, so that D derives from C1 derives from C, and C1 overrides C.__rdiv__). And even then one could construct cases that would fool the test. I'm going to think about this some more... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=623669&group_id=5470 From noreply@sourceforge.net Mon Jan 6 23:02:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 15:02:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-642358 ] metaclass causes __dict__ to be dict Message-ID: Bugs item #642358, was opened at 2002-11-22 11:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=642358&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None >Priority: 9 Submitted By: Jeremy Hylton (jhylton) Assigned to: Guido van Rossum (gvanrossum) Summary: metaclass causes __dict__ to be dict Initial Comment: class Meta(type): def __new__(meta, name, bases, dict): return super(Meta, name).__new__(meta, name, bases, dict) class AClass: __metaclass__ = Meta print type(AClass.__dict__) With 2.2.2, this prints dict-proxy. With 2.3, this prints dict. As you noted, it should always be a dict-proxy to prevent people from getting the __dict__ and the tp slots out of sync. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-06 18:02 Message: Logged In: YES user_id=6380 I should address this next, since it apparently causes Zope3 problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=642358&group_id=5470 From noreply@sourceforge.net Mon Jan 6 23:43:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 15:43:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-663397 ] Tru64 Unix macro problems Message-ID: Bugs item #663397, was opened at 2003-01-06 15:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663397&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: Tru64 Unix macro problems Initial Comment: Commands used for installing Python 2.3a1: ./configure --prefix=/usr/local_cci/Python-2.3a1 make make install Compilation of C++ code (Boost.Python library) fails. Here is a minimal example: % cat trouble.cpp #include #include #include % cxx -std strict_ansi -msg_disable 450 - I/usr/local_cci/Python-2.3a1/include/python2.3 -c trouble.cpp cxx: Warning: /usr/local_cci/Python- 2.3a1/include/python2.3/pyconfig.h, line 797: incompatible redefinition of macro "_OSF_SOURCE" (declared at line 206 of "/usr/include/standards.h") #define _OSF_SOURCE 1 --------^ cxx: Warning: /usr/local_cci/Python- 2.3a1/include/python2.3/pyconfig.h, line 804: incompatible redefinition of macro "_POSIX_C_SOURCE" (declared at line 198 of "/usr/include/standards.h") #define _POSIX_C_SOURCE 200112L --------^ cxx: Warning: /usr/local_cci/Python- 2.3a1/include/python2.3/pyconfig.h, line 816: incompatible redefinition of macro "_XOPEN_SOURCE" (declared at line 188 of "/usr/include/standards.h") #define _XOPEN_SOURCE 600 --------^ cxx: Error: /usr/include/sys/stat.h, line 204: identifier "blksize_t" is undefined __F64_STAT --------^ cxx: Error: /usr/include/sys/stat.h, line 204: identifier "blkcnt_t" is undefined __F64_STAT --------^ cxx: Info: 2 errors detected in the compilation of "trouble.cpp". I am glad to open an account on our machine if this could help in correcting the problem. Thanks, Ralf ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663397&group_id=5470 From noreply@sourceforge.net Tue Jan 7 00:10:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 16:10:55 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-633543 ] Korean support, unknown charsets Message-ID: Feature Requests item #633543, was opened at 2002-11-04 16:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=633543&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Korean support, unknown charsets Initial Comment: The following patch needs to be integrated into the email package: http://article.gmane.org/gmane.comp.python.mime.devel/250 Most of it was delayed due to the impending Python 2.2.2 release, but the patch is important, and I don't want to see the work lost. ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2003-01-06 17:10 Message: Logged In: YES user_id=85984 Can't this be applied to CVS? It's a no-brainer, but until it's applied, it makes it difficult for me to sync the official email package with my working copy, as right now this is the only difference. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-11-05 16:05 Message: Logged In: YES user_id=85984 See http://article.gmane.org/gmane.comp.python.mime.devel/319 for the Charset.py portion of the patch against current CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=633543&group_id=5470 From noreply@sourceforge.net Tue Jan 7 00:30:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 16:30:29 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-633543 ] Korean support, unknown charsets Message-ID: Feature Requests item #633543, was opened at 2002-11-04 18:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=633543&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) >Assigned to: Ben Gertzfield (che_fox) Summary: Korean support, unknown charsets Initial Comment: The following patch needs to be integrated into the email package: http://article.gmane.org/gmane.comp.python.mime.devel/250 Most of it was delayed due to the impending Python 2.2.2 release, but the patch is important, and I don't want to see the work lost. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-06 19:30 Message: Logged In: YES user_id=12800 Jason, all you want are the CHARSETS, ALIASES, and CODEC_MAP entries in Charset.py from the referenced article, right? I think everything else is in there now. I'll commit these changes, and close this request, but here's a question for Ben: shouldn't we uncomment the iso-8859-* entries in CHARSETS and set them to BASE64? If not, why? :) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2003-01-06 19:10 Message: Logged In: YES user_id=85984 Can't this be applied to CVS? It's a no-brainer, but until it's applied, it makes it difficult for me to sync the official email package with my working copy, as right now this is the only difference. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-11-05 18:05 Message: Logged In: YES user_id=85984 See http://article.gmane.org/gmane.comp.python.mime.devel/319 for the Charset.py portion of the patch against current CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=633543&group_id=5470 From noreply@sourceforge.net Tue Jan 7 00:51:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 16:51:35 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-633543 ] Korean support, unknown charsets Message-ID: Feature Requests item #633543, was opened at 2002-11-04 16:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=633543&group_id=5470 Category: Python Library Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Ben Gertzfield (che_fox) Summary: Korean support, unknown charsets Initial Comment: The following patch needs to be integrated into the email package: http://article.gmane.org/gmane.comp.python.mime.devel/250 Most of it was delayed due to the impending Python 2.2.2 release, but the patch is important, and I don't want to see the work lost. ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2003-01-06 17:51 Message: Logged In: YES user_id=85984 That's correct, all I need are the updates to CHARSETS, ALIASES, and CODEC_MAP. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-06 17:30 Message: Logged In: YES user_id=12800 Jason, all you want are the CHARSETS, ALIASES, and CODEC_MAP entries in Charset.py from the referenced article, right? I think everything else is in there now. I'll commit these changes, and close this request, but here's a question for Ben: shouldn't we uncomment the iso-8859-* entries in CHARSETS and set them to BASE64? If not, why? :) ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2003-01-06 17:10 Message: Logged In: YES user_id=85984 Can't this be applied to CVS? It's a no-brainer, but until it's applied, it makes it difficult for me to sync the official email package with my working copy, as right now this is the only difference. ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-11-05 16:05 Message: Logged In: YES user_id=85984 See http://article.gmane.org/gmane.comp.python.mime.devel/319 for the Charset.py portion of the patch against current CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=633543&group_id=5470 From noreply@sourceforge.net Tue Jan 7 03:43:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 06 Jan 2003 19:43:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-658254 ] Accept None for time.ctime() and friends Message-ID: Bugs item #658254, was opened at 2002-12-24 11:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658254&group_id=5470 Category: Extension Modules Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: Accept None for time.ctime() and friends Initial Comment: Several functions in the time module can have the time value they operate on omitted to indicate the current time, but they do not accept None as equivalent to omitting the value. It should be equivalent. ---------------------------------------------------------------------- Comment By: Christopher Blunck (blunck2) Date: 2003-01-06 22:43 Message: Logged In: YES user_id=531881 see patch 663482 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658254&group_id=5470 From noreply@sourceforge.net Tue Jan 7 22:22:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 14:22:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-513033 ] unsafe call to PyThreadState_Swap Message-ID: Bugs item #513033, was opened at 2002-02-04 18:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=513033&group_id=5470 Category: Python Library Group: Python 2.2.1 candidate >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jake McGuire (jamcguir) Assigned to: Guido van Rossum (gvanrossum) Summary: unsafe call to PyThreadState_Swap Initial Comment: It appears that there is a blatantly unsafe call to PyThreadState_Swap in the functions on_hook and on_completer in Modules/Readline.c The diff adding these calls is viewable at http://cvs.sourceforge.net/cgi- bin/viewcvs.cgi/python/python/dist/src/Modules/readline .c.diff?r1=2.5&r2=2.6&only_with_tag=MAIN The call to PyThreadState_Swap is added directly below a comment pointing out that readline() is called with the interpreter lock released. Viewing the code shows that the interpreter lock is indeed released before calling readline (in myreadline.c). Multithreaded programs that define callback functions suffer from intermittent crashes, often Py_FatalError- ing claiming "tstate mix-up" from ceval.c Removing the calls to PyThreadState_Swap makes these problems go away. Can someone explain how the call to PyThreadState_Swap is indeed the right thing to be doing? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 17:22 Message: Logged In: YES user_id=33168 Closing this since it seems to be fixed as part of 660476 according to checkin comment and messages in the bug reports. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2002-12-31 15:50 Message: Logged In: YES user_id=670441 That PyThreadState_Swap sure looks wrong to me. The code before the diff you reference also looks wrong though. See my posting under bug 660476 for a fix. (My bug is the same as yours, but I didn't realize it when I posted it) ---------------------------------------------------------------------- Comment By: Stephan A. Terre (sfiedler) Date: 2002-06-11 17:09 Message: Logged In: YES user_id=246063 Just wanted to note that this problem is affecting my users as well, I believe in the on_completion branch rather than the on_hook branch. We're using Python to write multi-threaded scientific applications; with other Python threads active, pressing TAB for interactive completion occasionally yields the tstate mix-up. We are perfectly happy to wait for Python 2.3 for a fix. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-17 22:15 Message: Logged In: YES user_id=6380 That's ancient history and will take some time to wrap my brains around. I don't have time for this tonight, maybe tomorrow but I doubt the priority can be raised enough to catch my attention long enough to matter. But it should be fixed for 2.3. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-03-16 12:40 Message: Logged In: YES user_id=6656 jamcguir (or indeed anyone else), can you provide a patch for this pronto? I'd kind of like to have it fixed in 2.2.1, but this is obscure enough that I'm not going to hold up the release for it. ---------------------------------------------------------------------- Comment By: Jake McGuire (jamcguir) Date: 2002-02-04 18:55 Message: Logged In: YES user_id=448911 Unfortunately, the scenario isn't really *simple*. I think it goes like this: Thread A defines a readline startup hook. Thread A calls PyOS_Readline() in myreadline.c Thread A calls Py_BEGIN_ALLOW_THREADS, saving its thread state and setting the global thread state to NULL. Thread A calls readline. Thread A gets blocked, and Thread B gets scheduled. Thread B grabs the global interpreter lock, and restores its thread state. Thread B gets suspended, and Thread A gets scheduled. -- note: Thread B has the intepreter lock -- Thread A calls PyThreadState_Swap in on_hook(), setting the current global thread state to NULL Thread A calls PyEval_RestoreThread, which blocks waiting for the global interpreter lock Thread B gets scheduled, tries to run, but finds that the global thread state is NULL. Bad things happen. Proposed solution: Change Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS in myreadline.c:PyOS_Readline to calls to PyEval_SaveThread and PyEval_RestoreThread. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-02-04 18:41 Message: Logged In: YES user_id=31435 Guido's checkin comment said: """ Darn. When thread support is disabled, the BEGIN/END macros don't save and restore the tstate, but explicitly calling PyEval_SaveThread() does reset it! While I think about how to fix this for real, here's a fix that avoids getting a fatal error. """ Therefore I assigned the bug to Guido . It would help if you could describe a specific simple scenario that provokes the problems you're seeing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=513033&group_id=5470 From noreply@sourceforge.net Tue Jan 7 22:35:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 14:35:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-664044 ] Lib Man 2.2.6.2 word change Message-ID: Bugs item #664044, was opened at 2003-01-07 17:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=664044&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Terry J. Reedy (tjreedy) Assigned to: Nobody/Anonymous (nobody) Summary: Lib Man 2.2.6.2 word change Initial Comment: In the conversion types table, the 's' line s String (converts any python object using str()). should have 'non-unicode' substituted for or inserted before 'python' to be consistent with both the last sentence of the first paragraph and current (2.2.1) behavior. This non-updated line has fooled at least one person (clp poster). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=664044&group_id=5470 From noreply@sourceforge.net Tue Jan 7 13:43:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 05:43:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-642358 ] metaclass causes __dict__ to be dict Message-ID: Bugs item #642358, was opened at 2002-11-22 11:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=642358&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Fixed Priority: 9 Submitted By: Jeremy Hylton (jhylton) Assigned to: Guido van Rossum (gvanrossum) Summary: metaclass causes __dict__ to be dict Initial Comment: class Meta(type): def __new__(meta, name, bases, dict): return super(Meta, name).__new__(meta, name, bases, dict) class AClass: __metaclass__ = Meta print type(AClass.__dict__) With 2.2.2, this prints dict-proxy. With 2.3, this prints dict. As you noted, it should always be a dict-proxy to prevent people from getting the __dict__ and the tp slots out of sync. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-07 08:43 Message: Logged In: YES user_id=6380 This one was easy. Fixed as typeobject.c rev 2.202. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-07 07:47 Message: Logged In: YES user_id=6380 I think why this is. type_new() now always adds a __dict__ descriptor. Will have to be more subtle than that... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-06 18:02 Message: Logged In: YES user_id=6380 I should address this next, since it apparently causes Zope3 problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=642358&group_id=5470 From noreply@sourceforge.net Tue Jan 7 12:47:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 04:47:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-642358 ] metaclass causes __dict__ to be dict Message-ID: Bugs item #642358, was opened at 2002-11-22 11:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=642358&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 9 Submitted By: Jeremy Hylton (jhylton) Assigned to: Guido van Rossum (gvanrossum) Summary: metaclass causes __dict__ to be dict Initial Comment: class Meta(type): def __new__(meta, name, bases, dict): return super(Meta, name).__new__(meta, name, bases, dict) class AClass: __metaclass__ = Meta print type(AClass.__dict__) With 2.2.2, this prints dict-proxy. With 2.3, this prints dict. As you noted, it should always be a dict-proxy to prevent people from getting the __dict__ and the tp slots out of sync. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-07 07:47 Message: Logged In: YES user_id=6380 I think why this is. type_new() now always adds a __dict__ descriptor. Will have to be more subtle than that... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-06 18:02 Message: Logged In: YES user_id=6380 I should address this next, since it apparently causes Zope3 problems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=642358&group_id=5470 From noreply@sourceforge.net Tue Jan 7 12:59:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 04:59:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-663397 ] Tru64 Unix macro problems Message-ID: Bugs item #663397, was opened at 2003-01-07 00:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663397&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: Tru64 Unix macro problems Initial Comment: Commands used for installing Python 2.3a1: ./configure --prefix=/usr/local_cci/Python-2.3a1 make make install Compilation of C++ code (Boost.Python library) fails. Here is a minimal example: % cat trouble.cpp #include #include #include % cxx -std strict_ansi -msg_disable 450 - I/usr/local_cci/Python-2.3a1/include/python2.3 -c trouble.cpp cxx: Warning: /usr/local_cci/Python- 2.3a1/include/python2.3/pyconfig.h, line 797: incompatible redefinition of macro "_OSF_SOURCE" (declared at line 206 of "/usr/include/standards.h") #define _OSF_SOURCE 1 --------^ cxx: Warning: /usr/local_cci/Python- 2.3a1/include/python2.3/pyconfig.h, line 804: incompatible redefinition of macro "_POSIX_C_SOURCE" (declared at line 198 of "/usr/include/standards.h") #define _POSIX_C_SOURCE 200112L --------^ cxx: Warning: /usr/local_cci/Python- 2.3a1/include/python2.3/pyconfig.h, line 816: incompatible redefinition of macro "_XOPEN_SOURCE" (declared at line 188 of "/usr/include/standards.h") #define _XOPEN_SOURCE 600 --------^ cxx: Error: /usr/include/sys/stat.h, line 204: identifier "blksize_t" is undefined __F64_STAT --------^ cxx: Error: /usr/include/sys/stat.h, line 204: identifier "blkcnt_t" is undefined __F64_STAT --------^ cxx: Info: 2 errors detected in the compilation of "trouble.cpp". I am glad to open an account on our machine if this could help in correcting the problem. Thanks, Ralf ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-07 13:59 Message: Logged In: YES user_id=21627 That's an error in your code. You must always include Python.h as the first header file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663397&group_id=5470 From noreply@sourceforge.net Tue Jan 7 22:44:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 14:44:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-663701 ] sets module review Message-ID: Bugs item #663701, was opened at 2003-01-07 09:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663701&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sebastien Keim (s_keim) Assigned to: Nobody/Anonymous (nobody) Summary: sets module review Initial Comment: * the ^ operator doesnt print well in pdf generated documentation (both in what's new and in library reference) * shouldn't the _as_immutable and _as_temporaly_immutable be spelled __as_immutable__ and __as_temporaly_immutable__ for consistency with other hook methods? * cmp() suck: 
bash-2.05$ ./python 
Python 2.3a1 (#1, Jan  4 2003, 10:17:56) 
[GCC 2.95.3 20010315 (release)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import sets
>>> s = sets.Set
>>> a = s([0])
>>> b = s([1])
>>> cmp(a,b)
1
>>> 
bash-2.05$ ./python 
Python 2.3a1 (#1, Jan  4 2003, 10:17:56) 
[GCC 2.95.3 20010315 (release)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import sets
>>> a=sets.Set([0])
>>> b=sets.Set([1])
>>> cmp(a,b)
-1
* Because we can have set1!=set2 and both (set1 behavior? ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-01-07 17:44 Message: Logged In: YES user_id=593130 If/when sets become builtin, would type object be called 'set' or break current convention by being called 'Set'? If the former, I think classSet should be 'set' now so one can write 'from sets import set' and have rest of code ready for the future. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663701&group_id=5470 From noreply@sourceforge.net Tue Jan 7 18:59:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 10:59:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-660476 ] readline and threads crashes Message-ID: Bugs item #660476, was opened at 2002-12-31 14:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660476&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Open Resolution: None Priority: 7 Submitted By: Michael Stone (mbrierst) Assigned to: Guido van Rossum (gvanrossum) Summary: readline and threads crashes Initial Comment: Python 2.2.2 with linux kernel 2.2.17 paste into the interpreter: import readline, rlcompleter readline.parse_and_bind('tab: complete') import thread import math def starter(a): for i in range(1000000): a = math.cos(i) thread.start_new_thread(starter, (1,)) now type any letter and hit segfault or "Fatal Python error: ceval: tstate mix-up" will occur, if not the first time, then eventually if you keep hitting tab this might be related to: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=513033 but I'm posting anyway as I'm not sure it's the same, and that one doesn't seem to be getting attention ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-07 13:59 Message: Logged In: YES user_id=6380 I can reproduce this in both 2.2.2 and 2.3CVS, on Linux. I've looked at the other bug report, and I agree that the explanation there is correct. The recipe to reproduce it matches that description. I'll review the patch shortly. Boy I am embarrassed that this has sat on SF since last March!!! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-31 15:58 Message: Logged In: YES user_id=6380 Will look after 2.3a1 is released. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-31 15:53 Message: Logged In: YES user_id=33168 I cannot replicate this for 2.3, but I get the crash for 2.2.2. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2002-12-31 15:33 Message: Logged In: YES user_id=670441 I don't claim to have a real good understanding of the python internals, but it seems like someone was doing some obviously wrong thread stuff. The diff below gives a fix that seems to solve my problems. After looking at it more, this does seem to be the same bug listed in the link in original comment. --- readline.c.old Tue Dec 31 15:15:45 2002 +++ readline.c Tue Dec 31 15:09:08 2002 @@ -404,16 +404,14 @@ /* C function to call the Python hooks. */ static int -on_hook(PyObject *func, PyThreadState *tstate) +on_hook(PyObject *func, PyThreadState **tstate) { int result = 0; if (func != NULL) { PyObject *r; - PyThreadState *save_tstate; /* Note that readline is called with the interpreter lock released! */ - save_tstate = PyThreadState_Swap(NULL); - PyEval_RestoreThread(tstate); + PyEval_RestoreThread(*tstate); r = PyObject_CallFunction(func, NULL); if (r == NULL) goto error; @@ -427,8 +425,7 @@ PyErr_Clear(); Py_XDECREF(r); done: - PyEval_SaveThread(); - PyThreadState_Swap(save_tstate); + *tstate = PyEval_SaveThread(); } return result; } @@ -436,14 +433,14 @@ static int on_startup_hook(void) { - return on_hook(startup_hook, startup_hook_tstate); + return on_hook(startup_hook, &startup_hook_tstate); } #ifdef HAVE_RL_PRE_INPUT_HOOK static int on_pre_input_hook(void) { - return on_hook(pre_input_hook, pre_input_hook_tstate); + return on_hook(pre_input_hook, &pre_input_hook_tstate); } #endif @@ -455,10 +452,8 @@ char *result = NULL; if (completer != NULL) { PyObject *r; - PyThreadState *save_tstate; /* Note that readline is called with the interpreter lock released! */ - save_tstate = PyThreadState_Swap(NULL); PyEval_RestoreThread(completer_tstate); r = PyObject_CallFunction(completer, "si", text, state); if (r == NULL) @@ -478,8 +473,7 @@ PyErr_Clear(); Py_XDECREF(r); done: - PyEval_SaveThread(); - PyThreadState_Swap(save_tstate); + completer_tstate = PyEval_SaveThread(); } return result; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660476&group_id=5470 From noreply@sourceforge.net Tue Jan 7 20:19:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 12:19:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-663397 ] Tru64 Unix macro problems Message-ID: Bugs item #663397, was opened at 2003-01-07 00:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663397&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: Tru64 Unix macro problems Initial Comment: Commands used for installing Python 2.3a1: ./configure --prefix=/usr/local_cci/Python-2.3a1 make make install Compilation of C++ code (Boost.Python library) fails. Here is a minimal example: % cat trouble.cpp #include #include #include % cxx -std strict_ansi -msg_disable 450 - I/usr/local_cci/Python-2.3a1/include/python2.3 -c trouble.cpp cxx: Warning: /usr/local_cci/Python- 2.3a1/include/python2.3/pyconfig.h, line 797: incompatible redefinition of macro "_OSF_SOURCE" (declared at line 206 of "/usr/include/standards.h") #define _OSF_SOURCE 1 --------^ cxx: Warning: /usr/local_cci/Python- 2.3a1/include/python2.3/pyconfig.h, line 804: incompatible redefinition of macro "_POSIX_C_SOURCE" (declared at line 198 of "/usr/include/standards.h") #define _POSIX_C_SOURCE 200112L --------^ cxx: Warning: /usr/local_cci/Python- 2.3a1/include/python2.3/pyconfig.h, line 816: incompatible redefinition of macro "_XOPEN_SOURCE" (declared at line 188 of "/usr/include/standards.h") #define _XOPEN_SOURCE 600 --------^ cxx: Error: /usr/include/sys/stat.h, line 204: identifier "blksize_t" is undefined __F64_STAT --------^ cxx: Error: /usr/include/sys/stat.h, line 204: identifier "blkcnt_t" is undefined __F64_STAT --------^ cxx: Info: 2 errors detected in the compilation of "trouble.cpp". I am glad to open an account on our machine if this could help in correcting the problem. Thanks, Ralf ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-07 21:19 Message: Logged In: YES user_id=21627 > If all libraries took that attitude it would be impossible to > combine them. Irrelevant for the bug in question. There are no other libraries. > The macros in question are not documented in the Tru64 cc > and cxx man pages. _POSIX_C_SOURCE is defined by the POSIX standards. POSIX specifies that applications must define it before including system headers. Same for _XOPEN_SOURCE _OSF_SOURCE is defined in standards(5). > The restriction does not exist in Python <= 2.2. This is not true. It existed in all Python versions. You may not have noticed, which might be either because you only got silent errors, or because there happened to be no errors on your platform. > The new restriction will frustrate many users of the current > Boost 1.29.0 release. The users will get over their frustration. > It is conceivable that other extension systems are also > affected negatively. Not relevant for this bug report. > #ifdef _OSF // maybe not the right symbol > # include > #endif > #ifndef _OSF_SOURCE > # define _OSF_SOURCE whatever > #endif This would be stupid, and incorrect. _OSF_SOURCE must be defined before any system header is included, or else it does not have the desired effect. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-01-07 18:00 Message: Logged In: YES user_id=71407 - If all libraries took that attitude it would be impossible to combine them. - The macros in question are not documented in the Tru64 cc and cxx man pages. Therefore the user should not interfere with these macros. Even if the hacks in pyconfig.h work under certain circumstances, they are likely to cause complications with future versions of the compilers. - The restriction does not exist in Python <= 2.2. Why is it necessary to introduce the restriction now? - The new restriction will frustrate many users of the current Boost 1.29.0 release. - It is conceivable that other extension systems are also affected negatively. All these negative points could easily be eliminated with a more careful approach like this (pseudocode): #ifdef _OSF // maybe not the right symbol # include #endif #ifndef _OSF_SOURCE # define _OSF_SOURCE whatever #endif ... etc. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-07 13:59 Message: Logged In: YES user_id=21627 That's an error in your code. You must always include Python.h as the first header file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663397&group_id=5470 From noreply@sourceforge.net Tue Jan 7 20:33:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 12:33:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-660476 ] readline and threads crashes Message-ID: Bugs item #660476, was opened at 2002-12-31 14:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660476&group_id=5470 Category: Threads Group: Python 2.2.2 >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Michael Stone (mbrierst) Assigned to: Guido van Rossum (gvanrossum) Summary: readline and threads crashes Initial Comment: Python 2.2.2 with linux kernel 2.2.17 paste into the interpreter: import readline, rlcompleter readline.parse_and_bind('tab: complete') import thread import math def starter(a): for i in range(1000000): a = math.cos(i) thread.start_new_thread(starter, (1,)) now type any letter and hit segfault or "Fatal Python error: ceval: tstate mix-up" will occur, if not the first time, then eventually if you keep hitting tab this might be related to: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=513033 but I'm posting anyway as I'm not sure it's the same, and that one doesn't seem to be getting attention ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-07 15:33 Message: Logged In: YES user_id=6380 Thanks! The fix looks good and works. Checked in as readline.c 2.58. Will check into 2.2 maintenance branch too. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-07 13:59 Message: Logged In: YES user_id=6380 I can reproduce this in both 2.2.2 and 2.3CVS, on Linux. I've looked at the other bug report, and I agree that the explanation there is correct. The recipe to reproduce it matches that description. I'll review the patch shortly. Boy I am embarrassed that this has sat on SF since last March!!! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-31 15:58 Message: Logged In: YES user_id=6380 Will look after 2.3a1 is released. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-31 15:53 Message: Logged In: YES user_id=33168 I cannot replicate this for 2.3, but I get the crash for 2.2.2. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2002-12-31 15:33 Message: Logged In: YES user_id=670441 I don't claim to have a real good understanding of the python internals, but it seems like someone was doing some obviously wrong thread stuff. The diff below gives a fix that seems to solve my problems. After looking at it more, this does seem to be the same bug listed in the link in original comment. --- readline.c.old Tue Dec 31 15:15:45 2002 +++ readline.c Tue Dec 31 15:09:08 2002 @@ -404,16 +404,14 @@ /* C function to call the Python hooks. */ static int -on_hook(PyObject *func, PyThreadState *tstate) +on_hook(PyObject *func, PyThreadState **tstate) { int result = 0; if (func != NULL) { PyObject *r; - PyThreadState *save_tstate; /* Note that readline is called with the interpreter lock released! */ - save_tstate = PyThreadState_Swap(NULL); - PyEval_RestoreThread(tstate); + PyEval_RestoreThread(*tstate); r = PyObject_CallFunction(func, NULL); if (r == NULL) goto error; @@ -427,8 +425,7 @@ PyErr_Clear(); Py_XDECREF(r); done: - PyEval_SaveThread(); - PyThreadState_Swap(save_tstate); + *tstate = PyEval_SaveThread(); } return result; } @@ -436,14 +433,14 @@ static int on_startup_hook(void) { - return on_hook(startup_hook, startup_hook_tstate); + return on_hook(startup_hook, &startup_hook_tstate); } #ifdef HAVE_RL_PRE_INPUT_HOOK static int on_pre_input_hook(void) { - return on_hook(pre_input_hook, pre_input_hook_tstate); + return on_hook(pre_input_hook, &pre_input_hook_tstate); } #endif @@ -455,10 +452,8 @@ char *result = NULL; if (completer != NULL) { PyObject *r; - PyThreadState *save_tstate; /* Note that readline is called with the interpreter lock released! */ - save_tstate = PyThreadState_Swap(NULL); PyEval_RestoreThread(completer_tstate); r = PyObject_CallFunction(completer, "si", text, state); if (r == NULL) @@ -478,8 +473,7 @@ PyErr_Clear(); Py_XDECREF(r); done: - PyEval_SaveThread(); - PyThreadState_Swap(save_tstate); + completer_tstate = PyEval_SaveThread(); } return result; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660476&group_id=5470 From noreply@sourceforge.net Tue Jan 7 20:45:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 12:45:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-660476 ] readline and threads crashes Message-ID: Bugs item #660476, was opened at 2002-12-31 14:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660476&group_id=5470 Category: Threads Group: Python 2.2.2 Status: Closed Resolution: Accepted Priority: 7 Submitted By: Michael Stone (mbrierst) Assigned to: Guido van Rossum (gvanrossum) Summary: readline and threads crashes Initial Comment: Python 2.2.2 with linux kernel 2.2.17 paste into the interpreter: import readline, rlcompleter readline.parse_and_bind('tab: complete') import thread import math def starter(a): for i in range(1000000): a = math.cos(i) thread.start_new_thread(starter, (1,)) now type any letter and hit segfault or "Fatal Python error: ceval: tstate mix-up" will occur, if not the first time, then eventually if you keep hitting tab this might be related to: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=513033 but I'm posting anyway as I'm not sure it's the same, and that one doesn't seem to be getting attention ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-07 15:45 Message: Logged In: YES user_id=6380 Fixed. Thanks! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-07 15:33 Message: Logged In: YES user_id=6380 Thanks! The fix looks good and works. Checked in as readline.c 2.58. Will check into 2.2 maintenance branch too. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-07 13:59 Message: Logged In: YES user_id=6380 I can reproduce this in both 2.2.2 and 2.3CVS, on Linux. I've looked at the other bug report, and I agree that the explanation there is correct. The recipe to reproduce it matches that description. I'll review the patch shortly. Boy I am embarrassed that this has sat on SF since last March!!! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-31 15:58 Message: Logged In: YES user_id=6380 Will look after 2.3a1 is released. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-31 15:53 Message: Logged In: YES user_id=33168 I cannot replicate this for 2.3, but I get the crash for 2.2.2. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2002-12-31 15:33 Message: Logged In: YES user_id=670441 I don't claim to have a real good understanding of the python internals, but it seems like someone was doing some obviously wrong thread stuff. The diff below gives a fix that seems to solve my problems. After looking at it more, this does seem to be the same bug listed in the link in original comment. --- readline.c.old Tue Dec 31 15:15:45 2002 +++ readline.c Tue Dec 31 15:09:08 2002 @@ -404,16 +404,14 @@ /* C function to call the Python hooks. */ static int -on_hook(PyObject *func, PyThreadState *tstate) +on_hook(PyObject *func, PyThreadState **tstate) { int result = 0; if (func != NULL) { PyObject *r; - PyThreadState *save_tstate; /* Note that readline is called with the interpreter lock released! */ - save_tstate = PyThreadState_Swap(NULL); - PyEval_RestoreThread(tstate); + PyEval_RestoreThread(*tstate); r = PyObject_CallFunction(func, NULL); if (r == NULL) goto error; @@ -427,8 +425,7 @@ PyErr_Clear(); Py_XDECREF(r); done: - PyEval_SaveThread(); - PyThreadState_Swap(save_tstate); + *tstate = PyEval_SaveThread(); } return result; } @@ -436,14 +433,14 @@ static int on_startup_hook(void) { - return on_hook(startup_hook, startup_hook_tstate); + return on_hook(startup_hook, &startup_hook_tstate); } #ifdef HAVE_RL_PRE_INPUT_HOOK static int on_pre_input_hook(void) { - return on_hook(pre_input_hook, pre_input_hook_tstate); + return on_hook(pre_input_hook, &pre_input_hook_tstate); } #endif @@ -455,10 +452,8 @@ char *result = NULL; if (completer != NULL) { PyObject *r; - PyThreadState *save_tstate; /* Note that readline is called with the interpreter lock released! */ - save_tstate = PyThreadState_Swap(NULL); PyEval_RestoreThread(completer_tstate); r = PyObject_CallFunction(completer, "si", text, state); if (r == NULL) @@ -478,8 +473,7 @@ PyErr_Clear(); Py_XDECREF(r); done: - PyEval_SaveThread(); - PyThreadState_Swap(save_tstate); + completer_tstate = PyEval_SaveThread(); } return result; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660476&group_id=5470 From noreply@sourceforge.net Wed Jan 8 00:10:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 16:10:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-663397 ] Tru64 Unix macro problems Message-ID: Bugs item #663397, was opened at 2003-01-07 00:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663397&group_id=5470 Category: Extension Modules Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: Tru64 Unix macro problems Initial Comment: Commands used for installing Python 2.3a1: ./configure --prefix=/usr/local_cci/Python-2.3a1 make make install Compilation of C++ code (Boost.Python library) fails. Here is a minimal example: % cat trouble.cpp #include #include #include % cxx -std strict_ansi -msg_disable 450 - I/usr/local_cci/Python-2.3a1/include/python2.3 -c trouble.cpp cxx: Warning: /usr/local_cci/Python- 2.3a1/include/python2.3/pyconfig.h, line 797: incompatible redefinition of macro "_OSF_SOURCE" (declared at line 206 of "/usr/include/standards.h") #define _OSF_SOURCE 1 --------^ cxx: Warning: /usr/local_cci/Python- 2.3a1/include/python2.3/pyconfig.h, line 804: incompatible redefinition of macro "_POSIX_C_SOURCE" (declared at line 198 of "/usr/include/standards.h") #define _POSIX_C_SOURCE 200112L --------^ cxx: Warning: /usr/local_cci/Python- 2.3a1/include/python2.3/pyconfig.h, line 816: incompatible redefinition of macro "_XOPEN_SOURCE" (declared at line 188 of "/usr/include/standards.h") #define _XOPEN_SOURCE 600 --------^ cxx: Error: /usr/include/sys/stat.h, line 204: identifier "blksize_t" is undefined __F64_STAT --------^ cxx: Error: /usr/include/sys/stat.h, line 204: identifier "blkcnt_t" is undefined __F64_STAT --------^ cxx: Info: 2 errors detected in the compilation of "trouble.cpp". I am glad to open an account on our machine if this could help in correcting the problem. Thanks, Ralf ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-08 01:10 Message: Logged In: YES user_id=21627 > Is this a documented restriction? See http://www.python.org/doc/current/api/includes.html (3rd sentence) > In practice we've never come across the restriction. On Linux and Solaris atleast, including Python.h at the wrong time will give you incorrect definitions for off_t, and other API that relates to large file support. In one case, different definitions of off_t have caused an application crash for the user. > It is not irrelevant to us. Then make a bug report providing all necessary details. I will close this one as invalid. > What is your prime motivation for manipulating proprietary > macros directly? We are not manipulating them, we are defining them - _OSF_SOURCE is a feature selection macro, the application defines it to request "interfaces that are proprietary". The specific feature being requested is the mkdev macro, and the major and minor macros. They are widely available enough to expose them from the os module, but DEC considered them proprietary, and provides _OSF_SOURCE as a mechanism to access them. _XOPEN_SOURCE is the primary means for an application to request that all POSIX functions are available (and functions take their POSIX meanings if multiple conflicting meanings are supported on a system). This is known to have relevant effects on Solaris, Linux, and Tru64; the effects on Tru64 triggered the definition in Python 2.3. _POSIX_C_SOURCE must be defined on some system to reacquire certain interfaces that would have been hidden by defining _XOPEN_SOURCE. Those aren't proprietary, they are used to get non-proprietary behaviour across systems. > Could you please explain why it is necessary to frustrate users? It is necessary to define these things to implement features requested by users, such as large file support, complete socket libraries, etc. These features now uncover bugs in user C code that have been there all the time. It is understandable that users get frustrated, but it is better if they get compiler error messages instead of mysterious crashes. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-01-08 00:46 Message: Logged In: YES user_id=71407 > > The restriction does not exist in Python <= 2.2. > > This is not true. It existed in all Python versions. You may > not have noticed, which might be either because you only got > silent errors, or because there happened to be no errors on > your platform. Is this a documented restriction? In practice we've never come across the restriction. We are using Python 2.2 with many versions of gcc under Linux and Solaris, Visual C++ 6 & 7 and Codewarrior >= 7.2 under Windows, MipsPro CC under IRIX and Tru64 cxx. Others use even more platforms (http://www.boost.org/libs/python/doc/v2/platforms.html). > > If all libraries took that attitude it would be impossible to > > combine them. > > Irrelevant for the bug in question. There are no other > libraries. It is not irrelevant to us. We are using other libraries to create new Python extensions. > > The macros in question are not documented in the Tru64 cc > > and cxx man pages. > > _POSIX_C_SOURCE is defined by the POSIX standards. POSIX > specifies that applications must define it before including > system headers. Same for _XOPEN_SOURCE OK. > _OSF_SOURCE is defined in standards(5). The man page does not suggest that defining _OSF_SOURCE is good or necessary. > ... _OSF_SOURCE must be > defined before any system header is included, or else it > does not have the desired effect. _OSF_SOURCE is defined by including . What difficulties do you have with this approach? What is your prime motivation for manipulating proprietary macros directly? > > The new restriction will frustrate many users of the current > > Boost 1.29.0 release. > > The users will get over their frustration. I was hoping that we could collaborate on finding a solution that is good for everybody. Could you please explain why it is necessary to frustrate users? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-07 21:19 Message: Logged In: YES user_id=21627 > If all libraries took that attitude it would be impossible to > combine them. Irrelevant for the bug in question. There are no other libraries. > The macros in question are not documented in the Tru64 cc > and cxx man pages. _POSIX_C_SOURCE is defined by the POSIX standards. POSIX specifies that applications must define it before including system headers. Same for _XOPEN_SOURCE _OSF_SOURCE is defined in standards(5). > The restriction does not exist in Python <= 2.2. This is not true. It existed in all Python versions. You may not have noticed, which might be either because you only got silent errors, or because there happened to be no errors on your platform. > The new restriction will frustrate many users of the current > Boost 1.29.0 release. The users will get over their frustration. > It is conceivable that other extension systems are also > affected negatively. Not relevant for this bug report. > #ifdef _OSF // maybe not the right symbol > # include > #endif > #ifndef _OSF_SOURCE > # define _OSF_SOURCE whatever > #endif This would be stupid, and incorrect. _OSF_SOURCE must be defined before any system header is included, or else it does not have the desired effect. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-01-07 18:00 Message: Logged In: YES user_id=71407 - If all libraries took that attitude it would be impossible to combine them. - The macros in question are not documented in the Tru64 cc and cxx man pages. Therefore the user should not interfere with these macros. Even if the hacks in pyconfig.h work under certain circumstances, they are likely to cause complications with future versions of the compilers. - The restriction does not exist in Python <= 2.2. Why is it necessary to introduce the restriction now? - The new restriction will frustrate many users of the current Boost 1.29.0 release. - It is conceivable that other extension systems are also affected negatively. All these negative points could easily be eliminated with a more careful approach like this (pseudocode): #ifdef _OSF // maybe not the right symbol # include #endif #ifndef _OSF_SOURCE # define _OSF_SOURCE whatever #endif ... etc. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-07 13:59 Message: Logged In: YES user_id=21627 That's an error in your code. You must always include Python.h as the first header file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663397&group_id=5470 From noreply@sourceforge.net Tue Jan 7 23:46:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 15:46:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-663397 ] Tru64 Unix macro problems Message-ID: Bugs item #663397, was opened at 2003-01-06 15:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663397&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: Tru64 Unix macro problems Initial Comment: Commands used for installing Python 2.3a1: ./configure --prefix=/usr/local_cci/Python-2.3a1 make make install Compilation of C++ code (Boost.Python library) fails. Here is a minimal example: % cat trouble.cpp #include #include #include % cxx -std strict_ansi -msg_disable 450 - I/usr/local_cci/Python-2.3a1/include/python2.3 -c trouble.cpp cxx: Warning: /usr/local_cci/Python- 2.3a1/include/python2.3/pyconfig.h, line 797: incompatible redefinition of macro "_OSF_SOURCE" (declared at line 206 of "/usr/include/standards.h") #define _OSF_SOURCE 1 --------^ cxx: Warning: /usr/local_cci/Python- 2.3a1/include/python2.3/pyconfig.h, line 804: incompatible redefinition of macro "_POSIX_C_SOURCE" (declared at line 198 of "/usr/include/standards.h") #define _POSIX_C_SOURCE 200112L --------^ cxx: Warning: /usr/local_cci/Python- 2.3a1/include/python2.3/pyconfig.h, line 816: incompatible redefinition of macro "_XOPEN_SOURCE" (declared at line 188 of "/usr/include/standards.h") #define _XOPEN_SOURCE 600 --------^ cxx: Error: /usr/include/sys/stat.h, line 204: identifier "blksize_t" is undefined __F64_STAT --------^ cxx: Error: /usr/include/sys/stat.h, line 204: identifier "blkcnt_t" is undefined __F64_STAT --------^ cxx: Info: 2 errors detected in the compilation of "trouble.cpp". I am glad to open an account on our machine if this could help in correcting the problem. Thanks, Ralf ---------------------------------------------------------------------- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-01-07 15:46 Message: Logged In: YES user_id=71407 > > The restriction does not exist in Python <= 2.2. > > This is not true. It existed in all Python versions. You may > not have noticed, which might be either because you only got > silent errors, or because there happened to be no errors on > your platform. Is this a documented restriction? In practice we've never come across the restriction. We are using Python 2.2 with many versions of gcc under Linux and Solaris, Visual C++ 6 & 7 and Codewarrior >= 7.2 under Windows, MipsPro CC under IRIX and Tru64 cxx. Others use even more platforms (http://www.boost.org/libs/python/doc/v2/platforms.html). > > If all libraries took that attitude it would be impossible to > > combine them. > > Irrelevant for the bug in question. There are no other > libraries. It is not irrelevant to us. We are using other libraries to create new Python extensions. > > The macros in question are not documented in the Tru64 cc > > and cxx man pages. > > _POSIX_C_SOURCE is defined by the POSIX standards. POSIX > specifies that applications must define it before including > system headers. Same for _XOPEN_SOURCE OK. > _OSF_SOURCE is defined in standards(5). The man page does not suggest that defining _OSF_SOURCE is good or necessary. > ... _OSF_SOURCE must be > defined before any system header is included, or else it > does not have the desired effect. _OSF_SOURCE is defined by including . What difficulties do you have with this approach? What is your prime motivation for manipulating proprietary macros directly? > > The new restriction will frustrate many users of the current > > Boost 1.29.0 release. > > The users will get over their frustration. I was hoping that we could collaborate on finding a solution that is good for everybody. Could you please explain why it is necessary to frustrate users? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-07 12:19 Message: Logged In: YES user_id=21627 > If all libraries took that attitude it would be impossible to > combine them. Irrelevant for the bug in question. There are no other libraries. > The macros in question are not documented in the Tru64 cc > and cxx man pages. _POSIX_C_SOURCE is defined by the POSIX standards. POSIX specifies that applications must define it before including system headers. Same for _XOPEN_SOURCE _OSF_SOURCE is defined in standards(5). > The restriction does not exist in Python <= 2.2. This is not true. It existed in all Python versions. You may not have noticed, which might be either because you only got silent errors, or because there happened to be no errors on your platform. > The new restriction will frustrate many users of the current > Boost 1.29.0 release. The users will get over their frustration. > It is conceivable that other extension systems are also > affected negatively. Not relevant for this bug report. > #ifdef _OSF // maybe not the right symbol > # include > #endif > #ifndef _OSF_SOURCE > # define _OSF_SOURCE whatever > #endif This would be stupid, and incorrect. _OSF_SOURCE must be defined before any system header is included, or else it does not have the desired effect. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-01-07 09:00 Message: Logged In: YES user_id=71407 - If all libraries took that attitude it would be impossible to combine them. - The macros in question are not documented in the Tru64 cc and cxx man pages. Therefore the user should not interfere with these macros. Even if the hacks in pyconfig.h work under certain circumstances, they are likely to cause complications with future versions of the compilers. - The restriction does not exist in Python <= 2.2. Why is it necessary to introduce the restriction now? - The new restriction will frustrate many users of the current Boost 1.29.0 release. - It is conceivable that other extension systems are also affected negatively. All these negative points could easily be eliminated with a more careful approach like this (pseudocode): #ifdef _OSF // maybe not the right symbol # include #endif #ifndef _OSF_SOURCE # define _OSF_SOURCE whatever #endif ... etc. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-07 04:59 Message: Logged In: YES user_id=21627 That's an error in your code. You must always include Python.h as the first header file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663397&group_id=5470 From noreply@sourceforge.net Wed Jan 8 00:59:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 16:59:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-625698 ] Errors with recursive objects Message-ID: Bugs item #625698, was opened at 2002-10-19 15:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 Category: Python Interpreter Core Group: None Status: Open >Resolution: Works For Me Priority: 5 Submitted By: Erik Andersén (erik_andersen) Assigned to: Nobody/Anonymous (nobody) Summary: Errors with recursive objects Initial Comment: List and dictionaries put Python into an infinite loop if they contain more than one reference to itself >>> d = {} >>> d[1] = d >>> d == d # OK Python can handle one recursion 1 >>> d[2] = d >>> d == d # Crash with two Lists are similar >>> l=[] >>> l.append(l) >>> l==l # OK 1 >>> l.append(l) >>> l==l # Crash >>> l>l # Also crash Tested with ActivePython 2.2.1 under Windows 98 and (the first part) Python 2.2.2 under Linux ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 19:59 Message: Logged In: YES user_id=33168 Erik, do you still have this problem with 2.2.2? I can't reproduce your problem under Linux. mly can't reproduce the problems with 2.2.1 on Windows (2000). Do you only have the problem on Windows? ---------------------------------------------------------------------- Comment By: Magnus Lyckå (mly) Date: 2002-10-26 19:12 Message: Logged In: YES user_id=95217 I tried the above under Python 2.2.1 (#34, Sep 27 2002, 18:37:42) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. (ActiveState on Win 2000) and Python 2.1.1 (#1, Aug 20 2001, 20:23:29) [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.60mdk)] on linux-i386 In both cases it works correctly. No crash. It takes a lot of time though, Several seconds on Duron 700 w/ Win2k, and tens of seconds on K6-233 w/ Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 From noreply@sourceforge.net Wed Jan 8 01:05:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 17:05:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-598797 ] HTTPConnection memory leak Message-ID: Bugs item #598797, was opened at 2002-08-22 10:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598797&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mark Moales (mmoales) Assigned to: Nobody/Anonymous (nobody) Summary: HTTPConnection memory leak Initial Comment: This may be related to bugs 559117 and 592645. I am using Python 2.2.1 (#34, 4/9/2002) on Windows 2000 (5.00.2195, Service Pack 2). Similar to bug 559117, I see a steady increase of 4K in the size of the process after every 10 seconds or so. Here's my test script: import httplib import time for i in range(1000): conn = httplib.HTTPConnection("www.python.org") conn.request("GET", "/index.html") r1 = conn.getresponse() time.sleep(0.5) conn.close() ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 20:05 Message: Logged In: YES user_id=33168 Mark, are you still having problems with 2.2.2 or can we close this bug? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 13:20 Message: Logged In: YES user_id=31392 Doesn't look like this is still a problem, but waiting to close until we hear for certain. ---------------------------------------------------------------------- Comment By: Mark Moales (mmoales) Date: 2002-09-03 13:54 Message: Logged In: YES user_id=565165 I was able to get 2.3 to build (with the latest stuff from CVS) and the problem seems to be fixed. I'll try and update 2.2.1 when I have some time and test that. Thanks! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-03 12:29 Message: Logged In: YES user_id=33168 Tim apparently fixed this problem in 2.3, at least he fixed a problem. :-) Could you test w/2.3 and/or 2.2.1+ (do a cvs upd -r release22-maint)? 2.2.1+ has bug fixes that will be rolled into 2.2.2. ---------------------------------------------------------------------- Comment By: Mark Moales (mmoales) Date: 2002-09-03 10:02 Message: Logged In: YES user_id=565165 I built the debug and release versions of 2.2.1 on Windows and still see the problem with both. I have not had any success building 2.3 on Windows. When I try to build 2.3, I get errors in tokenizer.c. Just so you know, I have not been able to duplicate the problem on Linux. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-01 18:42 Message: Logged In: YES user_id=33168 I can't duplicate this problem on Linux. I used valgrind too. It's possible this problem was fixed. Mark, can you build the version from CVS and see if you still have the problem? I think there was a memory leak in this area, but I'm not sure if it effected windows. I cannot test on windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598797&group_id=5470 From noreply@sourceforge.net Wed Jan 8 01:07:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 17:07:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-589149 ] Memory leakage in SAX with exception Message-ID: Bugs item #589149, was opened at 2002-07-31 11:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589149&group_id=5470 Category: XML Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Paolo Andreetto (pandreetto) Assigned to: Martin v. Löwis (loewis) Summary: Memory leakage in SAX with exception Initial Comment: Trying the following test: #!/usr/bin/python import sys,string,StringIO,traceback,time,gc import xml.sax,xml.sax.handler gc.set_debug(gc.DEBUG_SAVEALL) class SimpleHandler(xml.sax.handler.ContentHandler): def __init__(self): pass def startElement(self,name,attrs): print 'start ',name def endElement(self,name): print 'end ',name def characters(self,content): print content class SimpleErrorHandler(xml.sax.handler.ErrorHandler): def __init__(self): pass def fatalError(self,e): print e myHandler=SimpleHandler() myErrHandler=SimpleErrorHandler() data='something' while 1: gc.collect() print len(gc.garbage) try: #xml.sax.parseString(data,myHandler,myErrHandler) xml.sax.parseString(data,myHandler) except Exception, e: sinfo=sys.exc_info() traceback.print_tb(sinfo[2],None) time.sleep(1) it seems that lots of object remain uncollectable. Using the SimpleErrorHandler the behaviour of gc is good but a memory leakage still remain (4Kb every 30 seconds). Tests run on i386 with debian/Linux (sid), python 2.1.3 (Build of July 29th). Thanks ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 20:07 Message: Logged In: YES user_id=33168 Paolo, can you confirm that this bug should be closed? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 05:12 Message: Logged In: YES user_id=21627 There might indeed have been a memory leak in Python 2.1.3, but I cannot reproduce this with Python 2.2 or CVS-Python anymore. Can you please try a more recent version and see whether the problem goes away? ---------------------------------------------------------------------- Comment By: Paolo Andreetto (pandreetto) Date: 2002-08-05 04:25 Message: Logged In: YES user_id=551296 This is correct, it's my fault, but removing the gc.set_dubug instruction the situation doesn't change. The script is just a simple test, my trouble comes from a memory leakage into SOAPpy module which uses another SAX-based XML-parser. If you think the problem doesn't depends on the python core, please close this bug. Thanks ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-04 22:06 Message: Logged In: YES user_id=21627 Your analysis of this result is wrong. Instead, the result shows that all objects *are* collectible, and that there is merely cyclic garbage in case of a parser error - this garbage *will* be collected, unless you explicitly ask the GC to save it (which you do in your example). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589149&group_id=5470 From noreply@sourceforge.net Wed Jan 8 01:08:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 17:08:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-579116 ] pthread_exit missing in thread_pthread.h Message-ID: Bugs item #579116, was opened at 2002-07-09 09:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=579116&group_id=5470 Category: Threads Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Michael Pronath (micpro) Assigned to: Nobody/Anonymous (nobody) Summary: pthread_exit missing in thread_pthread.h Initial Comment: I'm using the Python 2.2.1 interpreter for scripting language in a larger program. When I used the threading module to create new threads, my main program did not exit anymore, but hang, because one python thread always remained. It got much better when I inserted a call to pthread_exit into do_PyThread_exit_thread (thread_pthread.h). Patchfile is attached. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 20:08 Message: Logged In: YES user_id=33168 Michael do you still have this problem with 2.2.2 or do you still require this patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=579116&group_id=5470 From noreply@sourceforge.net Wed Jan 8 01:02:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 17:02:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-610401 ] linuxaudiodev not documented Message-ID: Bugs item #610401, was opened at 2002-09-17 03:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=610401&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexandre Fayolle (afayolle) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: linuxaudiodev not documented Initial Comment: Hi, I've just discovered that there is a linuxaudiodev module in python, which is not mentioned in the standard library documentation. While it looks a lot like sunaudiodev, which is documented, the sunaudiodev docs cannot be used directly because both modules don't share the same interfaces. For instance open() does not accept the same parameters, and the audio device objects don't have the same methods. Having some docstrings in the linuxaudiodev module could help a lot. Cheers, Alexandre ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 20:02 Message: Logged In: YES user_id=33168 Note: linuxaudiodev has been deprecated. ossaudiodev is the module which should be documented. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-09-17 10:05 Message: Logged In: YES user_id=3066 There's also an "audiodev" module, which masks the differences between the SGI interface (the "al" and "AL" modules) and the Solaris interface ("sunaudiodev"). Probably the right thing would be for someone who understands the linuxaudiodev interface to extend the "audiodev" module to support Linux as well, and then we could document the audiodev interface instead, and treat the others as implementation details. But I know almost nothing about audio beyond how to stick a CD in a CD player. Contributions are welcome. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=610401&group_id=5470 From noreply@sourceforge.net Wed Jan 8 01:23:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 17:23:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-538361 ] packing double yields garbage Message-ID: Bugs item #538361, was opened at 2002-04-02 12:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=538361&group_id=5470 Category: Python Library >Group: 3rd Party Status: Open >Resolution: Invalid Priority: 5 Submitted By: Mike Carifio (carifio) >Assigned to: Neal Norwitz (nnorwitz) Summary: packing double yields garbage Initial Comment: On RH Linux 6.2/alpha (kernal 2.2.14-6.0), egcs- 2.91.66, python 2.2.1c2. I build python from source and test_struct.py dies with a floating point exception. I believe I've found out why: >>> import struct >>> s = struct.pack("d", 3.14e20) >>> struct.unpack("d", s) (1.69270791053e-307,) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 20:23 Message: Logged In: YES user_id=33168 This same problem exists in the snake farm (RedHat 6.2/alpha egcs 2.91.66). It turned out to be a compiler bug. Turning optimization off fixed the problem. Unless I hear otherwise, I will close this bug report. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-04 12:41 Message: Logged In: YES user_id=539787 I think it is something that might have been solved by patch 601369. carifio, can you try downloading the latest Modules/structmodule.c and try again? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-07 18:19 Message: Logged In: YES user_id=6380 - Does the same error occur in earlier versions (2.2, 2.1.2)? - I'm relabeling this as platform-specific because it only fails on alphas (not the world's most popular CPU architecture). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-02 16:24 Message: Logged In: YES user_id=31435 Can you show what's in s? As is, it's impossible to guess whether the problem is in pack() or unpack(). Life would be simpler if you started with a simpler float too (like, say, 1.0). Something random that might help: recompile structmodule.c with optimization turned off. One other: is this Alpha configured to run in big-endian or little-endian mode? ---------------------------------------------------------------------- Comment By: Mike Carifio (carifio) Date: 2002-04-02 13:59 Message: Logged In: YES user_id=503643 EV6 I think. Can I run a command to find out? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-04-02 13:51 Message: Logged In: YES user_id=6656 Oh. That means it might be our fault. Damn. Erm, clutching at straws: what flavour of alpha is this? I'm guessing this is some kind of alignment problem. ---------------------------------------------------------------------- Comment By: Mike Carifio (carifio) Date: 2002-04-02 13:48 Message: Logged In: YES user_id=503643 I also tried this on RH7.*/alpha/2.4.something kernel and gcc 2.95.something and got the same error. Actually, it started with test_struct.py core dumping. I don't actually need to pack doubles. I was just being a good doobie. ---------------------------------------------------------------------- Comment By: Mike Carifio (carifio) Date: 2002-04-02 13:47 Message: Logged In: YES user_id=503643 I also tried this on RH7.*/alpha/2.4.something kernel and gcc 2.95.something and got the same error. Actually, it started with test_struct.py core dumping. I don't actually need to pack doubles. I was just being a good doobie. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-04-02 13:33 Message: Logged In: YES user_id=6656 Hmm, that looks broke. However, I don't see this behaviour on sf's compile farm with 221c1; I'm building 221c2 now, but I'd be amazed if it's different. That machine has kernel 2.4.something and gcc 2.95.something, so is it possible that this is a now-fixed bug in one those (most likely the compiler)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=538361&group_id=5470 From noreply@sourceforge.net Wed Jan 8 01:24:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 17:24:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-532631 ] Confusions in formatfloat Message-ID: Bugs item #532631, was opened at 2002-03-20 13:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532631&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: Confusions in formatfloat Initial Comment: stringobject.c's formatfloat seems confused in a couple respects. 1. Testing "fabs(x)/1e25 >= 1e25" is pretty baffling. What is it intending to do? If it means what it says, it should be the simpler "fabs(x) >= 1e50". But maybe it really intended to test "fabs(x) >= 1e25". 2. The "worst case length calc" is fantasy in some %f cases. It assumes there's one digit before the decimal point, but, e.g., '%.100f'% 1e49 produces dozens of digits before the decimal point. We're saved from a buffer overrun thanks to the PyOS_snprintf () following, but unclear that truncation is sensible here (e.g., the user asked for a precision of 100 here, but only gets back 50 digits after the decimal point). Complication: we're deliberately replacing C's %f with C's %g in some cases, but the docs don't document the rules Python intends for %f. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 20:24 Message: Logged In: YES user_id=33168 Tim, did MALs recent checkin fix any of these problems? Is doc the only thing left to do? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532631&group_id=5470 From noreply@sourceforge.net Wed Jan 8 01:29:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 17:29:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-532631 ] Confusions in formatfloat Message-ID: Bugs item #532631, was opened at 2002-03-20 13:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532631&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) >Assigned to: M.-A. Lemburg (lemburg) Summary: Confusions in formatfloat Initial Comment: stringobject.c's formatfloat seems confused in a couple respects. 1. Testing "fabs(x)/1e25 >= 1e25" is pretty baffling. What is it intending to do? If it means what it says, it should be the simpler "fabs(x) >= 1e50". But maybe it really intended to test "fabs(x) >= 1e25". 2. The "worst case length calc" is fantasy in some %f cases. It assumes there's one digit before the decimal point, but, e.g., '%.100f'% 1e49 produces dozens of digits before the decimal point. We're saved from a buffer overrun thanks to the PyOS_snprintf () following, but unclear that truncation is sensible here (e.g., the user asked for a precision of 100 here, but only gets back 50 digits after the decimal point). Complication: we're deliberately replacing C's %f with C's %g in some cases, but the docs don't document the rules Python intends for %f. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-07 20:29 Message: Logged In: YES user_id=31435 Marc-Andre is in a better position to tell us what he fixed than I am, so assigned to him. MAL, feel free to close this if you think it's history. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 20:24 Message: Logged In: YES user_id=33168 Tim, did MALs recent checkin fix any of these problems? Is doc the only thing left to do? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532631&group_id=5470 From noreply@sourceforge.net Wed Jan 8 02:12:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 18:12:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-538361 ] packing double yields garbage Message-ID: Bugs item #538361, was opened at 2002-04-02 12:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=538361&group_id=5470 Category: Python Library Group: 3rd Party Status: Open Resolution: Invalid Priority: 5 Submitted By: Mike Carifio (carifio) Assigned to: Neal Norwitz (nnorwitz) Summary: packing double yields garbage Initial Comment: On RH Linux 6.2/alpha (kernal 2.2.14-6.0), egcs- 2.91.66, python 2.2.1c2. I build python from source and test_struct.py dies with a floating point exception. I believe I've found out why: >>> import struct >>> s = struct.pack("d", 3.14e20) >>> struct.unpack("d", s) (1.69270791053e-307,) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-07 21:12 Message: Logged In: YES user_id=31435 Is our evidence that it's a compiler bug solely that turning optimization off made the problem go away? If so, that's a good clue but not definitive. It could be that Python's C code is ill-defined in such a way that optimizing or not changes which kind of undefined behavior obtains. To nail this really requires determining exactly which piece of the Python code changed behavior. This may not be easy, and in some cases may even require digging into the generated machine code. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 20:23 Message: Logged In: YES user_id=33168 This same problem exists in the snake farm (RedHat 6.2/alpha egcs 2.91.66). It turned out to be a compiler bug. Turning optimization off fixed the problem. Unless I hear otherwise, I will close this bug report. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-04 12:41 Message: Logged In: YES user_id=539787 I think it is something that might have been solved by patch 601369. carifio, can you try downloading the latest Modules/structmodule.c and try again? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-07 18:19 Message: Logged In: YES user_id=6380 - Does the same error occur in earlier versions (2.2, 2.1.2)? - I'm relabeling this as platform-specific because it only fails on alphas (not the world's most popular CPU architecture). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-02 16:24 Message: Logged In: YES user_id=31435 Can you show what's in s? As is, it's impossible to guess whether the problem is in pack() or unpack(). Life would be simpler if you started with a simpler float too (like, say, 1.0). Something random that might help: recompile structmodule.c with optimization turned off. One other: is this Alpha configured to run in big-endian or little-endian mode? ---------------------------------------------------------------------- Comment By: Mike Carifio (carifio) Date: 2002-04-02 13:59 Message: Logged In: YES user_id=503643 EV6 I think. Can I run a command to find out? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-04-02 13:51 Message: Logged In: YES user_id=6656 Oh. That means it might be our fault. Damn. Erm, clutching at straws: what flavour of alpha is this? I'm guessing this is some kind of alignment problem. ---------------------------------------------------------------------- Comment By: Mike Carifio (carifio) Date: 2002-04-02 13:48 Message: Logged In: YES user_id=503643 I also tried this on RH7.*/alpha/2.4.something kernel and gcc 2.95.something and got the same error. Actually, it started with test_struct.py core dumping. I don't actually need to pack doubles. I was just being a good doobie. ---------------------------------------------------------------------- Comment By: Mike Carifio (carifio) Date: 2002-04-02 13:47 Message: Logged In: YES user_id=503643 I also tried this on RH7.*/alpha/2.4.something kernel and gcc 2.95.something and got the same error. Actually, it started with test_struct.py core dumping. I don't actually need to pack doubles. I was just being a good doobie. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-04-02 13:33 Message: Logged In: YES user_id=6656 Hmm, that looks broke. However, I don't see this behaviour on sf's compile farm with 221c1; I'm building 221c2 now, but I'd be amazed if it's different. That machine has kernel 2.4.something and gcc 2.95.something, so is it possible that this is a now-fixed bug in one those (most likely the compiler)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=538361&group_id=5470 From noreply@sourceforge.net Wed Jan 8 02:22:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 18:22:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-538361 ] packing double yields garbage Message-ID: Bugs item #538361, was opened at 2002-04-02 12:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=538361&group_id=5470 Category: Python Library Group: 3rd Party Status: Open Resolution: Invalid Priority: 5 Submitted By: Mike Carifio (carifio) Assigned to: Neal Norwitz (nnorwitz) Summary: packing double yields garbage Initial Comment: On RH Linux 6.2/alpha (kernal 2.2.14-6.0), egcs- 2.91.66, python 2.2.1c2. I build python from source and test_struct.py dies with a floating point exception. I believe I've found out why: >>> import struct >>> s = struct.pack("d", 3.14e20) >>> struct.unpack("d", s) (1.69270791053e-307,) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 21:22 Message: Logged In: YES user_id=33168 > Is our evidence that it's a compiler bug solely that turning > optimization off made the problem go away? Yes. The test is failing right now: http://www.lysator.liu.se/xenofarm/python/files/2437_6/testlog.txt I built the test normally and got the same failure. I built python with -O0 and the test passed. Python's code may have had a problem. On 9/3/2002, rev 2.57 to Module/structmodule.c changed to use memcpy "to avoid alignment errors." That was from patch 601369 which appeared to be necessary for MIPS. The same code does work on a different alpha, running a different kernel, different glibc, and different compiler. (It works with optimization.) http://www.lysator.liu.se/xenofarm/python/files/2479_31/testlog.txt Suggestions? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-07 21:12 Message: Logged In: YES user_id=31435 Is our evidence that it's a compiler bug solely that turning optimization off made the problem go away? If so, that's a good clue but not definitive. It could be that Python's C code is ill-defined in such a way that optimizing or not changes which kind of undefined behavior obtains. To nail this really requires determining exactly which piece of the Python code changed behavior. This may not be easy, and in some cases may even require digging into the generated machine code. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 20:23 Message: Logged In: YES user_id=33168 This same problem exists in the snake farm (RedHat 6.2/alpha egcs 2.91.66). It turned out to be a compiler bug. Turning optimization off fixed the problem. Unless I hear otherwise, I will close this bug report. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-04 12:41 Message: Logged In: YES user_id=539787 I think it is something that might have been solved by patch 601369. carifio, can you try downloading the latest Modules/structmodule.c and try again? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-07 18:19 Message: Logged In: YES user_id=6380 - Does the same error occur in earlier versions (2.2, 2.1.2)? - I'm relabeling this as platform-specific because it only fails on alphas (not the world's most popular CPU architecture). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-02 16:24 Message: Logged In: YES user_id=31435 Can you show what's in s? As is, it's impossible to guess whether the problem is in pack() or unpack(). Life would be simpler if you started with a simpler float too (like, say, 1.0). Something random that might help: recompile structmodule.c with optimization turned off. One other: is this Alpha configured to run in big-endian or little-endian mode? ---------------------------------------------------------------------- Comment By: Mike Carifio (carifio) Date: 2002-04-02 13:59 Message: Logged In: YES user_id=503643 EV6 I think. Can I run a command to find out? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-04-02 13:51 Message: Logged In: YES user_id=6656 Oh. That means it might be our fault. Damn. Erm, clutching at straws: what flavour of alpha is this? I'm guessing this is some kind of alignment problem. ---------------------------------------------------------------------- Comment By: Mike Carifio (carifio) Date: 2002-04-02 13:48 Message: Logged In: YES user_id=503643 I also tried this on RH7.*/alpha/2.4.something kernel and gcc 2.95.something and got the same error. Actually, it started with test_struct.py core dumping. I don't actually need to pack doubles. I was just being a good doobie. ---------------------------------------------------------------------- Comment By: Mike Carifio (carifio) Date: 2002-04-02 13:47 Message: Logged In: YES user_id=503643 I also tried this on RH7.*/alpha/2.4.something kernel and gcc 2.95.something and got the same error. Actually, it started with test_struct.py core dumping. I don't actually need to pack doubles. I was just being a good doobie. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-04-02 13:33 Message: Logged In: YES user_id=6656 Hmm, that looks broke. However, I don't see this behaviour on sf's compile farm with 221c1; I'm building 221c2 now, but I'd be amazed if it's different. That machine has kernel 2.4.something and gcc 2.95.something, so is it possible that this is a now-fixed bug in one those (most likely the compiler)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=538361&group_id=5470 From noreply@sourceforge.net Wed Jan 8 02:29:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 18:29:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-538361 ] packing double yields garbage Message-ID: Bugs item #538361, was opened at 2002-04-02 12:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=538361&group_id=5470 Category: Python Library Group: 3rd Party Status: Open Resolution: Invalid Priority: 5 Submitted By: Mike Carifio (carifio) Assigned to: Neal Norwitz (nnorwitz) Summary: packing double yields garbage Initial Comment: On RH Linux 6.2/alpha (kernal 2.2.14-6.0), egcs- 2.91.66, python 2.2.1c2. I build python from source and test_struct.py dies with a floating point exception. I believe I've found out why: >>> import struct >>> s = struct.pack("d", 3.14e20) >>> struct.unpack("d", s) (1.69270791053e-307,) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-07 21:29 Message: Logged In: YES user_id=31435 You have to be really interested to track one of these down. I started asking leading questions in April, but didn't get a response. If nobody who runs on Alphas is interested enough to help, the heck with it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 21:22 Message: Logged In: YES user_id=33168 > Is our evidence that it's a compiler bug solely that turning > optimization off made the problem go away? Yes. The test is failing right now: http://www.lysator.liu.se/xenofarm/python/files/2437_6/testlog.txt I built the test normally and got the same failure. I built python with -O0 and the test passed. Python's code may have had a problem. On 9/3/2002, rev 2.57 to Module/structmodule.c changed to use memcpy "to avoid alignment errors." That was from patch 601369 which appeared to be necessary for MIPS. The same code does work on a different alpha, running a different kernel, different glibc, and different compiler. (It works with optimization.) http://www.lysator.liu.se/xenofarm/python/files/2479_31/testlog.txt Suggestions? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-07 21:12 Message: Logged In: YES user_id=31435 Is our evidence that it's a compiler bug solely that turning optimization off made the problem go away? If so, that's a good clue but not definitive. It could be that Python's C code is ill-defined in such a way that optimizing or not changes which kind of undefined behavior obtains. To nail this really requires determining exactly which piece of the Python code changed behavior. This may not be easy, and in some cases may even require digging into the generated machine code. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 20:23 Message: Logged In: YES user_id=33168 This same problem exists in the snake farm (RedHat 6.2/alpha egcs 2.91.66). It turned out to be a compiler bug. Turning optimization off fixed the problem. Unless I hear otherwise, I will close this bug report. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-04 12:41 Message: Logged In: YES user_id=539787 I think it is something that might have been solved by patch 601369. carifio, can you try downloading the latest Modules/structmodule.c and try again? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-07 18:19 Message: Logged In: YES user_id=6380 - Does the same error occur in earlier versions (2.2, 2.1.2)? - I'm relabeling this as platform-specific because it only fails on alphas (not the world's most popular CPU architecture). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-02 16:24 Message: Logged In: YES user_id=31435 Can you show what's in s? As is, it's impossible to guess whether the problem is in pack() or unpack(). Life would be simpler if you started with a simpler float too (like, say, 1.0). Something random that might help: recompile structmodule.c with optimization turned off. One other: is this Alpha configured to run in big-endian or little-endian mode? ---------------------------------------------------------------------- Comment By: Mike Carifio (carifio) Date: 2002-04-02 13:59 Message: Logged In: YES user_id=503643 EV6 I think. Can I run a command to find out? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-04-02 13:51 Message: Logged In: YES user_id=6656 Oh. That means it might be our fault. Damn. Erm, clutching at straws: what flavour of alpha is this? I'm guessing this is some kind of alignment problem. ---------------------------------------------------------------------- Comment By: Mike Carifio (carifio) Date: 2002-04-02 13:48 Message: Logged In: YES user_id=503643 I also tried this on RH7.*/alpha/2.4.something kernel and gcc 2.95.something and got the same error. Actually, it started with test_struct.py core dumping. I don't actually need to pack doubles. I was just being a good doobie. ---------------------------------------------------------------------- Comment By: Mike Carifio (carifio) Date: 2002-04-02 13:47 Message: Logged In: YES user_id=503643 I also tried this on RH7.*/alpha/2.4.something kernel and gcc 2.95.something and got the same error. Actually, it started with test_struct.py core dumping. I don't actually need to pack doubles. I was just being a good doobie. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-04-02 13:33 Message: Logged In: YES user_id=6656 Hmm, that looks broke. However, I don't see this behaviour on sf's compile farm with 221c1; I'm building 221c2 now, but I'd be amazed if it's different. That machine has kernel 2.4.something and gcc 2.95.something, so is it possible that this is a now-fixed bug in one those (most likely the compiler)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=538361&group_id=5470 From noreply@sourceforge.net Wed Jan 8 05:16:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 21:16:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-664044 ] Lib Man 2.2.6.2 word change Message-ID: Bugs item #664044, was opened at 2003-01-07 17:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=664044&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Terry J. Reedy (tjreedy) Assigned to: Nobody/Anonymous (nobody) Summary: Lib Man 2.2.6.2 word change Initial Comment: In the conversion types table, the 's' line s String (converts any python object using str()). should have 'non-unicode' substituted for or inserted before 'python' to be consistent with both the last sentence of the first paragraph and current (2.2.1) behavior. This non-updated line has fooled at least one person (clp poster). ---------------------------------------------------------------------- Comment By: Christopher Blunck (blunck2) Date: 2003-01-08 00:16 Message: Logged In: YES user_id=531881 see patch 664183 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=664044&group_id=5470 From noreply@sourceforge.net Wed Jan 8 05:29:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 07 Jan 2003 21:29:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-661913 ] str.index() exception message not consistent Message-ID: Bugs item #661913, was opened at 2003-01-03 18:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661913&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Inyeol Lee (inyeol) Assigned to: Nobody/Anonymous (nobody) Summary: str.index() exception message not consistent Initial Comment: $ python Python 2.3a1 (#1, Jan 2 2003, 22:36:29) [GCC 2.95.3 20010315 (release)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> 'a'.index('b') Traceback (most recent call last): File "", line 1, in ? ValueError: substring not found in string.index >>> 'a'.rindex('b') Traceback (most recent call last): File "", line 1, in ? ValueError: substring not found in string.rindex >>> u'a'.index('b') Traceback (most recent call last): File "", line 1, in ? ValueError: substring not found >>> str.index()/str.rindex() exception message contains "in string.(r)index", but unicode.index()/unicode.rindex() doesn't. For me, unicode message is more clear, and it is consistent with other string methods which raises exception, for example; >>> 'a'.split('') Traceback (most recent call last): File "", line 1, in ? ValueError: empty separator >>> 2.2.2 has the same issues. Inyeol Lee ---------------------------------------------------------------------- Comment By: Christopher Blunck (blunck2) Date: 2003-01-08 00:29 Message: Logged In: YES user_id=531881 see patch 664192 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661913&group_id=5470 From noreply@sourceforge.net Wed Jan 8 10:17:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 08 Jan 2003 02:17:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-645594 ] for lin in file: file.tell() tells wrong Message-ID: Bugs item #645594, was opened at 2002-11-29 12:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=645594&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: for lin in file: file.tell() tells wrong Initial Comment: Consider following piece of code: f = file("test.txt", "rb") pos = f.tell() for line in f: print "%u: '%s'" % (pos, line) pos = f.tell() During the code execution we have following result: 0 'Line 1' 63 'Line 2' 63 'Line 3' ... 63 'Line 9' However, following piece of code works fine: f = file("test.txt", "rb") while True: pos = f.tell() line = f.readline() if line == "": break print "%u: '%s'" % (pos, line) It prints: 0 'Line 1' 7 'Line 2' 14 'Line 3' ... 56 'Line 9' It seems a file iterator makes file.tell() to tell positions of some internal blocks used by the iterator. ---------------------------------------------------------------------- >Comment By: Dmitry Vasiliev (hdima) Date: 2003-01-08 13:17 Message: Logged In: YES user_id=388573 I agree. Unfortunately a small patch doesn't work here. :-( But I suggest to recategorize it as a documentation bug. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-06 00:25 Message: Logged In: YES user_id=92689 This bug is very similar to #524804, which was closed as "won't fix". Unless it's recategorized as a documentation bug, I suggest to close this one as a duplicate. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2002-12-04 14:24 Message: Logged In: YES user_id=388573 File.next() uses readahead buffer (8192 bytes for now). Calling file.seek() drops the buffer, but other operations don't. I think it's possible for file.tell() to return right result (I'll try to make a patch). But all these quirks should be documented. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-11-30 01:07 Message: Logged In: YES user_id=45365 Actually, all file operations behave the same (well, all: I tried one: readline():-): they behave as if the whole file has been read. I.e. file.readline() within a "for line in file" will return an empty string. If a file iterator behaves as if it has read the complete file at once on instantiation (never mind what it actually does: if it *behaves* as if this happens) I think this should just be documented and that's it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-29 19:57 Message: Logged In: YES user_id=31435 Possibly. Maybe something fancier could be done too, to give "expected" results. although I don't know how to approach that on Windows for text-mode files (byte arithmetic on seek/tell results doesn't work at all for those). I'd take it to Python-Dev. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-29 19:01 Message: Logged In: YES user_id=21627 Shouldn't tell raise an exception then? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-29 18:42 Message: Logged In: YES user_id=31435 "for x in file" does do its own chunking under the covers, for speed, and seek() and tell() are indeed not to be used on a file being iterated over in this way. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2002-11-29 17:46 Message: Logged In: YES user_id=388573 I'll try to dig in. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-29 17:30 Message: Logged In: YES user_id=21627 Would you like to investigate this further? There is no need to, but if you find a solution and a patch, there is a better chance that this is fixed before 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=645594&group_id=5470 From noreply@sourceforge.net Wed Jan 8 14:50:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 08 Jan 2003 06:50:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-589149 ] Memory leakage in SAX with exception Message-ID: Bugs item #589149, was opened at 2002-07-31 17:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589149&group_id=5470 Category: XML Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Paolo Andreetto (pandreetto) Assigned to: Martin v. Löwis (loewis) Summary: Memory leakage in SAX with exception Initial Comment: Trying the following test: #!/usr/bin/python import sys,string,StringIO,traceback,time,gc import xml.sax,xml.sax.handler gc.set_debug(gc.DEBUG_SAVEALL) class SimpleHandler(xml.sax.handler.ContentHandler): def __init__(self): pass def startElement(self,name,attrs): print 'start ',name def endElement(self,name): print 'end ',name def characters(self,content): print content class SimpleErrorHandler(xml.sax.handler.ErrorHandler): def __init__(self): pass def fatalError(self,e): print e myHandler=SimpleHandler() myErrHandler=SimpleErrorHandler() data='something' while 1: gc.collect() print len(gc.garbage) try: #xml.sax.parseString(data,myHandler,myErrHandler) xml.sax.parseString(data,myHandler) except Exception, e: sinfo=sys.exc_info() traceback.print_tb(sinfo[2],None) time.sleep(1) it seems that lots of object remain uncollectable. Using the SimpleErrorHandler the behaviour of gc is good but a memory leakage still remain (4Kb every 30 seconds). Tests run on i386 with debian/Linux (sid), python 2.1.3 (Build of July 29th). Thanks ---------------------------------------------------------------------- >Comment By: Paolo Andreetto (pandreetto) Date: 2003-01-08 15:50 Message: Logged In: YES user_id=551296 With Python 2.3a1 (#2, Jan 1 2003, 18:44:29) there's no memory leakage. With Python 2.2.2 (#1, Jan 3 2003, 12:42:27) the problem still occurs. I've used debian (unstable) package for both versions of python. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-08 02:07 Message: Logged In: YES user_id=33168 Paolo, can you confirm that this bug should be closed? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-09-22 11:12 Message: Logged In: YES user_id=21627 There might indeed have been a memory leak in Python 2.1.3, but I cannot reproduce this with Python 2.2 or CVS-Python anymore. Can you please try a more recent version and see whether the problem goes away? ---------------------------------------------------------------------- Comment By: Paolo Andreetto (pandreetto) Date: 2002-08-05 10:25 Message: Logged In: YES user_id=551296 This is correct, it's my fault, but removing the gc.set_dubug instruction the situation doesn't change. The script is just a simple test, my trouble comes from a memory leakage into SOAPpy module which uses another SAX-based XML-parser. If you think the problem doesn't depends on the python core, please close this bug. Thanks ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-05 04:06 Message: Logged In: YES user_id=21627 Your analysis of this result is wrong. Instead, the result shows that all objects *are* collectible, and that there is merely cyclic garbage in case of a parser error - this garbage *will* be collected, unless you explicitly ask the GC to save it (which you do in your example). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=589149&group_id=5470 From noreply@sourceforge.net Wed Jan 8 15:36:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 08 Jan 2003 07:36:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-598797 ] HTTPConnection memory leak Message-ID: Bugs item #598797, was opened at 2002-08-22 10:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598797&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mark Moales (mmoales) Assigned to: Nobody/Anonymous (nobody) Summary: HTTPConnection memory leak Initial Comment: This may be related to bugs 559117 and 592645. I am using Python 2.2.1 (#34, 4/9/2002) on Windows 2000 (5.00.2195, Service Pack 2). Similar to bug 559117, I see a steady increase of 4K in the size of the process after every 10 seconds or so. Here's my test script: import httplib import time for i in range(1000): conn = httplib.HTTPConnection("www.python.org") conn.request("GET", "/index.html") r1 = conn.getresponse() time.sleep(0.5) conn.close() ---------------------------------------------------------------------- >Comment By: Mark Moales (mmoales) Date: 2003-01-08 10:36 Message: Logged In: YES user_id=565165 Go ahead and close the bug because it appears to be fixed in 2.2.2. Sorry for not following up on this sooner. Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 20:05 Message: Logged In: YES user_id=33168 Mark, are you still having problems with 2.2.2 or can we close this bug? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 13:20 Message: Logged In: YES user_id=31392 Doesn't look like this is still a problem, but waiting to close until we hear for certain. ---------------------------------------------------------------------- Comment By: Mark Moales (mmoales) Date: 2002-09-03 13:54 Message: Logged In: YES user_id=565165 I was able to get 2.3 to build (with the latest stuff from CVS) and the problem seems to be fixed. I'll try and update 2.2.1 when I have some time and test that. Thanks! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-03 12:29 Message: Logged In: YES user_id=33168 Tim apparently fixed this problem in 2.3, at least he fixed a problem. :-) Could you test w/2.3 and/or 2.2.1+ (do a cvs upd -r release22-maint)? 2.2.1+ has bug fixes that will be rolled into 2.2.2. ---------------------------------------------------------------------- Comment By: Mark Moales (mmoales) Date: 2002-09-03 10:02 Message: Logged In: YES user_id=565165 I built the debug and release versions of 2.2.1 on Windows and still see the problem with both. I have not had any success building 2.3 on Windows. When I try to build 2.3, I get errors in tokenizer.c. Just so you know, I have not been able to duplicate the problem on Linux. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-01 18:42 Message: Logged In: YES user_id=33168 I can't duplicate this problem on Linux. I used valgrind too. It's possible this problem was fixed. Mark, can you build the version from CVS and see if you still have the problem? I think there was a memory leak in this area, but I'm not sure if it effected windows. I cannot test on windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598797&group_id=5470 From noreply@sourceforge.net Wed Jan 8 15:41:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 08 Jan 2003 07:41:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-598797 ] HTTPConnection memory leak Message-ID: Bugs item #598797, was opened at 2002-08-22 10:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598797&group_id=5470 Category: Python Library Group: Python 2.2.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mark Moales (mmoales) Assigned to: Nobody/Anonymous (nobody) Summary: HTTPConnection memory leak Initial Comment: This may be related to bugs 559117 and 592645. I am using Python 2.2.1 (#34, 4/9/2002) on Windows 2000 (5.00.2195, Service Pack 2). Similar to bug 559117, I see a steady increase of 4K in the size of the process after every 10 seconds or so. Here's my test script: import httplib import time for i in range(1000): conn = httplib.HTTPConnection("www.python.org") conn.request("GET", "/index.html") r1 = conn.getresponse() time.sleep(0.5) conn.close() ---------------------------------------------------------------------- Comment By: Mark Moales (mmoales) Date: 2003-01-08 10:36 Message: Logged In: YES user_id=565165 Go ahead and close the bug because it appears to be fixed in 2.2.2. Sorry for not following up on this sooner. Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 20:05 Message: Logged In: YES user_id=33168 Mark, are you still having problems with 2.2.2 or can we close this bug? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 13:20 Message: Logged In: YES user_id=31392 Doesn't look like this is still a problem, but waiting to close until we hear for certain. ---------------------------------------------------------------------- Comment By: Mark Moales (mmoales) Date: 2002-09-03 13:54 Message: Logged In: YES user_id=565165 I was able to get 2.3 to build (with the latest stuff from CVS) and the problem seems to be fixed. I'll try and update 2.2.1 when I have some time and test that. Thanks! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-03 12:29 Message: Logged In: YES user_id=33168 Tim apparently fixed this problem in 2.3, at least he fixed a problem. :-) Could you test w/2.3 and/or 2.2.1+ (do a cvs upd -r release22-maint)? 2.2.1+ has bug fixes that will be rolled into 2.2.2. ---------------------------------------------------------------------- Comment By: Mark Moales (mmoales) Date: 2002-09-03 10:02 Message: Logged In: YES user_id=565165 I built the debug and release versions of 2.2.1 on Windows and still see the problem with both. I have not had any success building 2.3 on Windows. When I try to build 2.3, I get errors in tokenizer.c. Just so you know, I have not been able to duplicate the problem on Linux. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-01 18:42 Message: Logged In: YES user_id=33168 I can't duplicate this problem on Linux. I used valgrind too. It's possible this problem was fixed. Mark, can you build the version from CVS and see if you still have the problem? I think there was a memory leak in this area, but I'm not sure if it effected windows. I cannot test on windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=598797&group_id=5470 From noreply@sourceforge.net Wed Jan 8 16:15:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 08 Jan 2003 08:15:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-548661 ] os.popen w/o using the shell Message-ID: Bugs item #548661, was opened at 2002-04-25 15:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548661&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Ian Bicking (ianbicking) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen w/o using the shell Initial Comment: I heard that there was an undocumented feature to the os.popen family, where instead of passing a command string as the first argument you could pass a list, as [path, arg1, arg2, ...], and circumvent any shell interpretation. I was disapointed to see that this was not so ("popen() argument 1 must be string, not list" ditto tuple) I believe this would be an excellent feature -- using the shell is a significant source of errors due to quoting, as well as a serious security concern. 95% of the time the shell is not required. The shell also introduces portability concerns (e.g., bug #512433) -- creating a Python shell is not necessary when the shell is usually superfluous anyway. ---------------------------------------------------------------------- Comment By: Julián Muñoz (julian69) Date: 2003-01-08 16:15 Message: Logged In: YES user_id=77756 Does this mean that giving a list to popen2 free us from taking care of the dangerous characters that could be interprated/escaped by the shell ??? I don't find any documentation about this feature !!! ---------------------------------------------------------------------- Comment By: Ian Bicking (ianbicking) Date: 2002-04-25 18:18 Message: Logged In: YES user_id=210337 I see you are correct. It would be nice if this feature was consistent across all popen*, and was also documented (and so also committed to with clear semantics) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-04-25 18:13 Message: Logged In: YES user_id=21627 This feature is indeed available in popen2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548661&group_id=5470 From noreply@sourceforge.net Wed Jan 8 17:11:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 08 Jan 2003 09:11:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-662787 ] test_signal hang on some Solaris boxes Message-ID: Bugs item #662787, was opened at 2003-01-05 14:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Martin v. Löwis (loewis) Summary: test_signal hang on some Solaris boxes Initial Comment: Martin, I'm assigning this to you because you checked in the patch which caused this problem. I think your input on fixes will also be valuable. When semaphore support was added to Python/thread_pthread.h in 2.39 originally from patch 525532, it broke tests on some Solaris boxes. I know this affects Solaris 8, not sure if any other versions are affected. I believe on or more of the following Solaris 8 patches (108528, 108827) fixes the problem: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108528&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108827&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on Patches can be gotten from here: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access One way to fix the hang is to add #undef USE_SEMAPHORES at line 113 of Python/thread_pthread.h (ie, after USE_SEMAPHORES may be set). I don't know of any other way to fix this problem. I don't know if we can test for this in configure and set USE_SEMAPHORES appropriately (or if it's worth it). We can always disable USE_SEMAPHORES and allow the user to use it by manually setting the macro. We keep the code as is, and document the problem. Suggestions? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-08 12:11 Message: Logged In: YES user_id=33168 Martin, how do you think we should proceed with this problem? Some alternatives include: 1) try to build an autoconf test to find the problem and disable USE_SEMAPHORES 2) always disable USE_SEMAPHORES for Solaris 3) try to find a work-around 4) leave it as-is At least temporarily, I'd like to see #2. The problem is that if we do that, it will probably never get fixed. #1 is probably a lot of work. I can't implement #1 since I don't have access to a machine that works. Do you have any other ideas or possible solutions/work-arounds? ---------------------------------------------------------------------- Comment By: Inyeol Lee (inyeol) Date: 2003-01-06 22:46 Message: Logged In: YES user_id=595280 Neal, This is the patch version of my Solaris8 system you've requested; Patch: 108528-07 Patch: 108528-13 Patch: 108827-07 Patch: 108827-15 Inyeol Lee ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 09:46 Message: Logged In: YES user_id=21627 showrev -p is good, as is patchadd -p (this also shows the patches you could backup to). I notice that my Solaris 9 machine does not experience the problem, so Sun has fixed something. It would be good if a Solaris 8 machine could be brought up-to-date with regard to patches (they recommend -18 and -35 respectively, at the moment). On that machine, either those two patches selectively, or an entire patch cluster (8_Recommended.zip) should be installed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-06 08:44 Message: Logged In: YES user_id=33168 I thought I could not duplicate the hang on our sun, but now it's happening. Your test program also hangs. How do you determine the revision of a patch on solaris? I'm using showrev -p | grep patch-#. I'm not sure that is correct. The way I read it, it says I have 108528-16 and 108827-12. In the snake farm proton has: 108528-12 and 108827-12 fafner has: 108528-13 and 108827-19 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 07:29 Message: Logged In: YES user_id=21627 It would be good to find a system that has 108528-17 installed. I see that this fixes 4498831 system timer stops sending signals ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 07:13 Message: Logged In: YES user_id=21627 I meant revisions of the Sun patches. On one system, I have 108528-16 and 108827-34, and test_signal still hangs. I found that the blocking occurs when test_queue.py is run before, and have distilled this into the following example: import sys import thread import time import signal fsema = thread.allocate_lock() def tfunc(): time.sleep(.1) fsema.release() fsema.acquire() thread.start_new_thread(tfunc,()) fsema.acquire() fsema.release() signal.alarm(3) signal.pause() It appears that the alarm is simply lost; the pause call does not return. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 18:38 Message: Logged In: YES user_id=33168 What do you mean by revision of the patches? CVS revision of thread_pthread.h? I believe 2.38 worked and 2.39 broke. I can test that if you'd like. Do you want me to go back to the revision before the patch for all files affected? Since 2.39 only added the semaphores, in essence, by doing the #undef that should have the same effect as reverting thread_pthread.h to 2.38. Or are you talking about the Solaris patches? If so, they are only a guess, we could compare the patch level on all the Solaris boxes we have access to and see which ones work and which don't. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-05 18:11 Message: Logged In: YES user_id=21627 Could you identify a revision of these patches for which the problem disappears? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 15:57 Message: Logged In: YES user_id=33168 For (possibly) more info, see: http://lists.lysator.liu.se/pipermail/snake-farm/2003-January/000617.html ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 15:38 Message: Logged In: YES user_id=33168 Attaching output of truss (like strace for Solaris) which doesn't provide me with any more info. Hopefully this will help someone else. 2 files attached, one with complete output from; truss ./python -E -tt ./Lib/test/regrtest.py test_queue test_signal the other is just the end. It should correspond to these lines from the test: signal.alarm(20) # Entire test lasts at most 20 sec. signal.signal(5, handlerA) signal.signal(2, handlerB) signal.signal(3, signal.SIG_IGN) signal.signal(signal.SIGALRM, signal.default_int_handler) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 From noreply@sourceforge.net Wed Jan 8 17:15:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 08 Jan 2003 09:15:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-662787 ] test_signal hang on some Solaris boxes Message-ID: Bugs item #662787, was opened at 2003-01-05 20:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Martin v. Löwis (loewis) Summary: test_signal hang on some Solaris boxes Initial Comment: Martin, I'm assigning this to you because you checked in the patch which caused this problem. I think your input on fixes will also be valuable. When semaphore support was added to Python/thread_pthread.h in 2.39 originally from patch 525532, it broke tests on some Solaris boxes. I know this affects Solaris 8, not sure if any other versions are affected. I believe on or more of the following Solaris 8 patches (108528, 108827) fixes the problem: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108528&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108827&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on Patches can be gotten from here: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access One way to fix the hang is to add #undef USE_SEMAPHORES at line 113 of Python/thread_pthread.h (ie, after USE_SEMAPHORES may be set). I don't know of any other way to fix this problem. I don't know if we can test for this in configure and set USE_SEMAPHORES appropriately (or if it's worth it). We can always disable USE_SEMAPHORES and allow the user to use it by manually setting the macro. We keep the code as is, and document the problem. Suggestions? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-08 18:15 Message: Logged In: YES user_id=21627 I quite object #2, although I could live with 5) disable USE_SEMAPHORES for Solaris 8 I would still like to find out whether applying all patches solves the problem. I'm quite certain that our code is correct and that there is a bug in Solaris. I'm reasonably certain that the bug has been fixed by now, so I would not want to leave USE_SEMAPHORES disabled forever on Solaris. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-08 18:11 Message: Logged In: YES user_id=33168 Martin, how do you think we should proceed with this problem? Some alternatives include: 1) try to build an autoconf test to find the problem and disable USE_SEMAPHORES 2) always disable USE_SEMAPHORES for Solaris 3) try to find a work-around 4) leave it as-is At least temporarily, I'd like to see #2. The problem is that if we do that, it will probably never get fixed. #1 is probably a lot of work. I can't implement #1 since I don't have access to a machine that works. Do you have any other ideas or possible solutions/work-arounds? ---------------------------------------------------------------------- Comment By: Inyeol Lee (inyeol) Date: 2003-01-07 04:46 Message: Logged In: YES user_id=595280 Neal, This is the patch version of my Solaris8 system you've requested; Patch: 108528-07 Patch: 108528-13 Patch: 108827-07 Patch: 108827-15 Inyeol Lee ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 15:46 Message: Logged In: YES user_id=21627 showrev -p is good, as is patchadd -p (this also shows the patches you could backup to). I notice that my Solaris 9 machine does not experience the problem, so Sun has fixed something. It would be good if a Solaris 8 machine could be brought up-to-date with regard to patches (they recommend -18 and -35 respectively, at the moment). On that machine, either those two patches selectively, or an entire patch cluster (8_Recommended.zip) should be installed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-06 14:44 Message: Logged In: YES user_id=33168 I thought I could not duplicate the hang on our sun, but now it's happening. Your test program also hangs. How do you determine the revision of a patch on solaris? I'm using showrev -p | grep patch-#. I'm not sure that is correct. The way I read it, it says I have 108528-16 and 108827-12. In the snake farm proton has: 108528-12 and 108827-12 fafner has: 108528-13 and 108827-19 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 13:29 Message: Logged In: YES user_id=21627 It would be good to find a system that has 108528-17 installed. I see that this fixes 4498831 system timer stops sending signals ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 13:13 Message: Logged In: YES user_id=21627 I meant revisions of the Sun patches. On one system, I have 108528-16 and 108827-34, and test_signal still hangs. I found that the blocking occurs when test_queue.py is run before, and have distilled this into the following example: import sys import thread import time import signal fsema = thread.allocate_lock() def tfunc(): time.sleep(.1) fsema.release() fsema.acquire() thread.start_new_thread(tfunc,()) fsema.acquire() fsema.release() signal.alarm(3) signal.pause() It appears that the alarm is simply lost; the pause call does not return. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-06 00:38 Message: Logged In: YES user_id=33168 What do you mean by revision of the patches? CVS revision of thread_pthread.h? I believe 2.38 worked and 2.39 broke. I can test that if you'd like. Do you want me to go back to the revision before the patch for all files affected? Since 2.39 only added the semaphores, in essence, by doing the #undef that should have the same effect as reverting thread_pthread.h to 2.38. Or are you talking about the Solaris patches? If so, they are only a guess, we could compare the patch level on all the Solaris boxes we have access to and see which ones work and which don't. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 00:11 Message: Logged In: YES user_id=21627 Could you identify a revision of these patches for which the problem disappears? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 21:57 Message: Logged In: YES user_id=33168 For (possibly) more info, see: http://lists.lysator.liu.se/pipermail/snake-farm/2003-January/000617.html ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 21:38 Message: Logged In: YES user_id=33168 Attaching output of truss (like strace for Solaris) which doesn't provide me with any more info. Hopefully this will help someone else. 2 files attached, one with complete output from; truss ./python -E -tt ./Lib/test/regrtest.py test_queue test_signal the other is just the end. It should correspond to these lines from the test: signal.alarm(20) # Entire test lasts at most 20 sec. signal.signal(5, handlerA) signal.signal(2, handlerB) signal.signal(3, signal.SIG_IGN) signal.signal(signal.SIGALRM, signal.default_int_handler) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 From noreply@sourceforge.net Wed Jan 8 17:21:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 08 Jan 2003 09:21:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-662787 ] test_signal hang on some Solaris boxes Message-ID: Bugs item #662787, was opened at 2003-01-05 14:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Anthony Baxter (anthonybaxter) Summary: test_signal hang on some Solaris boxes Initial Comment: Martin, I'm assigning this to you because you checked in the patch which caused this problem. I think your input on fixes will also be valuable. When semaphore support was added to Python/thread_pthread.h in 2.39 originally from patch 525532, it broke tests on some Solaris boxes. I know this affects Solaris 8, not sure if any other versions are affected. I believe on or more of the following Solaris 8 patches (108528, 108827) fixes the problem: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108528&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108827&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on Patches can be gotten from here: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access One way to fix the hang is to add #undef USE_SEMAPHORES at line 113 of Python/thread_pthread.h (ie, after USE_SEMAPHORES may be set). I don't know of any other way to fix this problem. I don't know if we can test for this in configure and set USE_SEMAPHORES appropriately (or if it's worth it). We can always disable USE_SEMAPHORES and allow the user to use it by manually setting the macro. We keep the code as is, and document the problem. Suggestions? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-08 12:21 Message: Logged In: YES user_id=33168 Sorry, that's really what I meant, only for Solaris 8. I'm not sure how to do that (figure out that we are on Solaris 8). I agree it would be nice to know the answer and suspect you are right that it's fixed. I don't know how to do that though. Hmmm, I think Anthony Baxter may have had Solaris. I'll assign this to him, in the hopes he can provide some more info. Anythony? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-08 12:15 Message: Logged In: YES user_id=21627 I quite object #2, although I could live with 5) disable USE_SEMAPHORES for Solaris 8 I would still like to find out whether applying all patches solves the problem. I'm quite certain that our code is correct and that there is a bug in Solaris. I'm reasonably certain that the bug has been fixed by now, so I would not want to leave USE_SEMAPHORES disabled forever on Solaris. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-08 12:11 Message: Logged In: YES user_id=33168 Martin, how do you think we should proceed with this problem? Some alternatives include: 1) try to build an autoconf test to find the problem and disable USE_SEMAPHORES 2) always disable USE_SEMAPHORES for Solaris 3) try to find a work-around 4) leave it as-is At least temporarily, I'd like to see #2. The problem is that if we do that, it will probably never get fixed. #1 is probably a lot of work. I can't implement #1 since I don't have access to a machine that works. Do you have any other ideas or possible solutions/work-arounds? ---------------------------------------------------------------------- Comment By: Inyeol Lee (inyeol) Date: 2003-01-06 22:46 Message: Logged In: YES user_id=595280 Neal, This is the patch version of my Solaris8 system you've requested; Patch: 108528-07 Patch: 108528-13 Patch: 108827-07 Patch: 108827-15 Inyeol Lee ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 09:46 Message: Logged In: YES user_id=21627 showrev -p is good, as is patchadd -p (this also shows the patches you could backup to). I notice that my Solaris 9 machine does not experience the problem, so Sun has fixed something. It would be good if a Solaris 8 machine could be brought up-to-date with regard to patches (they recommend -18 and -35 respectively, at the moment). On that machine, either those two patches selectively, or an entire patch cluster (8_Recommended.zip) should be installed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-06 08:44 Message: Logged In: YES user_id=33168 I thought I could not duplicate the hang on our sun, but now it's happening. Your test program also hangs. How do you determine the revision of a patch on solaris? I'm using showrev -p | grep patch-#. I'm not sure that is correct. The way I read it, it says I have 108528-16 and 108827-12. In the snake farm proton has: 108528-12 and 108827-12 fafner has: 108528-13 and 108827-19 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 07:29 Message: Logged In: YES user_id=21627 It would be good to find a system that has 108528-17 installed. I see that this fixes 4498831 system timer stops sending signals ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 07:13 Message: Logged In: YES user_id=21627 I meant revisions of the Sun patches. On one system, I have 108528-16 and 108827-34, and test_signal still hangs. I found that the blocking occurs when test_queue.py is run before, and have distilled this into the following example: import sys import thread import time import signal fsema = thread.allocate_lock() def tfunc(): time.sleep(.1) fsema.release() fsema.acquire() thread.start_new_thread(tfunc,()) fsema.acquire() fsema.release() signal.alarm(3) signal.pause() It appears that the alarm is simply lost; the pause call does not return. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 18:38 Message: Logged In: YES user_id=33168 What do you mean by revision of the patches? CVS revision of thread_pthread.h? I believe 2.38 worked and 2.39 broke. I can test that if you'd like. Do you want me to go back to the revision before the patch for all files affected? Since 2.39 only added the semaphores, in essence, by doing the #undef that should have the same effect as reverting thread_pthread.h to 2.38. Or are you talking about the Solaris patches? If so, they are only a guess, we could compare the patch level on all the Solaris boxes we have access to and see which ones work and which don't. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-05 18:11 Message: Logged In: YES user_id=21627 Could you identify a revision of these patches for which the problem disappears? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 15:57 Message: Logged In: YES user_id=33168 For (possibly) more info, see: http://lists.lysator.liu.se/pipermail/snake-farm/2003-January/000617.html ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 15:38 Message: Logged In: YES user_id=33168 Attaching output of truss (like strace for Solaris) which doesn't provide me with any more info. Hopefully this will help someone else. 2 files attached, one with complete output from; truss ./python -E -tt ./Lib/test/regrtest.py test_queue test_signal the other is just the end. It should correspond to these lines from the test: signal.alarm(20) # Entire test lasts at most 20 sec. signal.signal(5, handlerA) signal.signal(2, handlerB) signal.signal(3, signal.SIG_IGN) signal.signal(signal.SIGALRM, signal.default_int_handler) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 From noreply@sourceforge.net Wed Jan 8 18:57:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 08 Jan 2003 10:57:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-427345 ] CGIHTTPServer fix for Windows Message-ID: Bugs item #427345, was opened at 2001-05-25 13:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=427345&group_id=5470 Category: Python Library Group: Platform-specific >Status: Closed Resolution: None Priority: 5 Submitted By: Kevin Altis (kasplat) Assigned to: Steve Holden (holdenweb) Summary: CGIHTTPServer fix for Windows Initial Comment: CGIHTTPServer.py in the Python 2.1 library needs two changes to the popen2 section in order to support binary data and to avoid buffering problems under Windows. The complete code block is shown at the end of this message. The two changed lines are: cmdline = "%s -u %s" % (interp, cmdline) fi, fo = os.popen2(cmdline, 'b') I've tested this under Windows 2000 Pro and binary file uploads now work, however more extensive tests should probably be done. It appears there is another socket-related problem and/or end-of-line conversion error that occurs when using Internet Explorer 5.x and BASEHTTPServer with CGIHTTPServer on the same machine. I'm still investigating that issue. Finally, I have done a small rewrite of CGIHTTPServer.py to simplify subclassing it to support running CGIs in any or all directories and using other file extensions such as .cgi. The maintainer for the current file should email me about the changes to see whether they want to update the official library file. I didn't post it here since it needs more tweaking ka --- CGIHTTPServer.p fixes... elif self.have_popen2: # Windows -- use popen2 to create a subprocess import shutil os.environ.update(env) cmdline = scriptfile if self.is_python(scriptfile): interp = sys.executable if interp.lower().endswith("w.exe"): # On Windows, use python.exe, not python.exe interp = interp[:-5] = interp[-4:] cmdline = "%s -u %s" % (interp, cmdline) if '=' not in query and '"' not in query: cmdline = '%s "%s"' % (cmdline, query) self.log_error("command: %s", cmdline) try: nbytes = int(length) except: nbytes = 0 fi, fo = os.popen2(cmdline, 'b') if self.command.lower() == "post" and nbytes > 0: data = self.rfile.read(nbytes) fi.write(data) fi.close() shutil.copyfileobj(fo, self.wfile) sts = fo.close() if sts: self.log_error("CGI script exit status %#x", sts) else: self.log_error("CGI script exited OK") ---------------------------------------------------------------------- >Comment By: Steve Holden (holdenweb) Date: 2003-01-08 13:57 Message: Logged In: YES user_id=88157 Should be fixed by patch 654910, committed today. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-05 11:00 Message: Logged In: YES user_id=6380 Like 430160, I'm assigning this to Steve Holden who may check in a fix. Good luck! ---------------------------------------------------------------------- Comment By: Kevin Altis (kasplat) Date: 2002-08-05 00:07 Message: Logged In: YES user_id=228025 I have a possible fix, at least when the server is running on Windows. As suggested previously, the key is to read the bytes beyond the content-length, but without blocking. Steve Holden suggested I use select, which seems simpler than another solution which is to make the socket non-blocking, then attempting to read 2 bytes of data within a try/except block. The solution below just loops with select.select if self.command.lower() == "post" and nbytes > 0: data = self.rfile.read(nbytes) fi.write(data) # now throw away data past Content-length while select.select([self.rfile._sock], [], [], 0)[0] != []: waste = self.rfile._sock.recv(1) fi.close() This is slightly verbose. The two additional lines go below the fi.write statement on line 247 of CGIHTTPServer.py, line 248 if you count the import select statement that needs to be added at the top of the file. I have only tested this on Windows since the server code is Windows-specific. I do not know if a server running on Unix suffers this same problem. I verified that POST works correctly from the following browsers on Windows 2000: IE 5.5, Opera 6.0.4, and Netscape 4.7. Only IE sends the extra CR/LF, Opera and Netscape do not. ka ---------------------------------------------------------------------- Comment By: Kevin Altis (kasplat) Date: 2002-08-03 13:37 Message: Logged In: YES user_id=228025 This bug is related to another bug https://sourceforge.net/tracker/? func=detail&aid=430160&group_id=5470&atid=105470 Bob Denny (author of the WebSite server, formerly sold by O'Reilly) had this to say about the POST problem: "This is an old problem, traced back to Netscape and Unix- based shell CGI scripts. Netscape browsers did this to force completion of the POST into shell scripts. The cr/lf is not part of the POST payload, and the CGI script that is dealing with the POST needs to toss it away. The general solution is, read Content-Length bytes, then reas anything else that may be in the buffer and junk it. IE is emulating the behavior of Netscape." So, that explains why IE (and possibly other browsers) sticks a CR/LF on the end of a POST causing a mismatch with the Content-length header. Now the question is where a fix can be inserted in the libs? Looking again at CGIHTTPServer.py, perhaps this problem is isolated to Windows, in which case the fix might be in the block of code starting on line 218, and more specifically, line 246 data = self.rfile.read(nbytes) so at that point, the remaining 2 bytes should be read, but tossed. I'll investigate. Steve Holden and I have been emailing back and forth on this issue, so if anyone else has other suggestions, post here or email one of us. Thanks, ka ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-07-08 21:27 Message: Logged In: NO hello ---------------------------------------------------------------------- Comment By: Thomas Justin Shaw (justinshaw) Date: 2002-03-31 03:48 Message: Logged In: YES user_id=135558 To: Matthew King Thanks for reposting that solution. That did seem to fix the problem. To: Mark Lutz Using: Win2000 Pro IE5 python2.2.1c locally The bug shows up as a popup message but the page loads. When I tried it accross a lan the page wouldn't even load (blowing a little demo). So I guess it is not ONLY a local problem. Thanks for posting. Justin Shaw ---------------------------------------------------------------------- Comment By: Thomas Justin Shaw (justinshaw) Date: 2002-03-29 02:36 Message: Logged In: YES user_id=135558 I'm experiencing a problem on windows. When I execute the scripts as 'http://localhost:8080/cgi-bin\junk.py' the page seems to load ok but I get the popup message: Internet Explorer cannot open the Internet site http://localhost:8080/cgi-bin\junk.py The connection with the server ws reset On Netscape no errors but the download also takes forever. The slow download seems to be caused by the FieldStorage() call. ---------------------------------------------------------------------- Comment By: Matthew King (kyrrigle) Date: 2002-03-28 16:21 Message: Logged In: YES user_id=247536 this looks like the same issue as #430160. and here's what I just wrote there... it appears that IE is sending 2 extra bytes ('\r\n') after the request data. and if you don't read those two extra bytes off, the window's socket handling gets messed up. the result is that a partial response is returned and the socket closed. IE tries to recover by re-POST'ing (which is behavior specified in the HTTP/1.1 RFC)... only they seem to add an embedded NULL the second time through, and the original socket problem happens again anyway. Try reading an extra 2 bytes from the rfile before sending your response and the problem should go away. (you can do that by 'self.rfile._rbufsize = content_length + 2' inside your do_POST method before reading the content) not sure what the real fix for this should be? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-09-05 11:40 Message: Logged In: YES user_id=6380 Load shedding. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 09:14 Message: Logged In: YES user_id=6380 Reopening -- not that I have time for this. :-( Note that that patch is in socket.py. If this really is a work-around, I'd like to understand why. ---------------------------------------------------------------------- Comment By: Steve Pike (oztourer) Date: 2001-08-09 08:27 Message: Logged In: YES user_id=120658 To further elaborate on the problems with POST on Windows 95: without having reached any real understanding of the problem I have found a tolerable workaround. By modifying the default _rbufsize for class _fileobject in socket.py I can get any POSTs with text length less than _rbufsize to work. Here is the mod: 
class _fileobject:
    def __init__(self, sock, mode, bufsize):
        self._sock = sock
        self._mode = mode
        if bufsize < 0:
            bufsize = 512
        # SP 9 Aug 2001: default _rbufsize is too small, 
crashing CGIHTTPServer on POST's
        # This fix still only allows pages of less than 
given buffer size to be updated,
        # so the real fix has still to be discovered.
        #self._rbufsize = max(1, bufsize)
        self._rbufsize = max(16*1024, bufsize)
        self._wbufsize = bufsize
        self._wbuf = self._rbuf = ""
-- StevePike ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-07 15:59 Message: Logged In: YES user_id=6380 I agree that this is a laudable goal, but I don't have the time to spend to work on this. Please upload a patch to the SF patch manager and assign it to me and I'll look at it. In the mean time, I've applied the two small suggestions and will close this bug report. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-05-29 12:29 Message: Logged In: NO I want to elaborate on the second-to-last paragraph in this report. CGIHTTPServer in 2.1 and 2.0 is apparently broken for POST requests (only) to CGI scripts, when running locally on Windows with an IE client. The details: there is a problem with the combination of a CGIHTTPServer and Intenernet Explorer both running locally on Windows (with server name "localhost"). In this setup, POST requests to CGI scripts fail, but GET requests to the exact same script work fine. That is, a form with method=GET, or a URL with an appended query string, both work ok. In POST mode, the CGI script gets proper data in the input stream, and generates a correct reply stream (which is in fact identical to the output generated for quivalent GET requests). So, somewhere between CGIHTTPServer and IE, the data seems to be dropped or munged. The same thing happens of you force CGIHTTPServer to use execfile() to launch the script, instead of os.popen2. I've also observed that endline conventions seem to be irrelevant to the problem; using \n or \r\n makes no difference in both the input and reply streams. I've also been told that the problem may not exist in Netscape clients. Since CGIHTTPServer is a very nice way to test CGI scripts (all you need is a standard Python install), this seems important. It would also be nice if the directory assumptions in that module were more customizable, but that's just a wish. --Mark Lutz ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=427345&group_id=5470 From noreply@sourceforge.net Wed Jan 8 18:58:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 08 Jan 2003 10:58:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-430160 ] CGIHTTPServer.py POST bug using IE Message-ID: Bugs item #430160, was opened at 2001-06-04 20:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=430160&group_id=5470 Category: Windows Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Kevin Altis (kasplat) Assigned to: Steve Holden (holdenweb) Summary: CGIHTTPServer.py POST bug using IE Initial Comment: >From the readme included in the zip: This set of files shows a bug that occurs when doing POST requests via the CGIHTTPServer.py module in Python 2.1 The testpost.html file when accessed via Internet Explorer 5.5 from webserver.py should show this bug. On short POST requests IE will end up doing a second POST and then displaying an error message while longer POSTs will be followed by a second POST and then a GET. The problem appears to be specific to the interaction of IE and the handling of windows sockets in Python in the CGIHTTPServer.py module which relies on BaseHTTPServer.py, SocketServer.py... posttestwebserver.py is currently setup to use C:\tmp\testpost as the document root, so either move the "testpost" folder to C:\tmp or change the directory to wherever the testpost folder is located. Start the server using the .bat file and bring up .html page with something like: http://localhost/testpost.html The bug should occur when you try: Test short CGI response with POST or Test long CGI response with POST The other requests should work fine. The bug will occur regardless of whether IE is set to use HTTP/1.0 or HTTP/1.1. The bug doesn't appear to occur when going through a simple proxy. You can also get the bug to occur using a remote IE client (either on a LAN or over the Net). In addition, it doesn't appear to matter whether running with unbuffered binary pipes (python -u) or not. I also tested against my modified CGIHTTPServer.py See the bug I posted at: http://sourceforge.net/tracker/? func=detail&atid=105470&aid=427345&group_id=5470 My configuration: Windows 2000 Pro, SP2 AMD 1.2GHz 256MB RAM ActiveStatet Python 2.1 (build 210) Internet Explorer 5.5 (5.50.4522.1800) ka --- Mark Lutz said: "FWIW, I noticed today (in between lecturing a class) that on Windows, Python actually uses a special Python- coded socket.py library module, not the standard C- coded socket extension module. socket.py lives in the library directory; it does unique things for closes and deletes that may not make sense in all cases (e.g., the makefile call generates a class instance, not a true file object). It may also be trying to close the underlying socket twice. I don't have" ---------------------------------------------------------------------- >Comment By: Steve Holden (holdenweb) Date: 2003-01-08 13:58 Message: Logged In: YES user_id=88157 Should be fixed by patch 654910 committed today. ---------------------------------------------------------------------- Comment By: Steve Holden (holdenweb) Date: 2002-08-15 22:25 Message: Logged In: YES user_id=88157 This patch appears to fix the basic CGIHTTPServer behavior, at least for Unix and Wiondows platforms, but I'm not yet confident of its robustness in the face of Forking or threading mixin code. More later ... ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-08-05 10:57 Message: Logged In: YES user_id=6380 Steve, I'm assigning this bug to you. Feel free to check in a fix if you think one exists (as long as it doesn't break on Unix). ---------------------------------------------------------------------- Comment By: Matthew King (kyrrigle) Date: 2002-03-28 15:49 Message: Logged In: YES user_id=247536 it appears that IE is sending 2 extra bytes ('\r\n') after the request data. and if you don't read those two extra bytes off, the window's socket handling gets messed up. the result is that a partial response is returned and the socket closed. IE tries to recover by re-POST'ing (which is behavior specified in the HTTP/1.1 RFC)... only they seem to add an embedded NULL the second time through, and the original socket problem happens again anyway. Try reading an extra 2 bytes from the rfile before sending your response and the problem should go away. not sure what the real fix for this should be? ---------------------------------------------------------------------- Comment By: Steve Holden (holdenweb) Date: 2001-07-17 07:28 Message: Logged In: YES user_id=88157 Please note that I have observed this behavior on Windows 98 using Python 2.0 (#8, Mar 7 2001, 16:04:37) [MSC 32 bit (Intel)] using the same build of IE, so it is not a Win2k- specific problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=430160&group_id=5470 From noreply@sourceforge.net Wed Jan 8 19:28:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 08 Jan 2003 11:28:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-664581 ] test_bsddb3 fails when run directly Message-ID: Bugs item #664581, was opened at 2003-01-08 20:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=664581&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Barry A. Warsaw (bwarsaw) Summary: test_bsddb3 fails when run directly Initial Comment: This is Python CVS of 2003-01-08: projects/Python> pythondev Dev-Python/Lib/test/test_bsddb3.py -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Sleepycat Software: Berkeley DB 4.0.14: (November 18, 2001) bsddb.db.version(): (4, 0, 14) bsddb.db.__version__: 4.1.1 bsddb.db.cvsid: $Id: _bsddb.c,v 1.3 2002/12/30 20:53:52 bwarsaw Exp $ python version: 2.3a1 (#1, Jan 6 2003, 02:03:16) [GCC 2.95.3 20010315 (SuSE)] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Traceback (most recent call last): File "Dev-Python/Lib/test/test_bsddb3.py", line 67, in ? unittest.main(defaultTest='suite') File "/home/lemburg/projects/Python/Installation/lib/python2.3/unittest.py", line 710, in __init__ self.parseArgs(argv) File "/home/lemburg/projects/Python/Installation/lib/python2.3/unittest.py", line 737, in parseArgs self.createTests() File "/home/lemburg/projects/Python/Installation/lib/python2.3/unittest.py", line 743, in createTests self.module) File "/home/lemburg/projects/Python/Installation/lib/python2.3/unittest.py", line 509, in loadTestsFromNames suites.append(self.loadTestsFromName(name, module)) File "/home/lemburg/projects/Python/Installation/lib/python2.3/unittest.py", line 494, in loadTestsFromName test = obj() File "Dev-Python/Lib/test/test_bsddb3.py", line 44, in suite module = __import__("bsddb.test."+name, globals(), locals(), name) ImportError: No module named test.test_associate Looking at the installed bsddb package, there is no subpackage 'test' in there. It is available in the source tree, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=664581&group_id=5470 From noreply@sourceforge.net Wed Jan 8 19:31:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 08 Jan 2003 11:31:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-664584 ] test_ossaudiodev fails to run Message-ID: Bugs item #664584, was opened at 2003-01-08 20:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=664584&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Greg Ward (gward) Summary: test_ossaudiodev fails to run Initial Comment: This is Python CVS of 2003-01-08. test_ossaudiodev is skipped because ossaudiodev module itself is not being built and installed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=664584&group_id=5470 From noreply@sourceforge.net Wed Jan 8 19:55:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 08 Jan 2003 11:55:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-532631 ] Confusions in formatfloat Message-ID: Bugs item #532631, was opened at 2002-03-20 19:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532631&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) >Assigned to: Tim Peters (tim_one) Summary: Confusions in formatfloat Initial Comment: stringobject.c's formatfloat seems confused in a couple respects. 1. Testing "fabs(x)/1e25 >= 1e25" is pretty baffling. What is it intending to do? If it means what it says, it should be the simpler "fabs(x) >= 1e50". But maybe it really intended to test "fabs(x) >= 1e25". 2. The "worst case length calc" is fantasy in some %f cases. It assumes there's one digit before the decimal point, but, e.g., '%.100f'% 1e49 produces dozens of digits before the decimal point. We're saved from a buffer overrun thanks to the PyOS_snprintf () following, but unclear that truncation is sensible here (e.g., the user asked for a precision of 100 here, but only gets back 50 digits after the decimal point). Complication: we're deliberately replacing C's %f with C's %g in some cases, but the docs don't document the rules Python intends for %f. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-08 20:55 Message: Logged In: YES user_id=38388 Your first finding is baffling indeed. No idea how it came to be (I don't remember having added such code). The test seems to be intended to switch from 'g' format to 'f' format at an arbirary number of decimals before the decimal point. "fabs(x) >= 1e50" should do the same. Feel free to change this. The second point should be fixed after my checkin: >>> '%.100f'% 1e49 Traceback (most recent call last): File "", line 1, in ? OverflowError: formatted float is too long (precision too large?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-08 02:29 Message: Logged In: YES user_id=31435 Marc-Andre is in a better position to tell us what he fixed than I am, so assigned to him. MAL, feel free to close this if you think it's history. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-08 02:24 Message: Logged In: YES user_id=33168 Tim, did MALs recent checkin fix any of these problems? Is doc the only thing left to do? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532631&group_id=5470 From noreply@sourceforge.net Wed Jan 8 21:28:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 08 Jan 2003 13:28:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-532631 ] Confusions in formatfloat Message-ID: Bugs item #532631, was opened at 2002-03-20 13:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532631&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) >Assigned to: Nobody/Anonymous (nobody) Summary: Confusions in formatfloat Initial Comment: stringobject.c's formatfloat seems confused in a couple respects. 1. Testing "fabs(x)/1e25 >= 1e25" is pretty baffling. What is it intending to do? If it means what it says, it should be the simpler "fabs(x) >= 1e50". But maybe it really intended to test "fabs(x) >= 1e25". 2. The "worst case length calc" is fantasy in some %f cases. It assumes there's one digit before the decimal point, but, e.g., '%.100f'% 1e49 produces dozens of digits before the decimal point. We're saved from a buffer overrun thanks to the PyOS_snprintf () following, but unclear that truncation is sensible here (e.g., the user asked for a precision of 100 here, but only gets back 50 digits after the decimal point). Complication: we're deliberately replacing C's %f with C's %g in some cases, but the docs don't document the rules Python intends for %f. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-08 16:28 Message: Logged In: YES user_id=31435 Leaving this unassgned again, with the first and last points unresolved (I don't have time for this now). The "worst case length calc" point is probably fixed. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-08 14:55 Message: Logged In: YES user_id=38388 Your first finding is baffling indeed. No idea how it came to be (I don't remember having added such code). The test seems to be intended to switch from 'g' format to 'f' format at an arbirary number of decimals before the decimal point. "fabs(x) >= 1e50" should do the same. Feel free to change this. The second point should be fixed after my checkin: >>> '%.100f'% 1e49 Traceback (most recent call last): File "", line 1, in ? OverflowError: formatted float is too long (precision too large?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-07 20:29 Message: Logged In: YES user_id=31435 Marc-Andre is in a better position to tell us what he fixed than I am, so assigned to him. MAL, feel free to close this if you think it's history. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 20:24 Message: Logged In: YES user_id=33168 Tim, did MALs recent checkin fix any of these problems? Is doc the only thing left to do? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=532631&group_id=5470 From noreply@sourceforge.net Wed Jan 8 22:14:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 08 Jan 2003 14:14:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-664715 ] Demo/dbm.py - Rewrite using anydbm? Message-ID: Bugs item #664715, was opened at 2003-01-08 23:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=664715&group_id=5470 Category: Demos and Tools Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jack Jansen (jackjansen) Assigned to: Nobody/Anonymous (nobody) Summary: Demo/dbm.py - Rewrite using anydbm? Initial Comment: It may be a good idea to rewrite Demo/Dbm.py to use anydbm, which is available on all platforms. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=664715&group_id=5470 From noreply@sourceforge.net Thu Jan 9 13:32:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 09 Jan 2003 05:32:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-665014 ] files with long lines and an encoding crash Message-ID: Bugs item #665014, was opened at 2003-01-10 00:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665014&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 8 Submitted By: Mark Hammond (mhammond) Assigned to: M.-A. Lemburg (lemburg) Summary: files with long lines and an encoding crash Initial Comment: If a source file declares an encoding, but has a line > 512 characters, a buffer overflows. debug builds assert, but release builds trudge along. Problem is that when reading an encoded line, the 'size' param is not passed to the underlying readline function. Attaching a test case and a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665014&group_id=5470 From noreply@sourceforge.net Thu Jan 9 13:54:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 09 Jan 2003 05:54:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-665014 ] files with long lines and an encoding crash Message-ID: Bugs item #665014, was opened at 2003-01-09 14:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665014&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 8 Submitted By: Mark Hammond (mhammond) >Assigned to: Martin v. Löwis (loewis) Summary: files with long lines and an encoding crash Initial Comment: If a source file declares an encoding, but has a line > 512 characters, a buffer overflows. debug builds assert, but release builds trudge along. Problem is that when reading an encoded line, the 'size' param is not passed to the underlying readline function. Attaching a test case and a patch. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-09 14:54 Message: Logged In: YES user_id=38388 Assigned to Martin since he wrote the source code encoding support. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665014&group_id=5470 From noreply@sourceforge.net Thu Jan 9 15:47:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 09 Jan 2003 07:47:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-665101 ] Scripts menu display error in PythonIDE Message-ID: Bugs item #665101, was opened at 2003-01-09 07:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665101&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Larry Meyn (larrymeyn) >Assigned to: Just van Rossum (jvr) Summary: Scripts menu display error in PythonIDE Initial Comment: The Scripts menu of PythonIDE has a display problem. Everywhere the ellipsis (...) symbol should be are a comma, an umlauted A and a paragraph symbol. Python 2.3.a1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665101&group_id=5470 From noreply@sourceforge.net Thu Jan 9 18:24:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 09 Jan 2003 10:24:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-665194 ] datetime-RFC2822 roundtripping Message-ID: Bugs item #665194, was opened at 2003-01-09 19:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665194&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: datetime-RFC2822 roundtripping Initial Comment: It would be good to have a simply way to convert between datetime objects and RFC2822 style strings. >From string to datetime is easy with datetime.datetime(*email.Utils.parsedate(m)[:7]) (but this drops the timezone), but the other direction seems impossible. email.Utils.formatdate takes a timestamp argument, but AFAICT there's no way to get a timestamp out of a datetime object. Of course the best solution (ignoring backwards compatibility) would be for parsedate und formatdate to return/accept datetime objects or for datetime to have the appropriate methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665194&group_id=5470 From noreply@sourceforge.net Thu Jan 9 21:42:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 09 Jan 2003 13:42:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-665336 ] win32 os.path.normpath not correct for leading slash cases Message-ID: Bugs item #665336, was opened at 2003-01-09 21:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665336&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Stephan R.A. Deibel (sdeibel) Assigned to: Nobody/Anonymous (nobody) Summary: win32 os.path.normpath not correct for leading slash cases Initial Comment: os.path.normpath on win32 misses two cases in its duplicate slash removal code that I believe should be dealt with: c:\x\y\z \\x\y\z Both of these are returned unchanged. I've attached an implementation that fixes these to return the following, respectively: c:\x\y\z \x\y\z I did see the other normpath bugs that were reported and rejected and think that the above isn't also a case of "garbage in garbage out" but of course there's room for interpretation. I am a bit unsure about the UNC case since Posix collapses only 3+ leading slashes to a single slash and otherwise leaves up to two slashes. But in the context of win32 the above seems to make more sense to me. Thanks, Stephan Deibel Wing IDE Developer Archaeopteryx Software -------------------- def normpath(path): """Normalize path, eliminating double slashes, etc.""" path = path.replace("/", "\") prefix, path = os.path.splitdrive(path) if prefix == '': max_leading = 2 else: max_leading = 1 i = 0 while path[:1] == "\": if i < max_leading: prefix = prefix + "\" i += 1 path = path[1:] comps = path.split("\") i = 0 while i < len(comps): if comps[i] in ('.', ''): del comps[i] elif comps[i] == '..': if i > 0 and comps[i-1] != '..': del comps[i-1:i+1] i -= 1 elif i == 0 and prefix.endswith("\"): del comps[i] else: i += 1 else: i += 1 # If the path is now empty, substitute '.' if not prefix and not comps: comps.append('.') return prefix + "\".join(comps) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665336&group_id=5470 From noreply@sourceforge.net Thu Jan 9 15:46:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 09 Jan 2003 07:46:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-665101 ] Scripts menu display error in PythonIDE Message-ID: Bugs item #665101, was opened at 2003-01-09 07:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665101&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Larry Meyn (larrymeyn) Assigned to: Jack Jansen (jackjansen) Summary: Scripts menu display error in PythonIDE Initial Comment: The Scripts menu of PythonIDE has a display problem. Everywhere the ellipsis (...) symbol should be are a comma, an umlauted A and a paragraph symbol. Python 2.3.a1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665101&group_id=5470 From noreply@sourceforge.net Thu Jan 9 23:00:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 09 Jan 2003 15:00:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-665101 ] Scripts menu display error in PythonIDE Message-ID: Bugs item #665101, was opened at 2003-01-09 07:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665101&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Larry Meyn (larrymeyn) Assigned to: Just van Rossum (jvr) Summary: Scripts menu display error in PythonIDE Initial Comment: The Scripts menu of PythonIDE has a display problem. Everywhere the ellipsis (...) symbol should be are a comma, an umlauted A and a paragraph symbol. Python 2.3.a1 ---------------------------------------------------------------------- >Comment By: Larry Meyn (larrymeyn) Date: 2003-01-09 15:00 Message: Logged In: YES user_id=401558 On Thursday, January 9, 2003, at 02:38 PM, Skip Montanaro wrote: Pascal> Hmm... Seems like the PythonIDE (under MacPython 2.3a1 [*not* Pascal> OS9]) lost its ability to display mac-roman characters like ä, Pascal> ö, ü, or '...' (i.e. true ellipsis) from the scripts menu if Pascal> they occur inside script names. I thought I saw a note here or on the python-checkins list that Jack had switched the default encoding to ascii. If you want/need mac-roman I think you'll need to edit site.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665101&group_id=5470 From noreply@sourceforge.net Thu Jan 9 23:23:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 09 Jan 2003 15:23:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-665101 ] Scripts menu display error in PythonIDE Message-ID: Bugs item #665101, was opened at 2003-01-09 16:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665101&group_id=5470 Category: Macintosh Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Larry Meyn (larrymeyn) Assigned to: Just van Rossum (jvr) Summary: Scripts menu display error in PythonIDE Initial Comment: The Scripts menu of PythonIDE has a display problem. Everywhere the ellipsis (...) symbol should be are a comma, an umlauted A and a paragraph symbol. Python 2.3.a1 ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-01-10 00:23 Message: Logged In: YES user_id=92689 The poster on the mac list mentioned MacPython so I thought he meant the OS9-compatible MacPython. I don't see the effect there, but I do in a FrameWork build. Fixed in CVS. ---------------------------------------------------------------------- Comment By: Larry Meyn (larrymeyn) Date: 2003-01-10 00:00 Message: Logged In: YES user_id=401558 On Thursday, January 9, 2003, at 02:38 PM, Skip Montanaro wrote: Pascal> Hmm... Seems like the PythonIDE (under MacPython 2.3a1 [*not* Pascal> OS9]) lost its ability to display mac-roman characters like ä, Pascal> ö, ü, or '...' (i.e. true ellipsis) from the scripts menu if Pascal> they occur inside script names. I thought I saw a note here or on the python-checkins list that Jack had switched the default encoding to ascii. If you want/need mac-roman I think you'll need to edit site.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665101&group_id=5470 From noreply@sourceforge.net Fri Jan 10 02:51:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 09 Jan 2003 18:51:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-665460 ] Crash in binascii_a2b_uu Message-ID: Bugs item #665460, was opened at 2003-01-10 03:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665460&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Scharf (scharf) Assigned to: Nobody/Anonymous (nobody) Summary: Crash in binascii_a2b_uu Initial Comment: I submitted a patch to patches (http://sourceforge.net/tracker/index.php? func=detail&aid=665458&group_id=5470&atid=305470) its a similar type of bug as http://sourceforge.net/tracker/index.php? func=detail&aid=665014&group_id=5470&atid=105470 Michael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665460&group_id=5470 From noreply@sourceforge.net Fri Jan 10 02:53:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 09 Jan 2003 18:53:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-665460 ] Crash in binascii_a2b_uu Message-ID: Bugs item #665460, was opened at 2003-01-10 03:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665460&group_id=5470 >Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Scharf (scharf) Assigned to: Nobody/Anonymous (nobody) Summary: Crash in binascii_a2b_uu Initial Comment: I submitted a patch to patches (http://sourceforge.net/tracker/index.php? func=detail&aid=665458&group_id=5470&atid=305470) its a similar type of bug as http://sourceforge.net/tracker/index.php? func=detail&aid=665014&group_id=5470&atid=105470 Michael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665460&group_id=5470 From noreply@sourceforge.net Fri Jan 10 05:36:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 09 Jan 2003 21:36:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-639022 ] Install script goes into infinite loop Message-ID: Bugs item #639022, was opened at 2002-11-15 18:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639022&group_id=5470 Category: Installation Group: 3rd Party Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Mel (meldh) Assigned to: Nobody/Anonymous (nobody) Summary: Install script goes into infinite loop Initial Comment: ./configure -- works make -- works make test -- works make install -- gets as far as trying to do this: PYTHONPATH=/usr/local/lib/python2.2 \ ./python -tt /usr/local/lib/python2.2/compileall.py -x badsyntax \ /usr/local/lib/python2.2 Listing /usr/local/lib/python2.2 ... Listing /usr/local/lib/python2.2/ ... and then goes off into infinite loop, repeating the last line until Ctrl- C. Debian 2.2 (potato), 2.2.18pre21 kernel version. ---------------------------------------------------------------------- Comment By: Steve Traugott (stevegt) Date: 2003-01-10 05:36 Message: Logged In: YES user_id=17621 FYI I ran into the same problem on a RedHat 7.2-ish machine. The pyconfig.h workaround described earlier (deleting the three #defines for large file support) works. ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-20 09:06 Message: Logged In: YES user_id=649744 I think that seems reasonable. By editing pyconfig.h, I can at least get a version which works (well, aside from those weirdnesses with not importing socket properly, but those look to be unrelated). Thanks again to all involved for your help. Very odd one... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-20 08:25 Message: Logged In: YES user_id=21627 I would now propose to close this bug as 3rdparty: somehow, large file system (LFS) support is not working on your system, in a very subtle way. Since we cannot pin the problem, I can only recommend to manually disable LFS when configuring Python on this system, by editing pyconfig.h. It looks like the fault is not in the C library. If you want to investigate further, I recommend the following tests: - copy the binary that lists a set of empty quotes onto the other machine. See if it works there. - if it does work there, link the binary statically, and try again, on both systems. ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-19 23:32 Message: Logged In: YES user_id=649744 Compiling without the defines produces a version which correctly lists the directory. Compiling with the defines produces a version which lists a set of empty quotes. ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-19 23:22 Message: Logged In: YES user_id=649744 dpkg -l libc6 reckons that the library is version 2.2.5-6. Compiling now. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-19 22:44 Message: Logged In: YES user_id=21627 It looks like posixmodule is miscompiled. Can you please compile the attached l.c both with and without -D_HAVE_LARGEFILE_SUPPORT=1 -D_FILE_OFFSET_BITS=64 It should print out the directory contents of the current directory in both cases. If it doesn't, please attach the preprocessor output for both compilations (obtained with --save-temps, as l.i). Also, your ldconfig output does not provide the glibc version, please use "dpkg -l libc6" to report the precise version. ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-19 19:01 Message: Logged In: YES user_id=649744 Okay, done (I think). Gzipped output attached. Warning: long, dull... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-19 18:43 Message: Logged In: YES user_id=33168 It would be good to step into PyString_FromStringAndSize() to see the parameter values for the string and size too. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-19 18:41 Message: Logged In: YES user_id=33168 Getting closer, we need a bit more though. Where the list is created is in the loop 9+ lines down from PyArg_ParseTuple() at line 1156. My guess is that the string is coverted to the empty string on line 1170 each time through the loop. Can you print *ep? I'm guessing that ep->d_namlen == 0 but there is a string in ep->d_name. Is this what's happening? ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-19 18:28 Message: Logged In: YES user_id=649744 Log of stepthrough attached. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-19 18:14 Message: Logged In: YES user_id=21627 What we need is a step *through* posix_listdir. If step won't enter the function, please try stepi for a couple of instructions (10 or so), then do "info source", and "bt". ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-19 17:23 Message: Logged In: YES user_id=649744 Looks to me like it's trying to do the right thing... [lots of stepping elided] 79 return (*meth)(self, arg); (gdb) print meth $1 = 0x809a5ec (gdb) $2 = 0x809a5ec (gdb) step ['', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', '', ''] >>> quit If you want a copy of the full log with all the steps in, let me know (though it'll look a lot like the earlier one) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-19 16:57 Message: Logged In: YES user_id=21627 In the line that reads 79 return (*meth)(self, arg); you should be stepping into the function that will is called, i.e. posix_listdir. If gdb does not step into that function, can you please find out what the value of meth is, and how it compares to the address of posix_listdir? ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-19 14:45 Message: Logged In: YES user_id=649744 Running the debugger on the version built without the pyconfig.h changes (which does indeed still mean that os.listdir is broken) does break first in PyEval_EvalCode. Stepping through... hm. Attached gdb.log doesn't tell me a whole lot, but I'm hoping it'll make more sense to the rest of you out there. ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-19 14:17 Message: Logged In: YES user_id=649744 Posix is being imported as a builtin, same as your log - I've attached the output of test_os.py below. Now I'll have a crack at the debugger. ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-19 14:09 Message: Logged In: YES user_id=649744 OK, let me rebuild without the pyconfig.h changes (so that I get back to a version in which os.listdir doesn't work) and see if I can get gdb to do something useful; I'll set the breakpoints where you suggested and see what happens. More soon. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-19 13:44 Message: Logged In: YES user_id=33168 It appears all the failures are due to the socket failure. I don't know why socket failed to import, you can try importing it manually and see the error message you get. If you changed pyconfig.h manually, you may need to remove your entire build/ directory. The dependancies in Modules/ don't always rebuild everything they need to, I think. Mel, I think what Jack wanted, was for you to do this: ./python -v ./Lib/test/regrtest.py test_os.py This will show what is being imported. Mine shows this: [neal@epoch src]$ ./python -v ./Lib/test/regrtest.py test_os.py # /home/neal/build/python/dist/src/Lib/site.pyc matches /home/neal/build/python/dist/src/Lib/site.py import site # precompiled from /home/neal/build/python/dist/src/Lib/site.pyc # /home/neal/build/python/dist/src/Lib/os.pyc matches /home/neal/build/python/dist/src/Lib/os.py import os # precompiled from /home/neal/build/python/dist/src/Lib/os.pyc import posix # builtin So we see posix being imported. Jack seems to think (I've had the same thought) that when you run os.listdir() that is not calling the C posix_listdir() as it seems it should. You could do what I suggested before in the debugger, but break in PyEval_EvalCode(), fast_cfunction() and fast_function() and step through to find what's happening. For me, PyEval_EvalCode is where I break when running os.listdir(). I'm not sure where I got this from, but you can use this macro in gdb to print the python stack too. It's quite handy: define ppystack while $pc < Py_Main || $pc > Py_GetArgcArgv if $pc > eval_frame && $pc < PyEval_EvalCodeEx set $__fn = PyString_AsString(co->co_filename) set $__n = PyString_AsString(co->co_name) printf "%s (%d): %s\n", $__fn, f->f_lineno, $__n end up-silently 1 end select-frame 0 end I'm not sure if any of this will help, but it's more things to try to figure out the real problem. ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-19 11:20 Message: Logged In: YES user_id=649744 Attached is log of 'make install'. Could someone take a look and tell me which (if any) of these errors I should be concerned about? (the ones relating to _socket look likely candidates) ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-19 11:02 Message: Logged In: YES user_id=649744 Okay. The current situation after fixing pyconfig.h in the manner suggested by loewis is: - os.listdir now does what it ought to (i.e. lists the directory instead of lots of sets of empty quotes) - make appears to work OK - make test fails in some places, which I am now re-running to log - haven't tried make install yet (and would prefer to get make test running cleanly first in any case) Jack: this box didn't actually have a previous Python install as far as I am aware. (certainly 'which python' doesn't give me anything and I don't remember installing it when I set the box up last month). Only Python files, then, are in the build directory... ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-11-19 09:48 Message: Logged In: YES user_id=45365 WRT the debugger not working: are you sure you are actually using the posix module you think you're using? If you're somehow picking up a module that is meant for a different Python I could imagine random failures (like listdir returning empty strings). Could you run the listdir test with "python -v", and check that you are actually importing the posixmodule it should be importing? ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-18 23:40 Message: Logged In: YES user_id=649744 OK, some tests failed. I'll look at that more closely tomorrow. ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-18 23:32 Message: Logged In: YES user_id=649744 It's looking good; I'm running 'make test' at the moment and it's doing a whole bunch of tests rather than the paltry six it was coming up with before (because it wasn't finding the rest because they were in subdirectories, maybe?) ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-18 23:24 Message: Logged In: YES user_id=649744 Kernel version 2.2.18pre21 (as noted in initial report). I've attached the output from '/sbin/ldconfig -p'. I'll try the suggested tweak in a moment, though if 'large file system' means 'over 2Gb' as I think it may do, it should be a non-issue; none of the partitions on the box are over 2Gb. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-18 23:12 Message: Logged In: YES user_id=21627 Can you please report C library version and kernel version of your system? It may that large file system support is somehow broken; please try the following build procedure: - configure - edit pyconfig.h, remove the line HAVE_LARGEFILE_SUPPORT _LARGEFILE_SOURCE _FILE_OFFSET_BITS - make, make install Still, getting a meaningful debug session would be useful. ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-18 16:25 Message: Logged In: YES user_id=649744 Sorry, still no joy (same output as before; no break) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-18 16:08 Message: Logged In: YES user_id=33168 I think this is b/c posix is shared. This is the process you need to do (hopefully this is correct, it's from memory): gdb python run >>> import os >>> # press Ctrl-C to get back to gdb (gdb) br posix_listdir (gdb) continue >>> os.listdir("/usr/local/lib/python2.2") ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-18 15:36 Message: Logged In: YES user_id=649744 I should add that it does seem to set up the breakpoint correctly; it reports that it's setting up breakpoint 1 in ./Modules/posixmodule.c, line 1157 (on both machines) (Appreciate all your work on this, folks.) ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-18 15:35 Message: Logged In: YES user_id=649744 I have gdb installed but doing: gdb python break posix_listdir run import os os.listdir("/some/directory") doesn't actually cause a break; it does the same as last time (produces a list of empty pairs of quotes) and then ends normally when I quit out of it. It also doesn't break there in the working version. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-18 15:13 Message: Logged In: YES user_id=33168 Are you able to use a debugger and break in posix_listdir() to see what's going on? ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-18 14:42 Message: Logged In: YES user_id=649744 Erk. On the working install, it returns ['filename','filename',....,'filename'] (in other words, it looks wholly normal) On the not-working install, it returns ['','','',...,''] (if the exact number of empty pairs of quotes is critical, I can count them) I checked whether it would list other directories and no, it does the same thing on those also; produces a bunch of empty pairs of quotes (one per file, from the looks of it) ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-11-18 14:20 Message: Logged In: YES user_id=45365 If os.listdir("/usr/local/lib/python2.2") would return an empty string as the first item in it's output (it shouldn't, of course) I could imagine this happening. Could you do the following: % PYTHONPATH=/usr/local/lib/python2.2 ./python >>> import os >>> os.listdir("/usr/local/lib/python2.2") and show us the results? ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-18 13:51 Message: Logged In: YES user_id=649744 Nope, all components of /usr/local/lib appear to be normal, healthy directories; no symlinks in there at all. The actual built copies of python awaiting install are slightly different sizes on the two machines, which may or may not be significant (2177764 on working machine, 2177796 on not-working machine) ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-18 13:35 Message: Logged In: YES user_id=649744 Output of ./configure is identical on both machines. Output of make is slightly different (much of the difference is because one machine is 586 arch. and the other 686) Attached tgz file includes all three logs for each machine and a diff file for each set. Logs prefixed with 'sun-' are from the machine where the install works; logs prefixed with 'van-' are from the machine where the install fails. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-18 13:29 Message: Logged In: YES user_id=33168 Mel, is any path in /usr/local/lib/python2.2 a symlink, meaning: /usr, /usr/local, or /usr/local/lib ? ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-18 12:36 Message: Logged In: YES user_id=649744 OK, I've started reinstalling from scratch on both machines, and I'm logging the outputs from ./configure, make, make test, make install. _Something's_ got to be different... ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-18 12:28 Message: Logged In: YES user_id=649744 And still fails to work on the first machine. One thing I did notice was that on the second machine (the one on which the install works), there were a _lot_ more tests done with 'make test'. 240 or so, versus 6 on the not- working machine. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-18 12:25 Message: Logged In: YES user_id=21627 I'm not surprised it works; this behaviour is expected. Python recursively traverses all directories under /usr/local/lib/python2.2, and produces bytecode files for each .py file. For some reason, it concludes that /usr/local/lib/python2.2/ is a subdirectory of /usr/local/lib/python2.2 on your first machine, which is non-sense. ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-18 12:20 Message: Logged In: YES user_id=649744 ... which, bizarrely, works. The main difference seems to be that it gets as far as the line which reads: Listing /usr/local/lib/python2.2 ... and then it _doesn't_ go on to produce a(n infinite number of) lines saying: Listing /usr/local/lib/python2.2/ ... (with the extra / appended to the name of the directory listing). What's actually _supposed_ to happen with that line? It passes a directory listing back to the shell? (Listings work OK on the problem machine as far as I can tell.) OK, next step. Delete build directory, delete install directory, untar the tarball again and start over from scratch. ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-18 12:07 Message: Logged In: YES user_id=649744 I'm just trying to install from the same .tar.gz file I originally downloaded on a machine with a very similar setup (not, sadly, identical). Let's see if it does the same thing. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-18 12:04 Message: Logged In: YES user_id=21627 Ok, I give up. Unless somebody else has any idea, I will close this as unreproducable. ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-18 11:43 Message: Logged In: YES user_id=649744 fsck reports /usr('s filesystem) is clean. ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-17 22:38 Message: Logged In: YES user_id=649744 I can't do an fsck on that filesystem until I'm in front of the console tomorrow - no reason to suspect problems, though. I've attached a gzipped version of the output of 'strace make install'. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-17 21:00 Message: Logged In: YES user_id=21627 Ok, more tests: Can you please perform a file system check on that file system? Normally, I would also ask for strace output, but I suppose your strace won't decode getdents64. ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-17 19:16 Message: Logged In: YES user_id=649744 Zero output from that, I'm afraid. This is very weird. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-16 16:31 Message: Logged In: YES user_id=21627 I'm now convinced that there must be cyclic symbolic link somewhere. Please report the output of find /usr/local/lib/python2.2 -type l -print ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-16 15:59 Message: Logged In: YES user_id=649744 That's OK, me neither. ;) I've patched compileall.py and reran 'make install'. The log file doesn't tell me a whole lot more but I confess I'm no Python expert (I need to get it installed for a different app which requires it). Log file attached. Be warned, uncompressed it is about 6Mb. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-16 14:35 Message: Logged In: YES user_id=21627 I still have no clue what is going on here. Can you please apply the attached compileall.diff, rerun installation, and attach the resulting log file (or a significant portion thereof)? ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-16 10:36 Message: Logged In: YES user_id=649744 I downloaded it from http://www.python.org/ftp/python/2.2.2/Python-2.2.2.tgz (the most obvious link off www.python.org). Directory listing attached (I hope) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-11-16 09:52 Message: Logged In: YES user_id=21627 As a procedural comment: What is the source package that you use (precise URL please)? Can you please provide the output of ls -l /usr/local/lib/python2.2 ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-15 23:57 Message: Logged In: YES user_id=649744 Sure. (attached at end) Running the command from the shell does seem to do the same thing. There is no obvious symlink within /usr/local/lib/python2.2 (if a directory listing would be useful, let me know) Log excerpt: /usr/bin/install -c -m 644 ./Lib/distutils/command/install_scripts.py /usr/local/lib /python2.2/distutils/command /usr/bin/install -c -m 644 ./Lib/distutils/command/sdist.py /usr/local/lib/python2 .2/distutils/command /usr/bin/install -c -m 644 ./Lib/xml/__init__.py /usr/local/lib/python2.2/xml /usr/bin/install -c -m 644 ./Lib/xml/dom/__init__.py /usr/local/lib/python2.2/xml/ dom /usr/bin/install -c -m 644 ./Lib/xml/dom/domreg.py /usr/local/lib/python2.2/xml/ dom /usr/bin/install -c -m 644 ./Lib/xml/dom/minidom.py /usr/local/lib/python2.2/xml /dom /usr/bin/install -c -m 644 ./Lib/xml/dom/pulldom.py /usr/local/lib/python2.2/xml/ dom /usr/bin/install -c -m 644 ./Lib/xml/parsers/__init__.py /usr/local/lib/python2.2/x ml/parsers /usr/bin/install -c -m 644 ./Lib/xml/parsers/expat.py /usr/local/lib/python2.2/xm l/parsers /usr/bin/install -c -m 644 ./Lib/xml/sax/__init__.py /usr/local/lib/python2.2/xml/s ax /usr/bin/install -c -m 644 ./Lib/xml/sax/_exceptions.py /usr/local/lib/python2.2/x ml/sax /usr/bin/install -c -m 644 ./Lib/xml/sax/expatreader.py /usr/local/lib/python2.2/ xml/sax /usr/bin/install -c -m 644 ./Lib/xml/sax/handler.py /usr/local/lib/python2.2/xml/s ax /usr/bin/install -c -m 644 ./Lib/xml/sax/saxutils.py /usr/local/lib/python2.2/xml/s ax /usr/bin/install -c -m 644 ./Lib/xml/sax/xmlreader.py /usr/local/lib/python2.2/xm l/sax /usr/bin/install -c -m 644 ./Lib/curses/__init__.py /usr/local/lib/python2.2/curses /usr/bin/install -c -m 644 ./Lib/curses/ascii.py /usr/local/lib/python2.2/curses /usr/bin/install -c -m 644 ./Lib/curses/has_key.py /usr/local/lib/python2.2/curse s /usr/bin/install -c -m 644 ./Lib/curses/panel.py /usr/local/lib/python2.2/curses /usr/bin/install -c -m 644 ./Lib/curses/textpad.py /usr/local/lib/python2.2/curse s /usr/bin/install -c -m 644 ./Lib/curses/wrapper.py /usr/local/lib/python2.2/curse s /usr/bin/install -c -m 644 ./Lib/plat- linux2/CDROM.py /usr/local/lib/python2.2/plat-linux2 /usr/bin/install -c -m 644 ./Lib/plat- linux2/DLFCN.py /usr/local/lib/python2.2/plat-linux2 /usr/bin/install -c -m 644 ./Lib/plat- linux2/IN.py /usr/local/lib/python2.2/plat-linux2 /usr/bin/install -c -m 644 ./Lib/plat- linux2/TYPES.py /usr/local/lib/python2.2/plat-linux2 /usr/bin/install -c ./Lib/plat- linux2/regen /usr/local/lib/python2.2/plat-linux2 /usr/bin/install -c -m 644 ./LICENSE /usr/local/lib/python2.2/LICENSE.txt PYTHONPATH=/usr/local/lib/python2.2 \ ./python - tt /usr/local/lib/python2.2/compileall.py -x badsyntax \ /usr/local/lib/python2.2 Listing /usr/local/lib/python2.2 ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... Listing /usr/local/lib/python2.2/ ... (etc.) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-15 23:48 Message: Logged In: YES user_id=33168 Ok, could you paste a few listing lines and about 20 or so before that. Did you try running the command from the shell? Something like: PYTHONPATH=/usr/local/lib/python2.2 \ ./python -tt /usr/local/lib/python2.2/compileall.py \ -x badsyntax /usr/local/lib/python2.2 Does that do the same thing? Is it possible there is a symlink in /usr/local/lib/python2.2 to the same directory (or .)? ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-15 23:44 Message: Logged In: YES user_id=649744 I give in, it just doesn't want to let me attach the file. It has about 10000 repeats of that same 'Listing' line, in any case. ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-15 23:43 Message: Logged In: YES user_id=649744 Yeah, I tried that. In between the problems with file sizes, file names and the like, it doesn't seem to have worked. I'm giving it another go now. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-15 23:40 Message: Logged In: YES user_id=33168 There's no file. You have to click the checkbox next to "Check to Upload and Attach a File" in addition to entering the filename. ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-15 23:38 Message: Logged In: YES user_id=649744 Log file now attached, gzipped ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-15 23:38 Message: Logged In: YES user_id=649744 Log file now attached, gzipped ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-15 23:34 Message: Logged In: YES user_id=649744 Here's the log file. I let it run for about 10000 repeats and then killed it - there may be a lot of files, but _that_ many? ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-15 23:23 Message: Logged In: YES user_id=649744 It definitely isn't printing out anything else except the 'Listing...' line. I can let it run for a few minutes and see if it's printing that one-per-file or something, instead of just looping... hang on. ---------------------------------------------------------------------- Comment By: Mel (meldh) Date: 2002-11-15 23:22 Message: Logged In: YES user_id=649744 It definitely isn't printing out anything else except the 'Listing...' line. I can let it run for a few minutes and see if it's printing that one-per-file or something, instead of just looping... hang on. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-15 23:09 Message: Logged In: YES user_id=33168 Are you sure you let the process finish? It looks like there are at least 2 passes. One to generate .pyc files and the other to generate .pyo (optimized) files. There are a lot of files to run through. Does it only print the "Listing /usr/local/lib/python2.2 ... " lines and nothing in between? Could you save the output and attach it to this bug report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639022&group_id=5470 From noreply@sourceforge.net Fri Jan 10 08:13:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 10 Jan 2003 00:13:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-664044 ] Lib Man 2.2.6.2 word change Message-ID: Bugs item #664044, was opened at 2003-01-07 17:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=664044&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Terry J. Reedy (tjreedy) >Assigned to: Raymond Hettinger (rhettinger) Summary: Lib Man 2.2.6.2 word change Initial Comment: In the conversion types table, the 's' line s String (converts any python object using str()). should have 'non-unicode' substituted for or inserted before 'python' to be consistent with both the last sentence of the first paragraph and current (2.2.1) behavior. This non-updated line has fooled at least one person (clp poster). ---------------------------------------------------------------------- Comment By: Christopher Blunck (blunck2) Date: 2003-01-08 00:16 Message: Logged In: YES user_id=531881 see patch 664183 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=664044&group_id=5470 From noreply@sourceforge.net Fri Jan 10 09:34:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 10 Jan 2003 01:34:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-665570 ] curses causes interpreter crash Message-ID: Bugs item #665570, was opened at 2003-01-10 09:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665570&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: curses causes interpreter crash Initial Comment: [submitted to http://bugs.debian.org/175589 ] A call to curses.initscr() that fails because of an error (such as TERM not being set) causes the program to exit. No exception thrown, no error returned -- an EXIT. There is very anti-Pythonic and, at minimum, should be documented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665570&group_id=5470 From noreply@sourceforge.net Fri Jan 10 09:35:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 10 Jan 2003 01:35:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-652888 ] bad documentation for the "type" builtin Message-ID: Bugs item #652888, was opened at 2002-12-12 15:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=652888&group_id=5470 Category: Documentation Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michele Simionato (michele_s) Assigned to: Nobody/Anonymous (nobody) >Summary: bad documentation for the "type" builtin Initial Comment: After a discussion on comp.lang.python http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&threadm=7h38yyvgto8.fsf%40pc150.maths.bris.ac.uk&prev=/groups%3Fdq%3D%26num%3D25%26hl%3Den%26lr%3D%26ie%3DUTF-8%26group%3Dcomp.lang.python%26start%3D0 I was suggested to submit a bug report about the documentation of the built-in "type". The official 2.2.2 documentation says: type(object) Return the type of an object. The return value is a type object. The standard module types defines names for all built-in types. For instance: >>> import types >>> if type(x) == types.StringType: print "It's a string" This is misleading since the module types does not contains all possible types, for instance does not contain StaticMethodType (which I was looking for). Moreover, people pointed out much better idioms, like >>> if type(x) is str: print "It's a string" or even (without using type) >>> if isinstance(x, str): print "It's not a moose!" Moreover, I would be happy to see in the documentation of the types module a sentence about the alternative ways of retrieving the type of an object. -- Michele Simionato - Dept. of Physics and Astronomy 210 Allen Hall Pittsburgh PA 15260 U.S.A. Phone: 001-412-624-9041 Fax: 001-412-624-9163 Home-page: http://www.phyast.pitt.edu/~micheles/ ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 04:35 Message: Logged In: YES user_id=80475 Fixed. See Doc/lib/libtypes.tex 1.55 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=652888&group_id=5470 From noreply@sourceforge.net Fri Jan 10 09:36:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 10 Jan 2003 01:36:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-665572 ] missing important curses calls Message-ID: Bugs item #665572, was opened at 2003-01-10 09:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665572&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: missing important curses calls Initial Comment: [ submitted to http://bugs.debian.org/175590 ] The curses library is missing two important calls: newterm() -- required to work with multiple terminals, or to find out if it is possible to work with this terminal delscreen() -- required to free up the memory after endwin() -- current implementations have memory leaks for programs that need to start and stop (those that handle terminal resizes, for instance) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665572&group_id=5470 From noreply@sourceforge.net Fri Jan 10 09:42:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 10 Jan 2003 01:42:56 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-662827 ] optional pad character for zfill and center Message-ID: Feature Requests item #662827, was opened at 2003-01-05 16:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=662827&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: optional pad character for zfill and center Initial Comment: >>> 'padme'.zfill(10, '*') '*****padme' >>> 'padme'.center(10, '*') '**padme***' ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 04:42 Message: Logged In: YES user_id=80475 The optional character for center seems like a useful idea to me. People occasionally like to center captions in fields of hyphens or asterisks. Note, this proposal is similar to the recent "optional character" enhancements to str.strip (), str.lstrip(), and str.rstrip(). Doing the same for zfill() is more problematic because both its name and function do not equate to "padleft". The 'z' in zfill implies that a zero will be used. The actual function not only fills to the left, but also repositions any leading minus signs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=662827&group_id=5470 From noreply@sourceforge.net Fri Jan 10 09:47:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 10 Jan 2003 01:47:34 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-662923 ] iterator for dbm keys Message-ID: Feature Requests item #662923, was opened at 2003-01-05 21:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=662923&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: iterator for dbm keys Initial Comment: if d is a dbm (gdbm, bsddb, shelve, etc.) object, then "for k in d" should iterate through the keys of d, like you can do with dicts. Alternatively, add a new operation, d.xkeys(), which returns an iterator that steps through all the keys in d. d.keys() is often inappropriate since dbm databases can be extremely large and d.keys() tries to read all the keys into memory at once. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 04:47 Message: Logged In: YES user_id=80475 * for Py2.3, all shelve now inherits from UserDict.DictMixin which adds in the missing methods for a dictionary style interface. * the appropriate name for d.xkeys() is d.iterkeys(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=662923&group_id=5470 From noreply@sourceforge.net Fri Jan 10 10:38:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 10 Jan 2003 02:38:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-665616 ] Segfault while loading C module Message-ID: Bugs item #665616, was opened at 2003-01-10 11:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665616&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jean-Baptiste Combes (jbcombes) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault while loading C module Initial Comment: Note : This has only occured with gcc-2.95.3 / binutils 2.11.2 on Solaris 2.6. It just works fine on Solaris 2.8 with GCC 3.2. Problem described for the module struct. Python segfaults after calling Py_InitModule4 from initstruct in structmodule.c More precisely, the segfault occurs when it tries to get the length of the name of the first method in struct_methods[] Here the last part of the backtrace under gdb: (gdb) run setup.py build_ext Starting program: /tmp/python/Python-2.2.2/python setup.py build_ext running build_ext skipping 'struct' extension (up-to-date) Program received signal SIGSEGV, Segmentation fault. 0xef5a46fc in strlen () (gdb) bt #0 0xef5a46fc in strlen () #1 0x20874 in PyString_FromString (str=0xd24c58 "") at :111 #2 0xad440 in PyDict_SetItemString (v=0x177048, key=0xd24c58 "", item=0x10ebe8) at :1879 #3 0x683ac in Py_InitModule4 (name=0x2ad960 "", methods=0xeed35754, doc=0xeed34ce0 "Functions to convert between Python values and C structs.\nPython strings are used to hold the data representing the C struct\nand also as format strings to describe the layout of data in the C struct.\n"..., passthrough=0x0, module_api_version=1536072) at :63 #4 0xeed247d8 in Py_NoSiteFlag () #5 0x64ed8 in _PyImport_LoadDynamicModule (name=0xefffe1f8 "struct", pathname=0xefffdd08 "/tmp/python/Python-2.2.2/build/lib.solaris-2.6-sun4m-2.2/struct.so", fp=0xeed24798) at :53 #6 0x628d8 in load_module (name=0xefffe1f8 "struct", fp=0xf06e8, buf=0xefffdd08 "/tmp/python/Python-2.2.2/build/lib.solaris-2.6-sun4m-2.2/struct.so", type=3) at :1380 #7 0x6385c in import_submodule (mod=0xd5848, subname=0xefffe1f8 "struct", fullname=0xefffe1f8 "struct") at :1910 #8 0x6335c in load_next (mod=0xd5848, altmod=0xd5848, p_name=0xefffe1f8, buf=0xefffe1f8 "struct", p_buflen=0xefffe1f4) at :1766 #9 0x62e20 in import_module_ex (name=0x0, globals=0x0, locals=0x0, fromlist=0x0) at :1617 One more note : #4 in the backtrace is obviously false, it really calls initstruct... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665616&group_id=5470 From noreply@sourceforge.net Fri Jan 10 14:41:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 10 Jan 2003 06:41:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-665761 ] reduce() masks exception Message-ID: Bugs item #665761, was opened at 2003-01-10 15:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665761&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 3 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: reduce() masks exception Initial Comment: In the following test script ----- class Test: def __iter__(self): raise IOError reduce(lambda x,y: x+y, Test()) ----- the real IOError exception is masked, i.e. the traceback is ----- Traceback (most recent call last): File "test.py", line 5, in ? reduce(lambda x,y: x+y, Test()) TypeError: reduce() arg 2 must support iteration ----- but IMHO should be ----- Traceback (most recent call last): File "test.py", line 3, in ? raise IOError IOError ----- This can be fixed by removing the PyErr_SetString(PyExc_TypeError, "reduce() arg 2 must support iteration") call in bltinmodule.c/buildtin_reduce(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665761&group_id=5470 From noreply@sourceforge.net Fri Jan 10 16:36:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 10 Jan 2003 08:36:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-665835 ] filter() treatment of str and tuple inconsistent Message-ID: Bugs item #665835, was opened at 2003-01-10 17:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665835&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: filter() treatment of str and tuple inconsistent Initial Comment: class tuple2(tuple): · def __getitem__(self, index): · · return 2*tuple.__getitem__(self, index) class str2(str): · def __getitem__(self, index): · · return chr(ord(str.__getitem__(self, index))+1) print filter(lambda x: x>1, tuple2((1, 2))) print filter(lambda x: x>"a", str2("ab")) this prints: (2,) bc i.e. the overwritten __getitem__ is ignored in the first case, but honored in the second. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665835&group_id=5470 From noreply@sourceforge.net Fri Jan 10 17:35:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 10 Jan 2003 09:35:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-665616 ] Segfault while loading C module Message-ID: Bugs item #665616, was opened at 2003-01-10 11:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665616&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jean-Baptiste Combes (jbcombes) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault while loading C module Initial Comment: Note : This has only occured with gcc-2.95.3 / binutils 2.11.2 on Solaris 2.6. It just works fine on Solaris 2.8 with GCC 3.2. Problem described for the module struct. Python segfaults after calling Py_InitModule4 from initstruct in structmodule.c More precisely, the segfault occurs when it tries to get the length of the name of the first method in struct_methods[] Here the last part of the backtrace under gdb: (gdb) run setup.py build_ext Starting program: /tmp/python/Python-2.2.2/python setup.py build_ext running build_ext skipping 'struct' extension (up-to-date) Program received signal SIGSEGV, Segmentation fault. 0xef5a46fc in strlen () (gdb) bt #0 0xef5a46fc in strlen () #1 0x20874 in PyString_FromString (str=0xd24c58 "") at :111 #2 0xad440 in PyDict_SetItemString (v=0x177048, key=0xd24c58 "", item=0x10ebe8) at :1879 #3 0x683ac in Py_InitModule4 (name=0x2ad960 "", methods=0xeed35754, doc=0xeed34ce0 "Functions to convert between Python values and C structs.\nPython strings are used to hold the data representing the C struct\nand also as format strings to describe the layout of data in the C struct.\n"..., passthrough=0x0, module_api_version=1536072) at :63 #4 0xeed247d8 in Py_NoSiteFlag () #5 0x64ed8 in _PyImport_LoadDynamicModule (name=0xefffe1f8 "struct", pathname=0xefffdd08 "/tmp/python/Python-2.2.2/build/lib.solaris-2.6-sun4m-2.2/struct.so", fp=0xeed24798) at :53 #6 0x628d8 in load_module (name=0xefffe1f8 "struct", fp=0xf06e8, buf=0xefffdd08 "/tmp/python/Python-2.2.2/build/lib.solaris-2.6-sun4m-2.2/struct.so", type=3) at :1380 #7 0x6385c in import_submodule (mod=0xd5848, subname=0xefffe1f8 "struct", fullname=0xefffe1f8 "struct") at :1910 #8 0x6335c in load_next (mod=0xd5848, altmod=0xd5848, p_name=0xefffe1f8, buf=0xefffe1f8 "struct", p_buflen=0xefffe1f4) at :1766 #9 0x62e20 in import_module_ex (name=0x0, globals=0x0, locals=0x0, fromlist=0x0) at :1617 One more note : #4 in the backtrace is obviously false, it really calls initstruct... ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-10 18:35 Message: Logged In: YES user_id=21627 Even though this has been reported before, nobody was ever able to analyse the problem in so much detail as to find the cause. It is believed to be a compiler bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665616&group_id=5470 From noreply@sourceforge.net Fri Jan 10 17:55:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 10 Jan 2003 09:55:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-665616 ] Segfault while loading C module Message-ID: Bugs item #665616, was opened at 2003-01-10 11:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665616&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jean-Baptiste Combes (jbcombes) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault while loading C module Initial Comment: Note : This has only occured with gcc-2.95.3 / binutils 2.11.2 on Solaris 2.6. It just works fine on Solaris 2.8 with GCC 3.2. Problem described for the module struct. Python segfaults after calling Py_InitModule4 from initstruct in structmodule.c More precisely, the segfault occurs when it tries to get the length of the name of the first method in struct_methods[] Here the last part of the backtrace under gdb: (gdb) run setup.py build_ext Starting program: /tmp/python/Python-2.2.2/python setup.py build_ext running build_ext skipping 'struct' extension (up-to-date) Program received signal SIGSEGV, Segmentation fault. 0xef5a46fc in strlen () (gdb) bt #0 0xef5a46fc in strlen () #1 0x20874 in PyString_FromString (str=0xd24c58 "") at :111 #2 0xad440 in PyDict_SetItemString (v=0x177048, key=0xd24c58 "", item=0x10ebe8) at :1879 #3 0x683ac in Py_InitModule4 (name=0x2ad960 "", methods=0xeed35754, doc=0xeed34ce0 "Functions to convert between Python values and C structs.\nPython strings are used to hold the data representing the C struct\nand also as format strings to describe the layout of data in the C struct.\n"..., passthrough=0x0, module_api_version=1536072) at :63 #4 0xeed247d8 in Py_NoSiteFlag () #5 0x64ed8 in _PyImport_LoadDynamicModule (name=0xefffe1f8 "struct", pathname=0xefffdd08 "/tmp/python/Python-2.2.2/build/lib.solaris-2.6-sun4m-2.2/struct.so", fp=0xeed24798) at :53 #6 0x628d8 in load_module (name=0xefffe1f8 "struct", fp=0xf06e8, buf=0xefffdd08 "/tmp/python/Python-2.2.2/build/lib.solaris-2.6-sun4m-2.2/struct.so", type=3) at :1380 #7 0x6385c in import_submodule (mod=0xd5848, subname=0xefffe1f8 "struct", fullname=0xefffe1f8 "struct") at :1910 #8 0x6335c in load_next (mod=0xd5848, altmod=0xd5848, p_name=0xefffe1f8, buf=0xefffe1f8 "struct", p_buflen=0xefffe1f4) at :1766 #9 0x62e20 in import_module_ex (name=0x0, globals=0x0, locals=0x0, fromlist=0x0) at :1617 One more note : #4 in the backtrace is obviously false, it really calls initstruct... ---------------------------------------------------------------------- >Comment By: Jean-Baptiste Combes (jbcombes) Date: 2003-01-10 18:55 Message: Logged In: YES user_id=116408 Last try this afternoon; after upgrading to GCC 3.2: python builds and works OK. I vote for the compiler bug. Maybe adding something about this in the readme would be nice. As sidenote zlib segfaults, but I have no time to dig into it, sorry. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-10 18:35 Message: Logged In: YES user_id=21627 Even though this has been reported before, nobody was ever able to analyse the problem in so much detail as to find the cause. It is believed to be a compiler bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665616&group_id=5470 From noreply@sourceforge.net Fri Jan 10 18:15:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 10 Jan 2003 10:15:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-662787 ] test_signal hang on some Solaris boxes Message-ID: Bugs item #662787, was opened at 2003-01-05 19:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Anthony Baxter (anthonybaxter) Summary: test_signal hang on some Solaris boxes Initial Comment: Martin, I'm assigning this to you because you checked in the patch which caused this problem. I think your input on fixes will also be valuable. When semaphore support was added to Python/thread_pthread.h in 2.39 originally from patch 525532, it broke tests on some Solaris boxes. I know this affects Solaris 8, not sure if any other versions are affected. I believe on or more of the following Solaris 8 patches (108528, 108827) fixes the problem: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108528&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108827&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on Patches can be gotten from here: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access One way to fix the hang is to add #undef USE_SEMAPHORES at line 113 of Python/thread_pthread.h (ie, after USE_SEMAPHORES may be set). I don't know of any other way to fix this problem. I don't know if we can test for this in configure and set USE_SEMAPHORES appropriately (or if it's worth it). We can always disable USE_SEMAPHORES and allow the user to use it by manually setting the macro. We keep the code as is, and document the problem. Suggestions? ---------------------------------------------------------------------- Comment By: Inyeol Lee (inyeol) Date: 2003-01-10 18:15 Message: Logged In: YES user_id=595280 I patched my Solaris8 box and rebuilt 2.3a1 again. 'make test' still fails at test_signal. Martin's test code also fails. Installed patches are; Patch: 108528-07 Patch: 108528-13 Patch: 108528-18 Patch: 108827-07 Patch: 108827-15 Patch: 108827-35 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-08 17:21 Message: Logged In: YES user_id=33168 Sorry, that's really what I meant, only for Solaris 8. I'm not sure how to do that (figure out that we are on Solaris 8). I agree it would be nice to know the answer and suspect you are right that it's fixed. I don't know how to do that though. Hmmm, I think Anthony Baxter may have had Solaris. I'll assign this to him, in the hopes he can provide some more info. Anythony? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-08 17:15 Message: Logged In: YES user_id=21627 I quite object #2, although I could live with 5) disable USE_SEMAPHORES for Solaris 8 I would still like to find out whether applying all patches solves the problem. I'm quite certain that our code is correct and that there is a bug in Solaris. I'm reasonably certain that the bug has been fixed by now, so I would not want to leave USE_SEMAPHORES disabled forever on Solaris. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-08 17:11 Message: Logged In: YES user_id=33168 Martin, how do you think we should proceed with this problem? Some alternatives include: 1) try to build an autoconf test to find the problem and disable USE_SEMAPHORES 2) always disable USE_SEMAPHORES for Solaris 3) try to find a work-around 4) leave it as-is At least temporarily, I'd like to see #2. The problem is that if we do that, it will probably never get fixed. #1 is probably a lot of work. I can't implement #1 since I don't have access to a machine that works. Do you have any other ideas or possible solutions/work-arounds? ---------------------------------------------------------------------- Comment By: Inyeol Lee (inyeol) Date: 2003-01-07 03:46 Message: Logged In: YES user_id=595280 Neal, This is the patch version of my Solaris8 system you've requested; Patch: 108528-07 Patch: 108528-13 Patch: 108827-07 Patch: 108827-15 Inyeol Lee ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 14:46 Message: Logged In: YES user_id=21627 showrev -p is good, as is patchadd -p (this also shows the patches you could backup to). I notice that my Solaris 9 machine does not experience the problem, so Sun has fixed something. It would be good if a Solaris 8 machine could be brought up-to-date with regard to patches (they recommend -18 and -35 respectively, at the moment). On that machine, either those two patches selectively, or an entire patch cluster (8_Recommended.zip) should be installed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-06 13:44 Message: Logged In: YES user_id=33168 I thought I could not duplicate the hang on our sun, but now it's happening. Your test program also hangs. How do you determine the revision of a patch on solaris? I'm using showrev -p | grep patch-#. I'm not sure that is correct. The way I read it, it says I have 108528-16 and 108827-12. In the snake farm proton has: 108528-12 and 108827-12 fafner has: 108528-13 and 108827-19 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 12:29 Message: Logged In: YES user_id=21627 It would be good to find a system that has 108528-17 installed. I see that this fixes 4498831 system timer stops sending signals ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 12:13 Message: Logged In: YES user_id=21627 I meant revisions of the Sun patches. On one system, I have 108528-16 and 108827-34, and test_signal still hangs. I found that the blocking occurs when test_queue.py is run before, and have distilled this into the following example: import sys import thread import time import signal fsema = thread.allocate_lock() def tfunc(): time.sleep(.1) fsema.release() fsema.acquire() thread.start_new_thread(tfunc,()) fsema.acquire() fsema.release() signal.alarm(3) signal.pause() It appears that the alarm is simply lost; the pause call does not return. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 23:38 Message: Logged In: YES user_id=33168 What do you mean by revision of the patches? CVS revision of thread_pthread.h? I believe 2.38 worked and 2.39 broke. I can test that if you'd like. Do you want me to go back to the revision before the patch for all files affected? Since 2.39 only added the semaphores, in essence, by doing the #undef that should have the same effect as reverting thread_pthread.h to 2.38. Or are you talking about the Solaris patches? If so, they are only a guess, we could compare the patch level on all the Solaris boxes we have access to and see which ones work and which don't. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-05 23:11 Message: Logged In: YES user_id=21627 Could you identify a revision of these patches for which the problem disappears? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 20:57 Message: Logged In: YES user_id=33168 For (possibly) more info, see: http://lists.lysator.liu.se/pipermail/snake-farm/2003-January/000617.html ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 20:38 Message: Logged In: YES user_id=33168 Attaching output of truss (like strace for Solaris) which doesn't provide me with any more info. Hopefully this will help someone else. 2 files attached, one with complete output from; truss ./python -E -tt ./Lib/test/regrtest.py test_queue test_signal the other is just the end. It should correspond to these lines from the test: signal.alarm(20) # Entire test lasts at most 20 sec. signal.signal(5, handlerA) signal.signal(2, handlerB) signal.signal(3, signal.SIG_IGN) signal.signal(signal.SIGALRM, signal.default_int_handler) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 From noreply@sourceforge.net Fri Jan 10 18:52:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 10 Jan 2003 10:52:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-665616 ] Segfault while loading C module Message-ID: Bugs item #665616, was opened at 2003-01-10 11:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665616&group_id=5470 Category: Extension Modules >Group: 3rd Party >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Jean-Baptiste Combes (jbcombes) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault while loading C module Initial Comment: Note : This has only occured with gcc-2.95.3 / binutils 2.11.2 on Solaris 2.6. It just works fine on Solaris 2.8 with GCC 3.2. Problem described for the module struct. Python segfaults after calling Py_InitModule4 from initstruct in structmodule.c More precisely, the segfault occurs when it tries to get the length of the name of the first method in struct_methods[] Here the last part of the backtrace under gdb: (gdb) run setup.py build_ext Starting program: /tmp/python/Python-2.2.2/python setup.py build_ext running build_ext skipping 'struct' extension (up-to-date) Program received signal SIGSEGV, Segmentation fault. 0xef5a46fc in strlen () (gdb) bt #0 0xef5a46fc in strlen () #1 0x20874 in PyString_FromString (str=0xd24c58 "") at :111 #2 0xad440 in PyDict_SetItemString (v=0x177048, key=0xd24c58 "", item=0x10ebe8) at :1879 #3 0x683ac in Py_InitModule4 (name=0x2ad960 "", methods=0xeed35754, doc=0xeed34ce0 "Functions to convert between Python values and C structs.\nPython strings are used to hold the data representing the C struct\nand also as format strings to describe the layout of data in the C struct.\n"..., passthrough=0x0, module_api_version=1536072) at :63 #4 0xeed247d8 in Py_NoSiteFlag () #5 0x64ed8 in _PyImport_LoadDynamicModule (name=0xefffe1f8 "struct", pathname=0xefffdd08 "/tmp/python/Python-2.2.2/build/lib.solaris-2.6-sun4m-2.2/struct.so", fp=0xeed24798) at :53 #6 0x628d8 in load_module (name=0xefffe1f8 "struct", fp=0xf06e8, buf=0xefffdd08 "/tmp/python/Python-2.2.2/build/lib.solaris-2.6-sun4m-2.2/struct.so", type=3) at :1380 #7 0x6385c in import_submodule (mod=0xd5848, subname=0xefffe1f8 "struct", fullname=0xefffe1f8 "struct") at :1910 #8 0x6335c in load_next (mod=0xd5848, altmod=0xd5848, p_name=0xefffe1f8, buf=0xefffe1f8 "struct", p_buflen=0xefffe1f4) at :1766 #9 0x62e20 in import_module_ex (name=0x0, globals=0x0, locals=0x0, fromlist=0x0) at :1617 One more note : #4 in the backtrace is obviously false, it really calls initstruct... ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-10 19:52 Message: Logged In: YES user_id=21627 It's unclear under what circumstances the problem occurs - gcc 2.95.3 itself alone is no problem, that makes giving advise in the readme difficult. So I'm closing this as 3rdparty. ---------------------------------------------------------------------- Comment By: Jean-Baptiste Combes (jbcombes) Date: 2003-01-10 18:55 Message: Logged In: YES user_id=116408 Last try this afternoon; after upgrading to GCC 3.2: python builds and works OK. I vote for the compiler bug. Maybe adding something about this in the readme would be nice. As sidenote zlib segfaults, but I have no time to dig into it, sorry. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-10 18:35 Message: Logged In: YES user_id=21627 Even though this has been reported before, nobody was ever able to analyse the problem in so much detail as to find the cause. It is believed to be a compiler bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665616&group_id=5470 From noreply@sourceforge.net Fri Jan 10 21:31:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 10 Jan 2003 13:31:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-660697 ] ossaudiodev issues Message-ID: Bugs item #660697, was opened at 2003-01-01 10:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660697&group_id=5470 Category: Extension Modules Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Greg Ward (gward) Summary: ossaudiodev issues Initial Comment: Greg, I noticed several things about ossaudiodev. It doesn't seem to be mentioned in Misc/NEWS. Likewise, the deprecation of linuxaudiodev. linuxaudiodev is still in setup.py, but ossaudiodev isn't mentioned in setup.py or Modules/Setup. I added it to setup.py and tried to build, but got 2 compilation errors: SNDCTL_DSP_GETSPDIF and SNDCTL_DSP_SETSPDIF are not defined (Redhat 7.2, Linux 2.4.7-10). After commenting out lines 1019 and 1031 (those with the two constants) and it compiled. The test failed: *** lines 2-7 of actual output doesn't appear in expected output after line 1: + expected rate >= 0, not -1 + expected sample size >= 0, not -2 + nchannels must be 1 or 2, not 3 + unknown audio encoding: 177 + for linear unsigned 16-bit little-endian audio, expected sample size 16, not 8 + for linear unsigned 8-bit audio, expected sample size 8, not 16 I'm not sure the status of ossaudiodev or if you know about these problems. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-10 16:31 Message: Logged In: YES user_id=33168 This has been fixed by various checkins, including my last one -- ossaudiodev.c 1.21 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660697&group_id=5470 From noreply@sourceforge.net Fri Jan 10 23:26:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 10 Jan 2003 15:26:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-602259 ] 3rd parameter for Tkinter.scan_dragto Message-ID: Bugs item #602259, was opened at 2002-08-30 03:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602259&group_id=5470 Category: Tkinter Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Neal Norwitz (nnorwitz) Summary: 3rd parameter for Tkinter.scan_dragto Initial Comment: In Tk8.3 (possibly earlier), one can add a third optional parameter, called "gain", which determines the multiplier used when performing the panning operation. The Tkinter call does not allow this parameter to be passed in the resultant Tk's default gain of 10 is often unusable. Work around is to just do this call manually: self.canv.tk.call(self.canv._w, 'scan', 'dragto', event.x, event.y, 1) uses a gain of `1'. [from http://bugs.debian.org/158168] ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-10 18:26 Message: Logged In: YES user_id=33168 Checked in as: Lib/lib-tk/Tkinter.py 1.168 Misc/NEWS 1.611 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602259&group_id=5470 From noreply@sourceforge.net Fri Jan 10 23:36:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 10 Jan 2003 15:36:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-639945 ] 64-bit bug on AIX Message-ID: Bugs item #639945, was opened at 2002-11-18 03:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639945&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Florent Cayré (florent_cayre) Assigned to: Neal Norwitz (nnorwitz) Summary: 64-bit bug on AIX Initial Comment: A bug in dynload_aix.c causes unpredictable segmentation faults on 64-bit AIX when importing a module. This bug is due to an (unsigned int) improper cast in the aix_getoldmodules function, returning a bad address as the beginning of the next ld_info structure pointed to by ldiptr. Following is a minimalist patch proposal obtained by changing these (unsigned int) casts into (char*) casts in the Python 2.2.1 version. Regards, Florent Cayré. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-10 18:36 Message: Logged In: YES user_id=33168 Checked in as: Python/dynload_aix.c 2.11.6.1 Misc/NEWS 1.337.2.4.2.53 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-30 19:08 Message: Logged In: YES user_id=33168 Checked in as Python/dynload_aix.c 2.13. 2.3a1 should be out in about a day. Florent, it would be great if you can test it on both 32- and 64- bit AIX. Leaving open to remind to backport to 2.2.3 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-22 09:48 Message: Logged In: YES user_id=33168 Florent, thank you. Your patch seems correct, but unfortunately I can't test it at this time. Once I can test it, I will check in the changes. If someone else can verify this patch works for them on both 32 & 64 bit compiles, I will check it in. ---------------------------------------------------------------------- Comment By: Florent Cayré (florent_cayre) Date: 2002-11-20 01:59 Message: Logged In: YES user_id=648804 Not sure I understand your question... However I filled in the Group drop down list and join my entire dynload_aix.c file with the proposed correction in it. Regards, Florent Cayré. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-19 14:04 Message: Logged In: YES user_id=33168 Florent, could you please point out the exact code and change necessary? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639945&group_id=5470 From noreply@sourceforge.net Fri Jan 10 23:50:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 10 Jan 2003 15:50:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-659228 ] 'realpath' function missing from os.path Message-ID: Bugs item #659228, was opened at 2002-12-27 20:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659228&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: David MacQuigg (macquigg) Assigned to: Neal Norwitz (nnorwitz) Summary: 'realpath' function missing from os.path Initial Comment: The 'realpath()' function does not appear when you import all functions: from os.path import * Looks like this due to the name 'realpath' being missing from the '__all__' list in .../Python-2.2.2/Lib/posixpath.py All the other functions appear normally. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-10 18:50 Message: Logged In: YES user_id=33168 2.2.3 backport checked in as: macpath.py 1.31.10.1 ntpath.py 1.44.8.2 dospath.py 1.25.10.1 posixpath.py 1.46.10.2 ---------------------------------------------------------------------- Comment By: David MacQuigg (macquigg) Date: 2003-01-03 13:25 Message: Logged In: YES user_id=676422 Seems like a safe backport to me. I can't imagine any code depending on 'realpath' being *missing* from the list functions. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-03 13:06 Message: Logged In: YES user_id=33168 Checked in as: macpath.py 1.43 ntpath.py 1.54 os2emxpath.py 1.9 posixpath.py 1.57 I have a question about if this should be backported, so I'm leaving this open for now. I think it should be backported. It is an API change, but only to correct the bug. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=659228&group_id=5470 From noreply@sourceforge.net Sat Jan 11 05:10:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 10 Jan 2003 21:10:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-665194 ] datetime-RFC2822 roundtripping Message-ID: Bugs item #665194, was opened at 2003-01-09 13:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665194&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: datetime-RFC2822 roundtripping Initial Comment: It would be good to have a simply way to convert between datetime objects and RFC2822 style strings. >From string to datetime is easy with datetime.datetime(*email.Utils.parsedate(m)[:7]) (but this drops the timezone), but the other direction seems impossible. email.Utils.formatdate takes a timestamp argument, but AFAICT there's no way to get a timestamp out of a datetime object. Of course the best solution (ignoring backwards compatibility) would be for parsedate und formatdate to return/accept datetime objects or for datetime to have the appropriate methods. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-11 00:10 Message: Logged In: YES user_id=31435 You can get a timestamp like so: >>> time.mktime(datetime.date(2002, 1, 1).timetuple()) 1009861200.0 >>> The dates for which this works depends on the platform mktime implementation, though. BTW, this sounds a lot more like a new feature request than a bug! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665194&group_id=5470 From noreply@sourceforge.net Sat Jan 11 12:33:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 11 Jan 2003 04:33:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-665194 ] datetime-RFC2822 roundtripping Message-ID: Bugs item #665194, was opened at 2003-01-09 19:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665194&group_id=5470 Category: None >Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: datetime-RFC2822 roundtripping Initial Comment: It would be good to have a simply way to convert between datetime objects and RFC2822 style strings. >From string to datetime is easy with datetime.datetime(*email.Utils.parsedate(m)[:7]) (but this drops the timezone), but the other direction seems impossible. email.Utils.formatdate takes a timestamp argument, but AFAICT there's no way to get a timestamp out of a datetime object. Of course the best solution (ignoring backwards compatibility) would be for parsedate und formatdate to return/accept datetime objects or for datetime to have the appropriate methods. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-01-11 13:33 Message: Logged In: YES user_id=89016 OK, I'll mark this a feature request. datetime has fromordinal() and toordinal(), it has fromtimestamp(), so I'd say a totimestamp() method would be a logical addition. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-11 06:10 Message: Logged In: YES user_id=31435 You can get a timestamp like so: >>> time.mktime(datetime.date(2002, 1, 1).timetuple()) 1009861200.0 >>> The dates for which this works depends on the platform mktime implementation, though. BTW, this sounds a lot more like a new feature request than a bug! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665194&group_id=5470 From noreply@sourceforge.net Sat Jan 11 14:23:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 11 Jan 2003 06:23:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-666219 ] AssertionErrors in httplib Message-ID: Bugs item #666219, was opened at 2003-01-11 08:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666219&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Jeremy Hylton (jhylton) Summary: AssertionErrors in httplib Initial Comment: I've recently noticed AssertionErrors being raised by httplib.LineAndFileWrapper.read(). It happens reliably when the server exits unexpectedly. Here's an example of an AssertionError in an xmlrpclib client when I kill the server it's talking to: Traceback (most recent call last): File "qa.py", line 22, in ? x = s.query(tmpl, st, en, radius, age) File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 985, in __call__ return self.__send(self.__name, args) File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1269, in __request verbose=self.__verbose File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1036, in request return self._parse_response(h.getfile(), sock) File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1165, in _parse_response response = file.read(1024) File "/Users/skip/local/lib/python2.3/httplib.py", line 1150, in read assert not self._line_consumed and self._line_left AssertionError I don't see a problem with raising an exception in this situation. I just wonder if AssertionError is the best exception to raise (unless of course, the cause is a logic error in the httplib code). If an exception is being raised because the server went away, I think it would be better to raise IncompleteRead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666219&group_id=5470 From noreply@sourceforge.net Sat Jan 11 16:32:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 11 Jan 2003 08:32:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-665194 ] datetime-RFC2822 roundtripping Message-ID: Bugs item #665194, was opened at 2003-01-09 13:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665194&group_id=5470 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: datetime-RFC2822 roundtripping Initial Comment: It would be good to have a simply way to convert between datetime objects and RFC2822 style strings. >From string to datetime is easy with datetime.datetime(*email.Utils.parsedate(m)[:7]) (but this drops the timezone), but the other direction seems impossible. email.Utils.formatdate takes a timestamp argument, but AFAICT there's no way to get a timestamp out of a datetime object. Of course the best solution (ignoring backwards compatibility) would be for parsedate und formatdate to return/accept datetime objects or for datetime to have the appropriate methods. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-11 11:32 Message: Logged In: YES user_id=31435 Define what totimestamp() should do. The range of timestamps supported by the *platform* C library (and so indirectly by Python's time module) isn't defined by any standard, and isn't easily discoverable either. It may or may not work before 1970, may or may not after 2038. datetime covers days far outside that range. Note that even a double doesn't have enough bits of precision to cover the full range of datetime values, either. In contrast, ordinals are wholly under Python's control, so we can promise surprise-free conversion in both directions. All we can promise about timestamps is that if the platform supports a timestamp for a time in datetime's range, datetime can make sense of it. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-11 07:33 Message: Logged In: YES user_id=89016 OK, I'll mark this a feature request. datetime has fromordinal() and toordinal(), it has fromtimestamp(), so I'd say a totimestamp() method would be a logical addition. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-11 00:10 Message: Logged In: YES user_id=31435 You can get a timestamp like so: >>> time.mktime(datetime.date(2002, 1, 1).timetuple()) 1009861200.0 >>> The dates for which this works depends on the platform mktime implementation, though. BTW, this sounds a lot more like a new feature request than a bug! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665194&group_id=5470 From noreply@sourceforge.net Sat Jan 11 17:08:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 11 Jan 2003 09:08:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-665761 ] reduce() masks exception Message-ID: Bugs item #665761, was opened at 2003-01-10 09:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665761&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 3 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: reduce() masks exception Initial Comment: In the following test script ----- class Test: def __iter__(self): raise IOError reduce(lambda x,y: x+y, Test()) ----- the real IOError exception is masked, i.e. the traceback is ----- Traceback (most recent call last): File "test.py", line 5, in ? reduce(lambda x,y: x+y, Test()) TypeError: reduce() arg 2 must support iteration ----- but IMHO should be ----- Traceback (most recent call last): File "test.py", line 3, in ? raise IOError IOError ----- This can be fixed by removing the PyErr_SetString(PyExc_TypeError, "reduce() arg 2 must support iteration") call in bltinmodule.c/buildtin_reduce(). ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2003-01-11 12:08 Message: Logged In: YES user_id=366566 the __iter__ method is supposed to return an object that defines a 'next' method. The returned object is the one used for iteration, not the original. So I believe the error message is correct - Test does not support iteration. If you change the code to: >>> class test: ... def __iter__(self): ... return self ... def next(self): ... raise IOError ... >>> reduce(operator.add, test()) You get the expected result... Traceback (most recent call last):   File "", line 1, in ?   File "", line 5, in next IOError ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665761&group_id=5470 From noreply@sourceforge.net Sun Jan 12 01:04:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 11 Jan 2003 17:04:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-666444 ] 'help' makes linefeed only under Win32 Message-ID: Bugs item #666444, was opened at 2003-01-11 20:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666444&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: 'help' makes linefeed only under Win32 Initial Comment: The 'help' command, under a win32 console app, separates lines with \n instead of \r\n as it has in the past, making its output a little hard to follow. Possibly an unintended side effect of the 'universal newline' addition? Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC v.1200 32 bit (Intel)] on win32 (windows 98) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666444&group_id=5470 From noreply@sourceforge.net Sun Jan 12 02:32:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 11 Jan 2003 18:32:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-666468 ] round() not working as expected Message-ID: Bugs item #666468, was opened at 2003-01-12 02:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666468&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mr Topf (mrtopf) Assigned to: Nobody/Anonymous (nobody) Summary: round() not working as expected Initial Comment: I tried the following: >> round(1.11,2) 1.1100000000000001 I would expect 1.11 as result. So this seems not to be right. This seems to be the case for all of the 1.1x numbers. This happened on Linux (SuSE 8.1 and 8.0) and on various python version (2.1,2.2). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666468&group_id=5470 From noreply@sourceforge.net Sun Jan 12 03:00:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 11 Jan 2003 19:00:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-666468 ] round() not working as expected Message-ID: Bugs item #666468, was opened at 2003-01-11 21:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666468&group_id=5470 Category: Python Library >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Mr Topf (mrtopf) >Assigned to: Tim Peters (tim_one) Summary: round() not working as expected Initial Comment: I tried the following: >> round(1.11,2) 1.1100000000000001 I would expect 1.11 as result. So this seems not to be right. This seems to be the case for all of the 1.1x numbers. This happened on Linux (SuSE 8.1 and 8.0) and on various python version (2.1,2.2). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-11 22:00 Message: Logged In: YES user_id=31435 It's not a bug, but is revealing a property of your floating- point hardware. It's explained in detail in Appendix B of the Python Tutoral appendix; or see that online at http://tinyurl.com/1za6 Keep reading until you get to the round() example. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666468&group_id=5470 From noreply@sourceforge.net Sun Jan 12 04:44:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 11 Jan 2003 20:44:12 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-662827 ] optional pad character for zfill and center Message-ID: Feature Requests item #662827, was opened at 2003-01-05 16:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=662827&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: David Torpey (dtorp) Assigned to: Nobody/Anonymous (nobody) Summary: optional pad character for zfill and center Initial Comment: >>> 'padme'.zfill(10, '*') '*****padme' >>> 'padme'.center(10, '*') '**padme***' ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-11 23:44 Message: Logged In: YES user_id=80475 I checked with Guido and he thinks the feature is "nifty" but that the language is cleaner and easier to maintain without it (especially since it would entail similar changes to the unicode and UserString modules). Thank you for the suggestion. Closing the request. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-10 04:42 Message: Logged In: YES user_id=80475 The optional character for center seems like a useful idea to me. People occasionally like to center captions in fields of hyphens or asterisks. Note, this proposal is similar to the recent "optional character" enhancements to str.strip (), str.lstrip(), and str.rstrip(). Doing the same for zfill() is more problematic because both its name and function do not equate to "padleft". The 'z' in zfill implies that a zero will be used. The actual function not only fills to the left, but also repositions any leading minus signs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=662827&group_id=5470 From noreply@sourceforge.net Sun Jan 12 11:35:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 12 Jan 2003 03:35:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-660455 ] -hex/oct const generates wrong code Message-ID: Bugs item #660455, was opened at 2002-12-31 13:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660455&group_id=5470 Category: Parser/Compiler Group: Python 2.2 Status: Open Resolution: None Priority: 6 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: -hex/oct const generates wrong code Initial Comment: Since Python 2.2, there's code in com_factor() in compile.c that expands negative constants inline. For example, the expression -1 generates a single LOAD_CONST opcode for -1, rather than (as in Python 2.1 and before) generating a LOAD_CONST for +1 followed by a UNARY_NEGATIVE opcode. Unfortunately there's an end case where this causes surprising behavior: when the constant is an octal or hexadecimal constant that already has a negative value (despite having no sign), the generated code yields a different result than expected. For example: >>> print -(0xffffffff) 1 >>> x = 0xffffffff >>> print -x 1 >>> print -0xffffffff -4294967295 >>> Despite the fact that in Python 2.4 (!) all of these will print the third outcome, in Python 2.2 and 2.3, I think the third outcome is wrong and unexpected. No time to fix this for 2.3a1, but should fix it before 2.3a2. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-12 06:35 Message: Logged In: YES user_id=80475 See attached patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660455&group_id=5470 From noreply@sourceforge.net Sun Jan 12 14:20:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 12 Jan 2003 06:20:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-662701 ] sys.version[:3] gives incorrect version Message-ID: Bugs item #662701, was opened at 2003-01-05 12:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662701&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pearu Peterson (pearu) Assigned to: Nobody/Anonymous (nobody) Summary: sys.version[:3] gives incorrect version Initial Comment: sys.version[:3] is used in several places [*] for Python version and in most cases it is OK. However, when Python is build/installed, say, with make all install VERSION=2.2.2 then sys.version[:3] does not represent Python version correctly anymore. For example, the path to Python Lib is then /lib/python2.2.2/ but e.g. distutils finds it as /lib/python2.2/ which obviously causes either an exception or a silent incorrect behaviour [**] when trying to use distutils. Note about fix: I don't have it but simply replacing sys.version[:3] with sys.version.split()[0] will not work. Best regards, Pearu [*] Running grep "sys.version\[:3\]" {*,*/*,*/*/*}.py in the Python Lib tree shows 8 matches for Python 2.2.2. [**] .. e.g. when one has other Python installed with VERSION=2.2 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-12 09:20 Message: Logged In: YES user_id=6380 I don't know who added that to README, but that was never inteded usage, so I'd suggest to undocument it. There's no support for such usage and I don't think it's needed. If you want to install a variant like that, use prefix=. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 04:54 Message: Logged In: YES user_id=21627 I see. What you have been doing is indeed documented as supported. Unfortunately, there is currently no way in which distutils could find out what VERSION is. So if this is intended to work, we need to expose VERSION somewhere. ---------------------------------------------------------------------- Comment By: Pearu Peterson (pearu) Date: 2003-01-05 18:40 Message: Logged In: YES user_id=88489 A note: according to Python README Installation section, make make altinstall VERSION=2.2.2 is "legal". From reading the generated Makefile, the above seems to be identical to 'make all install VERSION=2.2.2', but I haven't actually tried it out, though, so I might be wrong. If fixing this issue is too difficult, that's fine with me. One can always use --prefix= as a workaround when configuring Python. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-05 18:14 Message: Logged In: YES user_id=21627 I would suggest that 'make all install VERSION=2.2.2' is not supported, so this does not need to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662701&group_id=5470 From noreply@sourceforge.net Sun Jan 12 14:28:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 12 Jan 2003 06:28:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-663701 ] sets module review Message-ID: Bugs item #663701, was opened at 2003-01-07 09:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663701&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sebastien Keim (s_keim) >Assigned to: Tim Peters (tim_one) Summary: sets module review Initial Comment: * the ^ operator doesnt print well in pdf generated documentation (both in what's new and in library reference) * shouldn't the _as_immutable and _as_temporaly_immutable be spelled __as_immutable__ and __as_temporaly_immutable__ for consistency with other hook methods? * cmp() suck: 
bash-2.05$ ./python 
Python 2.3a1 (#1, Jan  4 2003, 10:17:56) 
[GCC 2.95.3 20010315 (release)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import sets
>>> s = sets.Set
>>> a = s([0])
>>> b = s([1])
>>> cmp(a,b)
1
>>> 
bash-2.05$ ./python 
Python 2.3a1 (#1, Jan  4 2003, 10:17:56) 
[GCC 2.95.3 20010315 (release)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import sets
>>> a=sets.Set([0])
>>> b=sets.Set([1])
>>> cmp(a,b)
-1
* Because we can have set1!=set2 and both (set1 behavior? ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-12 09:28 Message: Logged In: YES user_id=6380 It's unlikely that the built-in type will behave exactly the same, so the name difference is a good way to distinguish the module from a future builtin. Regarding cmp(): hmm, we may need to think about this more. Currently comparison operators are used to express subset relationships, e.g. <= means subset, < means strict subset. The result of this is that cmp() between sets that are neither subset nor set gets a useless outcome. (I can reproduce your example but can't explain it.) Maybe we should implement __cmp__ to raise an exception? Or maybe <= for subset is too cute? Assigning for Tim to ask his opinion. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-01-07 17:44 Message: Logged In: YES user_id=593130 If/when sets become builtin, would type object be called 'set' or break current convention by being called 'Set'? If the former, I think classSet should be 'set' now so one can write 'from sets import set' and have rest of code ready for the future. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663701&group_id=5470 From noreply@sourceforge.net Sun Jan 12 15:00:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 12 Jan 2003 07:00:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-665570 ] curses causes interpreter crash Message-ID: Bugs item #665570, was opened at 2003-01-10 04:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665570&group_id=5470 Category: Python Library >Group: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Neal Norwitz (nnorwitz) Summary: curses causes interpreter crash Initial Comment: [submitted to http://bugs.debian.org/175589 ] A call to curses.initscr() that fails because of an error (such as TERM not being set) causes the program to exit. No exception thrown, no error returned -- an EXIT. There is very anti-Pythonic and, at minimum, should be documented. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-12 10:00 Message: Logged In: YES user_id=33168 I do not believe this is a bug in python. The exit is occuring in initscr() in libncurses: #0 exit (status=1) at exit.c:40 #1 0x40289b62 in initscr () from /usr/lib/libncurses.so.5 #2 0x402417f1 in PyCurses_InitScr (self=0x0) We have no control over this problem. I have documented that the interpreter can exit in Doc/lib/libcurses.tex 1.41and 1.37.6.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665570&group_id=5470 From noreply@sourceforge.net Sun Jan 12 16:45:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 12 Jan 2003 08:45:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-666700 ] os.popen+() can take string list and bypass shell. Message-ID: Bugs item #666700, was opened at 2003-01-12 16:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666700&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dani (asqui) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen+() can take string list and bypass shell. Initial Comment: After being somewhat dumbfounded by the fact that there is no easy way to securely give user input as parameters to an external utility (because of the fact that os.popen*() runs things in the shell), I was happy to find that (os | popen2).popen[234]() will accept either a string as the command and execute it within a shell, or a string list which is executed directly. This does not apply to os.popen(), however popen2.popen[234]() all use this piece of code to execute the command in the child process: /usr/lib/python2.2/popen2.py def _run_child(self, cmd): if isinstance(cmd, types.StringTypes): cmd = ['/bin/sh', '-c', cmd] for i in range(3, MAXFD): try: os.close(i) except: pass try: os.execvp(cmd[0], cmd) finally: os._exit(1) Meaning that unless cmd is a string it will be run directly, outside of any shell. This appears to be the case for os.popen[234]() as well as popen2.popen*() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666700&group_id=5470 From noreply@sourceforge.net Sun Jan 12 16:49:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 12 Jan 2003 08:49:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-666700 ] os.popen+() can take string list and bypass shell. Message-ID: Bugs item #666700, was opened at 2003-01-12 16:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666700&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Dani (asqui) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen+() can take string list and bypass shell. Initial Comment: After being somewhat dumbfounded by the fact that there is no easy way to securely give user input as parameters to an external utility (because of the fact that os.popen*() runs things in the shell), I was happy to find that (os | popen2).popen[234]() will accept either a string as the command and execute it within a shell, or a string list which is executed directly. This does not apply to os.popen(), however popen2.popen[234]() all use this piece of code to execute the command in the child process: /usr/lib/python2.2/popen2.py def _run_child(self, cmd): if isinstance(cmd, types.StringTypes): cmd = ['/bin/sh', '-c', cmd] for i in range(3, MAXFD): try: os.close(i) except: pass try: os.execvp(cmd[0], cmd) finally: os._exit(1) Meaning that unless cmd is a string it will be run directly, outside of any shell. This appears to be the case for os.popen[234]() as well as popen2.popen*() ---------------------------------------------------------------------- >Comment By: Dani (asqui) Date: 2003-01-12 16:49 Message: Logged In: YES user_id=569758 (The punch line which I omitted was that this fact is not documented anywhere.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666700&group_id=5470 From noreply@sourceforge.net Sun Jan 12 19:47:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 12 Jan 2003 11:47:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-602345 ] option for not writing .py[co] files Message-ID: Bugs item #602345, was opened at 2002-08-30 13:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602345&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 3 Submitted By: Matthias Klose (doko) Assigned to: Neal Norwitz (nnorwitz) Summary: option for not writing .py[co] files Initial Comment: [destilled from http://bugs.debian.org/96111] Currently python tries to write the .py[co] files even in situations, where it will fail, like on read-only mounted file systems. In other situations I don't want python trying to write the compiled files, i.e. having installed the modules as root as part of a distribution, compiled them correctly, there is no need to write them. Or compiling .py files which are configuration files. Is it reasonable to add an option to python (--dont-write-compiled-files) to the interpreter, which doesn't write them? This would not affect existing code at all. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-12 20:47 Message: Logged In: YES user_id=21627 The patch looks good, but is surely incomplete: there should be patches to the documentation, in particular to the man page. It might be also desirable to parallel this option with an environment variable, and/or to expose it writable through the sys module. With the environment variable, people could run Python scripts that won't create .pyc files (as #! /usr/bin/env python does not allow for further command line options). With the API, certain applications could declare that they never want to write .pyc files as they expect to run in parallel with itself, and might cause .pyc conflicts. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 17:39 Message: Logged In: YES user_id=6380 I think it's a good idea, but please use a single upper case letter for the option. Python doesn't support long options and I'm not about to start doing so. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-02 01:30 Message: Logged In: YES user_id=33168 Guido, do you think this is a good idea? If so, assign back to me and I'll work up a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602345&group_id=5470 From noreply@sourceforge.net Sun Jan 12 21:39:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 12 Jan 2003 13:39:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-602345 ] option for not writing .py[co] files Message-ID: Bugs item #602345, was opened at 2002-08-30 07:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602345&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 3 Submitted By: Matthias Klose (doko) Assigned to: Neal Norwitz (nnorwitz) Summary: option for not writing .py[co] files Initial Comment: [destilled from http://bugs.debian.org/96111] Currently python tries to write the .py[co] files even in situations, where it will fail, like on read-only mounted file systems. In other situations I don't want python trying to write the compiled files, i.e. having installed the modules as root as part of a distribution, compiled them correctly, there is no need to write them. Or compiling .py files which are configuration files. Is it reasonable to add an option to python (--dont-write-compiled-files) to the interpreter, which doesn't write them? This would not affect existing code at all. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-12 16:39 Message: Logged In: YES user_id=33168 You are correct about the patch being incomplete. I still have to do all the doc. I hadn't thought about an env't variable or variable in sys. Both are certainly reasonable. I will update the patch. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-12 14:47 Message: Logged In: YES user_id=21627 The patch looks good, but is surely incomplete: there should be patches to the documentation, in particular to the man page. It might be also desirable to parallel this option with an environment variable, and/or to expose it writable through the sys module. With the environment variable, people could run Python scripts that won't create .pyc files (as #! /usr/bin/env python does not allow for further command line options). With the API, certain applications could declare that they never want to write .pyc files as they expect to run in parallel with itself, and might cause .pyc conflicts. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-03 11:39 Message: Logged In: YES user_id=6380 I think it's a good idea, but please use a single upper case letter for the option. Python doesn't support long options and I'm not about to start doing so. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-01 19:30 Message: Logged In: YES user_id=33168 Guido, do you think this is a good idea? If so, assign back to me and I'll work up a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602345&group_id=5470 From noreply@sourceforge.net Sun Jan 12 23:52:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 12 Jan 2003 15:52:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-666880 ] readonly is now a compiler keyword Message-ID: Bugs item #666880, was opened at 2003-01-12 18:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666880&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Malmberg (wb8tyw) Assigned to: Nobody/Anonymous (nobody) Summary: readonly is now a compiler keyword Initial Comment: In module bufferobject.c, a variable is named readonly. This conflicts with the new C keyword readonly. Please change the name of this variable so that it does not conflict. Python: 2.3a1 pre-release Operating System: OpenVMS Alpha 7.3-1 $ CC/PREFIX=ALL /WARN=ENABLE=(LEVEL4,QUESTCODE)/include=(PRJ_SRC:,PRJ_INCLUDE:,P RJ_PARSER:,PRJ_PYTHON:,PRJ_MODULES:,FRONTPORT__DIR:)/define=(MOD_'f$element(0,"- ",f$parse("LCL_OBJECTS:BUFFEROBJECT",,,"NAME"))', HAVE_CONFIG_H)/NESTED_INCLUDE_DIR=NONE/- object=LCL_OBJECTS:BUFFEROBJECT.OBJ PRJ_OBJECTS:BUFFEROBJECT.C _PyBuffer_FromMemory(PyObject *base, void *ptr, int size, int readonly) ..............................................................^ %CC-I-READONLYEXT, readonly is a language extension. at line number 18 in file PROJECT_ROOT:[PYTHON.OBJECTS]BUFFEROBJECT.C;1 b->b_readonly = readonly; ........................^ %CC-E-BADEXPR, Invalid expression. at line number 36 in file PROJECT_ROOT:[PYTHON.OBJECTS]BUFFEROBJECT.C;1 return _PyBuffer_FromMemory(base, (char *)p + offset, size, readonly); ....................................................................^ %CC-E-BADEXPR, Invalid expression. at line number 79 in file PROJECT_ROOT:[PYTHON.OBJECTS]BUFFEROBJECT.C;1 _PyBuffer_FromMemory(PyObject *base, void *ptr, int size, int readonly) ..............................................................^ %CC-I-STORMODDCL, In this declaration, a storage class modifier without a declarator is meaningless. at line number 18 in file PROJECT_ROOT:[PYTHON.OBJECTS]BUFFEROBJECT.C;1 _PyBuffer_FromMemory(PyObject *base, void *ptr, int size, int readonly) ..............................................................^ %CC-E-PARMSTORMOD, In this declaration, a parameter cannot have a storage class modifier. at line number 18 in file PROJECT_ROOT:[PYTHON.OBJECTS]BUFFEROBJECT.C;1 getreadbufferproc proc, int readonly) .................................................^ %CC-I-STORMODDCL, In this declaration, a storage class modifier without a declarator is meaningless. at line number 44 in file PROJECT_ROOT:[PYTHON.OBJECTS]BUFFEROBJECT.C;1 getreadbufferproc proc, int readonly) .................................................^ %CC-E-PARMSTORMOD, In this declaration, a parameter cannot have a storage class modifier. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666880&group_id=5470 From noreply@sourceforge.net Mon Jan 13 03:53:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 12 Jan 2003 19:53:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-666880 ] readonly is now a compiler keyword Message-ID: Bugs item #666880, was opened at 2003-01-12 18:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666880&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Malmberg (wb8tyw) Assigned to: Nobody/Anonymous (nobody) Summary: readonly is now a compiler keyword Initial Comment: In module bufferobject.c, a variable is named readonly. This conflicts with the new C keyword readonly. Please change the name of this variable so that it does not conflict. Python: 2.3a1 pre-release Operating System: OpenVMS Alpha 7.3-1 $ CC/PREFIX=ALL /WARN=ENABLE=(LEVEL4,QUESTCODE)/include=(PRJ_SRC:,PRJ_INCLUDE:,P RJ_PARSER:,PRJ_PYTHON:,PRJ_MODULES:,FRONTPORT__DIR:)/define=(MOD_'f$element(0,"- ",f$parse("LCL_OBJECTS:BUFFEROBJECT",,,"NAME"))', HAVE_CONFIG_H)/NESTED_INCLUDE_DIR=NONE/- object=LCL_OBJECTS:BUFFEROBJECT.OBJ PRJ_OBJECTS:BUFFEROBJECT.C _PyBuffer_FromMemory(PyObject *base, void *ptr, int size, int readonly) ..............................................................^ %CC-I-READONLYEXT, readonly is a language extension. at line number 18 in file PROJECT_ROOT:[PYTHON.OBJECTS]BUFFEROBJECT.C;1 b->b_readonly = readonly; ........................^ %CC-E-BADEXPR, Invalid expression. at line number 36 in file PROJECT_ROOT:[PYTHON.OBJECTS]BUFFEROBJECT.C;1 return _PyBuffer_FromMemory(base, (char *)p + offset, size, readonly); ....................................................................^ %CC-E-BADEXPR, Invalid expression. at line number 79 in file PROJECT_ROOT:[PYTHON.OBJECTS]BUFFEROBJECT.C;1 _PyBuffer_FromMemory(PyObject *base, void *ptr, int size, int readonly) ..............................................................^ %CC-I-STORMODDCL, In this declaration, a storage class modifier without a declarator is meaningless. at line number 18 in file PROJECT_ROOT:[PYTHON.OBJECTS]BUFFEROBJECT.C;1 _PyBuffer_FromMemory(PyObject *base, void *ptr, int size, int readonly) ..............................................................^ %CC-E-PARMSTORMOD, In this declaration, a parameter cannot have a storage class modifier. at line number 18 in file PROJECT_ROOT:[PYTHON.OBJECTS]BUFFEROBJECT.C;1 getreadbufferproc proc, int readonly) .................................................^ %CC-I-STORMODDCL, In this declaration, a storage class modifier without a declarator is meaningless. at line number 44 in file PROJECT_ROOT:[PYTHON.OBJECTS]BUFFEROBJECT.C;1 getreadbufferproc proc, int readonly) .................................................^ %CC-E-PARMSTORMOD, In this declaration, a parameter cannot have a storage class modifier. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-12 22:53 Message: Logged In: YES user_id=31435 readonly isn't a keyword in the C89 or C99 ANSI/ISO C standards, so the source of the problem remains unclear. Is this a vendor extension specific to the C compiler you're using -- and which C compiler is that? A better solution may be to disable a non-standard compiler extension. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666880&group_id=5470 From noreply@sourceforge.net Mon Jan 13 04:17:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 12 Jan 2003 20:17:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-666958 ] repr.repr not always safe Message-ID: Bugs item #666958, was opened at 2003-01-12 23:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666958&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: repr.repr not always safe Initial Comment: >>> class A: ... def __repr__(self): ... raise Exception ... def someMethod(self): ... pass ... >>> A() Traceback (most recent call last): File "", line 1, in ? File "", line 3, in __repr__ Exception >>> repr.repr(A()) '' >>> repr.repr(A().someMethod) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/repr.py", line 15, in repr return self.repr1(x, self.maxlevel) File "/usr/lib/python2.2/repr.py", line 24, in repr1 s = `x` File "", line ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666958&group_id=5470 From noreply@sourceforge.net Mon Jan 13 04:34:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 12 Jan 2003 20:34:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-666958 ] repr.repr not always safe Message-ID: Bugs item #666958, was opened at 2003-01-12 23:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666958&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: repr.repr not always safe Initial Comment: >>> class A: ... def __repr__(self): ... raise Exception ... def someMethod(self): ... pass ... >>> A() Traceback (most recent call last): File "", line 1, in ? File "", line 3, in __repr__ Exception >>> repr.repr(A()) '' >>> repr.repr(A().someMethod) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/repr.py", line 15, in repr return self.repr1(x, self.maxlevel) File "/usr/lib/python2.2/repr.py", line 24, in repr1 s = `x` File "", line ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-12 23:34 Message: Logged In: YES user_id=31435 Why do say this is a bug? If you raise an exception, yes, you get an exception. Most __repr__ *implementations* try hard not to raise any exceptions, but it's never guaranteed that they won't. For example, just about any __repr__ implementation may run out of memory while trying to build its result string, so MemoryError is almost always a possible exception. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666958&group_id=5470 From noreply@sourceforge.net Mon Jan 13 04:43:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 12 Jan 2003 20:43:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-664044 ] Lib Man 2.2.6.2 word change Message-ID: Bugs item #664044, was opened at 2003-01-07 17:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=664044&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Terry J. Reedy (tjreedy) Assigned to: Raymond Hettinger (rhettinger) Summary: Lib Man 2.2.6.2 word change Initial Comment: In the conversion types table, the 's' line s String (converts any python object using str()). should have 'non-unicode' substituted for or inserted before 'python' to be consistent with both the last sentence of the first paragraph and current (2.2.1) behavior. This non-updated line has fooled at least one person (clp poster). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-12 23:43 Message: Logged In: YES user_id=80475 Fixed. See Doc/lib/libstdtypes.tex 1.117 and 1.80.6.18. ---------------------------------------------------------------------- Comment By: Christopher Blunck (blunck2) Date: 2003-01-08 00:16 Message: Logged In: YES user_id=531881 see patch 664183 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=664044&group_id=5470 From noreply@sourceforge.net Mon Jan 13 05:28:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 12 Jan 2003 21:28:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-663701 ] sets module review Message-ID: Bugs item #663701, was opened at 2003-01-07 09:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663701&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sebastien Keim (s_keim) >Assigned to: Guido van Rossum (gvanrossum) Summary: sets module review Initial Comment: * the ^ operator doesnt print well in pdf generated documentation (both in what's new and in library reference) * shouldn't the _as_immutable and _as_temporaly_immutable be spelled __as_immutable__ and __as_temporaly_immutable__ for consistency with other hook methods? * cmp() suck: 
bash-2.05$ ./python 
Python 2.3a1 (#1, Jan  4 2003, 10:17:56) 
[GCC 2.95.3 20010315 (release)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import sets
>>> s = sets.Set
>>> a = s([0])
>>> b = s([1])
>>> cmp(a,b)
1
>>> 
bash-2.05$ ./python 
Python 2.3a1 (#1, Jan  4 2003, 10:17:56) 
[GCC 2.95.3 20010315 (release)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import sets
>>> a=sets.Set([0])
>>> b=sets.Set([1])
>>> cmp(a,b)
-1
* Because we can have set1!=set2 and both (set1 behavior? ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-13 00:28 Message: Logged In: YES user_id=31435 try_rich_to_3way_compare gives up after LT, EQ and GT all return false. The comparison then falls back to the default comparison by object id (addresses). So, e.g., I can build an a, b, and c on my box such that: >>> a, b, c (Set([0]), Set([1]), Set([1])) >>> cmp(b, c) # b equals c 0 >>> cmp(a, b) # but a "greater than" b while 1 >>> cmp(a, c) # a "less than" c, despite that b == c -1 >>> This is simply because a is at a lower address than c but at a higher address than b: >>> id(a) < id(c) True >>> id(a) > id(b) True >>> I don't think <= for subset is too cute -- sets do have a natural and useful partial order. I don't really care happens if you pass them to cmp(), though. An exception would be fine -- sets weren't intended to be "generally" comparable. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-12 09:28 Message: Logged In: YES user_id=6380 It's unlikely that the built-in type will behave exactly the same, so the name difference is a good way to distinguish the module from a future builtin. Regarding cmp(): hmm, we may need to think about this more. Currently comparison operators are used to express subset relationships, e.g. <= means subset, < means strict subset. The result of this is that cmp() between sets that are neither subset nor set gets a useless outcome. (I can reproduce your example but can't explain it.) Maybe we should implement __cmp__ to raise an exception? Or maybe <= for subset is too cute? Assigning for Tim to ask his opinion. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-01-07 17:44 Message: Logged In: YES user_id=593130 If/when sets become builtin, would type object be called 'set' or break current convention by being called 'Set'? If the former, I think classSet should be 'set' now so one can write 'from sets import set' and have rest of code ready for the future. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663701&group_id=5470 From noreply@sourceforge.net Mon Jan 13 06:04:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 12 Jan 2003 22:04:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-666880 ] readonly is now a compiler keyword Message-ID: Bugs item #666880, was opened at 2003-01-12 18:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666880&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: John Malmberg (wb8tyw) Assigned to: Nobody/Anonymous (nobody) Summary: readonly is now a compiler keyword Initial Comment: In module bufferobject.c, a variable is named readonly. This conflicts with the new C keyword readonly. Please change the name of this variable so that it does not conflict. Python: 2.3a1 pre-release Operating System: OpenVMS Alpha 7.3-1 $ CC/PREFIX=ALL /WARN=ENABLE=(LEVEL4,QUESTCODE)/include=(PRJ_SRC:,PRJ_INCLUDE:,P RJ_PARSER:,PRJ_PYTHON:,PRJ_MODULES:,FRONTPORT__DIR:)/define=(MOD_'f$element(0,"- ",f$parse("LCL_OBJECTS:BUFFEROBJECT",,,"NAME"))', HAVE_CONFIG_H)/NESTED_INCLUDE_DIR=NONE/- object=LCL_OBJECTS:BUFFEROBJECT.OBJ PRJ_OBJECTS:BUFFEROBJECT.C _PyBuffer_FromMemory(PyObject *base, void *ptr, int size, int readonly) ..............................................................^ %CC-I-READONLYEXT, readonly is a language extension. at line number 18 in file PROJECT_ROOT:[PYTHON.OBJECTS]BUFFEROBJECT.C;1 b->b_readonly = readonly; ........................^ %CC-E-BADEXPR, Invalid expression. at line number 36 in file PROJECT_ROOT:[PYTHON.OBJECTS]BUFFEROBJECT.C;1 return _PyBuffer_FromMemory(base, (char *)p + offset, size, readonly); ....................................................................^ %CC-E-BADEXPR, Invalid expression. at line number 79 in file PROJECT_ROOT:[PYTHON.OBJECTS]BUFFEROBJECT.C;1 _PyBuffer_FromMemory(PyObject *base, void *ptr, int size, int readonly) ..............................................................^ %CC-I-STORMODDCL, In this declaration, a storage class modifier without a declarator is meaningless. at line number 18 in file PROJECT_ROOT:[PYTHON.OBJECTS]BUFFEROBJECT.C;1 _PyBuffer_FromMemory(PyObject *base, void *ptr, int size, int readonly) ..............................................................^ %CC-E-PARMSTORMOD, In this declaration, a parameter cannot have a storage class modifier. at line number 18 in file PROJECT_ROOT:[PYTHON.OBJECTS]BUFFEROBJECT.C;1 getreadbufferproc proc, int readonly) .................................................^ %CC-I-STORMODDCL, In this declaration, a storage class modifier without a declarator is meaningless. at line number 44 in file PROJECT_ROOT:[PYTHON.OBJECTS]BUFFEROBJECT.C;1 getreadbufferproc proc, int readonly) .................................................^ %CC-E-PARMSTORMOD, In this declaration, a parameter cannot have a storage class modifier. ---------------------------------------------------------------------- >Comment By: John Malmberg (wb8tyw) Date: 2003-01-13 01:04 Message: Logged In: YES user_id=686238 I should have researched this before submittiing. "readonly" is an obsolete VAX C keyword that is an alias for "const". I though I had VAX C compatablilty mode disabled in the compiler. Compiler is COMPAQ C 6.5. It appears that the only way to get the compiler to disable that extension is to make it accept only strict ANSI89 compatability. This has greatly increased the number of informational diagnostics that I am getting. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-12 22:53 Message: Logged In: YES user_id=31435 readonly isn't a keyword in the C89 or C99 ANSI/ISO C standards, so the source of the problem remains unclear. Is this a vendor extension specific to the C compiler you're using -- and which C compiler is that? A better solution may be to disable a non-standard compiler extension. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666880&group_id=5470 From noreply@sourceforge.net Mon Jan 13 09:52:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 13 Jan 2003 01:52:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-643005 ] socket.inet_aton("255.255.255.255") Message-ID: Bugs item #643005, was opened at 2002-11-24 11:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=643005&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 6 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: socket.inet_aton("255.255.255.255") Initial Comment: This comes up as an error on platforms with a 32 bit in_addr_t type, because 0xFFFFFFFF -> -1 -> INADDR_ANY -> error condition. socketmodule's inet_aton() should probably be changed to use inet_aton if available (I'm not sure how to make the appropriate platform checks, or I'd submit a patch). It isn't clear to me the best way to work around this on platforms lacking inet_aton(), short of re-implementing its functionality. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-01-13 11:52 Message: Logged In: YES user_id=539787 I'm in the process of trying to make a patch, since I found this relating to a mistaken 8-byte result in 64-bit machines. When I come up with an answer, I will post a link to the patch here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=643005&group_id=5470 From noreply@sourceforge.net Mon Jan 13 13:05:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 13 Jan 2003 05:05:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-665194 ] datetime-RFC2822 roundtripping Message-ID: Bugs item #665194, was opened at 2003-01-09 19:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665194&group_id=5470 Category: None Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: datetime-RFC2822 roundtripping Initial Comment: It would be good to have a simply way to convert between datetime objects and RFC2822 style strings. >From string to datetime is easy with datetime.datetime(*email.Utils.parsedate(m)[:7]) (but this drops the timezone), but the other direction seems impossible. email.Utils.formatdate takes a timestamp argument, but AFAICT there's no way to get a timestamp out of a datetime object. Of course the best solution (ignoring backwards compatibility) would be for parsedate und formatdate to return/accept datetime objects or for datetime to have the appropriate methods. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-01-13 14:05 Message: Logged In: YES user_id=89016 totimestamp() should be the inverse of fromtimestamp(), i.e. foo.totimestamp() should be the same as time.mktime(foo.timetuple()). datetime.datetime.totimestamp() should raise OverflowError iff time.mktime() raises OverflowError. But as this may lose precision, I'd say it would be better, if datetime supported RFC1123 conversion directly, i.e. two methods frommime() and tomime(), that parse and format strings like "Sun, 06 Nov 1994 08:49:37 GMT" (what rfc822.parsedate() and rfc822.formatdate() do) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-11 17:32 Message: Logged In: YES user_id=31435 Define what totimestamp() should do. The range of timestamps supported by the *platform* C library (and so indirectly by Python's time module) isn't defined by any standard, and isn't easily discoverable either. It may or may not work before 1970, may or may not after 2038. datetime covers days far outside that range. Note that even a double doesn't have enough bits of precision to cover the full range of datetime values, either. In contrast, ordinals are wholly under Python's control, so we can promise surprise-free conversion in both directions. All we can promise about timestamps is that if the platform supports a timestamp for a time in datetime's range, datetime can make sense of it. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-11 13:33 Message: Logged In: YES user_id=89016 OK, I'll mark this a feature request. datetime has fromordinal() and toordinal(), it has fromtimestamp(), so I'd say a totimestamp() method would be a logical addition. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-11 06:10 Message: Logged In: YES user_id=31435 You can get a timestamp like so: >>> time.mktime(datetime.date(2002, 1, 1).timetuple()) 1009861200.0 >>> The dates for which this works depends on the platform mktime implementation, though. BTW, this sounds a lot more like a new feature request than a bug! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665194&group_id=5470 From noreply@sourceforge.net Mon Jan 13 13:18:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 13 Jan 2003 05:18:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-665761 ] reduce() masks exception Message-ID: Bugs item #665761, was opened at 2003-01-10 15:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665761&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 3 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: reduce() masks exception Initial Comment: In the following test script ----- class Test: def __iter__(self): raise IOError reduce(lambda x,y: x+y, Test()) ----- the real IOError exception is masked, i.e. the traceback is ----- Traceback (most recent call last): File "test.py", line 5, in ? reduce(lambda x,y: x+y, Test()) TypeError: reduce() arg 2 must support iteration ----- but IMHO should be ----- Traceback (most recent call last): File "test.py", line 3, in ? raise IOError IOError ----- This can be fixed by removing the PyErr_SetString(PyExc_TypeError, "reduce() arg 2 must support iteration") call in bltinmodule.c/buildtin_reduce(). ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-01-13 14:18 Message: Logged In: YES user_id=89016 The point is that Python/bltinmodule.c/builtin_reduce() masks the error returned from PyObject_GetIter(). Errors from PyIter_Next() are not masked. What about the following example: class LazyFile: def __init__(self, name, mode="r"): self.name = name self.mode = mode def __iter__(self): return open(self.name, self.mode) import operator f = LazyFile("does not exist") s = reduce(operator.add, f) LazyFile *does* support iteration, but the underlying problem of the non existing file is masked. Removing the call PyErr_SetString(PyExc_TypeError, "reduce() arg 2 must support iteration"); in builtin_reduce(), will produce the original exception "IOError: [Errno 2] No such file or directory: 'does not exist'" and when the second argument is not iteratable, the original exception is just as good: >>> reduce(lambda x,y: x+y, 42) Traceback (most recent call last): File "", line 1, in ? TypeError: iteration over non-sequence ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2003-01-11 18:08 Message: Logged In: YES user_id=366566 the __iter__ method is supposed to return an object that defines a 'next' method. The returned object is the one used for iteration, not the original. So I believe the error message is correct - Test does not support iteration. If you change the code to: >>> class test: ... def __iter__(self): ... return self ... def next(self): ... raise IOError ... >>> reduce(operator.add, test()) You get the expected result... Traceback (most recent call last):   File "", line 1, in ?   File "", line 5, in next IOError ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665761&group_id=5470 From noreply@sourceforge.net Mon Jan 13 13:25:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 13 Jan 2003 05:25:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-667147 ] Segmentation fault printing str subclass Message-ID: Bugs item #667147, was opened at 2003-01-13 13:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667147&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: James Henderson (henderj) Assigned to: Nobody/Anonymous (nobody) Summary: Segmentation fault printing str subclass Initial Comment: If I define a subclass of the built-in type str as follows: class Letter(str): def __new__(cls, letter): if letter == 'EPS': return str.__new__(cls) return str.__new__(cls, letter) def __str__(self): if not self: return 'EPS' return self then the following produces a segmentation fault: >>> w = Letter('w') >>> print w I realize that the last line of the class definition should be: return str.__str__(self) but what I tried should still not cause a crash. I am running Red Hat Linux 7.1 and I have got the same behaviour on Python 2.2, Python 2.2.2 and Python 2.3a0. James ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667147&group_id=5470 From noreply@sourceforge.net Mon Jan 13 13:51:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 13 Jan 2003 05:51:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-667147 ] Segmentation fault printing str subclass Message-ID: Bugs item #667147, was opened at 2003-01-13 08:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667147&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Open Resolution: None >Priority: 7 Submitted By: James Henderson (henderj) Assigned to: Nobody/Anonymous (nobody) Summary: Segmentation fault printing str subclass Initial Comment: If I define a subclass of the built-in type str as follows: class Letter(str): def __new__(cls, letter): if letter == 'EPS': return str.__new__(cls) return str.__new__(cls, letter) def __str__(self): if not self: return 'EPS' return self then the following produces a segmentation fault: >>> w = Letter('w') >>> print w I realize that the last line of the class definition should be: return str.__str__(self) but what I tried should still not cause a crash. I am running Red Hat Linux 7.1 and I have got the same behaviour on Python 2.2, Python 2.2.2 and Python 2.3a0. James ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-13 08:51 Message: Logged In: YES user_id=33168 Ouch! This affects both 2.2.2 and 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667147&group_id=5470 From noreply@sourceforge.net Mon Jan 13 14:54:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 13 Jan 2003 06:54:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-666958 ] repr.repr not always safe Message-ID: Bugs item #666958, was opened at 2003-01-12 23:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666958&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: repr.repr not always safe Initial Comment: >>> class A: ... def __repr__(self): ... raise Exception ... def someMethod(self): ... pass ... >>> A() Traceback (most recent call last): File "", line 1, in ? File "", line 3, in __repr__ Exception >>> repr.repr(A()) '' >>> repr.repr(A().someMethod) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/repr.py", line 15, in repr return self.repr1(x, self.maxlevel) File "/usr/lib/python2.2/repr.py", line 24, in repr1 s = `x` File "", line ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2003-01-13 09:54 Message: Logged In: YES user_id=139309 I say it's a bug because it's inconsistent behavior. You can repr the class instance that throws during a __repr__ just fine ('' ), but you can't __repr__ a bound method of the class instance without throwing an exception. In fact, if the __repr__ of the class instance returns anything but a string, say it returns None for example, then the exception will bubble all the way up and you get no useful output from repr.repr. It's very annoying if you're doing something equivalent to, but more useful than: repr.repr([1, 2, 3, 4, A().someMethod, 6, 7, 8, A()]) Note that repr.repr([1, 2, 3, 4, A(), 6, 7, 8]) does not throw any exceptions. There should be some sort of graceful way to do it, no? I think it ought to handle the bound method broken instance case just like it handles the broken instance case directly. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-12 23:34 Message: Logged In: YES user_id=31435 Why do say this is a bug? If you raise an exception, yes, you get an exception. Most __repr__ *implementations* try hard not to raise any exceptions, but it's never guaranteed that they won't. For example, just about any __repr__ implementation may run out of memory while trying to build its result string, so MemoryError is almost always a possible exception. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666958&group_id=5470 From noreply@sourceforge.net Mon Jan 13 15:22:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 13 Jan 2003 07:22:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-667147 ] Segmentation fault printing str subclass Message-ID: Bugs item #667147, was opened at 2003-01-13 08:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667147&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: James Henderson (henderj) >Assigned to: Guido van Rossum (gvanrossum) Summary: Segmentation fault printing str subclass Initial Comment: If I define a subclass of the built-in type str as follows: class Letter(str): def __new__(cls, letter): if letter == 'EPS': return str.__new__(cls) return str.__new__(cls, letter) def __str__(self): if not self: return 'EPS' return self then the following produces a segmentation fault: >>> w = Letter('w') >>> print w I realize that the last line of the class definition should be: return str.__str__(self) but what I tried should still not cause a crash. I am running Red Hat Linux 7.1 and I have got the same behaviour on Python 2.2, Python 2.2.2 and Python 2.3a0. James ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-13 10:22 Message: Logged In: YES user_id=33168 This problem is caused in object.c::PyObject_Print(). PyObject_Print() recurses infinitely calling itself, with str(obj). Since str(obj) == obj, we never complete. Even if this condition is fixed there's nothing preventing 2 classes __str__()s to call each other and create infinite mutual recursion. The flags could keep a count of the recurses into PyObject_Print() and refuse to go deeper than 64 or some number, thus limiting the number of flags which can be used. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-13 08:51 Message: Logged In: YES user_id=33168 Ouch! This affects both 2.2.2 and 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667147&group_id=5470 From noreply@sourceforge.net Mon Jan 13 16:11:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 13 Jan 2003 08:11:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-667147 ] Segmentation fault printing str subclass Message-ID: Bugs item #667147, was opened at 2003-01-13 08:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667147&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: James Henderson (henderj) >Assigned to: Neal Norwitz (nnorwitz) Summary: Segmentation fault printing str subclass Initial Comment: If I define a subclass of the built-in type str as follows: class Letter(str): def __new__(cls, letter): if letter == 'EPS': return str.__new__(cls) return str.__new__(cls, letter) def __str__(self): if not self: return 'EPS' return self then the following produces a segmentation fault: >>> w = Letter('w') >>> print w I realize that the last line of the class definition should be: return str.__str__(self) but what I tried should still not cause a crash. I am running Red Hat Linux 7.1 and I have got the same behaviour on Python 2.2, Python 2.2.2 and Python 2.3a0. James ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-13 11:11 Message: Logged In: YES user_id=6380 How about a simple internal helper that tracks print recursion? See attached patch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-13 10:22 Message: Logged In: YES user_id=33168 This problem is caused in object.c::PyObject_Print(). PyObject_Print() recurses infinitely calling itself, with str(obj). Since str(obj) == obj, we never complete. Even if this condition is fixed there's nothing preventing 2 classes __str__()s to call each other and create infinite mutual recursion. The flags could keep a count of the recurses into PyObject_Print() and refuse to go deeper than 64 or some number, thus limiting the number of flags which can be used. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-13 08:51 Message: Logged In: YES user_id=33168 Ouch! This affects both 2.2.2 and 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667147&group_id=5470 From noreply@sourceforge.net Mon Jan 13 16:52:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 13 Jan 2003 08:52:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-667147 ] Segmentation fault printing str subclass Message-ID: Bugs item #667147, was opened at 2003-01-13 08:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667147&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: James Henderson (henderj) >Assigned to: Guido van Rossum (gvanrossum) Summary: Segmentation fault printing str subclass Initial Comment: If I define a subclass of the built-in type str as follows: class Letter(str): def __new__(cls, letter): if letter == 'EPS': return str.__new__(cls) return str.__new__(cls, letter) def __str__(self): if not self: return 'EPS' return self then the following produces a segmentation fault: >>> w = Letter('w') >>> print w I realize that the last line of the class definition should be: return str.__str__(self) but what I tried should still not cause a crash. I am running Red Hat Linux 7.1 and I have got the same behaviour on Python 2.2, Python 2.2.2 and Python 2.3a0. James ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-13 11:52 Message: Logged In: YES user_id=33168 The patch works for me. Do you think 10 is a good nesting level? 100? I can add the test from this bug report and doc NEWS. Is there anything else that needs to be done? Do you want to check in the patch or do you want me to? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-13 11:11 Message: Logged In: YES user_id=6380 How about a simple internal helper that tracks print recursion? See attached patch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-13 10:22 Message: Logged In: YES user_id=33168 This problem is caused in object.c::PyObject_Print(). PyObject_Print() recurses infinitely calling itself, with str(obj). Since str(obj) == obj, we never complete. Even if this condition is fixed there's nothing preventing 2 classes __str__()s to call each other and create infinite mutual recursion. The flags could keep a count of the recurses into PyObject_Print() and refuse to go deeper than 64 or some number, thus limiting the number of flags which can be used. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-13 08:51 Message: Logged In: YES user_id=33168 Ouch! This affects both 2.2.2 and 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667147&group_id=5470 From noreply@sourceforge.net Mon Jan 13 17:03:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 13 Jan 2003 09:03:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-667147 ] Segmentation fault printing str subclass Message-ID: Bugs item #667147, was opened at 2003-01-13 08:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667147&group_id=5470 Category: Type/class unification Group: Python 2.2 Status: Open Resolution: None Priority: 7 Submitted By: James Henderson (henderj) >Assigned to: Neal Norwitz (nnorwitz) Summary: Segmentation fault printing str subclass Initial Comment: If I define a subclass of the built-in type str as follows: class Letter(str): def __new__(cls, letter): if letter == 'EPS': return str.__new__(cls) return str.__new__(cls, letter) def __str__(self): if not self: return 'EPS' return self then the following produces a segmentation fault: >>> w = Letter('w') >>> print w I realize that the last line of the class definition should be: return str.__str__(self) but what I tried should still not cause a crash. I am running Red Hat Linux 7.1 and I have got the same behaviour on Python 2.2, Python 2.2.2 and Python 2.3a0. James ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-13 12:03 Message: Logged In: YES user_id=6380 If anything, 10 is too deep already. There should be at most one extra recursive invocation; anything else is too much. But I'll accept that in extreme cases there may be more than one delegation going on, so 10 is fine. Please go ahead and check it in and do the needful. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-13 11:52 Message: Logged In: YES user_id=33168 The patch works for me. Do you think 10 is a good nesting level? 100? I can add the test from this bug report and doc NEWS. Is there anything else that needs to be done? Do you want to check in the patch or do you want me to? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-13 11:11 Message: Logged In: YES user_id=6380 How about a simple internal helper that tracks print recursion? See attached patch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-13 10:22 Message: Logged In: YES user_id=33168 This problem is caused in object.c::PyObject_Print(). PyObject_Print() recurses infinitely calling itself, with str(obj). Since str(obj) == obj, we never complete. Even if this condition is fixed there's nothing preventing 2 classes __str__()s to call each other and create infinite mutual recursion. The flags could keep a count of the recurses into PyObject_Print() and refuse to go deeper than 64 or some number, thus limiting the number of flags which can be used. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-13 08:51 Message: Logged In: YES user_id=33168 Ouch! This affects both 2.2.2 and 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667147&group_id=5470 From noreply@sourceforge.net Mon Jan 13 20:20:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 13 Jan 2003 12:20:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-667147 ] Segmentation fault printing str subclass Message-ID: Bugs item #667147, was opened at 2003-01-13 08:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667147&group_id=5470 Category: Type/class unification Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: James Henderson (henderj) Assigned to: Neal Norwitz (nnorwitz) Summary: Segmentation fault printing str subclass Initial Comment: If I define a subclass of the built-in type str as follows: class Letter(str): def __new__(cls, letter): if letter == 'EPS': return str.__new__(cls) return str.__new__(cls, letter) def __str__(self): if not self: return 'EPS' return self then the following produces a segmentation fault: >>> w = Letter('w') >>> print w I realize that the last line of the class definition should be: return str.__str__(self) but what I tried should still not cause a crash. I am running Red Hat Linux 7.1 and I have got the same behaviour on Python 2.2, Python 2.2.2 and Python 2.3a0. James ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-13 15:20 Message: Logged In: YES user_id=33168 Thanks! Checked in as: * Objects/object.c: 2.195 and 2.162.6.9 * Lib/test/test_descr.py: 1.177 and 1.113.4.30 * Misc/NEWS: 1.613 and 1.337.2.4.2.56 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-13 12:03 Message: Logged In: YES user_id=6380 If anything, 10 is too deep already. There should be at most one extra recursive invocation; anything else is too much. But I'll accept that in extreme cases there may be more than one delegation going on, so 10 is fine. Please go ahead and check it in and do the needful. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-13 11:52 Message: Logged In: YES user_id=33168 The patch works for me. Do you think 10 is a good nesting level? 100? I can add the test from this bug report and doc NEWS. Is there anything else that needs to be done? Do you want to check in the patch or do you want me to? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-13 11:11 Message: Logged In: YES user_id=6380 How about a simple internal helper that tracks print recursion? See attached patch. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-13 10:22 Message: Logged In: YES user_id=33168 This problem is caused in object.c::PyObject_Print(). PyObject_Print() recurses infinitely calling itself, with str(obj). Since str(obj) == obj, we never complete. Even if this condition is fixed there's nothing preventing 2 classes __str__()s to call each other and create infinite mutual recursion. The flags could keep a count of the recurses into PyObject_Print() and refuse to go deeper than 64 or some number, thus limiting the number of flags which can be used. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-13 08:51 Message: Logged In: YES user_id=33168 Ouch! This affects both 2.2.2 and 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667147&group_id=5470 From noreply@sourceforge.net Mon Jan 13 21:50:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 13 Jan 2003 13:50:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-487471 ] urllib2 proxyhandle won't work. Message-ID: Bugs item #487471, was opened at 2001-11-30 07:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=487471&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Ha Shao (hashao) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 proxyhandle won't work. Initial Comment: For python 2.2b2: Adding proxyhandler with build_opener, install_opener does not work since order of the handlers does matter (my guess). In the current code, new handlers are appended at the end of the handlers list. At least under windows, the proxyhandle will never got called if it is added with install_opener. HTTPHandler always get called before proxyhandler if the default list is altered. The attached patch try to reserve the order of handlers based on their baseclass when adding new handlers. Handlers with the same baseclasses might be added more than once. Not sure if it is a good thing or bad thing. Current code will raise except when it trys to remove the default handlers twice. Since order does matter, build_opener should be repleased by a list like class such that user can insert their handlers to specific place. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-13 16:50 Message: Logged In: YES user_id=33168 Ha Shao, I know there were many changes in Python 2.2.x in this area. Do you still have this problem? Can this bug be closed? ---------------------------------------------------------------------- Comment By: Ha Shao (hashao) Date: 2001-11-30 08:10 Message: Logged In: YES user_id=8717 forgot some code and changed a stupid variable name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=487471&group_id=5470 From noreply@sourceforge.net Mon Jan 13 22:13:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 13 Jan 2003 14:13:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-662701 ] sys.version[:3] gives incorrect version Message-ID: Bugs item #662701, was opened at 2003-01-05 18:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662701&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pearu Peterson (pearu) >Assigned to: Martin v. Löwis (loewis) Summary: sys.version[:3] gives incorrect version Initial Comment: sys.version[:3] is used in several places [*] for Python version and in most cases it is OK. However, when Python is build/installed, say, with make all install VERSION=2.2.2 then sys.version[:3] does not represent Python version correctly anymore. For example, the path to Python Lib is then /lib/python2.2.2/ but e.g. distutils finds it as /lib/python2.2/ which obviously causes either an exception or a silent incorrect behaviour [**] when trying to use distutils. Note about fix: I don't have it but simply replacing sys.version[:3] with sys.version.split()[0] will not work. Best regards, Pearu [*] Running grep "sys.version\[:3\]" {*,*/*,*/*/*}.py in the Python Lib tree shows 8 matches for Python 2.2.2. [**] .. e.g. when one has other Python installed with VERSION=2.2 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-12 15:20 Message: Logged In: YES user_id=6380 I don't know who added that to README, but that was never inteded usage, so I'd suggest to undocument it. There's no support for such usage and I don't think it's needed. If you want to install a variant like that, use prefix=. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 10:54 Message: Logged In: YES user_id=21627 I see. What you have been doing is indeed documented as supported. Unfortunately, there is currently no way in which distutils could find out what VERSION is. So if this is intended to work, we need to expose VERSION somewhere. ---------------------------------------------------------------------- Comment By: Pearu Peterson (pearu) Date: 2003-01-06 00:40 Message: Logged In: YES user_id=88489 A note: according to Python README Installation section, make make altinstall VERSION=2.2.2 is "legal". From reading the generated Makefile, the above seems to be identical to 'make all install VERSION=2.2.2', but I haven't actually tried it out, though, so I might be wrong. If fixing this issue is too difficult, that's fine with me. One can always use --prefix= as a workaround when configuring Python. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 00:14 Message: Logged In: YES user_id=21627 I would suggest that 'make all install VERSION=2.2.2' is not supported, so this does not need to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662701&group_id=5470 From noreply@sourceforge.net Mon Jan 13 22:13:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 13 Jan 2003 14:13:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-527022 ] raw_input non-ascii failure on Linux/KDE Message-ID: Bugs item #527022, was opened at 2002-03-07 11:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=527022&group_id=5470 Category: IDLE Group: Platform-specific Status: Open >Resolution: Remind Priority: 5 Submitted By: Alex Martelli (aleax) >Assigned to: Neal Norwitz (nnorwitz) Summary: raw_input non-ascii failure on Linux/KDE Initial Comment: With default encoding left as 'ascii', interactively doing x=raw_input('say something funny: ') and entering a non-ascii character seems to work OK in a textmode interactive interpreter (Linux Mandrake 8.1 and KDE Console, Win98) and on IDLE on Win98. On IDLE with Linux Mandrake 8.1 and KDE, though: Python 2.2 (#1, Dec 23 2001, 20:09:01) [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)] on linux2 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> palö UnicodeError: ASCII encoding error: ordinal not in range(128) >>> x=raw_input('say something funny: ') say something funny: palö Traceback (most recent call last): File "", line 1, in ? x=raw_input('say something funny: ') TypeError: object.readline() returned non-string >>> This came up on python-help (not sure what platform the querant was using), I originally didn't think of it as a bug and told the querant to change the default encoding in site.py, but Skip doubted that was OK and asked on python-list, where Martin said: "In IDLE, I'd say there is a bug somewhere. I'm not sure what ... If there is a bug, it is ok to work around it with any means you find. It would be better to report it to SF, though." so here it is, the SF bug report as requested. Alex ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-13 17:13 Message: Logged In: YES user_id=33168 This is fixed in IDLEfork. Remind to close when idlefork is merged. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=527022&group_id=5470 From noreply@sourceforge.net Mon Jan 13 22:40:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 13 Jan 2003 14:40:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-528990 ] bug? in PyImport_ImportModule under AIX Message-ID: Bugs item #528990, was opened at 2002-03-12 11:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=528990&group_id=5470 Category: Python Interpreter Core Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Fanny Wattez (wattez) Assigned to: Nobody/Anonymous (nobody) Summary: bug? in PyImport_ImportModule under AIX Initial Comment: Here is a description of the problem we encounter. platform : AIX 4.3.3 Python 2.2 environment variables : ---------------------------------------- PATH=/home/soft/ccm_gdc7/bin:/bin:/usr/sbin:/usr/etc:/u sr/lpp/X11/bin:/usr/wf/bin:/usr/local/bin:/usr/local/ad min/etc:/lbin:/usr/bin/etc:/usr/ucb:/home/users/wattez/ lbin:/sbin:.:/usr/bin/X11:/sbin:/home/users/wattez/lbin /fvwm- exec:/tools/versant/6.0.0/rs6000/bin:/tools/views402/st udio/rs6000:/tools/sp1.3.4/bin:/tools/imagemagick5.4.2/ bin:/tools/python2.2.debug/bin PYTHON_ROOT=/tools/python2.2.debug PYTHONPATH=/tools/python2.2.debug/lib/python2.2:/tools/ python2.2.debug/lib/python2.2/lib- tk:/tools/xmlproc0.70:/tools/doctemplate2.2.1:/tools/py thon2.2.debug/lib/python2.2/plat- aix4:/tools/python2.2.debug/lib/python2.2/lib- dynload:/tools/python2.2.debug/lib/python2.2/site- packages test program : ------------------- #include #include int main(int i__argc,char* i__argv[]) { Py_Initialize(); cout << endl << "CALL of PyImport_ImportModule with argument " << getenv("NAME_MODULE") << endl; PyObject * l__obj = PyImport_ImportModule (getenv("NAME_MODULE")); if (l__obj == NULL) cout << "importation of module " << getenv ("NAME_MODULE") << " does not work well!" << endl; return 1; } We ran this test program for different values of $NAME_MODULE. $NAME_MODULE | does the test program work well? ---------------------------------------------------- base64 | KO (Segmentation fault) at the call of PyImport_ImportModule os | OK strop | KO (Segmentation fault) at the call of PyImport_ImportModule string | KO (Segmentation fault) at the call of PyImport_ImportModule What do we see with dbx (Python 2.2 is compiled in debug mode)? ------------------------------------- The last instructions in the stack are : stropmodule.split_whitespace(s = "strop", len = 806723600, maxsplit = 806727672), line 80 in "stropmodule.c" initstrop(), line 1221 in "stropmodule.c" _PyImport_LoadDynamicModule(0x2ff1d2b0, 0x2ff1cdc0, 0xf0004d40), line 53 in "importdl.c" with 0x2ff1d2b0 = "strop" 0x2ff1cdc0 = "/tools/python2.2.debug/lib/python2.2/lib- dynload/strop.so" Could you help us understand the problem? Note : under the interactive Python interpreter, we have no problems importing each of these modules. The test program only crashes under AIX 4.3.3 not under Windows 2000. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-13 17:40 Message: Logged In: YES user_id=33168 Fanny, did this problem happen to occur when running in 64-bit mode? There was another bug that was similar which changed an (unsigned int) to a (char *). The change was in Python/dynload_aix.c Could you test with the CVS version of 2.2.2+ or 2.3a1? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=528990&group_id=5470 From noreply@sourceforge.net Mon Jan 13 22:44:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 13 Jan 2003 14:44:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-538361 ] packing double yields garbage Message-ID: Bugs item #538361, was opened at 2002-04-02 12:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=538361&group_id=5470 Category: Python Library Group: 3rd Party >Status: Closed Resolution: Invalid Priority: 5 Submitted By: Mike Carifio (carifio) Assigned to: Neal Norwitz (nnorwitz) Summary: packing double yields garbage Initial Comment: On RH Linux 6.2/alpha (kernal 2.2.14-6.0), egcs- 2.91.66, python 2.2.1c2. I build python from source and test_struct.py dies with a floating point exception. I believe I've found out why: >>> import struct >>> s = struct.pack("d", 3.14e20) >>> struct.unpack("d", s) (1.69270791053e-307,) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-07 21:29 Message: Logged In: YES user_id=31435 You have to be really interested to track one of these down. I started asking leading questions in April, but didn't get a response. If nobody who runs on Alphas is interested enough to help, the heck with it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 21:22 Message: Logged In: YES user_id=33168 > Is our evidence that it's a compiler bug solely that turning > optimization off made the problem go away? Yes. The test is failing right now: http://www.lysator.liu.se/xenofarm/python/files/2437_6/testlog.txt I built the test normally and got the same failure. I built python with -O0 and the test passed. Python's code may have had a problem. On 9/3/2002, rev 2.57 to Module/structmodule.c changed to use memcpy "to avoid alignment errors." That was from patch 601369 which appeared to be necessary for MIPS. The same code does work on a different alpha, running a different kernel, different glibc, and different compiler. (It works with optimization.) http://www.lysator.liu.se/xenofarm/python/files/2479_31/testlog.txt Suggestions? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-07 21:12 Message: Logged In: YES user_id=31435 Is our evidence that it's a compiler bug solely that turning optimization off made the problem go away? If so, that's a good clue but not definitive. It could be that Python's C code is ill-defined in such a way that optimizing or not changes which kind of undefined behavior obtains. To nail this really requires determining exactly which piece of the Python code changed behavior. This may not be easy, and in some cases may even require digging into the generated machine code. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 20:23 Message: Logged In: YES user_id=33168 This same problem exists in the snake farm (RedHat 6.2/alpha egcs 2.91.66). It turned out to be a compiler bug. Turning optimization off fixed the problem. Unless I hear otherwise, I will close this bug report. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2002-09-04 12:41 Message: Logged In: YES user_id=539787 I think it is something that might have been solved by patch 601369. carifio, can you try downloading the latest Modules/structmodule.c and try again? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-07 18:19 Message: Logged In: YES user_id=6380 - Does the same error occur in earlier versions (2.2, 2.1.2)? - I'm relabeling this as platform-specific because it only fails on alphas (not the world's most popular CPU architecture). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-02 16:24 Message: Logged In: YES user_id=31435 Can you show what's in s? As is, it's impossible to guess whether the problem is in pack() or unpack(). Life would be simpler if you started with a simpler float too (like, say, 1.0). Something random that might help: recompile structmodule.c with optimization turned off. One other: is this Alpha configured to run in big-endian or little-endian mode? ---------------------------------------------------------------------- Comment By: Mike Carifio (carifio) Date: 2002-04-02 13:59 Message: Logged In: YES user_id=503643 EV6 I think. Can I run a command to find out? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-04-02 13:51 Message: Logged In: YES user_id=6656 Oh. That means it might be our fault. Damn. Erm, clutching at straws: what flavour of alpha is this? I'm guessing this is some kind of alignment problem. ---------------------------------------------------------------------- Comment By: Mike Carifio (carifio) Date: 2002-04-02 13:48 Message: Logged In: YES user_id=503643 I also tried this on RH7.*/alpha/2.4.something kernel and gcc 2.95.something and got the same error. Actually, it started with test_struct.py core dumping. I don't actually need to pack doubles. I was just being a good doobie. ---------------------------------------------------------------------- Comment By: Mike Carifio (carifio) Date: 2002-04-02 13:47 Message: Logged In: YES user_id=503643 I also tried this on RH7.*/alpha/2.4.something kernel and gcc 2.95.something and got the same error. Actually, it started with test_struct.py core dumping. I don't actually need to pack doubles. I was just being a good doobie. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-04-02 13:33 Message: Logged In: YES user_id=6656 Hmm, that looks broke. However, I don't see this behaviour on sf's compile farm with 221c1; I'm building 221c2 now, but I'd be amazed if it's different. That machine has kernel 2.4.something and gcc 2.95.something, so is it possible that this is a now-fixed bug in one those (most likely the compiler)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=538361&group_id=5470 From noreply@sourceforge.net Tue Jan 14 02:24:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 13 Jan 2003 18:24:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-661184 ] inspect.getsource bug Message-ID: Bugs item #661184, was opened at 2003-01-02 12:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661184&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michele Simionato (michele_s) Assigned to: Raymond Hettinger (rhettinger) Summary: inspect.getsource bug Initial Comment: I have found a bug in inspect.getsource. I am using Python 2.2.2 on Red-Hat 7.3. Here is the problem. --begin bug.py import inspect def f(x): return x print inspect.getsource(f) --end bug.py % python bug.py Traceback (most recent call last): File "bug.py", line 3, in ? print inspect.getsource(f) File "/usr/local/lib/python2.2/inspect.py", line 520, in getsource return string.join(lines, '') File "/usr/local/lib/python2.2/string.py", line 131, in join return sep.join(words) TypeError: sequence expected, NoneType found Notice that --begin noproblem.py import inspect def f(x): return x print inspect.getsource(f) --end noproblem.py works: % python noproblem.py def f(x): return x I discovered this bug in trying to retrieve the source code for lambda expressions: --begin lambda.py import inspect f=lambda x: x print inspect.getsource(f) --begin lambda.py (same error message). -- Michele Simionato - Dept. of Physics and Astronomy 210 Allen Hall Pittsburgh PA 15260 U.S.A. Phone: 001-412-624-9041 Fax: 001-412-624-9163 Home-page: http://www.phyast.pitt.edu/~micheles/ ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-13 21:24 Message: Logged In: YES user_id=80475 I made my own cut at this and also found that the problem was the try/except fall-through returning None instead of the first line. Also, I've added 'lambda' to regular expression search so that lambda's work as well as defs. The part that jvr commented out needs to stay in. It starts at the first line of code and works its way back until the def is found, that way the comments and docstring get included. Since Just and I independently arrived at the same analysis, considering this one solved. Committed as Lib/inspect.py 1.40 Not recommending for backport because handling one liners is more featuresque than buglike. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-03 06:58 Message: Logged In: YES user_id=92689 It seems inspect.py indeed has problems finding one-line functions. I've attached a patch that addresses this, but to also make it work for lambda's I had to remove a few lines that I don't quite understand the purpose of, as it seems to work well without it. I've commented them out. Their purpose seems to be to adjust co.co_firstlineno in case it's off, it's just that I don't know how/when it can be off. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661184&group_id=5470 From noreply@sourceforge.net Tue Jan 14 08:23:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 14 Jan 2003 00:23:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-662701 ] sys.version[:3] gives incorrect version Message-ID: Bugs item #662701, was opened at 2003-01-05 18:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662701&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pearu Peterson (pearu) >Assigned to: Neil Schemenauer (nascheme) Summary: sys.version[:3] gives incorrect version Initial Comment: sys.version[:3] is used in several places [*] for Python version and in most cases it is OK. However, when Python is build/installed, say, with make all install VERSION=2.2.2 then sys.version[:3] does not represent Python version correctly anymore. For example, the path to Python Lib is then /lib/python2.2.2/ but e.g. distutils finds it as /lib/python2.2/ which obviously causes either an exception or a silent incorrect behaviour [**] when trying to use distutils. Note about fix: I don't have it but simply replacing sys.version[:3] with sys.version.split()[0] will not work. Best regards, Pearu [*] Running grep "sys.version\[:3\]" {*,*/*,*/*/*}.py in the Python Lib tree shows 8 matches for Python 2.2.2. [**] .. e.g. when one has other Python installed with VERSION=2.2 ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-14 09:23 Message: Logged In: YES user_id=21627 Assigning to Neil, since he documented that feature. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-12 15:20 Message: Logged In: YES user_id=6380 I don't know who added that to README, but that was never inteded usage, so I'd suggest to undocument it. There's no support for such usage and I don't think it's needed. If you want to install a variant like that, use prefix=. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 10:54 Message: Logged In: YES user_id=21627 I see. What you have been doing is indeed documented as supported. Unfortunately, there is currently no way in which distutils could find out what VERSION is. So if this is intended to work, we need to expose VERSION somewhere. ---------------------------------------------------------------------- Comment By: Pearu Peterson (pearu) Date: 2003-01-06 00:40 Message: Logged In: YES user_id=88489 A note: according to Python README Installation section, make make altinstall VERSION=2.2.2 is "legal". From reading the generated Makefile, the above seems to be identical to 'make all install VERSION=2.2.2', but I haven't actually tried it out, though, so I might be wrong. If fixing this issue is too difficult, that's fine with me. One can always use --prefix= as a workaround when configuring Python. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 00:14 Message: Logged In: YES user_id=21627 I would suggest that 'make all install VERSION=2.2.2' is not supported, so this does not need to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662701&group_id=5470 From noreply@sourceforge.net Tue Jan 14 08:25:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 14 Jan 2003 00:25:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-665014 ] files with long lines and an encoding crash Message-ID: Bugs item #665014, was opened at 2003-01-09 14:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665014&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 8 Submitted By: Mark Hammond (mhammond) Assigned to: Martin v. Löwis (loewis) Summary: files with long lines and an encoding crash Initial Comment: If a source file declares an encoding, but has a line > 512 characters, a buffer overflows. debug builds assert, but release builds trudge along. Problem is that when reading an encoded line, the 'size' param is not passed to the underlying readline function. Attaching a test case and a patch. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-14 09:25 Message: Logged In: YES user_id=21627 I can't reproduce this. What specific assertion failure do you get, on what system (Windows, I guess)? Can you please attach the test case? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-09 14:54 Message: Logged In: YES user_id=38388 Assigned to Martin since he wrote the source code encoding support. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665014&group_id=5470 From noreply@sourceforge.net Tue Jan 14 11:21:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 14 Jan 2003 03:21:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-665014 ] files with long lines and an encoding crash Message-ID: Bugs item #665014, was opened at 2003-01-10 00:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665014&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 8 Submitted By: Mark Hammond (mhammond) Assigned to: Martin v. Löwis (loewis) Summary: files with long lines and an encoding crash Initial Comment: If a source file declares an encoding, but has a line > 512 characters, a buffer overflows. debug builds assert, but release builds trudge along. Problem is that when reading an encoded line, the 'size' param is not passed to the underlying readline function. Attaching a test case and a patch. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-01-14 22:21 Message: Logged In: YES user_id=14198 Test case already attached, as I mentioned. See crash.py. Sorry, I should have mentioned the assertion failure is inside the debug crt, which detects the 512 byte buffer being overwritten due to the lack of a 'size' arg. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-14 19:25 Message: Logged In: YES user_id=21627 I can't reproduce this. What specific assertion failure do you get, on what system (Windows, I guess)? Can you please attach the test case? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-10 00:54 Message: Logged In: YES user_id=38388 Assigned to Martin since he wrote the source code encoding support. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665014&group_id=5470 From noreply@sourceforge.net Tue Jan 14 12:16:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 14 Jan 2003 04:16:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-665014 ] files with long lines and an encoding crash Message-ID: Bugs item #665014, was opened at 2003-01-09 14:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665014&group_id=5470 Category: Unicode Group: None Status: Open >Resolution: Accepted Priority: 8 Submitted By: Mark Hammond (mhammond) >Assigned to: Mark Hammond (mhammond) Summary: files with long lines and an encoding crash Initial Comment: If a source file declares an encoding, but has a line > 512 characters, a buffer overflows. debug builds assert, but release builds trudge along. Problem is that when reading an encoded line, the 'size' param is not passed to the underlying readline function. Attaching a test case and a patch. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-14 13:16 Message: Logged In: YES user_id=21627 I see. The patch is fine, please apply it. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-01-14 12:21 Message: Logged In: YES user_id=14198 Test case already attached, as I mentioned. See crash.py. Sorry, I should have mentioned the assertion failure is inside the debug crt, which detects the 512 byte buffer being overwritten due to the lack of a 'size' arg. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-14 09:25 Message: Logged In: YES user_id=21627 I can't reproduce this. What specific assertion failure do you get, on what system (Windows, I guess)? Can you please attach the test case? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-09 14:54 Message: Logged In: YES user_id=38388 Assigned to Martin since he wrote the source code encoding support. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665014&group_id=5470 From noreply@sourceforge.net Tue Jan 14 15:02:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 14 Jan 2003 07:02:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-667770 ] import C API mess Message-ID: Bugs item #667770, was opened at 2003-01-14 10:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667770&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Guido van Rossum (gvanrossum) Summary: import C API mess Initial Comment: There are too many different C-level APIs for importing a module. Many of them have the nasty property that they can try to do a relative import in the context of the nearest Python stack frame, where that is not what the C code intended. This needs to be cleaned up. Example use case: time.strptime() is now a C wrapper that imports the _strptime module; but if you follow the path it takes to import, it's quite an amazing journey. It should cut all of that short by looking in sys.modules['_strptime'] first. (But what about restricted execution? Well _strptime.py ought to be safe.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667770&group_id=5470 From noreply@sourceforge.net Tue Jan 14 18:36:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 14 Jan 2003 10:36:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-667931 ] BoundaryError: multipart message with no defined boundary Message-ID: Bugs item #667931, was opened at 2003-01-14 11:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667931&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: BoundaryError: multipart message with no defined boundary Initial Comment: More problems with the email package raising exceptions when trying to parse non-compliant messages. Even when lax parsing is enabled, a BoundaryError is raised when trying to parse the attached spam message. I'd like to see some sort of workaround to handle these cases more gracefully when when lax parsing is enabled. This behavior seems like 'strict' parsing behavior to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667931&group_id=5470 From noreply@sourceforge.net Tue Jan 14 18:38:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 14 Jan 2003 10:38:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-667931 ] BoundaryError: multipart message with no defined boundary Message-ID: Bugs item #667931, was opened at 2003-01-14 11:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667931&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: BoundaryError: multipart message with no defined boundary Initial Comment: More problems with the email package raising exceptions when trying to parse non-compliant messages. Even when lax parsing is enabled, a BoundaryError is raised when trying to parse the attached spam message. I'd like to see some sort of workaround to handle these cases more gracefully when when lax parsing is enabled. This behavior seems like 'strict' parsing behavior to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=667931&group_id=5470 From noreply@sourceforge.net Tue Jan 14 21:18:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 14 Jan 2003 13:18:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-666219 ] AssertionErrors in httplib Message-ID: Bugs item #666219, was opened at 2003-01-11 14:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666219&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Jeremy Hylton (jhylton) Summary: AssertionErrors in httplib Initial Comment: I've recently noticed AssertionErrors being raised by httplib.LineAndFileWrapper.read(). It happens reliably when the server exits unexpectedly. Here's an example of an AssertionError in an xmlrpclib client when I kill the server it's talking to: Traceback (most recent call last): File "qa.py", line 22, in ? x = s.query(tmpl, st, en, radius, age) File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 985, in __call__ return self.__send(self.__name, args) File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1269, in __request verbose=self.__verbose File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1036, in request return self._parse_response(h.getfile(), sock) File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1165, in _parse_response response = file.read(1024) File "/Users/skip/local/lib/python2.3/httplib.py", line 1150, in read assert not self._line_consumed and self._line_left AssertionError I don't see a problem with raising an exception in this situation. I just wonder if AssertionError is the best exception to raise (unless of course, the cause is a logic error in the httplib code). If an exception is being raised because the server went away, I think it would be better to raise IncompleteRead. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-01-14 21:18 Message: Logged In: YES user_id=31392 It's definitely the case that an AssertionError shouldn't be raised. It was my intention that the assert never fail. Do you know which part of the assert fails? Perhaps you could change the assert to print the values of _line_consumed and _line_left and run some more tests. I can't figure out how this goes wrong. Also, do you know when the server is sending an HTTP/0.9 response? I wonder if there's a bug somewhere else and the client is guessing the wrong protocol version for the response. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666219&group_id=5470 From noreply@sourceforge.net Tue Jan 14 21:27:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 14 Jan 2003 13:27:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-661340 ] test_httplib fails on the mac Message-ID: Bugs item #661340, was opened at 2003-01-02 22:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661340&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Jeremy Hylton (jhylton) Summary: test_httplib fails on the mac Initial Comment: test_httplib fails on MacPython-OS9. This is because the output contains \r and \n characters, and this fails on MacOS9. There are two problems really: 1. output/test_httplib is checked in as a text file, while it is a binary file (it contains some \r\n data) or even (brrr:-) mixed-mode (it also contains \n lineendings). 2. The output file is opened in text mode (when re-reading the data), so this can probably not be fixed by a simple cvs admin -kb. I think that putting repr()s in the output in stead of raw strings is probably good enough, but you probably know better what is going on here. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-01-14 21:27 Message: Logged In: YES user_id=31392 I think the actual line-endings are uninteresting as far as what the test is trying to do. I've changed the test so that it doesn't contain \r\n pairs. I think the right thing is to change the way debugging output is generated by httplib, but that's a big project. So I'll just change the test to capture stdout and clean it before printing it. (Checking coming as soon as sourceforge responds.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661340&group_id=5470 From noreply@sourceforge.net Tue Jan 14 23:18:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 14 Jan 2003 15:18:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-665014 ] files with long lines and an encoding crash Message-ID: Bugs item #665014, was opened at 2003-01-10 00:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665014&group_id=5470 Category: Unicode Group: None >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: files with long lines and an encoding crash Initial Comment: If a source file declares an encoding, but has a line > 512 characters, a buffer overflows. debug builds assert, but release builds trudge along. Problem is that when reading an encoded line, the 'size' param is not passed to the underlying readline function. Attaching a test case and a patch. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-01-15 10:18 Message: Logged In: YES user_id=14198 Thanks. /cvsroot/python/python/dist/src/Parser/tokenizer.c,v <-- tokenizer.c new revision: 2.71; previous revision: 2.70 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-14 23:16 Message: Logged In: YES user_id=21627 I see. The patch is fine, please apply it. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-01-14 22:21 Message: Logged In: YES user_id=14198 Test case already attached, as I mentioned. See crash.py. Sorry, I should have mentioned the assertion failure is inside the debug crt, which detects the 512 byte buffer being overwritten due to the lack of a 'size' arg. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-14 19:25 Message: Logged In: YES user_id=21627 I can't reproduce this. What specific assertion failure do you get, on what system (Windows, I guess)? Can you please attach the test case? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-10 00:54 Message: Logged In: YES user_id=38388 Assigned to Martin since he wrote the source code encoding support. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665014&group_id=5470 From noreply@sourceforge.net Wed Jan 15 04:45:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 14 Jan 2003 20:45:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-668302 ] a = b += c, a += b = c gives syntax error Message-ID: Bugs item #668302, was opened at 2003-01-14 20:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668302&group_id=5470 Category: Parser/Compiler Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: a = b += c, a += b = c gives syntax error Initial Comment: The new augmented assignment operators apparently are not syntactically parallel to the assignment operator. I can't come up with an immediate reason why they shouldn't be, and I would like them to be. Python 2.2.1, Red Hat Linux 7.3 I looked in the release notes for Python 2.2.2, and didn't see anything about this. I also searched the open bug list for "assignment", and didn't see this mentioned. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668302&group_id=5470 From noreply@sourceforge.net Wed Jan 15 05:39:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 14 Jan 2003 21:39:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-661913 ] str.index() exception message not consistent Message-ID: Bugs item #661913, was opened at 2003-01-03 18:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661913&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Inyeol Lee (inyeol) >Assigned to: Raymond Hettinger (rhettinger) Summary: str.index() exception message not consistent Initial Comment: $ python Python 2.3a1 (#1, Jan 2 2003, 22:36:29) [GCC 2.95.3 20010315 (release)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> 'a'.index('b') Traceback (most recent call last): File "", line 1, in ? ValueError: substring not found in string.index >>> 'a'.rindex('b') Traceback (most recent call last): File "", line 1, in ? ValueError: substring not found in string.rindex >>> u'a'.index('b') Traceback (most recent call last): File "", line 1, in ? ValueError: substring not found >>> str.index()/str.rindex() exception message contains "in string.(r)index", but unicode.index()/unicode.rindex() doesn't. For me, unicode message is more clear, and it is consistent with other string methods which raises exception, for example; >>> 'a'.split('') Traceback (most recent call last): File "", line 1, in ? ValueError: empty separator >>> 2.2.2 has the same issues. Inyeol Lee ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-15 00:39 Message: Logged In: YES user_id=80475 Fixed. See /Objects/stringobject.c 2.204. Thanks for the bugreport. ---------------------------------------------------------------------- Comment By: Christopher Blunck (blunck2) Date: 2003-01-08 00:29 Message: Logged In: YES user_id=531881 see patch 664192 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661913&group_id=5470 From noreply@sourceforge.net Wed Jan 15 11:39:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 03:39:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-668302 ] a = b += c, a += b = c gives syntax error Message-ID: Bugs item #668302, was opened at 2003-01-15 04:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668302&group_id=5470 Category: Parser/Compiler Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: a = b += c, a += b = c gives syntax error Initial Comment: The new augmented assignment operators apparently are not syntactically parallel to the assignment operator. I can't come up with an immediate reason why they shouldn't be, and I would like them to be. Python 2.2.1, Red Hat Linux 7.3 I looked in the release notes for Python 2.2.2, and didn't see anything about this. I also searched the open bug list for "assignment", and didn't see this mentioned. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-01-15 11:39 Message: Logged In: YES user_id=6656 What would you have a = b += c do? This has been discussed *somewhere* -- python-list, maybe? I'm strongly against changing this, fwiw. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668302&group_id=5470 From noreply@sourceforge.net Wed Jan 15 12:23:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 04:23:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-668433 ] Abort with "negative ref count" Message-ID: Bugs item #668433, was opened at 2003-01-15 13:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668433&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: Abort with "negative ref count" Initial Comment: Python 2.3a1 and the current CVS version abort with the following error message when executing the attached test script: Fatal Python error: D:\Python-current\dist\src\Objects\descrobject.c:10 object at 007C3208 has negative ref count -1 This happens only in the debug build, both on Linux (with configure --enable-unicode=ucs4 --with-pydebug and 2.3a1) and on Windows (with the debug build and current CVS). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668433&group_id=5470 From noreply@sourceforge.net Wed Jan 15 15:04:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 07:04:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-668433 ] Abort with "negative ref count" Message-ID: Bugs item #668433, was opened at 2003-01-15 07:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668433&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) >Summary: Abort with "negative ref count" Initial Comment: Python 2.3a1 and the current CVS version abort with the following error message when executing the attached test script: Fatal Python error: D:\Python-current\dist\src\Objects\descrobject.c:10 object at 007C3208 has negative ref count -1 This happens only in the debug build, both on Linux (with configure --enable-unicode=ucs4 --with-pydebug and 2.3a1) and on Windows (with the debug build and current CVS). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-15 10:04 Message: Logged In: YES user_id=33168 Walter, there's no file attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668433&group_id=5470 From noreply@sourceforge.net Wed Jan 15 15:16:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 07:16:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-668433 ] Abort with "negative ref count" Message-ID: Bugs item #668433, was opened at 2003-01-15 13:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668433&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) >Summary: Abort with "negative ref count" Initial Comment: Python 2.3a1 and the current CVS version abort with the following error message when executing the attached test script: Fatal Python error: D:\Python-current\dist\src\Objects\descrobject.c:10 object at 007C3208 has negative ref count -1 This happens only in the debug build, both on Linux (with configure --enable-unicode=ucs4 --with-pydebug and 2.3a1) and on Windows (with the debug build and current CVS). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-15 16:04 Message: Logged In: YES user_id=33168 Walter, there's no file attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668433&group_id=5470 From noreply@sourceforge.net Wed Jan 15 16:08:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 08:08:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-662701 ] sys.version[:3] gives incorrect version Message-ID: Bugs item #662701, was opened at 2003-01-05 17:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662701&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Pearu Peterson (pearu) Assigned to: Neil Schemenauer (nascheme) Summary: sys.version[:3] gives incorrect version Initial Comment: sys.version[:3] is used in several places [*] for Python version and in most cases it is OK. However, when Python is build/installed, say, with make all install VERSION=2.2.2 then sys.version[:3] does not represent Python version correctly anymore. For example, the path to Python Lib is then /lib/python2.2.2/ but e.g. distutils finds it as /lib/python2.2/ which obviously causes either an exception or a silent incorrect behaviour [**] when trying to use distutils. Note about fix: I don't have it but simply replacing sys.version[:3] with sys.version.split()[0] will not work. Best regards, Pearu [*] Running grep "sys.version\[:3\]" {*,*/*,*/*/*}.py in the Python Lib tree shows 8 matches for Python 2.2.2. [**] .. e.g. when one has other Python installed with VERSION=2.2 ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2003-01-15 16:08 Message: Logged In: YES user_id=35752 I've removed that section from the README. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-14 08:23 Message: Logged In: YES user_id=21627 Assigning to Neil, since he documented that feature. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-12 14:20 Message: Logged In: YES user_id=6380 I don't know who added that to README, but that was never inteded usage, so I'd suggest to undocument it. There's no support for such usage and I don't think it's needed. If you want to install a variant like that, use prefix=. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 09:54 Message: Logged In: YES user_id=21627 I see. What you have been doing is indeed documented as supported. Unfortunately, there is currently no way in which distutils could find out what VERSION is. So if this is intended to work, we need to expose VERSION somewhere. ---------------------------------------------------------------------- Comment By: Pearu Peterson (pearu) Date: 2003-01-05 23:40 Message: Logged In: YES user_id=88489 A note: according to Python README Installation section, make make altinstall VERSION=2.2.2 is "legal". From reading the generated Makefile, the above seems to be identical to 'make all install VERSION=2.2.2', but I haven't actually tried it out, though, so I might be wrong. If fixing this issue is too difficult, that's fine with me. One can always use --prefix= as a workaround when configuring Python. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-05 23:14 Message: Logged In: YES user_id=21627 I would suggest that 'make all install VERSION=2.2.2' is not supported, so this does not need to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662701&group_id=5470 From noreply@sourceforge.net Wed Jan 15 16:20:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 08:20:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-668302 ] a = b += c, a += b = c gives syntax error Message-ID: Bugs item #668302, was opened at 2003-01-14 20:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668302&group_id=5470 Category: Parser/Compiler Group: Python 2.2.1 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: a = b += c, a += b = c gives syntax error Initial Comment: The new augmented assignment operators apparently are not syntactically parallel to the assignment operator. I can't come up with an immediate reason why they shouldn't be, and I would like them to be. Python 2.2.1, Red Hat Linux 7.3 I looked in the release notes for Python 2.2.2, and didn't see anything about this. I also searched the open bug list for "assignment", and didn't see this mentioned. ---------------------------------------------------------------------- >Comment By: L. Peter Deutsch (lpd) Date: 2003-01-15 08:20 Message: Logged In: YES user_id=8861 I went back and read the language doc more carefully. I didn't realize that a = b = c is handled differently from C, Java, etc. in that after evaluating c, the assignments are done from left to right -- i.e., there isn't even a conceptual claim that this is like a = (b = c). So assignments in Python are even less like expressions than I had thought. Nevertheless, I find it really irksome that I can write a[big_compllicated_expression] += 1 but I can't write x = a[big_complicated_expression] += 1 and instead have to write a[big_complicated_expression] = x = a[big_complicated_expression] + 1 or a[big_complicated_expression] += 1 x = a[big_complicated_expression] or i = big_complicated_expression a[i] += 1 x = a[i] or i = big_complicated_expression a[i] = x = a[i] + 1 My suggestion was based on the belief that Python does multiple assignments like a = b = c right to left. Since it doesn't, I don't like the answer to "what would I like a = b += c to do". Nevertheless, I will answer the question. I would like a = b += c to be exactly equivalent to b += c a = b except that the targets are only evaluated once. I realize that this amounts to right-to-left assignment order, and since this is not consistent with the existing Python order for multiple assignments, I'm willing to withdraw the request -- for this reason, and this reason only. Frankly, having understood the situation better, I think augmented assignment is kind of warty. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-15 03:39 Message: Logged In: YES user_id=6656 What would you have a = b += c do? This has been discussed *somewhere* -- python-list, maybe? I'm strongly against changing this, fwiw. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668302&group_id=5470 From noreply@sourceforge.net Wed Jan 15 19:00:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 11:00:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-668662 ] Compiling C sources with absolute path bug Message-ID: Bugs item #668662, was opened at 2003-01-15 20:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668662&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Pearu Peterson (pearu) Assigned to: Nobody/Anonymous (nobody) Summary: Compiling C sources with absolute path bug Initial Comment: Py-2.3 distutils is broken in the following situation when building extension modules: If a file in C sources list is given with absolute path, say /path/to/foo.c then Py-2.3 distutils tries to create the corresponding object file to /path/to/foo.o (earlier versions would create it to, say, build/temp.linux-i686-2.2/foo.o). This causes problems when 1) an user does not have permissions to write to /path/to/, e.g. in multiuser systems 2) an user builds extension modules, say, using different compilers or flags. Then /path/to/foo.o will be in a way for subsequent builds. IMHO, distutils should not create any files outside the given build directory, unless explicitely specified using --build-temp. Fix: The problematic code seems to be in the method ccompiler.object_filenames in file distutils/ccompiler.py. As a fix, I suggest using the following object name for a C source if given with absolute path: ./build/temp.linux-i686-2.2/path/to/foo.o. This can be achived by inserting the following line just after the line `base, ext = os.path.splitext(src_name)`: base = base[os.path.isabs(base):] Pearu ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668662&group_id=5470 From noreply@sourceforge.net Wed Jan 15 19:03:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 11:03:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-668302 ] a = b += c, a += b = c gives syntax error Message-ID: Bugs item #668302, was opened at 2003-01-14 23:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668302&group_id=5470 Category: Parser/Compiler Group: Python 2.2.1 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: a = b += c, a += b = c gives syntax error Initial Comment: The new augmented assignment operators apparently are not syntactically parallel to the assignment operator. I can't come up with an immediate reason why they shouldn't be, and I would like them to be. Python 2.2.1, Red Hat Linux 7.3 I looked in the release notes for Python 2.2.2, and didn't see anything about this. I also searched the open bug list for "assignment", and didn't see this mentioned. ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2003-01-15 14:03 Message: Logged In: YES user_id=292741 The order of ops is not the only problem -- " b += c a = b except that the targets are only evaluated once. " This is the issue here - if 'b' is something like foo[bar] or foo.bar, then it has to be evaluated three times, once for reading it, once for writing it, and once for reading it again. This is true even if the += is done via a __iadd__ method. Remember, there is no concept of evaluating '&b' as in C, which then allows you to read and write b without having to evaluate &b again. In Python, b's methods must be used for all accesses (assuming b isn't just a variable) so you can't save this work. In C, you can write foo[e*4+f] += c a = foo[e*4+f] This is implicitly int *p = &foo[e*4+f]; *p = *p + c a = foo[e*4+f] and of course a = foo[e*4+f] += c is implicitly int *p = &foo[e*4+f]; *p = *p + c a = *p // compiler may be able to eliminate the read You can do sometimes do a similar thing explicitly in Python, as in Numeric: bslc = b[x:] # take slice of array starting at x bslc[0] += c # add c to b[x] a = bslc[0] # and copy to a without evaluating x twice The slice object, which acts a a view on the b array, is about the closest thing you can get to a dynamically computed lvalue, I think. The semantics of all this generally aren't what they seem, if you are coming from a C background. a += b may often change 'a' to a different object. a = 0 a += 1 here, a += 1 must change 'a' to a different object since the old '0' object is immutable. In other cases (e.g. 'a' is a list) it is guaranteed to leave 'a' the same object. foo[m] += x is thus equivalent to a = foo[m] anew = a.__iadd__(x) #a += x; # # (or anew = a+x if you can't __iadd__) # 'a is anew' may or may not be true now. # foo[m] = anew # put it back. <> ... whereas in C++ it would be simply operator += ( foo[m], x ) or, to be explicit, operator += ( * (foo+m), x ) ... where the '*' is not evaluated by the caller (since arg is a ref). As you can see, it's not practical to combine the attribute access with the += operation, as would be the case in C. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2003-01-15 11:20 Message: Logged In: YES user_id=8861 I went back and read the language doc more carefully. I didn't realize that a = b = c is handled differently from C, Java, etc. in that after evaluating c, the assignments are done from left to right -- i.e., there isn't even a conceptual claim that this is like a = (b = c). So assignments in Python are even less like expressions than I had thought. Nevertheless, I find it really irksome that I can write a[big_compllicated_expression] += 1 but I can't write x = a[big_complicated_expression] += 1 and instead have to write a[big_complicated_expression] = x = a[big_complicated_expression] + 1 or a[big_complicated_expression] += 1 x = a[big_complicated_expression] or i = big_complicated_expression a[i] += 1 x = a[i] or i = big_complicated_expression a[i] = x = a[i] + 1 My suggestion was based on the belief that Python does multiple assignments like a = b = c right to left. Since it doesn't, I don't like the answer to "what would I like a = b += c to do". Nevertheless, I will answer the question. I would like a = b += c to be exactly equivalent to b += c a = b except that the targets are only evaluated once. I realize that this amounts to right-to-left assignment order, and since this is not consistent with the existing Python order for multiple assignments, I'm willing to withdraw the request -- for this reason, and this reason only. Frankly, having understood the situation better, I think augmented assignment is kind of warty. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-15 06:39 Message: Logged In: YES user_id=6656 What would you have a = b += c do? This has been discussed *somewhere* -- python-list, maybe? I'm strongly against changing this, fwiw. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668302&group_id=5470 From noreply@sourceforge.net Wed Jan 15 19:23:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 11:23:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-668662 ] Compiling C sources with absolute path bug Message-ID: Bugs item #668662, was opened at 2003-01-15 18:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668662&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Pearu Peterson (pearu) >Assigned to: A.M. Kuchling (akuchling) Summary: Compiling C sources with absolute path bug Initial Comment: Py-2.3 distutils is broken in the following situation when building extension modules: If a file in C sources list is given with absolute path, say /path/to/foo.c then Py-2.3 distutils tries to create the corresponding object file to /path/to/foo.o (earlier versions would create it to, say, build/temp.linux-i686-2.2/foo.o). This causes problems when 1) an user does not have permissions to write to /path/to/, e.g. in multiuser systems 2) an user builds extension modules, say, using different compilers or flags. Then /path/to/foo.o will be in a way for subsequent builds. IMHO, distutils should not create any files outside the given build directory, unless explicitely specified using --build-temp. Fix: The problematic code seems to be in the method ccompiler.object_filenames in file distutils/ccompiler.py. As a fix, I suggest using the following object name for a C source if given with absolute path: ./build/temp.linux-i686-2.2/path/to/foo.o. This can be achived by inserting the following line just after the line `base, ext = os.path.splitext(src_name)`: base = base[os.path.isabs(base):] Pearu ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-01-15 19:23 Message: Logged In: YES user_id=6656 I'm a little boggled by how distutils would get an absolute path, but I'm going to assign this to amk anyway :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668662&group_id=5470 From noreply@sourceforge.net Wed Jan 15 19:40:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 11:40:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-668302 ] a = b += c, a += b = c gives syntax error Message-ID: Bugs item #668302, was opened at 2003-01-14 20:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668302&group_id=5470 Category: Parser/Compiler Group: Python 2.2.1 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: a = b += c, a += b = c gives syntax error Initial Comment: The new augmented assignment operators apparently are not syntactically parallel to the assignment operator. I can't come up with an immediate reason why they shouldn't be, and I would like them to be. Python 2.2.1, Red Hat Linux 7.3 I looked in the release notes for Python 2.2.2, and didn't see anything about this. I also searched the open bug list for "assignment", and didn't see this mentioned. ---------------------------------------------------------------------- >Comment By: L. Peter Deutsch (lpd) Date: 2003-01-15 11:40 Message: Logged In: YES user_id=8861 For the augmented assignment b += c, I believe b is *not* evaluated twice if it has an __iadd__ method. In fact, I believe it isn't evaluated twice if it doesn't have such a method. The *object denoted by the expression b* may be *accessed* twice (that is, two methods may be invoked) if it doesn't have an __iadd__ method, but the *expression b itself* is not *evaluated* twice. I believe I understand this distinction properly, and I stand by my previous answer to the question. However, because of the order issue, I don't think a change should be made. OTOH, it might be worth adding a note to the Python documentation for augmented assignment to point out that unlike ordinary Python assignment, and unlike assignment in other languages that have both kinds (such as C, C++, and Java), an augmented assignment must stand alone (cannot be cascaded with other assignments). ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2003-01-15 11:03 Message: Logged In: YES user_id=292741 The order of ops is not the only problem -- " b += c a = b except that the targets are only evaluated once. " This is the issue here - if 'b' is something like foo[bar] or foo.bar, then it has to be evaluated three times, once for reading it, once for writing it, and once for reading it again. This is true even if the += is done via a __iadd__ method. Remember, there is no concept of evaluating '&b' as in C, which then allows you to read and write b without having to evaluate &b again. In Python, b's methods must be used for all accesses (assuming b isn't just a variable) so you can't save this work. In C, you can write foo[e*4+f] += c a = foo[e*4+f] This is implicitly int *p = &foo[e*4+f]; *p = *p + c a = foo[e*4+f] and of course a = foo[e*4+f] += c is implicitly int *p = &foo[e*4+f]; *p = *p + c a = *p // compiler may be able to eliminate the read You can do sometimes do a similar thing explicitly in Python, as in Numeric: bslc = b[x:] # take slice of array starting at x bslc[0] += c # add c to b[x] a = bslc[0] # and copy to a without evaluating x twice The slice object, which acts a a view on the b array, is about the closest thing you can get to a dynamically computed lvalue, I think. The semantics of all this generally aren't what they seem, if you are coming from a C background. a += b may often change 'a' to a different object. a = 0 a += 1 here, a += 1 must change 'a' to a different object since the old '0' object is immutable. In other cases (e.g. 'a' is a list) it is guaranteed to leave 'a' the same object. foo[m] += x is thus equivalent to a = foo[m] anew = a.__iadd__(x) #a += x; # # (or anew = a+x if you can't __iadd__) # 'a is anew' may or may not be true now. # foo[m] = anew # put it back. <> ... whereas in C++ it would be simply operator += ( foo[m], x ) or, to be explicit, operator += ( * (foo+m), x ) ... where the '*' is not evaluated by the caller (since arg is a ref). As you can see, it's not practical to combine the attribute access with the += operation, as would be the case in C. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2003-01-15 08:20 Message: Logged In: YES user_id=8861 I went back and read the language doc more carefully. I didn't realize that a = b = c is handled differently from C, Java, etc. in that after evaluating c, the assignments are done from left to right -- i.e., there isn't even a conceptual claim that this is like a = (b = c). So assignments in Python are even less like expressions than I had thought. Nevertheless, I find it really irksome that I can write a[big_compllicated_expression] += 1 but I can't write x = a[big_complicated_expression] += 1 and instead have to write a[big_complicated_expression] = x = a[big_complicated_expression] + 1 or a[big_complicated_expression] += 1 x = a[big_complicated_expression] or i = big_complicated_expression a[i] += 1 x = a[i] or i = big_complicated_expression a[i] = x = a[i] + 1 My suggestion was based on the belief that Python does multiple assignments like a = b = c right to left. Since it doesn't, I don't like the answer to "what would I like a = b += c to do". Nevertheless, I will answer the question. I would like a = b += c to be exactly equivalent to b += c a = b except that the targets are only evaluated once. I realize that this amounts to right-to-left assignment order, and since this is not consistent with the existing Python order for multiple assignments, I'm willing to withdraw the request -- for this reason, and this reason only. Frankly, having understood the situation better, I think augmented assignment is kind of warty. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-15 03:39 Message: Logged In: YES user_id=6656 What would you have a = b += c do? This has been discussed *somewhere* -- python-list, maybe? I'm strongly against changing this, fwiw. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668302&group_id=5470 From noreply@sourceforge.net Wed Jan 15 19:48:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 11:48:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-668662 ] Compiling C sources with absolute path bug Message-ID: Bugs item #668662, was opened at 2003-01-15 20:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668662&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Pearu Peterson (pearu) Assigned to: A.M. Kuchling (akuchling) Summary: Compiling C sources with absolute path bug Initial Comment: Py-2.3 distutils is broken in the following situation when building extension modules: If a file in C sources list is given with absolute path, say /path/to/foo.c then Py-2.3 distutils tries to create the corresponding object file to /path/to/foo.o (earlier versions would create it to, say, build/temp.linux-i686-2.2/foo.o). This causes problems when 1) an user does not have permissions to write to /path/to/, e.g. in multiuser systems 2) an user builds extension modules, say, using different compilers or flags. Then /path/to/foo.o will be in a way for subsequent builds. IMHO, distutils should not create any files outside the given build directory, unless explicitely specified using --build-temp. Fix: The problematic code seems to be in the method ccompiler.object_filenames in file distutils/ccompiler.py. As a fix, I suggest using the following object name for a C source if given with absolute path: ./build/temp.linux-i686-2.2/path/to/foo.o. This can be achived by inserting the following line just after the line `base, ext = os.path.splitext(src_name)`: base = base[os.path.isabs(base):] Pearu ---------------------------------------------------------------------- >Comment By: Pearu Peterson (pearu) Date: 2003-01-15 21:48 Message: Logged In: YES user_id=88489 FYI, distutils does not make this absolute path, but one can specify absolute paths in setup.py files, for instance. Also, tools that create extension modules (e.g. f2py), may ship with C sources that are installed as data files and compiled for each generated extension module separately (possibly with different compilers and flags so that pre-compilation of such sources would not be an option). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-15 21:23 Message: Logged In: YES user_id=6656 I'm a little boggled by how distutils would get an absolute path, but I'm going to assign this to amk anyway :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668662&group_id=5470 From noreply@sourceforge.net Wed Jan 15 20:19:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 12:19:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-668708 ] Py_NewInterpreter() doesn't work Message-ID: Bugs item #668708, was opened at 2003-01-15 21:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668708&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Geert Jansen (geertj) Assigned to: Nobody/Anonymous (nobody) Summary: Py_NewInterpreter() doesn't work Initial Comment: Hello, mod_python doesn't seem to work with Python 2.3a1. After some debugging, it seems the culprit is Py_NewInterpreter(). The following C program works with Python 2.2 but gives an error with Python 2.3: #include int main() { PyThreadState *tstate; Py_Initialize(); tstate = Py_NewInterpreter(); return 0; } The relevant part of this program's output: geertj@cristina:~$ PYTHONVERBOSE=1 ./a.out # installing zipimport hook import zipimport # builtin [...] import __builtin__ # previously loaded (__builtin__) import sys # previously loaded (sys) 'import site' failed; traceback: ImportError: No module named site It seems that Python is unable to find the module "site". Greetings, Geert Jansen ---------------------------------------------------------------------- >Comment By: Geert Jansen (geertj) Date: 2003-01-15 21:19 Message: Logged In: YES user_id=537938 I forgot to mention that the Python version used is 2.3a1. Geert Jansen ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668708&group_id=5470 From noreply@sourceforge.net Wed Jan 15 20:17:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 12:17:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-668708 ] Py_NewInterpreter() doesn't work Message-ID: Bugs item #668708, was opened at 2003-01-15 21:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668708&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Geert Jansen (geertj) Assigned to: Nobody/Anonymous (nobody) Summary: Py_NewInterpreter() doesn't work Initial Comment: Hello, mod_python doesn't seem to work with Python 2.3a1. After some debugging, it seems the culprit is Py_NewInterpreter(). The following C program works with Python 2.2 but gives an error with Python 2.3: #include int main() { PyThreadState *tstate; Py_Initialize(); tstate = Py_NewInterpreter(); return 0; } The relevant part of this program's output: geertj@cristina:~$ PYTHONVERBOSE=1 ./a.out # installing zipimport hook import zipimport # builtin [...] import __builtin__ # previously loaded (__builtin__) import sys # previously loaded (sys) 'import site' failed; traceback: ImportError: No module named site It seems that Python is unable to find the module "site". Greetings, Geert Jansen ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668708&group_id=5470 From noreply@sourceforge.net Wed Jan 15 20:37:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 12:37:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-668433 ] Abort with "negative ref count" Message-ID: Bugs item #668433, was opened at 2003-01-15 07:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668433&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) >Summary: Abort with "negative ref count" Initial Comment: Python 2.3a1 and the current CVS version abort with the following error message when executing the attached test script: Fatal Python error: D:\Python-current\dist\src\Objects\descrobject.c:10 object at 007C3208 has negative ref count -1 This happens only in the debug build, both on Linux (with configure --enable-unicode=ucs4 --with-pydebug and 2.3a1) and on Windows (with the debug build and current CVS). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-15 15:37 Message: Logged In: YES user_id=33168 I'm not running w/--enable-unicode=ucs4, but I still get the problem. I've simplified the test, but only a little so far. The problem did not affect 2.2.2, only 2.3. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-15 10:04 Message: Logged In: YES user_id=33168 Walter, there's no file attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668433&group_id=5470 From noreply@sourceforge.net Wed Jan 15 21:37:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 13:37:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-668433 ] Abort with "negative ref count" Message-ID: Bugs item #668433, was opened at 2003-01-15 07:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668433&group_id=5470 >Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Guido van Rossum (gvanrossum) >Summary: Abort with "negative ref count" Initial Comment: Python 2.3a1 and the current CVS version abort with the following error message when executing the attached test script: Fatal Python error: D:\Python-current\dist\src\Objects\descrobject.c:10 object at 007C3208 has negative ref count -1 This happens only in the debug build, both on Linux (with configure --enable-unicode=ucs4 --with-pydebug and 2.3a1) and on Windows (with the debug build and current CVS). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-15 16:37 Message: Logged In: YES user_id=33168 8/6/2002 works without complaints, 8/8/2002 breaks, 8/7/2002 breaks with a different error message: Objects/typeobject.c:466: subtype_dealloc: Assertion `g->gc.gc_refs != (-2)' failed. All dates are American, ie, August, 6-8. The change corresponds to Object/typeobject.c: 8/6 - 2.165 works 8/7 - 2.166 assertion listed above 8/8 - 2.167 assertion in bug report (current) Guido made all the changes, assigning to him. :-) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-15 15:37 Message: Logged In: YES user_id=33168 I'm not running w/--enable-unicode=ucs4, but I still get the problem. I've simplified the test, but only a little so far. The problem did not affect 2.2.2, only 2.3. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-15 10:04 Message: Logged In: YES user_id=33168 Walter, there's no file attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668433&group_id=5470 From noreply@sourceforge.net Wed Jan 15 21:52:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 13:52:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-668433 ] Abort with "negative ref count" Message-ID: Bugs item #668433, was opened at 2003-01-15 07:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668433&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) >Summary: Abort with "negative ref count" Initial Comment: Python 2.3a1 and the current CVS version abort with the following error message when executing the attached test script: Fatal Python error: D:\Python-current\dist\src\Objects\descrobject.c:10 object at 007C3208 has negative ref count -1 This happens only in the debug build, both on Linux (with configure --enable-unicode=ucs4 --with-pydebug and 2.3a1) and on Windows (with the debug build and current CVS). ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-15 16:52 Message: Logged In: YES user_id=6380 Bah. Trashcan code. :-( OK, I'll look at it. When I have time. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-15 16:37 Message: Logged In: YES user_id=33168 8/6/2002 works without complaints, 8/8/2002 breaks, 8/7/2002 breaks with a different error message: Objects/typeobject.c:466: subtype_dealloc: Assertion `g->gc.gc_refs != (-2)' failed. All dates are American, ie, August, 6-8. The change corresponds to Object/typeobject.c: 8/6 - 2.165 works 8/7 - 2.166 assertion listed above 8/8 - 2.167 assertion in bug report (current) Guido made all the changes, assigning to him. :-) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-15 15:37 Message: Logged In: YES user_id=33168 I'm not running w/--enable-unicode=ucs4, but I still get the problem. I've simplified the test, but only a little so far. The problem did not affect 2.2.2, only 2.3. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-15 10:04 Message: Logged In: YES user_id=33168 Walter, there's no file attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668433&group_id=5470 From noreply@sourceforge.net Wed Jan 15 22:07:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 14:07:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-668302 ] a = b += c, a += b = c gives syntax error Message-ID: Bugs item #668302, was opened at 2003-01-14 23:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668302&group_id=5470 Category: Parser/Compiler Group: Python 2.2.1 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: a = b += c, a += b = c gives syntax error Initial Comment: The new augmented assignment operators apparently are not syntactically parallel to the assignment operator. I can't come up with an immediate reason why they shouldn't be, and I would like them to be. Python 2.2.1, Red Hat Linux 7.3 I looked in the release notes for Python 2.2.2, and didn't see anything about this. I also searched the open bug list for "assignment", and didn't see this mentioned. ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2003-01-15 17:07 Message: Logged In: YES user_id=292741 I was using 'b' symbolically - if 'b' is something like foo.bar or foo[bar], and you apply += to it, then python does a getattr/getitem to it, applies += to the result, and then stores the result of the += back to foo using setattr or setitem. This has nothing to do with whether the result of the 'get' operation has __iadd__ or not; the result of the += still needs to be stored back, which is a trivial operation when b is a local variable, but may be more involved when setattr/setitem is involved. If 'b' is foo[bar**2], then the bar**2 gets done only once but two methods get called on foo. I guess it depends on exactly what we mean by 'evaluated twice', certainly += is handy when the subscript expression is complex def a(): foo.bar += 3 dis.dis(a) # line-nos deleted 6 LOAD_GLOBAL 0 (foo) 9 DUP_TOP # dup foo ref for store_attr later 10 LOAD_ATTR 1 (bar) # getattr(foo,'bar') 13 LOAD_CONST 1 (3) 16 INPLACE_ADD # result of this to be stored 17 ROT_TWO 18 STORE_ATTR 1 (bar) #setattr(foo,'bar', ...) 21 LOAD_CONST 0 (None) 24 RETURN_VALUE Hey, suppose you have this in Numeric: arr[a:b,c:d,::-1] += something as discussed, this involves constructing an index (here, a sequence of slice objects) , doing a getitem (result is a sliced array view), doing a += on that, and then doing a setitem with the same slice sequence. The last operation is redundant if the __iadd__ is implemented, since the result is already in the original array. I don't know how Numeric handles this, but it does implement __iadd__. So the store following the += would be redundant, since it would involve copying the same data back over itself. The Numeric implementation could check for this, however, it could still be a lot of work to figure out that it is the case. It seems to me there should be a way to avoid this extra work... the special store-if-not-identical function mentioned below could be one way, but may be fraught wth peril, since += could change an object in ways requiring it to be 'put back' into another container. anyway, enough for now.. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2003-01-15 14:40 Message: Logged In: YES user_id=8861 For the augmented assignment b += c, I believe b is *not* evaluated twice if it has an __iadd__ method. In fact, I believe it isn't evaluated twice if it doesn't have such a method. The *object denoted by the expression b* may be *accessed* twice (that is, two methods may be invoked) if it doesn't have an __iadd__ method, but the *expression b itself* is not *evaluated* twice. I believe I understand this distinction properly, and I stand by my previous answer to the question. However, because of the order issue, I don't think a change should be made. OTOH, it might be worth adding a note to the Python documentation for augmented assignment to point out that unlike ordinary Python assignment, and unlike assignment in other languages that have both kinds (such as C, C++, and Java), an augmented assignment must stand alone (cannot be cascaded with other assignments). ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2003-01-15 14:03 Message: Logged In: YES user_id=292741 The order of ops is not the only problem -- " b += c a = b except that the targets are only evaluated once. " This is the issue here - if 'b' is something like foo[bar] or foo.bar, then it has to be evaluated three times, once for reading it, once for writing it, and once for reading it again. This is true even if the += is done via a __iadd__ method. Remember, there is no concept of evaluating '&b' as in C, which then allows you to read and write b without having to evaluate &b again. In Python, b's methods must be used for all accesses (assuming b isn't just a variable) so you can't save this work. In C, you can write foo[e*4+f] += c a = foo[e*4+f] This is implicitly int *p = &foo[e*4+f]; *p = *p + c a = foo[e*4+f] and of course a = foo[e*4+f] += c is implicitly int *p = &foo[e*4+f]; *p = *p + c a = *p // compiler may be able to eliminate the read You can do sometimes do a similar thing explicitly in Python, as in Numeric: bslc = b[x:] # take slice of array starting at x bslc[0] += c # add c to b[x] a = bslc[0] # and copy to a without evaluating x twice The slice object, which acts a a view on the b array, is about the closest thing you can get to a dynamically computed lvalue, I think. The semantics of all this generally aren't what they seem, if you are coming from a C background. a += b may often change 'a' to a different object. a = 0 a += 1 here, a += 1 must change 'a' to a different object since the old '0' object is immutable. In other cases (e.g. 'a' is a list) it is guaranteed to leave 'a' the same object. foo[m] += x is thus equivalent to a = foo[m] anew = a.__iadd__(x) #a += x; # # (or anew = a+x if you can't __iadd__) # 'a is anew' may or may not be true now. # foo[m] = anew # put it back. <> ... whereas in C++ it would be simply operator += ( foo[m], x ) or, to be explicit, operator += ( * (foo+m), x ) ... where the '*' is not evaluated by the caller (since arg is a ref). As you can see, it's not practical to combine the attribute access with the += operation, as would be the case in C. ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2003-01-15 11:20 Message: Logged In: YES user_id=8861 I went back and read the language doc more carefully. I didn't realize that a = b = c is handled differently from C, Java, etc. in that after evaluating c, the assignments are done from left to right -- i.e., there isn't even a conceptual claim that this is like a = (b = c). So assignments in Python are even less like expressions than I had thought. Nevertheless, I find it really irksome that I can write a[big_compllicated_expression] += 1 but I can't write x = a[big_complicated_expression] += 1 and instead have to write a[big_complicated_expression] = x = a[big_complicated_expression] + 1 or a[big_complicated_expression] += 1 x = a[big_complicated_expression] or i = big_complicated_expression a[i] += 1 x = a[i] or i = big_complicated_expression a[i] = x = a[i] + 1 My suggestion was based on the belief that Python does multiple assignments like a = b = c right to left. Since it doesn't, I don't like the answer to "what would I like a = b += c to do". Nevertheless, I will answer the question. I would like a = b += c to be exactly equivalent to b += c a = b except that the targets are only evaluated once. I realize that this amounts to right-to-left assignment order, and since this is not consistent with the existing Python order for multiple assignments, I'm willing to withdraw the request -- for this reason, and this reason only. Frankly, having understood the situation better, I think augmented assignment is kind of warty. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-15 06:39 Message: Logged In: YES user_id=6656 What would you have a = b += c do? This has been discussed *somewhere* -- python-list, maybe? I'm strongly against changing this, fwiw. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668302&group_id=5470 From noreply@sourceforge.net Wed Jan 15 22:48:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 14:48:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-661762 ] macpath.py missing ismount splitunc Message-ID: Bugs item #661762, was opened at 2003-01-03 19:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661762&group_id=5470 Category: Macintosh Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Jack Jansen (jackjansen) Summary: macpath.py missing ismount splitunc Initial Comment: Jack, I noticed that macpath is missing an ismount() function and reference in __all__. I'm not sure it can be implemented. ismount() exists in all 3 other *path files: Lib/ntpath.py Lib/os2emxpath.py Lib/posixpath.py. splitunc() is also missing, but it is also missing from posixpath. I'm not sure if it's appropriate or not. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-01-15 23:48 Message: Logged In: YES user_id=45365 Fixed in macpath.py rev 1.44 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661762&group_id=5470 From noreply@sourceforge.net Wed Jan 15 22:59:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 14:59:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-571845 ] test_import crashes/hangs for MacPython Message-ID: Bugs item #571845, was opened at 2002-06-20 23:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=571845&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: test_import crashes/hangs for MacPython Initial Comment: Test_import breaks for MacPython after the patches for bug #561858 were committed. On Mac OS 9 the test runs into an out-of-memory situation (after gobbling up 23MB), on Mac OS X it hangs (or, at least, it doesn't respond for 15 minutes). I think this is unrelated to the original bug, so I'm putting this in a separate report. For now I am disabling the specific test when running under MacPython, but this should be fixed eventually. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-01-15 23:59 Message: Logged In: YES user_id=45365 This should have been closed when test_import.py 1.16 was checked in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-08-11 17:38 Message: Logged In: YES user_id=33168 Jack, I wanted to make sure this was forgotten. Has this been fixed with the other memory allocation changes? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=571845&group_id=5470 From noreply@sourceforge.net Wed Jan 15 23:08:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 15:08:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-668787 ] test_logging fails if setlocale() not supported Message-ID: Bugs item #668787, was opened at 2003-01-16 00:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668787&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Neal Norwitz (nnorwitz) Summary: test_logging fails if setlocale() not supported Initial Comment: Test_logging fails if setlocale doesn't work (such as on MacOSX). This strikes me as a bit over the top. BTW: on MacOSX calling setlocale() results in locale.Error being raised. There is a try/except for ValueError, but I'm not sure whether I can simply add locale.Error to the expected exceptions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668787&group_id=5470 From noreply@sourceforge.net Wed Jan 15 23:20:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 15:20:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-668787 ] test_logging fails if setlocale() not supported Message-ID: Bugs item #668787, was opened at 2003-01-15 18:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668787&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) >Assigned to: Jack Jansen (jackjansen) Summary: test_logging fails if setlocale() not supported Initial Comment: Test_logging fails if setlocale doesn't work (such as on MacOSX). This strikes me as a bit over the top. BTW: on MacOSX calling setlocale() results in locale.Error being raised. There is a try/except for ValueError, but I'm not sure whether I can simply add locale.Error to the expected exceptions. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-15 18:20 Message: Logged In: YES user_id=33168 I think you can just add the expected exceptions. So the clause would be: except (ValueError, locale.Error): I'm not sure why setting locale was necessary. If the test runs after the change, feel free to check in the fix. It seems more robust that way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668787&group_id=5470 From noreply@sourceforge.net Wed Jan 15 23:03:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 15:03:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-661354 ] test_strptime fails on the Mac Message-ID: Bugs item #661354, was opened at 2003-01-02 23:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: test_strptime fails on the Mac Initial Comment: test_strptime fails for MacPython-OS9. It appears to be an error in the test itself, but it could be this error is triggered only on the Mac (because it doesn't have a builtin strptime() function but uses the pure Python strptime implementation). Here is the first stacktrace from the test (a lot of very similar ones follow): Traceback (most recent call last): File "Moes:SWdev:Jack:MacPython:Lib:test:test_strptime.py", line 183, in test_compile compiled = self.time_re.compile("%%%s"% directive) File "Moes:SWdev:Jack:MacPython:Lib:_strptime.py", line 394, in compile return re_compile(self.pattern(format), IGNORECASE) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 179, in compile return _compile(pattern, flags) File "Moes:SWdev:Jack:MacPython:Lib:sre.py", line 229, in _compile raise error, v # invalid expression error: redefinition of group name 'Z' as group 2; was group 1 ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-01-16 00:03 Message: Logged In: YES user_id=45365 Fix checked in as _strptime.py rev 1.9. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-04 09:34 Message: Logged In: YES user_id=357491 Patch #662053 fixes _strptime.py to handle any possibility of a locale not knowing anything about a certain thing (timezone, AM/PM as in Swedish, etc.). Also added two tests to the test suite. Left unassigned and said it was for the LIbrary and not MacOS specifically since it is a general fix. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-01-04 03:26 Message: Logged In: YES user_id=45365 Nou, dank je wel... :-) ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-01-04 01:01 Message: Logged In: YES user_id=45365 Close, but not an empty tuple but a tuple of empty strings: >>> import time >>> time.tzname ('', '') >>> time.strftime("%Z") '' >>> ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-03 23:52 Message: Logged In: YES user_id=357491 Congrats, Jack, you have found another edge case I didn't expect; a platform that doesn't know its own possible timezones. =) This means that ``time.tzname`` comes out with an tuple with no values. Does ``time.strftime("%Z")`` output anything? That regex will match absolutely anything. This would explain why there are ending up more than one Z group in the regex (probably happening when creating an LC_* value). So, I will write up a patch later today that will check for this special edge case of a possible regex that will match anything and make sure it doesn't output anything (basically make the Z regex be the empty string). _strptime already leaves the timezone value at -1 if it can't determine what timezone it is so at least that doesn't change anything. I will also add a test to the suite. Oh,, and a question for you, Guido. Would you prefer it if I removed the ``__author__`` and ``__email__`` variables and just added a small comment in the doc string for author and contact info? Or should I just leave them? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-01-03 17:10 Message: Logged In: YES user_id=45365 No two Z groups, but I do get something different than you, with no timezone names: >>> import _strptime >>> _strptime.TimeRE().compile("%Z").pattern '(?#)(?P||)' I've attached the whole output of test_strptime. Enjoy! (hihi:-) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-03 01:39 Message: Logged In: YES user_id=357491 And for Jack's own personal knowledge, test_strptime is only run against _strptime.py. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-03 01:38 Message: Logged In: YES user_id=357491 OK, with Tim's info I am starting to wonder if this isn't some how an OS 9-specific thing. To make sure, Jack, can you run this code?:: >>> import _strptime >>> _strptime.TimeRE().compile("%Z").pattern The ``TimeRE`` class is what handles the creation of the final regex to use for parsing the input string. the ``.compile()`` method takes the directive format string and outputs the regex pattern object. The above code should spit out a string similar to ``(?#)(?PPST|PDT|)`` (and yes, that emptiness after the last pipe is expected; have to handle chance that no timezone is actually in the input string since it *could* be there). If this has two Z groups, then we have found our problem. If not, then I am goiing to need basically all the tracebacks to figure this one out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-03 01:01 Message: Logged In: YES user_id=31435 FYI, it also passes on Windows (98SE and 2K). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-03 00:54 Message: Logged In: YES user_id=357491 As for the bug, obviously a regex is being created where the regex group Z is being specified twice. I will take a look, but I just ran the tests and I am having no problems on OS X 10.2.3. I have some ideas on where this trouble could be produced, though, so I will see if I can find a problem or come up with some code Jack can run to try to help figure out the problem. Are the "very similar ones" that follow this stack trace all from the same line in test_strptime, or all from the same line in _strptime? In other words, are they all the same error being caused by the same test or the same chunk of code in _strptime? Or am I so unlucky that it is just the same redefinition error but with everything else different every time? Oh, and one quick syntax thing; line 394 in test_strptime.py has a string where the ``%`` operator has no space between it and the string being worked on. I know what a stickler you are, Guido, so I thought you should know . ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 23:44 Message: Logged In: YES user_id=6380 BTW, there's an #undef HAVE_STRPTIME in timemodule.c, so that *everybody* will *always* be using the Python implementation. The test passes for me on Linux, FWIW. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 23:40 Message: Logged In: YES user_id=6380 I've forwarded this to Brett Cannon -- he's the author, maybe he understands what's going on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661354&group_id=5470 From noreply@sourceforge.net Wed Jan 15 23:46:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 15:46:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-668787 ] test_logging fails if setlocale() not supported Message-ID: Bugs item #668787, was opened at 2003-01-16 00:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668787&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: test_logging fails if setlocale() not supported Initial Comment: Test_logging fails if setlocale doesn't work (such as on MacOSX). This strikes me as a bit over the top. BTW: on MacOSX calling setlocale() results in locale.Error being raised. There is a try/except for ValueError, but I'm not sure whether I can simply add locale.Error to the expected exceptions. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-01-16 00:46 Message: Logged In: YES user_id=45365 Ok, fixed in rev 1.3 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-16 00:20 Message: Logged In: YES user_id=33168 I think you can just add the expected exceptions. So the clause would be: except (ValueError, locale.Error): I'm not sure why setting locale was necessary. If the test runs after the change, feel free to check in the fix. It seems more robust that way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668787&group_id=5470 From noreply@sourceforge.net Wed Jan 15 23:53:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 15:53:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-668787 ] test_logging fails if setlocale() not supported Message-ID: Bugs item #668787, was opened at 2003-01-16 00:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668787&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: test_logging fails if setlocale() not supported Initial Comment: Test_logging fails if setlocale doesn't work (such as on MacOSX). This strikes me as a bit over the top. BTW: on MacOSX calling setlocale() results in locale.Error being raised. There is a try/except for ValueError, but I'm not sure whether I can simply add locale.Error to the expected exceptions. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-01-16 00:46 Message: Logged In: YES user_id=45365 Ok, fixed in rev 1.3 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-16 00:20 Message: Logged In: YES user_id=33168 I think you can just add the expected exceptions. So the clause would be: except (ValueError, locale.Error): I'm not sure why setting locale was necessary. If the test runs after the change, feel free to check in the fix. It seems more robust that way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668787&group_id=5470 From noreply@sourceforge.net Wed Jan 15 23:56:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 15:56:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-602398 ] Jaguar "install" does not overwrite Message-ID: Bugs item #602398, was opened at 2002-08-30 14:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602398&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) >Summary: Jaguar "install" does not overwrite Initial Comment: Jaguar has a new version of the "install" program (taken from 4.4BSD, according to the man page) which uses copy in stead of move to install stuff. This makes it fail when you re-install Python. An obvious fix is to use install-sh, but this has the disadvantage of being dead slow. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-01-16 00:56 Message: Logged In: YES user_id=45365 I can't repeat this anymore, either it's been fixed or it was a mistake in the first place. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602398&group_id=5470 From noreply@sourceforge.net Thu Jan 16 00:08:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 16:08:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-644246 ] file URLs mis-handled by webbrowser Message-ID: Bugs item #644246, was opened at 2002-11-26 18:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=644246&group_id=5470 Category: Macintosh >Group: 3rd Party >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Jack Jansen (jackjansen) Summary: file URLs mis-handled by webbrowser Initial Comment: file:/... URLs are not handled correctly by the webbrowser module on MacOS X (MacOS X 10.2.1, Python 2.2.2). There are two problems: - The file is opened by its creator (which might be a text editor), rather than the user's default web browser. - Even if the creator happens to be a web browser, any #anchor portion of the URL is ignored. This may be a MacOS X bug. The applescript "open location" also exhibits this behavior, as does the command-line "open -a icab file:/..." (where icab is just one example browser I've tried). -- Russell ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-01-16 01:08 Message: Logged In: YES user_id=45365 This is indeed an Apple bug, and there is no way in which we can fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=644246&group_id=5470 From noreply@sourceforge.net Thu Jan 16 00:10:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 16:10:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-608584 ] gethostbyname("LOCALHOST") fails Message-ID: Bugs item #608584, was opened at 2002-09-12 22:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=608584&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) >Summary: gethostbyname("LOCALHOST") fails Initial Comment: On MacOSX 10.1.5 a gethostbyname("LOCALHOST") fails. Other lookups are correctly case-insensitive. This is probably an Apple bug, but even then I need to test it on 10.2 and report it if it's still there. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-01-16 01:10 Message: Logged In: YES user_id=45365 Fixed in MacOSX 10.2, apparently. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=608584&group_id=5470 From noreply@sourceforge.net Thu Jan 16 05:05:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 21:05:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-666444 ] 'help' makes linefeed only under Win32 Message-ID: Bugs item #666444, was opened at 2003-01-11 20:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666444&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: 'help' makes linefeed only under Win32 Initial Comment: The 'help' command, under a win32 console app, separates lines with \n instead of \r\n as it has in the past, making its output a little hard to follow. Possibly an unintended side effect of the 'universal newline' addition? Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC v.1200 32 bit (Intel)] on win32 (windows 98) ---------------------------------------------------------------------- >Comment By: Gregory Smith (gregsmith) Date: 2003-01-16 00:05 Message: Logged In: YES user_id=292741 Tracked this down to a change in pydoc.py: ---------------- 2.2.2 ------------------------- def tempfilepager(text, cmd): import tempfile filename = tempfile.mktemp() file = open(filename, 'w') file.write(text) file.close() ------------------2.3 ------------------------- def tempfilepager(text, cmd): import tempfile (fd, filename) = tempfile.mkstemp() file = os.fdopen(fd, 'w') file.write(text) file.close() ------------------------------------------------ It seems the use of fdopen means that \n's don't get changed to \r\n when the file is written, even though 'w' is used. Whether this should be fixed by modding this code, or whether this is a fdopen bug, I don't know. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666444&group_id=5470 From noreply@sourceforge.net Thu Jan 16 05:07:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 21:07:28 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-668905 ] logging module documentation Message-ID: Feature Requests item #668905, was opened at 2003-01-16 16:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=668905&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: logging module documentation Initial Comment: I believe the logging module documentation needs to give an example of how to simply log to a file. The following example snippet could be appropriate: import logging logger = logging.getLogger('myapp') hdlr = FileHandler('/var/myapp/debug.log') hdlr.setFormatter(Formatter('%(asctime)s %(level)s %(message)s')) logger.addHandler(hdlr) logger.setLevel(DEBUG) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=668905&group_id=5470 From noreply@sourceforge.net Thu Jan 16 05:11:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 21:11:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-668906 ] class browser raises AttributeError Message-ID: Bugs item #668906, was opened at 2003-01-16 00:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668906&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: class browser raises AttributeError Initial Comment: On win32 (specifically win98) with 3.2: (1) start IDLE (2) open ..../Lib/copy.py (or anything, really) (3) File>Class Browser Exception in Tkinter callback Traceback (most recent call last): File "C:\BIN\PYTHON23\lib\lib-tk\Tkinter.py", line 1306, in __call__ return apply(self.func, args) File "C:\BIN\PYTHON23\Tools\idle\EditorWindow.py", line 385, in open_class_browser ClassBrowser.ClassBrowser(self.flist, base, [head]) File "C:\BIN\PYTHON23\Tools\idle\ClassBrowser.py", line 28, in __init__ self.init(flist) File "C:\BIN\PYTHON23\Tools\idle\ClassBrowser.py", line 50, in init node.expand() File "C:\BIN\PYTHON23\Tools\idle\TreeWidget.py", line 131, in expand self.update() File "C:\BIN\PYTHON23\Tools\idle\TreeWidget.py", line 170, in update self.draw(7, 2) File "C:\BIN\PYTHON23\Tools\idle\TreeWidget.py", line 184, in draw sublist = self.item._GetSubList() File "C:\BIN\PYTHON23\Tools\idle\TreeWidget.py", line 337, in _GetSubList sublist = self.GetSubList() File "C:\BIN\PYTHON23\Tools\idle\ClassBrowser.py", line 72, in GetSubList for name in self.listclasses(): File "C:\BIN\PYTHON23\Tools\idle\ClassBrowser.py", line 101, in listclasses if cl.super: AttributeError: Function instance has no attribute 'super' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668906&group_id=5470 From noreply@sourceforge.net Thu Jan 16 06:58:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 15 Jan 2003 22:58:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-668925 ] 2.3 can't pickle bool objects -- breaks deepcopy Message-ID: Bugs item #668925, was opened at 2003-01-16 01:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668925&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Ripton (dripton) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3 can't pickle bool objects -- breaks deepcopy Initial Comment: A class which includes some logically Boolean fields is cloned using copy.deepcopy In Python 2.2.2, the logically Boolean fields are actually ints, and this works fine. In 2.3a1, they're real bools, and I get an error deepcopying the class. Simplified example that shows the problem: Python 2.3a1 (#1, Jan 15 2003, 22:01:37) [GCC 2.95.3 20010315 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import copy >>> li = [True] >>> li2 = copy.deepcopy(li) Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/copy.py", line 186, in deepcopy y = copierfunction(x, memo) File "/usr/local/lib/python2.3/copy.py", line 219, in _deepcopy_list y.append(deepcopy(a, memo)) File "/usr/local/lib/python2.3/copy.py", line 182, in deepcopy y = _reconstruct(x, reductor(), 1, memo) File "/usr/local/lib/python2.3/copy_reg.py", line 57, in _reduce raise TypeError, "can't pickle %s objects" % base.__name__ TypeError: can't pickle bool objects ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668925&group_id=5470 From noreply@sourceforge.net Thu Jan 16 10:22:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 16 Jan 2003 02:22:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-668980 ] classmethod does not check its arguments Message-ID: Bugs item #668980, was opened at 2003-01-16 11:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668980&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Guido van Rossum (gvanrossum) Summary: classmethod does not check its arguments Initial Comment: In 2.3a1, classmethod(3) works just fine. I think it should be a type error. It might be worthwhile to specialcase method objects, so that class X: def foo(self):pass X.foo=classmethod(X.foo) does the "right" thing, i.e. is equivalent to class X: def foo(self):pass foo=classmethod(foo) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668980&group_id=5470 From noreply@sourceforge.net Thu Jan 16 10:43:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 16 Jan 2003 02:43:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-668925 ] 2.3 can't pickle bool objects -- breaks deepcopy Message-ID: Bugs item #668925, was opened at 2003-01-16 07:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668925&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Ripton (dripton) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3 can't pickle bool objects -- breaks deepcopy Initial Comment: A class which includes some logically Boolean fields is cloned using copy.deepcopy In Python 2.2.2, the logically Boolean fields are actually ints, and this works fine. In 2.3a1, they're real bools, and I get an error deepcopying the class. Simplified example that shows the problem: Python 2.3a1 (#1, Jan 15 2003, 22:01:37) [GCC 2.95.3 20010315 (release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import copy >>> li = [True] >>> li2 = copy.deepcopy(li) Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/copy.py", line 186, in deepcopy y = copierfunction(x, memo) File "/usr/local/lib/python2.3/copy.py", line 219, in _deepcopy_list y.append(deepcopy(a, memo)) File "/usr/local/lib/python2.3/copy.py", line 182, in deepcopy y = _reconstruct(x, reductor(), 1, memo) File "/usr/local/lib/python2.3/copy_reg.py", line 57, in _reduce raise TypeError, "can't pickle %s objects" % base.__name__ TypeError: can't pickle bool objects ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-16 11:43 Message: Logged In: YES user_id=21627 Thanks for the report. Pickling booleans actually was supports - just copying them was not. This is fixed in copy.py 1.30. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668925&group_id=5470 From noreply@sourceforge.net Thu Jan 16 11:33:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 16 Jan 2003 03:33:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-660811 ] refman: importing x.y.z as m is possible, docs say otherwise Message-ID: Bugs item #660811, was opened at 2003-01-01 21:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660811&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Hans Nowak (zephyrfalcon) Assigned to: Nobody/Anonymous (nobody) Summary: refman: importing x.y.z as m is possible, docs say otherwise Initial Comment: In the reference manual, the 'import' documentation (Doc/ref/import.html) claims: "To avoid confusion, you cannot import modules with dotted names as a different local name. So import module as m is legal, but import module.submod as s is not." This doesn't seem to be true (anymore?): [Python 2.2.2] >>> import xml.dom.minidom as m >>> m [Python 2.3] >>> import xml.dom.minidom as m >>> m ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-16 12:33 Message: Logged In: YES user_id=21627 This is now fixed in ref6.tex 1.60. ---------------------------------------------------------------------- Comment By: Christopher Blunck (blunck2) Date: 2003-01-05 04:08 Message: Logged In: YES user_id=531881 see patch 662454 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660811&group_id=5470 From noreply@sourceforge.net Thu Jan 16 13:15:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 16 Jan 2003 05:15:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-669036 ] zipimport doesn't support prepended junk Message-ID: Bugs item #669036, was opened at 2003-01-16 14:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669036&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Just van Rossum (jvr) Assigned to: Just van Rossum (jvr) Summary: zipimport doesn't support prepended junk Initial Comment: Zip archives may be appended to/prepended by arbitrary data, but this is not supported by zipimport. zipfile.py does support this. Unfortunately there's a fair amount of offset juggling going on, so a fix is not completely straightforward. This should be fixed before 2.3a2. zipimport *also* doesn't support Zip archives that have a comment attached at the end of the file, but this is less important IMO. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669036&group_id=5470 From noreply@sourceforge.net Thu Jan 16 13:18:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 16 Jan 2003 05:18:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-610149 ] Mac IDE Browser / ListManager issue Message-ID: Bugs item #610149, was opened at 2002-09-16 21:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=610149&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Wont Fix Priority: 6 Submitted By: Just van Rossum (jvr) Assigned to: Just van Rossum (jvr) Summary: Mac IDE Browser / ListManager issue Initial Comment: The Mac IDE object browser traces back badly when the number of items to browse is large. This is caused by a "32kB" limitation of the ListManager (which should be dead an buried anyway). ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-01-16 14:18 Message: Logged In: YES user_id=92689 The traceback has been fixed, but the problem still occurs. It's a fairly fundamental problem and I'm going to punt. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=610149&group_id=5470 From noreply@sourceforge.net Thu Jan 16 13:28:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 16 Jan 2003 05:28:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-668662 ] Compiling C sources with absolute path bug Message-ID: Bugs item #668662, was opened at 2003-01-15 18:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668662&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Pearu Peterson (pearu) Assigned to: A.M. Kuchling (akuchling) Summary: Compiling C sources with absolute path bug Initial Comment: Py-2.3 distutils is broken in the following situation when building extension modules: If a file in C sources list is given with absolute path, say /path/to/foo.c then Py-2.3 distutils tries to create the corresponding object file to /path/to/foo.o (earlier versions would create it to, say, build/temp.linux-i686-2.2/foo.o). This causes problems when 1) an user does not have permissions to write to /path/to/, e.g. in multiuser systems 2) an user builds extension modules, say, using different compilers or flags. Then /path/to/foo.o will be in a way for subsequent builds. IMHO, distutils should not create any files outside the given build directory, unless explicitely specified using --build-temp. Fix: The problematic code seems to be in the method ccompiler.object_filenames in file distutils/ccompiler.py. As a fix, I suggest using the following object name for a C source if given with absolute path: ./build/temp.linux-i686-2.2/path/to/foo.o. This can be achived by inserting the following line just after the line `base, ext = os.path.splitext(src_name)`: base = base[os.path.isabs(base):] Pearu ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-01-16 13:28 Message: Logged In: YES user_id=6656 Actually, I guessed after posting that something like that could happen. BTW, I strongly suspect this is related to the fix for this bug: [ 599248 ] ext module generation problem Can you come up with a patch for your suggested fix? I'm sure Andrew would appreciate it :-) ---------------------------------------------------------------------- Comment By: Pearu Peterson (pearu) Date: 2003-01-15 19:48 Message: Logged In: YES user_id=88489 FYI, distutils does not make this absolute path, but one can specify absolute paths in setup.py files, for instance. Also, tools that create extension modules (e.g. f2py), may ship with C sources that are installed as data files and compiled for each generated extension module separately (possibly with different compilers and flags so that pre-compilation of such sources would not be an option). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-15 19:23 Message: Logged In: YES user_id=6656 I'm a little boggled by how distutils would get an absolute path, but I'm going to assign this to amk anyway :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668662&group_id=5470 From noreply@sourceforge.net Thu Jan 16 13:28:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 16 Jan 2003 05:28:57 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-617979 ] need easy way of decoding a literal Message-ID: Feature Requests item #617979, was opened at 2002-10-03 10:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=617979&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Michael Hudson (mwh) Assigned to: M.-A. Lemburg (lemburg) Summary: need easy way of decoding a literal Initial Comment: Especially since PEP 263, we badly need a way of turning a Python string literal into the appropriate object. The immediate need is to get the compiler package working again, but I'm sure there are other places it could be used. I thought Martin already had a patch somewhere doing this, but I can't find it. Maybe he remembers? ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-01-16 13:28 Message: Logged In: YES user_id=6656 For a bunch of reasons, I now care less about this so I'm going to reduce the priority. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-04 12:15 Message: Logged In: YES user_id=38388 MWH: My first paragraph was refering to Martin's suggestion to use eval() for mapping literal strings to objects. Please take this to the python-dev mailing list. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-04 10:00 Message: Logged In: YES user_id=6656 MAL: I don't understand your first paragraph at all. The {sys.,}source_encoding variable might work, but it would be a dreadful hack for my purposes. Using eval() is already a nasty hack, IMHO. I agree a mailing list is a more civilised interface than a web browser... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 20:21 Message: Logged In: YES user_id=21627 That would not be correct. If you have a (plain) string literal, it would end up encoded as UTF-8, whereas the original source encoding was, say, Latin-1. People will be confused if string literals don't come out in the expected encoding in interactive mode. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-03 19:11 Message: Logged In: YES user_id=38388 I believe the correct way to handle this would be to have eval() accept Unicode and then convert it to UTF-8 for the parser to process. The PEP only talks about compile() which should accept Unicode objects, but eval() is certainly a candidate too. About the source_encoding idea: wouldn't it be better to define this for interactive use in the sys module ? A Python startup script could then be used to set this variable in interactive mode. BTW, it's better to discuss these things on python-dev than in these small textareas... IMHO, at least. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 18:55 Message: Logged In: YES user_id=21627 I see. For a different reason (interactive mode), I have been contemplating to recognize a variable source_encoding in globals(), which would be set in interactive mode to the terminal's encoding, so that input of non-ASCII Unicode literals would "work", without having to type an encoding declaration each time. I believe such a mechanism could also solve this problem; callers of eval would have to set the global. What do you think? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-03 17:45 Message: Logged In: YES user_id=6656 How do you get eval to take notice of the declared encoding? What I want is the functionality of compile.c:parsestr available from Python. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-10-03 17:35 Message: Logged In: YES user_id=21627 Not sure what you are asking. eval() would certainly be an easy way, no? In any case, I'm not aware of an alternative. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=617979&group_id=5470 From noreply@sourceforge.net Thu Jan 16 14:52:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 16 Jan 2003 06:52:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-668980 ] classmethod does not check its arguments Message-ID: Bugs item #668980, was opened at 2003-01-16 05:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668980&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None >Priority: 1 Submitted By: Martin v. Löwis (loewis) Assigned to: Guido van Rossum (gvanrossum) Summary: classmethod does not check its arguments Initial Comment: In 2.3a1, classmethod(3) works just fine. I think it should be a type error. It might be worthwhile to specialcase method objects, so that class X: def foo(self):pass X.foo=classmethod(X.foo) does the "right" thing, i.e. is equivalent to class X: def foo(self):pass foo=classmethod(foo) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-16 09:52 Message: Logged In: YES user_id=6380 Not convinced; there are subtle things you might want to do with classmethod (and staticmethod) that a type check would prevent. I could live with something that checks whether the argument is callable. There are definitely some weird things: >>> C.x = classmethod(12) >>> C.x() Traceback (most recent call last): File "", line 1, in ? SystemError: ../Objects/classobject.c:2081: bad argument to internal function >>> vs. >>> C.x = staticmethod(12) >>> C.x() Traceback (most recent call last): File "", line 1, in ? TypeError: 'int' object is not callable >>> Anyway I have bigger fish to fry for now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668980&group_id=5470 From noreply@sourceforge.net Thu Jan 16 15:18:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 16 Jan 2003 07:18:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-660455 ] -hex/oct const generates wrong code Message-ID: Bugs item #660455, was opened at 2002-12-31 13:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660455&group_id=5470 Category: Parser/Compiler Group: Python 2.2 Status: Open Resolution: None Priority: 6 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: -hex/oct const generates wrong code Initial Comment: Since Python 2.2, there's code in com_factor() in compile.c that expands negative constants inline. For example, the expression -1 generates a single LOAD_CONST opcode for -1, rather than (as in Python 2.1 and before) generating a LOAD_CONST for +1 followed by a UNARY_NEGATIVE opcode. Unfortunately there's an end case where this causes surprising behavior: when the constant is an octal or hexadecimal constant that already has a negative value (despite having no sign), the generated code yields a different result than expected. For example: >>> print -(0xffffffff) 1 >>> x = 0xffffffff >>> print -x 1 >>> print -0xffffffff -4294967295 >>> Despite the fact that in Python 2.4 (!) all of these will print the third outcome, in Python 2.2 and 2.3, I think the third outcome is wrong and unexpected. No time to fix this for 2.3a1, but should fix it before 2.3a2. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-16 10:18 Message: Logged In: YES user_id=33168 Ideally, I'd like to keep the code, rather than rip it out. Is it possible to keep the optimization, but if it is - followed by a 0, then fallback to the original technique (ie, UNARY_NEGATIVE, followed by the value)? I have attached a patch which seems to implement this. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-12 06:35 Message: Logged In: YES user_id=80475 See attached patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660455&group_id=5470 From noreply@sourceforge.net Thu Jan 16 17:32:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 16 Jan 2003 09:32:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-660455 ] -hex/oct const generates wrong code Message-ID: Bugs item #660455, was opened at 2002-12-31 13:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660455&group_id=5470 Category: Parser/Compiler Group: Python 2.2 Status: Open Resolution: None Priority: 6 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: -hex/oct const generates wrong code Initial Comment: Since Python 2.2, there's code in com_factor() in compile.c that expands negative constants inline. For example, the expression -1 generates a single LOAD_CONST opcode for -1, rather than (as in Python 2.1 and before) generating a LOAD_CONST for +1 followed by a UNARY_NEGATIVE opcode. Unfortunately there's an end case where this causes surprising behavior: when the constant is an octal or hexadecimal constant that already has a negative value (despite having no sign), the generated code yields a different result than expected. For example: >>> print -(0xffffffff) 1 >>> x = 0xffffffff >>> print -x 1 >>> print -0xffffffff -4294967295 >>> Despite the fact that in Python 2.4 (!) all of these will print the third outcome, in Python 2.2 and 2.3, I think the third outcome is wrong and unexpected. No time to fix this for 2.3a1, but should fix it before 2.3a2. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-16 12:32 Message: Logged In: YES user_id=6380 I'd like to keep the optimization too. I think you have to do something different. The code currently tries to save some time by prepending a minus sign to the literal. I think it should just evaluate the literal and then apply PyNumber_Negative() to the result, all the while catching exceptions and falling back to unoptimized code if there are exceptions. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-16 10:18 Message: Logged In: YES user_id=33168 Ideally, I'd like to keep the code, rather than rip it out. Is it possible to keep the optimization, but if it is - followed by a 0, then fallback to the original technique (ie, UNARY_NEGATIVE, followed by the value)? I have attached a patch which seems to implement this. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-12 06:35 Message: Logged In: YES user_id=80475 See attached patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660455&group_id=5470 From noreply@sourceforge.net Thu Jan 16 18:38:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 16 Jan 2003 10:38:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-660455 ] -hex/oct const generates wrong code Message-ID: Bugs item #660455, was opened at 2002-12-31 13:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660455&group_id=5470 Category: Parser/Compiler Group: Python 2.2 Status: Open Resolution: None Priority: 6 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: -hex/oct const generates wrong code Initial Comment: Since Python 2.2, there's code in com_factor() in compile.c that expands negative constants inline. For example, the expression -1 generates a single LOAD_CONST opcode for -1, rather than (as in Python 2.1 and before) generating a LOAD_CONST for +1 followed by a UNARY_NEGATIVE opcode. Unfortunately there's an end case where this causes surprising behavior: when the constant is an octal or hexadecimal constant that already has a negative value (despite having no sign), the generated code yields a different result than expected. For example: >>> print -(0xffffffff) 1 >>> x = 0xffffffff >>> print -x 1 >>> print -0xffffffff -4294967295 >>> Despite the fact that in Python 2.4 (!) all of these will print the third outcome, in Python 2.2 and 2.3, I think the third outcome is wrong and unexpected. No time to fix this for 2.3a1, but should fix it before 2.3a2. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-16 13:38 Message: Logged In: YES user_id=33168 mwh pointed out that my patch breaks test_grammar. I'll take another look later, unless Raymond beats me to it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-16 12:32 Message: Logged In: YES user_id=6380 I'd like to keep the optimization too. I think you have to do something different. The code currently tries to save some time by prepending a minus sign to the literal. I think it should just evaluate the literal and then apply PyNumber_Negative() to the result, all the while catching exceptions and falling back to unoptimized code if there are exceptions. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-16 10:18 Message: Logged In: YES user_id=33168 Ideally, I'd like to keep the code, rather than rip it out. Is it possible to keep the optimization, but if it is - followed by a 0, then fallback to the original technique (ie, UNARY_NEGATIVE, followed by the value)? I have attached a patch which seems to implement this. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-12 06:35 Message: Logged In: YES user_id=80475 See attached patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660455&group_id=5470 From noreply@sourceforge.net Thu Jan 16 19:45:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 16 Jan 2003 11:45:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-660455 ] -hex/oct const generates wrong code Message-ID: Bugs item #660455, was opened at 2002-12-31 13:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660455&group_id=5470 Category: Parser/Compiler Group: Python 2.2 Status: Open Resolution: None Priority: 6 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: -hex/oct const generates wrong code Initial Comment: Since Python 2.2, there's code in com_factor() in compile.c that expands negative constants inline. For example, the expression -1 generates a single LOAD_CONST opcode for -1, rather than (as in Python 2.1 and before) generating a LOAD_CONST for +1 followed by a UNARY_NEGATIVE opcode. Unfortunately there's an end case where this causes surprising behavior: when the constant is an octal or hexadecimal constant that already has a negative value (despite having no sign), the generated code yields a different result than expected. For example: >>> print -(0xffffffff) 1 >>> x = 0xffffffff >>> print -x 1 >>> print -0xffffffff -4294967295 >>> Despite the fact that in Python 2.4 (!) all of these will print the third outcome, in Python 2.2 and 2.3, I think the third outcome is wrong and unexpected. No time to fix this for 2.3a1, but should fix it before 2.3a2. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-16 14:45 Message: Logged In: YES user_id=33168 The test fails because of line test_grammar.py:40: if -2147483647-1 != -020000000000: What should -020000000000 be? Without the -, it is: -(2**31)-1, so it can't be represented in an int (on 32-bit arches). With the patch, it is: 2147483648L. Later, I'll take a look at doing what Guido suggested. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-16 13:38 Message: Logged In: YES user_id=33168 mwh pointed out that my patch breaks test_grammar. I'll take another look later, unless Raymond beats me to it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-16 12:32 Message: Logged In: YES user_id=6380 I'd like to keep the optimization too. I think you have to do something different. The code currently tries to save some time by prepending a minus sign to the literal. I think it should just evaluate the literal and then apply PyNumber_Negative() to the result, all the while catching exceptions and falling back to unoptimized code if there are exceptions. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-16 10:18 Message: Logged In: YES user_id=33168 Ideally, I'd like to keep the code, rather than rip it out. Is it possible to keep the optimization, but if it is - followed by a 0, then fallback to the original technique (ie, UNARY_NEGATIVE, followed by the value)? I have attached a patch which seems to implement this. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-12 06:35 Message: Logged In: YES user_id=80475 See attached patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660455&group_id=5470 From noreply@sourceforge.net Thu Jan 16 19:53:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 16 Jan 2003 11:53:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-660455 ] -hex/oct const generates wrong code Message-ID: Bugs item #660455, was opened at 2002-12-31 13:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660455&group_id=5470 Category: Parser/Compiler Group: Python 2.2 Status: Open Resolution: None Priority: 6 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: -hex/oct const generates wrong code Initial Comment: Since Python 2.2, there's code in com_factor() in compile.c that expands negative constants inline. For example, the expression -1 generates a single LOAD_CONST opcode for -1, rather than (as in Python 2.1 and before) generating a LOAD_CONST for +1 followed by a UNARY_NEGATIVE opcode. Unfortunately there's an end case where this causes surprising behavior: when the constant is an octal or hexadecimal constant that already has a negative value (despite having no sign), the generated code yields a different result than expected. For example: >>> print -(0xffffffff) 1 >>> x = 0xffffffff >>> print -x 1 >>> print -0xffffffff -4294967295 >>> Despite the fact that in Python 2.4 (!) all of these will print the third outcome, in Python 2.2 and 2.3, I think the third outcome is wrong and unexpected. No time to fix this for 2.3a1, but should fix it before 2.3a2. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-16 14:53 Message: Logged In: YES user_id=6380 I believe that test relies on the bug. :-( So the test should be fixed. The value ought to be equal to -(020000000000L). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-16 14:45 Message: Logged In: YES user_id=33168 The test fails because of line test_grammar.py:40: if -2147483647-1 != -020000000000: What should -020000000000 be? Without the -, it is: -(2**31)-1, so it can't be represented in an int (on 32-bit arches). With the patch, it is: 2147483648L. Later, I'll take a look at doing what Guido suggested. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-16 13:38 Message: Logged In: YES user_id=33168 mwh pointed out that my patch breaks test_grammar. I'll take another look later, unless Raymond beats me to it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-16 12:32 Message: Logged In: YES user_id=6380 I'd like to keep the optimization too. I think you have to do something different. The code currently tries to save some time by prepending a minus sign to the literal. I think it should just evaluate the literal and then apply PyNumber_Negative() to the result, all the while catching exceptions and falling back to unoptimized code if there are exceptions. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-16 10:18 Message: Logged In: YES user_id=33168 Ideally, I'd like to keep the code, rather than rip it out. Is it possible to keep the optimization, but if it is - followed by a 0, then fallback to the original technique (ie, UNARY_NEGATIVE, followed by the value)? I have attached a patch which seems to implement this. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-12 06:35 Message: Logged In: YES user_id=80475 See attached patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660455&group_id=5470 From noreply@sourceforge.net Thu Jan 16 21:33:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 16 Jan 2003 13:33:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-660144 ] typeobject provides incorrect __mul__ Message-ID: Bugs item #660144, was opened at 2002-12-30 20:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660144&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Guido van Rossum (gvanrossum) Summary: typeobject provides incorrect __mul__ Initial Comment: type __mul__ is wierd: >> 'a'.__mul__(3.4) 'aaa' >>> [1].__mul__(3.4) [1, 1, 1] Floating point numbers with fractions should not be accepted. I think the problem is that __mul__ should not be trying to implement sq_repeat behavior (although I haven't dug deeply into this problem yet). Also, I think the code is vulnerable to integer overflow. Should also check __imul__ __add__ __iadd__. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2003-01-16 21:33 Message: Logged In: YES user_id=35752 I think the problem is that wrap_intargfunc and wrap_intintargfunc use PyArg_ParseTuple(args, "i", &i). This bug also is present in methods like __getitem__: >>> "Python"[1.2] Traceback (most recent call last): File "", line 1, in ? TypeError: sequence index must be integer >>> "Python".__getitem__(1.2) 'y' I think the right fix is to use explictly only allow only ints and longs to wrap_intargfunc and friends. If Guido agrees I will cook up a patch. It seems like we should have a code for PyParse_Tuple that only allows ints and longs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660144&group_id=5470 From noreply@sourceforge.net Thu Jan 16 21:57:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 16 Jan 2003 13:57:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-660144 ] typeobject provides incorrect __mul__ Message-ID: Bugs item #660144, was opened at 2002-12-30 15:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660144&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Guido van Rossum (gvanrossum) Summary: typeobject provides incorrect __mul__ Initial Comment: type __mul__ is wierd: >> 'a'.__mul__(3.4) 'aaa' >>> [1].__mul__(3.4) [1, 1, 1] Floating point numbers with fractions should not be accepted. I think the problem is that __mul__ should not be trying to implement sq_repeat behavior (although I haven't dug deeply into this problem yet). Also, I think the code is vulnerable to integer overflow. Should also check __imul__ __add__ __iadd__. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-16 16:57 Message: Logged In: YES user_id=6380 This is an age-old problem that crops up whenever "i" and similar format codes are used. The problem is that on the one hand you want "i" to accept other int-ish types that have an __int__ method. But on the other hand you don't want it to accept float, which also has an __int__ method. Or other float-ish types. I think the "i" format code has to be fixe, but I'm not sure how -- maybe as a start it would be sufficient to test explicitly for float and its subclasses and reject those. That would still allow 3rd party float-ish classes that implement __int__, but that's not so important. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-01-16 16:33 Message: Logged In: YES user_id=35752 I think the problem is that wrap_intargfunc and wrap_intintargfunc use PyArg_ParseTuple(args, "i", &i). This bug also is present in methods like __getitem__: >>> "Python"[1.2] Traceback (most recent call last): File "", line 1, in ? TypeError: sequence index must be integer >>> "Python".__getitem__(1.2) 'y' I think the right fix is to use explictly only allow only ints and longs to wrap_intargfunc and friends. If Guido agrees I will cook up a patch. It seems like we should have a code for PyParse_Tuple that only allows ints and longs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660144&group_id=5470 From noreply@sourceforge.net Thu Jan 16 23:10:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 16 Jan 2003 15:10:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-660144 ] typeobject provides incorrect __mul__ Message-ID: Bugs item #660144, was opened at 2002-12-30 20:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660144&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Guido van Rossum (gvanrossum) Summary: typeobject provides incorrect __mul__ Initial Comment: type __mul__ is wierd: >> 'a'.__mul__(3.4) 'aaa' >>> [1].__mul__(3.4) [1, 1, 1] Floating point numbers with fractions should not be accepted. I think the problem is that __mul__ should not be trying to implement sq_repeat behavior (although I haven't dug deeply into this problem yet). Also, I think the code is vulnerable to integer overflow. Should also check __imul__ __add__ __iadd__. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2003-01-16 23:10 Message: Logged In: YES user_id=35752 Would this be a change for the 2.3 release? I tried adding a PyFloat_Check test to 'i' and 'l' in getargs.c. It looks like all the unit tests pass. I agree that checking for float catches the important cases. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-16 21:57 Message: Logged In: YES user_id=6380 This is an age-old problem that crops up whenever "i" and similar format codes are used. The problem is that on the one hand you want "i" to accept other int-ish types that have an __int__ method. But on the other hand you don't want it to accept float, which also has an __int__ method. Or other float-ish types. I think the "i" format code has to be fixe, but I'm not sure how -- maybe as a start it would be sufficient to test explicitly for float and its subclasses and reject those. That would still allow 3rd party float-ish classes that implement __int__, but that's not so important. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-01-16 21:33 Message: Logged In: YES user_id=35752 I think the problem is that wrap_intargfunc and wrap_intintargfunc use PyArg_ParseTuple(args, "i", &i). This bug also is present in methods like __getitem__: >>> "Python"[1.2] Traceback (most recent call last): File "", line 1, in ? TypeError: sequence index must be integer >>> "Python".__getitem__(1.2) 'y' I think the right fix is to use explictly only allow only ints and longs to wrap_intargfunc and friends. If Guido agrees I will cook up a patch. It seems like we should have a code for PyParse_Tuple that only allows ints and longs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660144&group_id=5470 From noreply@sourceforge.net Fri Jan 17 00:19:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 16 Jan 2003 16:19:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-660144 ] typeobject provides incorrect __mul__ Message-ID: Bugs item #660144, was opened at 2002-12-30 15:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660144&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Guido van Rossum (gvanrossum) Summary: typeobject provides incorrect __mul__ Initial Comment: type __mul__ is wierd: >> 'a'.__mul__(3.4) 'aaa' >>> [1].__mul__(3.4) [1, 1, 1] Floating point numbers with fractions should not be accepted. I think the problem is that __mul__ should not be trying to implement sq_repeat behavior (although I haven't dug deeply into this problem yet). Also, I think the code is vulnerable to integer overflow. Should also check __imul__ __add__ __iadd__. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-16 19:19 Message: Logged In: YES user_id=6380 Yes, this should go into 2.3a2. Your attachment upload failed somehow. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-01-16 18:10 Message: Logged In: YES user_id=35752 Would this be a change for the 2.3 release? I tried adding a PyFloat_Check test to 'i' and 'l' in getargs.c. It looks like all the unit tests pass. I agree that checking for float catches the important cases. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-16 16:57 Message: Logged In: YES user_id=6380 This is an age-old problem that crops up whenever "i" and similar format codes are used. The problem is that on the one hand you want "i" to accept other int-ish types that have an __int__ method. But on the other hand you don't want it to accept float, which also has an __int__ method. Or other float-ish types. I think the "i" format code has to be fixe, but I'm not sure how -- maybe as a start it would be sufficient to test explicitly for float and its subclasses and reject those. That would still allow 3rd party float-ish classes that implement __int__, but that's not so important. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-01-16 16:33 Message: Logged In: YES user_id=35752 I think the problem is that wrap_intargfunc and wrap_intintargfunc use PyArg_ParseTuple(args, "i", &i). This bug also is present in methods like __getitem__: >>> "Python"[1.2] Traceback (most recent call last): File "", line 1, in ? TypeError: sequence index must be integer >>> "Python".__getitem__(1.2) 'y' I think the right fix is to use explictly only allow only ints and longs to wrap_intargfunc and friends. If Guido agrees I will cook up a patch. It seems like we should have a code for PyParse_Tuple that only allows ints and longs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660144&group_id=5470 From noreply@sourceforge.net Fri Jan 17 00:43:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 16 Jan 2003 16:43:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-669486 ] md5.new(unicode) fails, sha1 also Message-ID: Bugs item #669486, was opened at 2003-01-16 16:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669486&group_id=5470 Category: Unicode Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Martin D Katz, Ph.D. (drbits) Assigned to: M.-A. Lemburg (lemburg) Summary: md5.new(unicode) fails, sha1 also Initial Comment: Some library modules appear to choke on Unicode strings that cannot be converted to the default encoding. It appears that the functions in the modules are getting a character array that has been encoded from Unicode to the default encoding (ascii in my case) before being passed. The data should just be passed as an array of bytes, encoding it first is not appropriate for modules like md5 and sha. Thus: >>> import md5 >>> m = md5.new(u'\x80') Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range(128) This is in Windows 2000 (both sp1 or sp3). Using ActiveState python 2.2.1 (build 222) Martin Katz, Ph.D. Tapstone, Inc. mkatz@tapstone.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669486&group_id=5470 From noreply@sourceforge.net Fri Jan 17 08:48:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 17 Jan 2003 00:48:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-669486 ] md5.new(unicode) fails, sha1 also Message-ID: Bugs item #669486, was opened at 2003-01-17 01:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669486&group_id=5470 Category: Unicode Group: Python 2.2.1 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Martin D Katz, Ph.D. (drbits) Assigned to: M.-A. Lemburg (lemburg) Summary: md5.new(unicode) fails, sha1 also Initial Comment: Some library modules appear to choke on Unicode strings that cannot be converted to the default encoding. It appears that the functions in the modules are getting a character array that has been encoded from Unicode to the default encoding (ascii in my case) before being passed. The data should just be passed as an array of bytes, encoding it first is not appropriate for modules like md5 and sha. Thus: >>> import md5 >>> m = md5.new(u'\x80') Traceback (most recent call last): File "", line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range(128) This is in Windows 2000 (both sp1 or sp3). Using ActiveState python 2.2.1 (build 222) Martin Katz, Ph.D. Tapstone, Inc. mkatz@tapstone.com ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-17 09:48 Message: Logged In: YES user_id=38388 You have to differentiate between plain binary data and text data. Unicode is only meant for text while 8-bit strings can contain both text and binary data. Since APIs like the hash constructors work on binary data, it is only natural that they don't accept text data. If they would, the outcome of the hash value would be a function of the current default encoding and could result in subtle errors. Closing this as won't fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669486&group_id=5470 From noreply@sourceforge.net Fri Jan 17 10:47:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 17 Jan 2003 02:47:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-660455 ] -hex/oct const generates wrong code Message-ID: Bugs item #660455, was opened at 2002-12-31 18:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660455&group_id=5470 Category: Parser/Compiler Group: Python 2.2 Status: Open Resolution: None Priority: 6 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: -hex/oct const generates wrong code Initial Comment: Since Python 2.2, there's code in com_factor() in compile.c that expands negative constants inline. For example, the expression -1 generates a single LOAD_CONST opcode for -1, rather than (as in Python 2.1 and before) generating a LOAD_CONST for +1 followed by a UNARY_NEGATIVE opcode. Unfortunately there's an end case where this causes surprising behavior: when the constant is an octal or hexadecimal constant that already has a negative value (despite having no sign), the generated code yields a different result than expected. For example: >>> print -(0xffffffff) 1 >>> x = 0xffffffff >>> print -x 1 >>> print -0xffffffff -4294967295 >>> Despite the fact that in Python 2.4 (!) all of these will print the third outcome, in Python 2.2 and 2.3, I think the third outcome is wrong and unexpected. No time to fix this for 2.3a1, but should fix it before 2.3a2. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-01-17 10:47 Message: Logged In: YES user_id=6656 Oh, so maybe the fact that Lib/compiler has a problem in the same place *isn't* a problem with the compiler package... What ever gets done here should probably coincide with whatever happens in patch 661536. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-16 19:53 Message: Logged In: YES user_id=6380 I believe that test relies on the bug. :-( So the test should be fixed. The value ought to be equal to -(020000000000L). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-16 19:45 Message: Logged In: YES user_id=33168 The test fails because of line test_grammar.py:40: if -2147483647-1 != -020000000000: What should -020000000000 be? Without the -, it is: -(2**31)-1, so it can't be represented in an int (on 32-bit arches). With the patch, it is: 2147483648L. Later, I'll take a look at doing what Guido suggested. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-16 18:38 Message: Logged In: YES user_id=33168 mwh pointed out that my patch breaks test_grammar. I'll take another look later, unless Raymond beats me to it. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-16 17:32 Message: Logged In: YES user_id=6380 I'd like to keep the optimization too. I think you have to do something different. The code currently tries to save some time by prepending a minus sign to the literal. I think it should just evaluate the literal and then apply PyNumber_Negative() to the result, all the while catching exceptions and falling back to unoptimized code if there are exceptions. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-16 15:18 Message: Logged In: YES user_id=33168 Ideally, I'd like to keep the code, rather than rip it out. Is it possible to keep the optimization, but if it is - followed by a 0, then fallback to the original technique (ie, UNARY_NEGATIVE, followed by the value)? I have attached a patch which seems to implement this. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-12 11:35 Message: Logged In: YES user_id=80475 See attached patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660455&group_id=5470 From noreply@sourceforge.net Fri Jan 17 11:39:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 17 Jan 2003 03:39:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-669692 ] pdb user_call breakage Message-ID: Bugs item #669692, was opened at 2003-01-17 11:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669692&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: pdb user_call breakage Initial Comment: Reported on c.l.py: ----------- I'm running python 2.3a1 on a Win32 machine. pdb's behaviour seems to have been changed from 2.2*. "user_call" method is added, and it's called automatically for every function/method call when I set a breakpoint somewhere else and "continue". ------------ This is certainly my fauld, but I never use breakpoints in pdb, so right now I don't even know how to duplicate it, never mind fix it. It's probably shallow, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669692&group_id=5470 From noreply@sourceforge.net Fri Jan 17 17:03:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 17 Jan 2003 09:03:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-669838 ] Seg fault in gcmodule.c Message-ID: Bugs item #669838, was opened at 2003-01-17 12:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669838&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gregory Popovitch (greg7mdp) Assigned to: Nobody/Anonymous (nobody) Summary: Seg fault in gcmodule.c Initial Comment: Using Python 2.2.2 on Linux Redhat 7.2: Python 2.2.2 (#1, Oct 21 2002, 22:19:12) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 I have a crash which happens somewhat randomly (for example it goes away if I add a print statement somewhere). Here is some gdb info. lnx:0:usr/greg/ib> gdb python2.2 GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run rules.py > xx Starting program: /usr/local/bin/python2.2 rules.py > xx [New Thread 1024 (LWP 30182)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 30182)] 0x080996f8 in visit_decref (op=0x1000000, data=0x0) at Modules/gcmodule.c:185 185 if (op && PyObject_IS_GC(op)) { (gdb) print op $1 = (PyObject *) 0x1000000 (gdb) print data $2 = (void *) 0x0 (gdb) where 20 #0 0x080996f8 in visit_decref (op=0x1000000, data=0x0) at Modules/gcmodule.c:185 #1 0x080c9abb in dict_traverse (op=0x827bc34, visit=0x80996ec , arg=0x0) at Objects/dictobject.c:1589 #2 0x0809897e in collect (young=0x80ee5a0, old=0x80ee5ac) at Modules/gcmodule.c:201 #3 0x08099062 in collect_generations () at Modules/gcmodule.c:518 #4 0x08099576 in _PyObject_GC_New (tp=0x80f8ae0) at Modules/gcmodule.c:879 #5 0x080c7b75 in PyDict_New () at Objects/dictobject.c:161 #6 0x080869d5 in symtable_init () at Python/compile.c:4671 #7 0x08086910 in symtable_build (c=0xbfffea90, n=0x8240e68) at Python/compile.c:4261 #8 0x08084109 in jcompile (n=0x8240e68, filename=0x81f83ec "", base=0x0, flags=0xbfffebe4) at Python/compile.c:4111 #9 0x0808665e in PyNode_CompileFlags (n=0x8240e68, filename=0x81f83ec "", flags=0xbfffebe4) at Python/compile.c:4042 #10 0x080945c7 in Py_CompileStringFlags ( str=0x811f8bc "agrepy(\epreuve photographique\, 22, t, len(t), 0, re[0]) and re[1].search(t)", filename=0x81f83ec "", start=258, flags=0xbfffebe4) at Python/pythonrun.c:1133 #11 0x080cc4cc in builtin_compile (self=0x0, args=0x8241a04) at Python/bltinmodule.c:398 #12 0x080ca7cc in PyCFunction_Call (func=0x8105fb0, arg=0x8241a04, kw=0x0) at Objects/methodobject.c:100 #13 0x08077918 in eval_frame (f=0x81a6fbc) at Python/ceval.c:2014 #14 0x0807892b in PyEval_EvalCodeEx (co=0x81f8750, globals=0x8111ecc, locals=0x0, args=0x82ffe14, argcount=2, kws=0x82ffe1c, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2595 #15 0x0807aa43 in fast_function (func=0x815f754, pp_stack=0xbfffee14, n=2, na=2, nk=0) at Python/ceval.c:3173 #16 0x080779b5 in eval_frame (f=0x82ffc8c) at Python/ceval.c:2034 #17 0x0807892b in PyEval_EvalCodeEx (co=0x81f9768, globals=0x8111ecc, locals=0x0, args=0x81cc34c, argcount=3, kws=0x81cc358, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2595 #18 0x0807aa43 in fast_function (func=0x815f78c, pp_stack=0xbfffef74, n=3, na=3, nk=0) at Python/ceval.c:3173 #19 0x080779b5 in eval_frame (f=0x81cc1f4) at Python/ceval.c:2034 (More stack frames follow...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669838&group_id=5470 From noreply@sourceforge.net Fri Jan 17 17:05:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 17 Jan 2003 09:05:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-669838 ] Seg fault in gcmodule.c Message-ID: Bugs item #669838, was opened at 2003-01-17 12:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669838&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gregory Popovitch (greg7mdp) Assigned to: Nobody/Anonymous (nobody) Summary: Seg fault in gcmodule.c Initial Comment: Using Python 2.2.2 on Linux Redhat 7.2: Python 2.2.2 (#1, Oct 21 2002, 22:19:12) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 I have a crash which happens somewhat randomly (for example it goes away if I add a print statement somewhere). Here is some gdb info. lnx:0:usr/greg/ib> gdb python2.2 GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run rules.py > xx Starting program: /usr/local/bin/python2.2 rules.py > xx [New Thread 1024 (LWP 30182)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 30182)] 0x080996f8 in visit_decref (op=0x1000000, data=0x0) at Modules/gcmodule.c:185 185 if (op && PyObject_IS_GC(op)) { (gdb) print op $1 = (PyObject *) 0x1000000 (gdb) print data $2 = (void *) 0x0 (gdb) where 20 #0 0x080996f8 in visit_decref (op=0x1000000, data=0x0) at Modules/gcmodule.c:185 #1 0x080c9abb in dict_traverse (op=0x827bc34, visit=0x80996ec , arg=0x0) at Objects/dictobject.c:1589 #2 0x0809897e in collect (young=0x80ee5a0, old=0x80ee5ac) at Modules/gcmodule.c:201 #3 0x08099062 in collect_generations () at Modules/gcmodule.c:518 #4 0x08099576 in _PyObject_GC_New (tp=0x80f8ae0) at Modules/gcmodule.c:879 #5 0x080c7b75 in PyDict_New () at Objects/dictobject.c:161 #6 0x080869d5 in symtable_init () at Python/compile.c:4671 #7 0x08086910 in symtable_build (c=0xbfffea90, n=0x8240e68) at Python/compile.c:4261 #8 0x08084109 in jcompile (n=0x8240e68, filename=0x81f83ec "", base=0x0, flags=0xbfffebe4) at Python/compile.c:4111 #9 0x0808665e in PyNode_CompileFlags (n=0x8240e68, filename=0x81f83ec "", flags=0xbfffebe4) at Python/compile.c:4042 #10 0x080945c7 in Py_CompileStringFlags ( str=0x811f8bc "agrepy(\epreuve photographique\, 22, t, len(t), 0, re[0]) and re[1].search(t)", filename=0x81f83ec "", start=258, flags=0xbfffebe4) at Python/pythonrun.c:1133 #11 0x080cc4cc in builtin_compile (self=0x0, args=0x8241a04) at Python/bltinmodule.c:398 #12 0x080ca7cc in PyCFunction_Call (func=0x8105fb0, arg=0x8241a04, kw=0x0) at Objects/methodobject.c:100 #13 0x08077918 in eval_frame (f=0x81a6fbc) at Python/ceval.c:2014 #14 0x0807892b in PyEval_EvalCodeEx (co=0x81f8750, globals=0x8111ecc, locals=0x0, args=0x82ffe14, argcount=2, kws=0x82ffe1c, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2595 #15 0x0807aa43 in fast_function (func=0x815f754, pp_stack=0xbfffee14, n=2, na=2, nk=0) at Python/ceval.c:3173 #16 0x080779b5 in eval_frame (f=0x82ffc8c) at Python/ceval.c:2034 #17 0x0807892b in PyEval_EvalCodeEx (co=0x81f9768, globals=0x8111ecc, locals=0x0, args=0x81cc34c, argcount=3, kws=0x81cc358, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2595 #18 0x0807aa43 in fast_function (func=0x815f78c, pp_stack=0xbfffef74, n=3, na=3, nk=0) at Python/ceval.c:3173 #19 0x080779b5 in eval_frame (f=0x81cc1f4) at Python/ceval.c:2034 (More stack frames follow...) ---------------------------------------------------------------------- >Comment By: Gregory Popovitch (greg7mdp) Date: 2003-01-17 12:05 Message: Logged In: YES user_id=222034 I forgot to mention that this program is using the "exec()" builtin heavily, and I believe that the crash is related to this. gregory ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669838&group_id=5470 From noreply@sourceforge.net Fri Jan 17 17:49:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 17 Jan 2003 09:49:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-669859 ] socket.inet_aton() succeeds on invalid input Message-ID: Bugs item #669859, was opened at 2003-01-17 09:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669859&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matt Beaumont (mbeaumon) Assigned to: Nobody/Anonymous (nobody) Summary: socket.inet_aton() succeeds on invalid input Initial Comment: Given a string such as "5.6.7", inet_aton() returns '\x05\x06\x00\x07'. In C (using libraries installed with RedHat 7.2), the equivalent call returns 0, indicating that the address is invalid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669859&group_id=5470 From noreply@sourceforge.net Fri Jan 17 18:43:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 17 Jan 2003 10:43:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-669838 ] Seg fault in gcmodule.c Message-ID: Bugs item #669838, was opened at 2003-01-17 12:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669838&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gregory Popovitch (greg7mdp) Assigned to: Nobody/Anonymous (nobody) Summary: Seg fault in gcmodule.c Initial Comment: Using Python 2.2.2 on Linux Redhat 7.2: Python 2.2.2 (#1, Oct 21 2002, 22:19:12) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 I have a crash which happens somewhat randomly (for example it goes away if I add a print statement somewhere). Here is some gdb info. lnx:0:usr/greg/ib> gdb python2.2 GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run rules.py > xx Starting program: /usr/local/bin/python2.2 rules.py > xx [New Thread 1024 (LWP 30182)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 30182)] 0x080996f8 in visit_decref (op=0x1000000, data=0x0) at Modules/gcmodule.c:185 185 if (op && PyObject_IS_GC(op)) { (gdb) print op $1 = (PyObject *) 0x1000000 (gdb) print data $2 = (void *) 0x0 (gdb) where 20 #0 0x080996f8 in visit_decref (op=0x1000000, data=0x0) at Modules/gcmodule.c:185 #1 0x080c9abb in dict_traverse (op=0x827bc34, visit=0x80996ec , arg=0x0) at Objects/dictobject.c:1589 #2 0x0809897e in collect (young=0x80ee5a0, old=0x80ee5ac) at Modules/gcmodule.c:201 #3 0x08099062 in collect_generations () at Modules/gcmodule.c:518 #4 0x08099576 in _PyObject_GC_New (tp=0x80f8ae0) at Modules/gcmodule.c:879 #5 0x080c7b75 in PyDict_New () at Objects/dictobject.c:161 #6 0x080869d5 in symtable_init () at Python/compile.c:4671 #7 0x08086910 in symtable_build (c=0xbfffea90, n=0x8240e68) at Python/compile.c:4261 #8 0x08084109 in jcompile (n=0x8240e68, filename=0x81f83ec "", base=0x0, flags=0xbfffebe4) at Python/compile.c:4111 #9 0x0808665e in PyNode_CompileFlags (n=0x8240e68, filename=0x81f83ec "", flags=0xbfffebe4) at Python/compile.c:4042 #10 0x080945c7 in Py_CompileStringFlags ( str=0x811f8bc "agrepy(\epreuve photographique\, 22, t, len(t), 0, re[0]) and re[1].search(t)", filename=0x81f83ec "", start=258, flags=0xbfffebe4) at Python/pythonrun.c:1133 #11 0x080cc4cc in builtin_compile (self=0x0, args=0x8241a04) at Python/bltinmodule.c:398 #12 0x080ca7cc in PyCFunction_Call (func=0x8105fb0, arg=0x8241a04, kw=0x0) at Objects/methodobject.c:100 #13 0x08077918 in eval_frame (f=0x81a6fbc) at Python/ceval.c:2014 #14 0x0807892b in PyEval_EvalCodeEx (co=0x81f8750, globals=0x8111ecc, locals=0x0, args=0x82ffe14, argcount=2, kws=0x82ffe1c, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2595 #15 0x0807aa43 in fast_function (func=0x815f754, pp_stack=0xbfffee14, n=2, na=2, nk=0) at Python/ceval.c:3173 #16 0x080779b5 in eval_frame (f=0x82ffc8c) at Python/ceval.c:2034 #17 0x0807892b in PyEval_EvalCodeEx (co=0x81f9768, globals=0x8111ecc, locals=0x0, args=0x81cc34c, argcount=3, kws=0x81cc358, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2595 #18 0x0807aa43 in fast_function (func=0x815f78c, pp_stack=0xbfffef74, n=3, na=3, nk=0) at Python/ceval.c:3173 #19 0x080779b5 in eval_frame (f=0x81cc1f4) at Python/ceval.c:2034 (More stack frames follow...) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-17 13:43 Message: Logged In: YES user_id=33168 Can you post any code which causes the crash, even if it only crashes sometimes? Can you build python with ./configure --with-pydebug and run your program? This may find the problem closer to the cause. ---------------------------------------------------------------------- Comment By: Gregory Popovitch (greg7mdp) Date: 2003-01-17 12:05 Message: Logged In: YES user_id=222034 I forgot to mention that this program is using the "exec()" builtin heavily, and I believe that the crash is related to this. gregory ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669838&group_id=5470 From noreply@sourceforge.net Sat Jan 18 05:16:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 17 Jan 2003 21:16:18 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-443775 ] Update to the BEGIN_ALLOW_THREADS macros Message-ID: Feature Requests item #443775, was opened at 2001-07-23 16:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=443775&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin Sjögren (msjogren) Assigned to: Nobody/Anonymous (nobody) Summary: Update to the BEGIN_ALLOW_THREADS macros Initial Comment: The Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS currently do not support supplying WHERE to save the thread state via an argument. I needed that for a project myself so I wrote the following: #ifdef WITH_THREAD # define MY_BEGIN_ALLOW_THREADS(st) \ { st = PyEval_SaveThread(); } # define MY_END_ALLOW_THREADS(st) \ { PyEval_RestoreThread(st); st = NULL; } #else # define MY_BEGIN_ALLOW_THREADS(st) # define MY_END_ALLOW_THREADS(st) { st = NULL; } #endif This has, of course, the drawback that whenever the Py_BEGIN_ALLOW_THREADS macro changes I have to change mine! Therefore, I propose that these macros (under different names certainly) or macros that work something like this (I can't have asymmetric { and } in them, since I needed to retrieve the thread state somewhere else) in the standard Python distribution. ---------------------------------------------------------------------- Comment By: Michael Dubner (dubnerm) Date: 2003-01-18 08:16 Message: Logged In: YES user_id=39274 I think that current Py_BEGIN/END_ALLOW_THREADS macroses model (with block) is choosen to enforce compile-time pairwise check. Isn't it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=443775&group_id=5470 From noreply@sourceforge.net Sat Jan 18 05:49:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 17 Jan 2003 21:49:40 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-478407 ] Need Windows os.link() support Message-ID: Feature Requests item #478407, was opened at 2001-11-05 22:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=478407&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Need Windows os.link() support Initial Comment: NTFS has (always?) had hard link support. This functionality is now exposed in Win32 starting with Windows 2000 [see CreateHardLink()]. I've added Windows support to os.link(). I've tried to support FAT, NT, 95 by doing a CopyFile(). 2000 support is enabled by defining _WIN32_WINNT=0x500 in pythoncore.dsp. When this is done, the redundant #include in errnomodule.c gives compilation errors. ---------------------------------------------------------------------- Comment By: Michael Dubner (dubnerm) Date: 2003-01-18 08:49 Message: Logged In: YES user_id=39274 Also one can create os.symlink() and os.readlink() for all windows versions after 95 - using shell links (like cygwin do for symlink emulation). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-05 22:35 Message: Logged In: NO I think that I forgot to add my email address: bcox@semio.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=478407&group_id=5470 From noreply@sourceforge.net Sat Jan 18 16:43:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 18 Jan 2003 08:43:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-670311 ] sys.exit and PYTHONINSPECT Message-ID: Bugs item #670311, was opened at 2003-01-18 08:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=670311&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kevin Altis (kasplat) Assigned to: Nobody/Anonymous (nobody) Summary: sys.exit and PYTHONINSPECT Initial Comment: If you invoke the Python interpreter with -i, then even sys.exit shouldn't kill the interpreter, especially since sys.exit generates a SystemExit exception which can be caught. I can't think of any other case where -i fails to keep the interpreter alive after a script exits, whether because of an syntax or runtime error or normal termination. I started a thread on python-dev about this issue: http://mail.python.org/pipermail/python-dev/2003- January/032217.html ka ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=670311&group_id=5470 From noreply@sourceforge.net Sat Jan 18 22:39:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 18 Jan 2003 14:39:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-668906 ] class browser raises AttributeError Message-ID: Bugs item #668906, was opened at 2003-01-16 00:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668906&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gregory Smith (gregsmith) >Assigned to: Raymond Hettinger (rhettinger) Summary: class browser raises AttributeError Initial Comment: On win32 (specifically win98) with 3.2: (1) start IDLE (2) open ..../Lib/copy.py (or anything, really) (3) File>Class Browser Exception in Tkinter callback Traceback (most recent call last): File "C:\BIN\PYTHON23\lib\lib-tk\Tkinter.py", line 1306, in __call__ return apply(self.func, args) File "C:\BIN\PYTHON23\Tools\idle\EditorWindow.py", line 385, in open_class_browser ClassBrowser.ClassBrowser(self.flist, base, [head]) File "C:\BIN\PYTHON23\Tools\idle\ClassBrowser.py", line 28, in __init__ self.init(flist) File "C:\BIN\PYTHON23\Tools\idle\ClassBrowser.py", line 50, in init node.expand() File "C:\BIN\PYTHON23\Tools\idle\TreeWidget.py", line 131, in expand self.update() File "C:\BIN\PYTHON23\Tools\idle\TreeWidget.py", line 170, in update self.draw(7, 2) File "C:\BIN\PYTHON23\Tools\idle\TreeWidget.py", line 184, in draw sublist = self.item._GetSubList() File "C:\BIN\PYTHON23\Tools\idle\TreeWidget.py", line 337, in _GetSubList sublist = self.GetSubList() File "C:\BIN\PYTHON23\Tools\idle\ClassBrowser.py", line 72, in GetSubList for name in self.listclasses(): File "C:\BIN\PYTHON23\Tools\idle\ClassBrowser.py", line 101, in listclasses if cl.super: AttributeError: Function instance has no attribute 'super' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668906&group_id=5470 From noreply@sourceforge.net Sat Jan 18 22:58:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 18 Jan 2003 14:58:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-668906 ] class browser raises AttributeError Message-ID: Bugs item #668906, was opened at 2003-01-16 00:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668906&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Raymond Hettinger (rhettinger) Summary: class browser raises AttributeError Initial Comment: On win32 (specifically win98) with 3.2: (1) start IDLE (2) open ..../Lib/copy.py (or anything, really) (3) File>Class Browser Exception in Tkinter callback Traceback (most recent call last): File "C:\BIN\PYTHON23\lib\lib-tk\Tkinter.py", line 1306, in __call__ return apply(self.func, args) File "C:\BIN\PYTHON23\Tools\idle\EditorWindow.py", line 385, in open_class_browser ClassBrowser.ClassBrowser(self.flist, base, [head]) File "C:\BIN\PYTHON23\Tools\idle\ClassBrowser.py", line 28, in __init__ self.init(flist) File "C:\BIN\PYTHON23\Tools\idle\ClassBrowser.py", line 50, in init node.expand() File "C:\BIN\PYTHON23\Tools\idle\TreeWidget.py", line 131, in expand self.update() File "C:\BIN\PYTHON23\Tools\idle\TreeWidget.py", line 170, in update self.draw(7, 2) File "C:\BIN\PYTHON23\Tools\idle\TreeWidget.py", line 184, in draw sublist = self.item._GetSubList() File "C:\BIN\PYTHON23\Tools\idle\TreeWidget.py", line 337, in _GetSubList sublist = self.GetSubList() File "C:\BIN\PYTHON23\Tools\idle\ClassBrowser.py", line 72, in GetSubList for name in self.listclasses(): File "C:\BIN\PYTHON23\Tools\idle\ClassBrowser.py", line 101, in listclasses if cl.super: AttributeError: Function instance has no attribute 'super' ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-18 17:58 Message: Logged In: YES user_id=80475 Fixed. See Tools/idle/ClassBrowser.py 1.15. Thanks for the clear bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668906&group_id=5470 From noreply@sourceforge.net Sun Jan 19 14:06:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 19 Jan 2003 06:06:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-595018 ] inspect.getsource shows incorrect output Message-ID: Bugs item #595018, was opened at 2002-08-14 06:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595018&group_id=5470 Category: Python Library Group: Python 2.2.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gregor Lingl (glingl) Assigned to: Ka-Ping Yee (ping) Summary: inspect.getsource shows incorrect output Initial Comment: example: >>> from turtle import * >>> from inspect import * >>> print getsource(up) def up(): _getpen().up() def down(): _getpen().down() def width(width): _getpen().width(width) def color(*args): apply(_getpen().color, args) def write(arg, move=0): _getpen().write(arg, move) def fill(flag): _getpen().fill(flag) def circle(radius, extent=None): _getpen().circle(radius, extent) def goto(*args): apply(_getpen().goto, args) def demo(): reset() tracer(1) # etc ... changing the form of the definition of up in turtle to: def up(): _getpen().up() results in: >>> print getsource(up) def up(): _getpen().up() >>> So the error probably occurs when parsing the sourcefile if functiondefinition is a oneliner ... Regards Gregor Lingl ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-19 09:06 Message: Logged In: YES user_id=80475 Fixed in Py2.3 with a possible backport to 2.2.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=595018&group_id=5470 From noreply@sourceforge.net Sun Jan 19 16:05:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 19 Jan 2003 08:05:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-625698 ] Errors with recursive objects Message-ID: Bugs item #625698, was opened at 2002-10-19 15:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: Works For Me Priority: 5 Submitted By: Erik Andersén (erik_andersen) Assigned to: Nobody/Anonymous (nobody) Summary: Errors with recursive objects Initial Comment: List and dictionaries put Python into an infinite loop if they contain more than one reference to itself >>> d = {} >>> d[1] = d >>> d == d # OK Python can handle one recursion 1 >>> d[2] = d >>> d == d # Crash with two Lists are similar >>> l=[] >>> l.append(l) >>> l==l # OK 1 >>> l.append(l) >>> l==l # Crash >>> l>l # Also crash Tested with ActivePython 2.2.1 under Windows 98 and (the first part) Python 2.2.2 under Linux ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-19 11:05 Message: Logged In: YES user_id=33168 Attached is a patch which fixes the problem for me. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 19:59 Message: Logged In: YES user_id=33168 Erik, do you still have this problem with 2.2.2? I can't reproduce your problem under Linux. mly can't reproduce the problems with 2.2.1 on Windows (2000). Do you only have the problem on Windows? ---------------------------------------------------------------------- Comment By: Magnus Lyckå (mly) Date: 2002-10-26 19:12 Message: Logged In: YES user_id=95217 I tried the above under Python 2.2.1 (#34, Sep 27 2002, 18:37:42) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. (ActiveState on Win 2000) and Python 2.1.1 (#1, Aug 20 2001, 20:23:29) [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.60mdk)] on linux-i386 In both cases it works correctly. No crash. It takes a lot of time though, Several seconds on Duron 700 w/ Win2k, and tens of seconds on K6-233 w/ Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 From noreply@sourceforge.net Sun Jan 19 17:30:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 19 Jan 2003 09:30:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-625698 ] Errors with recursive objects Message-ID: Bugs item #625698, was opened at 2002-10-19 21:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 Category: Python Interpreter Core Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Erik Andersén (erik_andersen) >Assigned to: Neal Norwitz (nnorwitz) Summary: Errors with recursive objects Initial Comment: List and dictionaries put Python into an infinite loop if they contain more than one reference to itself >>> d = {} >>> d[1] = d >>> d == d # OK Python can handle one recursion 1 >>> d[2] = d >>> d == d # Crash with two Lists are similar >>> l=[] >>> l.append(l) >>> l==l # OK 1 >>> l.append(l) >>> l==l # Crash >>> l>l # Also crash Tested with ActivePython 2.2.1 under Windows 98 and (the first part) Python 2.2.2 under Linux ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-19 18:30 Message: Logged In: YES user_id=21627 The patch is fine, except that a comment needs to be added explaining what this does and why it does that. It should be understood that this can't fix the very similar case a = [] a.append(a) a.append(a) b = [] b.append(b) b.append(b) a==b This would still take a long time, right? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-19 17:05 Message: Logged In: YES user_id=33168 Attached is a patch which fixes the problem for me. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-08 01:59 Message: Logged In: YES user_id=33168 Erik, do you still have this problem with 2.2.2? I can't reproduce your problem under Linux. mly can't reproduce the problems with 2.2.1 on Windows (2000). Do you only have the problem on Windows? ---------------------------------------------------------------------- Comment By: Magnus Lyckå (mly) Date: 2002-10-27 01:12 Message: Logged In: YES user_id=95217 I tried the above under Python 2.2.1 (#34, Sep 27 2002, 18:37:42) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. (ActiveState on Win 2000) and Python 2.1.1 (#1, Aug 20 2001, 20:23:29) [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.60mdk)] on linux-i386 In both cases it works correctly. No crash. It takes a lot of time though, Several seconds on Duron 700 w/ Win2k, and tens of seconds on K6-233 w/ Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 From noreply@sourceforge.net Sun Jan 19 17:38:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 19 Jan 2003 09:38:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-669859 ] socket.inet_aton() succeeds on invalid input Message-ID: Bugs item #669859, was opened at 2003-01-17 18:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669859&group_id=5470 Category: Python Library Group: Python 2.2 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Matt Beaumont (mbeaumon) Assigned to: Nobody/Anonymous (nobody) Summary: socket.inet_aton() succeeds on invalid input Initial Comment: Given a string such as "5.6.7", inet_aton() returns '\x05\x06\x00\x07'. In C (using libraries installed with RedHat 7.2), the equivalent call returns 0, indicating that the address is invalid. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-19 18:38 Message: Logged In: YES user_id=21627 I can't see the problem. First, 5.6.7 is really a valid denotation of an IP number, and denotes the IP address 5.6.0.7, just like 10.13 denotes 10.0.0.13. Furthermore, Python uses inet_addr on the C level, which does not return a status; for the address given, it returns exactly the same result that you see in Python. Finally, I cannot reproduce inet_aton(3) returning an error: on my installation (SuSE 8.1), it returns 1, indicating success. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669859&group_id=5470 From noreply@sourceforge.net Sun Jan 19 19:35:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 19 Jan 2003 11:35:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-660144 ] typeobject provides incorrect __mul__ Message-ID: Bugs item #660144, was opened at 2002-12-30 20:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660144&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Guido van Rossum (gvanrossum) Summary: typeobject provides incorrect __mul__ Initial Comment: type __mul__ is wierd: >> 'a'.__mul__(3.4) 'aaa' >>> [1].__mul__(3.4) [1, 1, 1] Floating point numbers with fractions should not be accepted. I think the problem is that __mul__ should not be trying to implement sq_repeat behavior (although I haven't dug deeply into this problem yet). Also, I think the code is vulnerable to integer overflow. Should also check __imul__ __add__ __iadd__. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2003-01-19 19:35 Message: Logged In: YES user_id=35752 The small patch is attached. I only added the checking for 'i' and 'l'. I wonder if it should be done for the other integer codes as well (e.g. 'b', 'h'). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-17 00:19 Message: Logged In: YES user_id=6380 Yes, this should go into 2.3a2. Your attachment upload failed somehow. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-01-16 23:10 Message: Logged In: YES user_id=35752 Would this be a change for the 2.3 release? I tried adding a PyFloat_Check test to 'i' and 'l' in getargs.c. It looks like all the unit tests pass. I agree that checking for float catches the important cases. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-16 21:57 Message: Logged In: YES user_id=6380 This is an age-old problem that crops up whenever "i" and similar format codes are used. The problem is that on the one hand you want "i" to accept other int-ish types that have an __int__ method. But on the other hand you don't want it to accept float, which also has an __int__ method. Or other float-ish types. I think the "i" format code has to be fixe, but I'm not sure how -- maybe as a start it would be sufficient to test explicitly for float and its subclasses and reject those. That would still allow 3rd party float-ish classes that implement __int__, but that's not so important. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-01-16 21:33 Message: Logged In: YES user_id=35752 I think the problem is that wrap_intargfunc and wrap_intintargfunc use PyArg_ParseTuple(args, "i", &i). This bug also is present in methods like __getitem__: >>> "Python"[1.2] Traceback (most recent call last): File "", line 1, in ? TypeError: sequence index must be integer >>> "Python".__getitem__(1.2) 'y' I think the right fix is to use explictly only allow only ints and longs to wrap_intargfunc and friends. If Guido agrees I will cook up a patch. It seems like we should have a code for PyParse_Tuple that only allows ints and longs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660144&group_id=5470 From noreply@sourceforge.net Sun Jan 19 21:37:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 19 Jan 2003 13:37:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-670816 ] pickles are way slow Message-ID: Bugs item #670816, was opened at 2003-01-19 13:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=670816&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: pickles are way slow Initial Comment: I'm using Python pickles as the external representation for passing structured data from a C app to a Python app. (Integrating the C app through Python's C API is not an option.) The data consists of many relatively small objects organized into large, moderately deep trees. What I've found is that a good 1/3 of the time in the Python app is spent loading the pickles, even with cPickle. As far as I can tell, the main reason for this is an inordinate amount of time spent looking up class names because classes, unlike all other objects in the pickle file, cannot be "memoized", but must be looked up from strings each time. Currently, instances are represented by the following sequence of pickle tags: MARK << possible constructor arguments >> INST modulename \n classname \n ... I propose adding two new tags, CLASS and CONSTRUCT. CLASS modulename \n classname \n does the first part of INST -- look up the class name. However, it then pushes the class object on the stack rather than instantiating it. CONSTRUCT does the second part of INST, but takes the class object from the stack rather than reading and looking up the name. Using these two tags with PUT and GET allows classes to be memoized efficiently just like other objects. I believe no security issues are introduced: CONSTRUCT would do the same checks as INST. I estimate the total amount of new code to be under 100 lines of C and Python combined (assuming that the pickle writing code is also changed to take advantage of the new tags). I'm willing to write and test the code, for both pickle.py and cPickle.c, but I don't know how to submit it for approval and release. If someone can tell me the process, I don't think it would take me very long to do the implementation. TIA. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=670816&group_id=5470 From noreply@sourceforge.net Sun Jan 19 21:48:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 19 Jan 2003 13:48:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-670816 ] pickles are way slow Message-ID: Bugs item #670816, was opened at 2003-01-19 16:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=670816&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: pickles are way slow Initial Comment: I'm using Python pickles as the external representation for passing structured data from a C app to a Python app. (Integrating the C app through Python's C API is not an option.) The data consists of many relatively small objects organized into large, moderately deep trees. What I've found is that a good 1/3 of the time in the Python app is spent loading the pickles, even with cPickle. As far as I can tell, the main reason for this is an inordinate amount of time spent looking up class names because classes, unlike all other objects in the pickle file, cannot be "memoized", but must be looked up from strings each time. Currently, instances are represented by the following sequence of pickle tags: MARK << possible constructor arguments >> INST modulename \n classname \n ... I propose adding two new tags, CLASS and CONSTRUCT. CLASS modulename \n classname \n does the first part of INST -- look up the class name. However, it then pushes the class object on the stack rather than instantiating it. CONSTRUCT does the second part of INST, but takes the class object from the stack rather than reading and looking up the name. Using these two tags with PUT and GET allows classes to be memoized efficiently just like other objects. I believe no security issues are introduced: CONSTRUCT would do the same checks as INST. I estimate the total amount of new code to be under 100 lines of C and Python combined (assuming that the pickle writing code is also changed to take advantage of the new tags). I'm willing to write and test the code, for both pickle.py and cPickle.c, but I don't know how to submit it for approval and release. If someone can tell me the process, I don't think it would take me very long to do the implementation. TIA. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-19 16:48 Message: Logged In: YES user_id=33168 Below are some links which describe the process. You should probably verify your approach is acceptable on python-dev. http://www.python.org/dev/ http://www.python.org/dev/process.htmlhttp://www.python.org/patches/ Good Luck! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=670816&group_id=5470 From noreply@sourceforge.net Sun Jan 19 22:14:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 19 Jan 2003 14:14:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-670816 ] pickles are way slow Message-ID: Bugs item #670816, was opened at 2003-01-19 16:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=670816&group_id=5470 Category: Python Library Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: L. Peter Deutsch (lpd) >Assigned to: Guido van Rossum (gvanrossum) Summary: pickles are way slow Initial Comment: I'm using Python pickles as the external representation for passing structured data from a C app to a Python app. (Integrating the C app through Python's C API is not an option.) The data consists of many relatively small objects organized into large, moderately deep trees. What I've found is that a good 1/3 of the time in the Python app is spent loading the pickles, even with cPickle. As far as I can tell, the main reason for this is an inordinate amount of time spent looking up class names because classes, unlike all other objects in the pickle file, cannot be "memoized", but must be looked up from strings each time. Currently, instances are represented by the following sequence of pickle tags: MARK << possible constructor arguments >> INST modulename \n classname \n ... I propose adding two new tags, CLASS and CONSTRUCT. CLASS modulename \n classname \n does the first part of INST -- look up the class name. However, it then pushes the class object on the stack rather than instantiating it. CONSTRUCT does the second part of INST, but takes the class object from the stack rather than reading and looking up the name. Using these two tags with PUT and GET allows classes to be memoized efficiently just like other objects. I believe no security issues are introduced: CONSTRUCT would do the same checks as INST. I estimate the total amount of new code to be under 100 lines of C and Python combined (assuming that the pickle writing code is also changed to take advantage of the new tags). I'm willing to write and test the code, for both pickle.py and cPickle.c, but I don't know how to submit it for approval and release. If someone can tell me the process, I don't think it would take me very long to do the implementation. TIA. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-19 17:14 Message: Logged In: YES user_id=31435 Assigned to Guido, since he's currently looking at adding new pickle codes. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-19 16:48 Message: Logged In: YES user_id=33168 Below are some links which describe the process. You should probably verify your approach is acceptable on python-dev. http://www.python.org/dev/ http://www.python.org/dev/process.htmlhttp://www.python.org/patches/ Good Luck! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=670816&group_id=5470 From noreply@sourceforge.net Sun Jan 19 22:16:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 19 Jan 2003 14:16:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-670816 ] pickles are way slow Message-ID: Bugs item #670816, was opened at 2003-01-19 13:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=670816&group_id=5470 Category: Python Library Group: Python 2.2.1 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: L. Peter Deutsch (lpd) Assigned to: Guido van Rossum (gvanrossum) Summary: pickles are way slow Initial Comment: I'm using Python pickles as the external representation for passing structured data from a C app to a Python app. (Integrating the C app through Python's C API is not an option.) The data consists of many relatively small objects organized into large, moderately deep trees. What I've found is that a good 1/3 of the time in the Python app is spent loading the pickles, even with cPickle. As far as I can tell, the main reason for this is an inordinate amount of time spent looking up class names because classes, unlike all other objects in the pickle file, cannot be "memoized", but must be looked up from strings each time. Currently, instances are represented by the following sequence of pickle tags: MARK << possible constructor arguments >> INST modulename \n classname \n ... I propose adding two new tags, CLASS and CONSTRUCT. CLASS modulename \n classname \n does the first part of INST -- look up the class name. However, it then pushes the class object on the stack rather than instantiating it. CONSTRUCT does the second part of INST, but takes the class object from the stack rather than reading and looking up the name. Using these two tags with PUT and GET allows classes to be memoized efficiently just like other objects. I believe no security issues are introduced: CONSTRUCT would do the same checks as INST. I estimate the total amount of new code to be under 100 lines of C and Python combined (assuming that the pickle writing code is also changed to take advantage of the new tags). I'm willing to write and test the code, for both pickle.py and cPickle.c, but I don't know how to submit it for approval and release. If someone can tell me the process, I don't think it would take me very long to do the implementation. TIA. ---------------------------------------------------------------------- >Comment By: L. Peter Deutsch (lpd) Date: 2003-01-19 14:16 Message: Logged In: YES user_id=8861 Oops! The pickle format already does this, using the GLOBAL and OBJ tags. I just didn't read the code thoroughly enough to find them. My apologies for taking your time. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-19 14:14 Message: Logged In: YES user_id=31435 Assigned to Guido, since he's currently looking at adding new pickle codes. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-19 13:48 Message: Logged In: YES user_id=33168 Below are some links which describe the process. You should probably verify your approach is acceptable on python-dev. http://www.python.org/dev/ http://www.python.org/dev/process.htmlhttp://www.python.org/patches/ Good Luck! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=670816&group_id=5470 From noreply@sourceforge.net Sun Jan 19 22:59:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 19 Jan 2003 14:59:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-670845 ] IDE: "clear" and "cut" fail in output window Message-ID: Bugs item #670845, was opened at 2003-01-19 23:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=670845&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: IDE: "clear" and "cut" fail in output window Initial Comment: If the output window is frontmost and you use the Edit->Clear or Edit->Cut commands the IDE will crash in the WEClear or WECut call, with a "MacOS Error -9476". I tried both with and without a selection. This is with current CVS MacPython-OSX. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=670845&group_id=5470 From noreply@sourceforge.net Sun Jan 19 23:02:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 19 Jan 2003 15:02:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-554916 ] test_unicode fails in wide unicode build Message-ID: Bugs item #554916, was opened at 2002-05-11 18:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=554916&group_id=5470 Category: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: M.-A. Lemburg (lemburg) Summary: test_unicode fails in wide unicode build Initial Comment: Assigned somewhat arbitrarily. It's a roundtrip test, I think. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-20 00:02 Message: Logged In: YES user_id=38388 Michael, is the test still failing or can I close this ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-10 17:30 Message: Logged In: YES user_id=38388 I'm not exactly sure why things work again, but I do know that I looked into this some time ago. Perhaps I simply forgot to close the bug or one of the UTF-8 codec overhauls remedied the problem. Here's what I get with python 2.3 UCS4: >>> len(u'\U000d0000') 1 >>> len(u"\udb00\udc00") 2 >>> u'\U000d0000' == u"\udb00\udc00" False >>> len(unicode(u"\udb00\udc00".encode('utf-8'), 'utf-8')) 1 >>> len(unicode(u'\U000d0000'.encode('utf-8'), 'utf-8')) 1 This is what I get with Python 2.2.1: >>> len(u'\U000d0000') 2 >>> len(u"\udb00\udc00") 2 >>> u'\U000d0000' == u"\udb00\udc00" 1 >>> len(unicode(u"\udb00\udc00".encode('utf-8'), 'utf-8')) 2 >>> len(unicode(u'\U000d0000'.encode('utf-8'), 'utf-8')) 2 There's still a difference there, but the UTF-8 codec behaves consistently. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-09 14:57 Message: Logged In: YES user_id=6656 Hmm. The test has stopped failing, so maybe we can close this. I'd be happier if I knew why, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-13 16:06 Message: Logged In: YES user_id=6656 Even better: $ ./python Adding parser accelerators ... Done. Python 2.2.1 (#1, May 13 2002, 15:02:01) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> unicode(u"\udb00\udc00".encode("utf-8"), "utf-8") == u"\udb00\udc00" 0 [18762 refs] but the test passes. And there was me thinking that it wasn't a problem on the release22-maint branch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-13 15:58 Message: Logged In: YES user_id=6656 >>> a = u"\udb00\udc00" [20811 refs] >>> b = unicode(a.encode("utf-8"), "utf-8") [21061 refs] >>> a, b (u'\U000d0000', u'\U000d0000') [21063 refs] >>> len(a), len(b) (2, 1) [21063 refs] Erm...? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-05-13 15:38 Message: Logged In: YES user_id=89016 The minimal failing testcase is: >>> unicode(u"\udb00\udc00".encode("utf-8"), "utf-8") == u"\udb00\udc00" False which is strange, because they *seem* to be the same: u"\udb00\udc00" u'\U000d0000' >>> unicode(u"\udb00\udc00".encode("utf-8"), "utf-8") u'\U000d0000' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=554916&group_id=5470 From noreply@sourceforge.net Mon Jan 20 04:28:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 19 Jan 2003 20:28:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-625698 ] Errors with recursive objects Message-ID: Bugs item #625698, was opened at 2002-10-19 15:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Erik Andersén (erik_andersen) >Assigned to: Jeremy Hylton (jhylton) Summary: Errors with recursive objects Initial Comment: List and dictionaries put Python into an infinite loop if they contain more than one reference to itself >>> d = {} >>> d[1] = d >>> d == d # OK Python can handle one recursion 1 >>> d[2] = d >>> d == d # Crash with two Lists are similar >>> l=[] >>> l.append(l) >>> l==l # OK 1 >>> l.append(l) >>> l==l # Crash >>> l>l # Also crash Tested with ActivePython 2.2.1 under Windows 98 and (the first part) Python 2.2.2 under Linux ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-19 23:28 Message: Logged In: YES user_id=31435 The patch assumes "is" implies "==", which isn't necessarily so for rich comparisons. The attached patch cuts the time about in half, via: 1. Getting rid of the per-thread inprogress dicts, in favor of a shared inprogress dict. 2. Restoring the intent of the code that tuples be exempted (tuples can't be recursive). Rev 2.65 of tupleobject.c gave tuples a tp_as_mapping slot, breaking the intent of the code. 3. Changing the inprogress dict to map a tuple to the smallest value of compare_nesting at which the tuple was seen. delete_token() was changed to leave the token alone if the current compare_nesting value is greater than that. This allows tuples to stay in the dict longer. 4. Cutting NESTING_LIMIT from 20 to 19. This has a huge effect, because the algorithm is still basically exponential- time. The problem remaining is that the inprogress dict is still useless (and empty) so long as compare_nesting is less than NESTING_LIMIT. This can leave an exponential amount of work to be done to fight back up to NESTING_LIMIT. Leaving stuff in inprogress longer, and consulting inprogress regardless of the value of compare_nesting (provided that's gone over NESTING_LIMIT at least once) slashes the time to triviality. However, it isn't safe: we can't know that the addresses in the dict keys refer to the same objects then. We could if started storing into inprogress from the very start, but that would be a big speed hit for usual-case comparisons. I'd be happy to knock NESTING_LIMIT down more, though. Assigned to Jeremy, as IIRC this was his code originally. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-19 12:30 Message: Logged In: YES user_id=21627 The patch is fine, except that a comment needs to be added explaining what this does and why it does that. It should be understood that this can't fix the very similar case a = [] a.append(a) a.append(a) b = [] b.append(b) b.append(b) a==b This would still take a long time, right? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-19 11:05 Message: Logged In: YES user_id=33168 Attached is a patch which fixes the problem for me. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 19:59 Message: Logged In: YES user_id=33168 Erik, do you still have this problem with 2.2.2? I can't reproduce your problem under Linux. mly can't reproduce the problems with 2.2.1 on Windows (2000). Do you only have the problem on Windows? ---------------------------------------------------------------------- Comment By: Magnus Lyckå (mly) Date: 2002-10-26 19:12 Message: Logged In: YES user_id=95217 I tried the above under Python 2.2.1 (#34, Sep 27 2002, 18:37:42) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. (ActiveState on Win 2000) and Python 2.1.1 (#1, Aug 20 2001, 20:23:29) [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.60mdk)] on linux-i386 In both cases it works correctly. No crash. It takes a lot of time though, Several seconds on Duron 700 w/ Win2k, and tens of seconds on K6-233 w/ Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 From noreply@sourceforge.net Mon Jan 20 05:28:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 19 Jan 2003 21:28:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-666958 ] repr.repr not always safe Message-ID: Bugs item #666958, was opened at 2003-01-13 06:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666958&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: repr.repr not always safe Initial Comment: >>> class A: ... def __repr__(self): ... raise Exception ... def someMethod(self): ... pass ... >>> A() Traceback (most recent call last): File "", line 1, in ? File "", line 3, in __repr__ Exception >>> repr.repr(A()) '' >>> repr.repr(A().someMethod) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/repr.py", line 15, in repr return self.repr1(x, self.maxlevel) File "/usr/lib/python2.2/repr.py", line 24, in repr1 s = `x` File "", line ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-01-20 07:28 Message: Logged In: YES user_id=539787 Did you try to change the module name to, say, repr2 and then run it again? Any specific reason you named the module as an internal function? BTW, what is repr.repr supposed to do? Please supply the repr.py script, along with the full traceback. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-01-13 16:54 Message: Logged In: YES user_id=139309 I say it's a bug because it's inconsistent behavior. You can repr the class instance that throws during a __repr__ just fine ('' ), but you can't __repr__ a bound method of the class instance without throwing an exception. In fact, if the __repr__ of the class instance returns anything but a string, say it returns None for example, then the exception will bubble all the way up and you get no useful output from repr.repr. It's very annoying if you're doing something equivalent to, but more useful than: repr.repr([1, 2, 3, 4, A().someMethod, 6, 7, 8, A()]) Note that repr.repr([1, 2, 3, 4, A(), 6, 7, 8]) does not throw any exceptions. There should be some sort of graceful way to do it, no? I think it ought to handle the bound method broken instance case just like it handles the broken instance case directly. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-13 06:34 Message: Logged In: YES user_id=31435 Why do say this is a bug? If you raise an exception, yes, you get an exception. Most __repr__ *implementations* try hard not to raise any exceptions, but it's never guaranteed that they won't. For example, just about any __repr__ implementation may run out of memory while trying to build its result string, so MemoryError is almost always a possible exception. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666958&group_id=5470 From noreply@sourceforge.net Mon Jan 20 08:20:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 00:20:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-625698 ] Errors with recursive objects Message-ID: Bugs item #625698, was opened at 2002-10-19 21:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Erik Andersén (erik_andersen) Assigned to: Jeremy Hylton (jhylton) Summary: Errors with recursive objects Initial Comment: List and dictionaries put Python into an infinite loop if they contain more than one reference to itself >>> d = {} >>> d[1] = d >>> d == d # OK Python can handle one recursion 1 >>> d[2] = d >>> d == d # Crash with two Lists are similar >>> l=[] >>> l.append(l) >>> l==l # OK 1 >>> l.append(l) >>> l==l # Crash >>> l>l # Also crash Tested with ActivePython 2.2.1 under Windows 98 and (the first part) Python 2.2.2 under Linux ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-20 09:20 Message: Logged In: YES user_id=21627 Where does the documentation say that "is" may not imply ==? The check for recursion assumes this implication, anyway: if we meet the very same object, we infer that they are equal. What is the purpose of clear_inprogress_dict in your patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 05:28 Message: Logged In: YES user_id=31435 The patch assumes "is" implies "==", which isn't necessarily so for rich comparisons. The attached patch cuts the time about in half, via: 1. Getting rid of the per-thread inprogress dicts, in favor of a shared inprogress dict. 2. Restoring the intent of the code that tuples be exempted (tuples can't be recursive). Rev 2.65 of tupleobject.c gave tuples a tp_as_mapping slot, breaking the intent of the code. 3. Changing the inprogress dict to map a tuple to the smallest value of compare_nesting at which the tuple was seen. delete_token() was changed to leave the token alone if the current compare_nesting value is greater than that. This allows tuples to stay in the dict longer. 4. Cutting NESTING_LIMIT from 20 to 19. This has a huge effect, because the algorithm is still basically exponential- time. The problem remaining is that the inprogress dict is still useless (and empty) so long as compare_nesting is less than NESTING_LIMIT. This can leave an exponential amount of work to be done to fight back up to NESTING_LIMIT. Leaving stuff in inprogress longer, and consulting inprogress regardless of the value of compare_nesting (provided that's gone over NESTING_LIMIT at least once) slashes the time to triviality. However, it isn't safe: we can't know that the addresses in the dict keys refer to the same objects then. We could if started storing into inprogress from the very start, but that would be a big speed hit for usual-case comparisons. I'd be happy to knock NESTING_LIMIT down more, though. Assigned to Jeremy, as IIRC this was his code originally. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-19 18:30 Message: Logged In: YES user_id=21627 The patch is fine, except that a comment needs to be added explaining what this does and why it does that. It should be understood that this can't fix the very similar case a = [] a.append(a) a.append(a) b = [] b.append(b) b.append(b) a==b This would still take a long time, right? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-19 17:05 Message: Logged In: YES user_id=33168 Attached is a patch which fixes the problem for me. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-08 01:59 Message: Logged In: YES user_id=33168 Erik, do you still have this problem with 2.2.2? I can't reproduce your problem under Linux. mly can't reproduce the problems with 2.2.1 on Windows (2000). Do you only have the problem on Windows? ---------------------------------------------------------------------- Comment By: Magnus Lyckå (mly) Date: 2002-10-27 01:12 Message: Logged In: YES user_id=95217 I tried the above under Python 2.2.1 (#34, Sep 27 2002, 18:37:42) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. (ActiveState on Win 2000) and Python 2.1.1 (#1, Aug 20 2001, 20:23:29) [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.60mdk)] on linux-i386 In both cases it works correctly. No crash. It takes a lot of time though, Several seconds on Duron 700 w/ Win2k, and tens of seconds on K6-233 w/ Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 From noreply@sourceforge.net Mon Jan 20 09:07:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 01:07:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-670845 ] IDE: "clear" and "cut" fail in output window Message-ID: Bugs item #670845, was opened at 2003-01-19 23:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=670845&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) >Summary: IDE: "clear" and "cut" fail in output window Initial Comment: If the output window is frontmost and you use the Edit->Clear or Edit->Cut commands the IDE will crash in the WEClear or WECut call, with a "MacOS Error -9476". I tried both with and without a selection. This is with current CVS MacPython-OSX. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-01-20 10:07 Message: Logged In: YES user_id=92689 Fixed in rev. 1.13 of PyConsole.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=670845&group_id=5470 From noreply@sourceforge.net Mon Jan 20 10:12:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 02:12:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-554916 ] test_unicode fails in wide unicode build Message-ID: Bugs item #554916, was opened at 2002-05-11 17:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=554916&group_id=5470 Category: Unicode Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: M.-A. Lemburg (lemburg) Summary: test_unicode fails in wide unicode build Initial Comment: Assigned somewhat arbitrarily. It's a roundtrip test, I think. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-01-20 10:12 Message: Logged In: YES user_id=6656 Let's get rid of it. I still don't understand what happened, but we can worry about that if it resurfaces. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-19 23:02 Message: Logged In: YES user_id=38388 Michael, is the test still failing or can I close this ? ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-10-10 16:30 Message: Logged In: YES user_id=38388 I'm not exactly sure why things work again, but I do know that I looked into this some time ago. Perhaps I simply forgot to close the bug or one of the UTF-8 codec overhauls remedied the problem. Here's what I get with python 2.3 UCS4: >>> len(u'\U000d0000') 1 >>> len(u"\udb00\udc00") 2 >>> u'\U000d0000' == u"\udb00\udc00" False >>> len(unicode(u"\udb00\udc00".encode('utf-8'), 'utf-8')) 1 >>> len(unicode(u'\U000d0000'.encode('utf-8'), 'utf-8')) 1 This is what I get with Python 2.2.1: >>> len(u'\U000d0000') 2 >>> len(u"\udb00\udc00") 2 >>> u'\U000d0000' == u"\udb00\udc00" 1 >>> len(unicode(u"\udb00\udc00".encode('utf-8'), 'utf-8')) 2 >>> len(unicode(u'\U000d0000'.encode('utf-8'), 'utf-8')) 2 There's still a difference there, but the UTF-8 codec behaves consistently. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-10-09 13:57 Message: Logged In: YES user_id=6656 Hmm. The test has stopped failing, so maybe we can close this. I'd be happier if I knew why, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-13 15:06 Message: Logged In: YES user_id=6656 Even better: $ ./python Adding parser accelerators ... Done. Python 2.2.1 (#1, May 13 2002, 15:02:01) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> unicode(u"\udb00\udc00".encode("utf-8"), "utf-8") == u"\udb00\udc00" 0 [18762 refs] but the test passes. And there was me thinking that it wasn't a problem on the release22-maint branch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-13 14:58 Message: Logged In: YES user_id=6656 >>> a = u"\udb00\udc00" [20811 refs] >>> b = unicode(a.encode("utf-8"), "utf-8") [21061 refs] >>> a, b (u'\U000d0000', u'\U000d0000') [21063 refs] >>> len(a), len(b) (2, 1) [21063 refs] Erm...? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-05-13 14:38 Message: Logged In: YES user_id=89016 The minimal failing testcase is: >>> unicode(u"\udb00\udc00".encode("utf-8"), "utf-8") == u"\udb00\udc00" False which is strange, because they *seem* to be the same: u"\udb00\udc00" u'\U000d0000' >>> unicode(u"\udb00\udc00".encode("utf-8"), "utf-8") u'\U000d0000' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=554916&group_id=5470 From noreply@sourceforge.net Mon Jan 20 14:07:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 06:07:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-671175 ] test_format core dumps on cygwin Message-ID: Bugs item #671175, was opened at 2003-01-20 16:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671175&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_format core dumps on cygwin Initial Comment: './python Lib/test/test_format.py' casues segmentation fault. >From what I could see this happens AFTER the test finishes. (I''ve placed a print statement at the end of the file and it was printed). Attached the stack dump ... Miki ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671175&group_id=5470 From noreply@sourceforge.net Mon Jan 20 14:11:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 06:11:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-666958 ] repr.repr not always safe Message-ID: Bugs item #666958, was opened at 2003-01-12 23:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666958&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: repr.repr not always safe Initial Comment: >>> class A: ... def __repr__(self): ... raise Exception ... def someMethod(self): ... pass ... >>> A() Traceback (most recent call last): File "", line 1, in ? File "", line 3, in __repr__ Exception >>> repr.repr(A()) '' >>> repr.repr(A().someMethod) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/repr.py", line 15, in repr return self.repr1(x, self.maxlevel) File "/usr/lib/python2.2/repr.py", line 24, in repr1 s = `x` File "", line ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2003-01-20 09:11 Message: Logged In: YES user_id=139309 It's not my module, it comes with Python (at least in my 2.2, and 2.3 CVS HEAD). Look for yourself! The issue has nothing to do with the fact that it has the same name as the builtin. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-01-20 00:28 Message: Logged In: YES user_id=539787 Did you try to change the module name to, say, repr2 and then run it again? Any specific reason you named the module as an internal function? BTW, what is repr.repr supposed to do? Please supply the repr.py script, along with the full traceback. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-01-13 09:54 Message: Logged In: YES user_id=139309 I say it's a bug because it's inconsistent behavior. You can repr the class instance that throws during a __repr__ just fine ('' ), but you can't __repr__ a bound method of the class instance without throwing an exception. In fact, if the __repr__ of the class instance returns anything but a string, say it returns None for example, then the exception will bubble all the way up and you get no useful output from repr.repr. It's very annoying if you're doing something equivalent to, but more useful than: repr.repr([1, 2, 3, 4, A().someMethod, 6, 7, 8, A()]) Note that repr.repr([1, 2, 3, 4, A(), 6, 7, 8]) does not throw any exceptions. There should be some sort of graceful way to do it, no? I think it ought to handle the bound method broken instance case just like it handles the broken instance case directly. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-12 23:34 Message: Logged In: YES user_id=31435 Why do say this is a bug? If you raise an exception, yes, you get an exception. Most __repr__ *implementations* try hard not to raise any exceptions, but it's never guaranteed that they won't. For example, just about any __repr__ implementation may run out of memory while trying to build its result string, so MemoryError is almost always a possible exception. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666958&group_id=5470 From noreply@sourceforge.net Mon Jan 20 15:57:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 07:57:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-671175 ] test_format core dumps on cygwin Message-ID: Bugs item #671175, was opened at 2003-01-20 09:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671175&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) >Assigned to: Jason Tishler (jlt63) Summary: test_format core dumps on cygwin Initial Comment: './python Lib/test/test_format.py' casues segmentation fault. >From what I could see this happens AFTER the test finishes. (I''ve placed a print statement at the end of the file and it was printed). Attached the stack dump ... Miki ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-20 10:57 Message: Logged In: YES user_id=33168 There's no file attached. SF is broken, the file must be attached after creating the bug/patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671175&group_id=5470 From noreply@sourceforge.net Mon Jan 20 16:10:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 08:10:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-671175 ] test_format core dumps on cygwin Message-ID: Bugs item #671175, was opened at 2003-01-20 05:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671175&group_id=5470 Category: None Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Jason Tishler (jlt63) Summary: test_format core dumps on cygwin Initial Comment: './python Lib/test/test_format.py' casues segmentation fault. >From what I could see this happens AFTER the test finishes. (I''ve placed a print statement at the end of the file and it was printed). Attached the stack dump ... Miki ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-01-20 07:10 Message: Logged In: YES user_id=86216 This is a known Cygwin (i.e., newlib) bug: http://cygwin.com/ml/cygwin/2003-01/msg00047.html that has been fixed in CVS already. Please use the latest Cygwin snapshot: http://cygwin.com/snapshots/ or wait for the next Cygwin release. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-20 06:57 Message: Logged In: YES user_id=33168 There's no file attached. SF is broken, the file must be attached after creating the bug/patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671175&group_id=5470 From noreply@sourceforge.net Mon Jan 20 16:12:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 08:12:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-625698 ] Errors with recursive objects Message-ID: Bugs item #625698, was opened at 2002-10-19 15:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Erik Andersén (erik_andersen) Assigned to: Jeremy Hylton (jhylton) Summary: Errors with recursive objects Initial Comment: List and dictionaries put Python into an infinite loop if they contain more than one reference to itself >>> d = {} >>> d[1] = d >>> d == d # OK Python can handle one recursion 1 >>> d[2] = d >>> d == d # Crash with two Lists are similar >>> l=[] >>> l.append(l) >>> l==l # OK 1 >>> l.append(l) >>> l==l # Crash >>> l>l # Also crash Tested with ActivePython 2.2.1 under Windows 98 and (the first part) Python 2.2.2 under Linux ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-20 11:12 Message: Logged In: YES user_id=31435 I deleted my patch -- it didn't make sense. Martin, AFAIK the docs say nothing about the relationship (if any) between "is" and "==". It was deliberate intent that "is" not imply "==" for rich comparisons, though, in part so that IEEE-754 rules for NaN could be implemented by users. >>> class NaN: ... def __eq__(self, other): return False ... >>> n = NaN() >>> n is n True >>> n == n False >>> ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-20 03:20 Message: Logged In: YES user_id=21627 Where does the documentation say that "is" may not imply ==? The check for recursion assumes this implication, anyway: if we meet the very same object, we infer that they are equal. What is the purpose of clear_inprogress_dict in your patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-19 23:28 Message: Logged In: YES user_id=31435 The patch assumes "is" implies "==", which isn't necessarily so for rich comparisons. The attached patch cuts the time about in half, via: 1. Getting rid of the per-thread inprogress dicts, in favor of a shared inprogress dict. 2. Restoring the intent of the code that tuples be exempted (tuples can't be recursive). Rev 2.65 of tupleobject.c gave tuples a tp_as_mapping slot, breaking the intent of the code. 3. Changing the inprogress dict to map a tuple to the smallest value of compare_nesting at which the tuple was seen. delete_token() was changed to leave the token alone if the current compare_nesting value is greater than that. This allows tuples to stay in the dict longer. 4. Cutting NESTING_LIMIT from 20 to 19. This has a huge effect, because the algorithm is still basically exponential- time. The problem remaining is that the inprogress dict is still useless (and empty) so long as compare_nesting is less than NESTING_LIMIT. This can leave an exponential amount of work to be done to fight back up to NESTING_LIMIT. Leaving stuff in inprogress longer, and consulting inprogress regardless of the value of compare_nesting (provided that's gone over NESTING_LIMIT at least once) slashes the time to triviality. However, it isn't safe: we can't know that the addresses in the dict keys refer to the same objects then. We could if started storing into inprogress from the very start, but that would be a big speed hit for usual-case comparisons. I'd be happy to knock NESTING_LIMIT down more, though. Assigned to Jeremy, as IIRC this was his code originally. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-19 12:30 Message: Logged In: YES user_id=21627 The patch is fine, except that a comment needs to be added explaining what this does and why it does that. It should be understood that this can't fix the very similar case a = [] a.append(a) a.append(a) b = [] b.append(b) b.append(b) a==b This would still take a long time, right? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-19 11:05 Message: Logged In: YES user_id=33168 Attached is a patch which fixes the problem for me. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 19:59 Message: Logged In: YES user_id=33168 Erik, do you still have this problem with 2.2.2? I can't reproduce your problem under Linux. mly can't reproduce the problems with 2.2.1 on Windows (2000). Do you only have the problem on Windows? ---------------------------------------------------------------------- Comment By: Magnus Lyckå (mly) Date: 2002-10-26 19:12 Message: Logged In: YES user_id=95217 I tried the above under Python 2.2.1 (#34, Sep 27 2002, 18:37:42) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. (ActiveState on Win 2000) and Python 2.1.1 (#1, Aug 20 2001, 20:23:29) [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.60mdk)] on linux-i386 In both cases it works correctly. No crash. It takes a lot of time though, Several seconds on Duron 700 w/ Win2k, and tens of seconds on K6-233 w/ Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 From noreply@sourceforge.net Mon Jan 20 18:12:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 10:12:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-664584 ] test_ossaudiodev fails to run Message-ID: Bugs item #664584, was opened at 2003-01-08 14:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=664584&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Greg Ward (gward) Summary: test_ossaudiodev fails to run Initial Comment: This is Python CVS of 2003-01-08. test_ossaudiodev is skipped because ossaudiodev module itself is not being built and installed. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-20 13:12 Message: Logged In: YES user_id=33168 MAL, this is fixed for me, does it work for you now? Can we close this bug report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=664584&group_id=5470 From noreply@sourceforge.net Mon Jan 20 18:26:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 10:26:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-653301 ] py_compile does not return error code Message-ID: Bugs item #653301, was opened at 2002-12-13 10:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653301&group_id=5470 Category: Build Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Mark Ferris (mferris1) Assigned to: Nobody/Anonymous (nobody) Summary: py_compile does not return error code Initial Comment: Since py_compile.compile() does not return an error code, the compile_all module does not return an error code and my ant build process continues merrily along even though it should failOnError. This appears to be related to an incomplete fix for bug 412436. The download attached to that defect included changes to py_compile.py and compileall.py. It looks like the py_compile.py changes were not implemented. A simple fix that has been working for me is to change the py_compile.py file as follows. This diff was done against version 1.18 of py_compile.py: 69c69 < return 0 --- > return 83d82 < return 1 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-20 13:26 Message: Logged In: YES user_id=33168 An exception is now raised to indicate an error. The doraise flag must be set when calling py_compile.compile(). Does this satisfy your needs? Can we close this bug report? The change was Lib/py_compile.py 1.24 ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-03 07:23 Message: Logged In: YES user_id=92689 It indeed seems the fix for bug #412436 was not checked in completely. I'll add a note there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653301&group_id=5470 From noreply@sourceforge.net Mon Jan 20 18:27:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 10:27:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-664584 ] test_ossaudiodev fails to run Message-ID: Bugs item #664584, was opened at 2003-01-08 20:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=664584&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Greg Ward (gward) Summary: test_ossaudiodev fails to run Initial Comment: This is Python CVS of 2003-01-08. test_ossaudiodev is skipped because ossaudiodev module itself is not being built and installed. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-20 19:27 Message: Logged In: YES user_id=38388 Yes. ossaudiodev builds just fine now and the test no longer complains. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-20 19:12 Message: Logged In: YES user_id=33168 MAL, this is fixed for me, does it work for you now? Can we close this bug report? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=664584&group_id=5470 From noreply@sourceforge.net Mon Jan 20 18:29:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 10:29:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-638610 ] Instantiation init-less class with param Message-ID: Bugs item #638610, was opened at 2002-11-14 14:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=638610&group_id=5470 Category: Type/class unification >Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Shalabh Chaturvedi (shalabh) Assigned to: Nobody/Anonymous (nobody) Summary: Instantiation init-less class with param Initial Comment: Instantiation new style __init__-less class with parameters does not raise exception. Old style classes raise TypeError: this constructor takes no arguments. Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 >>> class C: ... pass ... >>> c = C('extra', 'params') Traceback (most recent call last): File "", line 1, in ? TypeError: this constructor takes no arguments >>> >>> class C(object): ... pass ... >>> c = C('whos','eating','my', 'params') >>> c <__main__.C object at 0x007A49B8> >>> Who? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-20 13:29 Message: Logged In: YES user_id=33168 Changed to 2.3 and bumped priority in the hopes that this can/will be fixed for 2.3. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-11-15 05:14 Message: Logged In: YES user_id=6656 This is known behaviour (at least, I knew about it ). This is why: >>> object(1,2,3) I seem to recall discussion that this had to be left alone in 2.2.X but should be fixed in 2.3... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-14 18:26 Message: Logged In: YES user_id=33168 Confirmed the behaviour in 2.2.2 and 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=638610&group_id=5470 From noreply@sourceforge.net Mon Jan 20 19:24:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 11:24:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-625698 ] Errors with recursive objects Message-ID: Bugs item #625698, was opened at 2002-10-19 19:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Erik Andersén (erik_andersen) Assigned to: Jeremy Hylton (jhylton) Summary: Errors with recursive objects Initial Comment: List and dictionaries put Python into an infinite loop if they contain more than one reference to itself >>> d = {} >>> d[1] = d >>> d == d # OK Python can handle one recursion 1 >>> d[2] = d >>> d == d # Crash with two Lists are similar >>> l=[] >>> l.append(l) >>> l==l # OK 1 >>> l.append(l) >>> l==l # Crash >>> l>l # Also crash Tested with ActivePython 2.2.1 under Windows 98 and (the first part) Python 2.2.2 under Linux ---------------------------------------------------------------------- >Comment By: Erik Andersén (erik_andersen) Date: 2003-01-20 19:24 Message: Logged In: YES user_id=364358 Excuse me for interupting the efficiency discussion, but what is the definition of equality for recursive containers. I am particularly worrided about cases like >>> class A: ... def __eq__(self,other): return not self.u==other.u ... >>> a=A() >>> l=[a] >>> a.u=l >>> l==l # ???? If l==l then a!=a and l[0]!=l[0], so l!=l. If l!=l then a==a and l[0]==l[0], so l==l !!!!!!! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 16:12 Message: Logged In: YES user_id=31435 I deleted my patch -- it didn't make sense. Martin, AFAIK the docs say nothing about the relationship (if any) between "is" and "==". It was deliberate intent that "is" not imply "==" for rich comparisons, though, in part so that IEEE-754 rules for NaN could be implemented by users. >>> class NaN: ... def __eq__(self, other): return False ... >>> n = NaN() >>> n is n True >>> n == n False >>> ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-20 08:20 Message: Logged In: YES user_id=21627 Where does the documentation say that "is" may not imply ==? The check for recursion assumes this implication, anyway: if we meet the very same object, we infer that they are equal. What is the purpose of clear_inprogress_dict in your patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 04:28 Message: Logged In: YES user_id=31435 The patch assumes "is" implies "==", which isn't necessarily so for rich comparisons. The attached patch cuts the time about in half, via: 1. Getting rid of the per-thread inprogress dicts, in favor of a shared inprogress dict. 2. Restoring the intent of the code that tuples be exempted (tuples can't be recursive). Rev 2.65 of tupleobject.c gave tuples a tp_as_mapping slot, breaking the intent of the code. 3. Changing the inprogress dict to map a tuple to the smallest value of compare_nesting at which the tuple was seen. delete_token() was changed to leave the token alone if the current compare_nesting value is greater than that. This allows tuples to stay in the dict longer. 4. Cutting NESTING_LIMIT from 20 to 19. This has a huge effect, because the algorithm is still basically exponential- time. The problem remaining is that the inprogress dict is still useless (and empty) so long as compare_nesting is less than NESTING_LIMIT. This can leave an exponential amount of work to be done to fight back up to NESTING_LIMIT. Leaving stuff in inprogress longer, and consulting inprogress regardless of the value of compare_nesting (provided that's gone over NESTING_LIMIT at least once) slashes the time to triviality. However, it isn't safe: we can't know that the addresses in the dict keys refer to the same objects then. We could if started storing into inprogress from the very start, but that would be a big speed hit for usual-case comparisons. I'd be happy to knock NESTING_LIMIT down more, though. Assigned to Jeremy, as IIRC this was his code originally. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-19 17:30 Message: Logged In: YES user_id=21627 The patch is fine, except that a comment needs to be added explaining what this does and why it does that. It should be understood that this can't fix the very similar case a = [] a.append(a) a.append(a) b = [] b.append(b) b.append(b) a==b This would still take a long time, right? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-19 16:05 Message: Logged In: YES user_id=33168 Attached is a patch which fixes the problem for me. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-08 00:59 Message: Logged In: YES user_id=33168 Erik, do you still have this problem with 2.2.2? I can't reproduce your problem under Linux. mly can't reproduce the problems with 2.2.1 on Windows (2000). Do you only have the problem on Windows? ---------------------------------------------------------------------- Comment By: Magnus Lyckå (mly) Date: 2002-10-26 23:12 Message: Logged In: YES user_id=95217 I tried the above under Python 2.2.1 (#34, Sep 27 2002, 18:37:42) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. (ActiveState on Win 2000) and Python 2.1.1 (#1, Aug 20 2001, 20:23:29) [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.60mdk)] on linux-i386 In both cases it works correctly. No crash. It takes a lot of time though, Several seconds on Duron 700 w/ Win2k, and tens of seconds on K6-233 w/ Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 From noreply@sourceforge.net Mon Jan 20 19:50:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 11:50:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-625698 ] Errors with recursive objects Message-ID: Bugs item #625698, was opened at 2002-10-19 15:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Erik Andersén (erik_andersen) Assigned to: Jeremy Hylton (jhylton) Summary: Errors with recursive objects Initial Comment: List and dictionaries put Python into an infinite loop if they contain more than one reference to itself >>> d = {} >>> d[1] = d >>> d == d # OK Python can handle one recursion 1 >>> d[2] = d >>> d == d # Crash with two Lists are similar >>> l=[] >>> l.append(l) >>> l==l # OK 1 >>> l.append(l) >>> l==l # Crash >>> l>l # Also crash Tested with ActivePython 2.2.1 under Windows 98 and (the first part) Python 2.2.2 under Linux ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-20 14:50 Message: Logged In: YES user_id=31435 Equailty for self-consistent recursive objects does a graph isomorphism computation. In your self-inconsistent example, it so happens that False is returned, although True would be returned if the compile-time constant (in object.c) NESTING_LIMIT were odd instead of even. But if you worry about this, you need to get out more . ---------------------------------------------------------------------- Comment By: Erik Andersén (erik_andersen) Date: 2003-01-20 14:24 Message: Logged In: YES user_id=364358 Excuse me for interupting the efficiency discussion, but what is the definition of equality for recursive containers. I am particularly worrided about cases like >>> class A: ... def __eq__(self,other): return not self.u==other.u ... >>> a=A() >>> l=[a] >>> a.u=l >>> l==l # ???? If l==l then a!=a and l[0]!=l[0], so l!=l. If l!=l then a==a and l[0]==l[0], so l==l !!!!!!! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 11:12 Message: Logged In: YES user_id=31435 I deleted my patch -- it didn't make sense. Martin, AFAIK the docs say nothing about the relationship (if any) between "is" and "==". It was deliberate intent that "is" not imply "==" for rich comparisons, though, in part so that IEEE-754 rules for NaN could be implemented by users. >>> class NaN: ... def __eq__(self, other): return False ... >>> n = NaN() >>> n is n True >>> n == n False >>> ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-20 03:20 Message: Logged In: YES user_id=21627 Where does the documentation say that "is" may not imply ==? The check for recursion assumes this implication, anyway: if we meet the very same object, we infer that they are equal. What is the purpose of clear_inprogress_dict in your patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-19 23:28 Message: Logged In: YES user_id=31435 The patch assumes "is" implies "==", which isn't necessarily so for rich comparisons. The attached patch cuts the time about in half, via: 1. Getting rid of the per-thread inprogress dicts, in favor of a shared inprogress dict. 2. Restoring the intent of the code that tuples be exempted (tuples can't be recursive). Rev 2.65 of tupleobject.c gave tuples a tp_as_mapping slot, breaking the intent of the code. 3. Changing the inprogress dict to map a tuple to the smallest value of compare_nesting at which the tuple was seen. delete_token() was changed to leave the token alone if the current compare_nesting value is greater than that. This allows tuples to stay in the dict longer. 4. Cutting NESTING_LIMIT from 20 to 19. This has a huge effect, because the algorithm is still basically exponential- time. The problem remaining is that the inprogress dict is still useless (and empty) so long as compare_nesting is less than NESTING_LIMIT. This can leave an exponential amount of work to be done to fight back up to NESTING_LIMIT. Leaving stuff in inprogress longer, and consulting inprogress regardless of the value of compare_nesting (provided that's gone over NESTING_LIMIT at least once) slashes the time to triviality. However, it isn't safe: we can't know that the addresses in the dict keys refer to the same objects then. We could if started storing into inprogress from the very start, but that would be a big speed hit for usual-case comparisons. I'd be happy to knock NESTING_LIMIT down more, though. Assigned to Jeremy, as IIRC this was his code originally. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-19 12:30 Message: Logged In: YES user_id=21627 The patch is fine, except that a comment needs to be added explaining what this does and why it does that. It should be understood that this can't fix the very similar case a = [] a.append(a) a.append(a) b = [] b.append(b) b.append(b) a==b This would still take a long time, right? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-19 11:05 Message: Logged In: YES user_id=33168 Attached is a patch which fixes the problem for me. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 19:59 Message: Logged In: YES user_id=33168 Erik, do you still have this problem with 2.2.2? I can't reproduce your problem under Linux. mly can't reproduce the problems with 2.2.1 on Windows (2000). Do you only have the problem on Windows? ---------------------------------------------------------------------- Comment By: Magnus Lyckå (mly) Date: 2002-10-26 19:12 Message: Logged In: YES user_id=95217 I tried the above under Python 2.2.1 (#34, Sep 27 2002, 18:37:42) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. (ActiveState on Win 2000) and Python 2.1.1 (#1, Aug 20 2001, 20:23:29) [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.60mdk)] on linux-i386 In both cases it works correctly. No crash. It takes a lot of time though, Several seconds on Duron 700 w/ Win2k, and tens of seconds on K6-233 w/ Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 From noreply@sourceforge.net Mon Jan 20 20:09:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 12:09:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-625698 ] Errors with recursive objects Message-ID: Bugs item #625698, was opened at 2002-10-19 15:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Erik Andersén (erik_andersen) Assigned to: Jeremy Hylton (jhylton) Summary: Errors with recursive objects Initial Comment: List and dictionaries put Python into an infinite loop if they contain more than one reference to itself >>> d = {} >>> d[1] = d >>> d == d # OK Python can handle one recursion 1 >>> d[2] = d >>> d == d # Crash with two Lists are similar >>> l=[] >>> l.append(l) >>> l==l # OK 1 >>> l.append(l) >>> l==l # Crash >>> l>l # Also crash Tested with ActivePython 2.2.1 under Windows 98 and (the first part) Python 2.2.2 under Linux ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-20 15:09 Message: Logged In: YES user_id=31435 BTW, Erik, what did you mean by "crash"? Nobody else has seen a crash here. You started the report by saying "infinite loop", which isn't the same thing as a crash. There isn't an infinite loop here either, although the algorithm can take astronomical amounts of time to finish (so may appear to be in an infinite loop). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 14:50 Message: Logged In: YES user_id=31435 Equailty for self-consistent recursive objects does a graph isomorphism computation. In your self-inconsistent example, it so happens that False is returned, although True would be returned if the compile-time constant (in object.c) NESTING_LIMIT were odd instead of even. But if you worry about this, you need to get out more . ---------------------------------------------------------------------- Comment By: Erik Andersén (erik_andersen) Date: 2003-01-20 14:24 Message: Logged In: YES user_id=364358 Excuse me for interupting the efficiency discussion, but what is the definition of equality for recursive containers. I am particularly worrided about cases like >>> class A: ... def __eq__(self,other): return not self.u==other.u ... >>> a=A() >>> l=[a] >>> a.u=l >>> l==l # ???? If l==l then a!=a and l[0]!=l[0], so l!=l. If l!=l then a==a and l[0]==l[0], so l==l !!!!!!! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 11:12 Message: Logged In: YES user_id=31435 I deleted my patch -- it didn't make sense. Martin, AFAIK the docs say nothing about the relationship (if any) between "is" and "==". It was deliberate intent that "is" not imply "==" for rich comparisons, though, in part so that IEEE-754 rules for NaN could be implemented by users. >>> class NaN: ... def __eq__(self, other): return False ... >>> n = NaN() >>> n is n True >>> n == n False >>> ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-20 03:20 Message: Logged In: YES user_id=21627 Where does the documentation say that "is" may not imply ==? The check for recursion assumes this implication, anyway: if we meet the very same object, we infer that they are equal. What is the purpose of clear_inprogress_dict in your patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-19 23:28 Message: Logged In: YES user_id=31435 The patch assumes "is" implies "==", which isn't necessarily so for rich comparisons. The attached patch cuts the time about in half, via: 1. Getting rid of the per-thread inprogress dicts, in favor of a shared inprogress dict. 2. Restoring the intent of the code that tuples be exempted (tuples can't be recursive). Rev 2.65 of tupleobject.c gave tuples a tp_as_mapping slot, breaking the intent of the code. 3. Changing the inprogress dict to map a tuple to the smallest value of compare_nesting at which the tuple was seen. delete_token() was changed to leave the token alone if the current compare_nesting value is greater than that. This allows tuples to stay in the dict longer. 4. Cutting NESTING_LIMIT from 20 to 19. This has a huge effect, because the algorithm is still basically exponential- time. The problem remaining is that the inprogress dict is still useless (and empty) so long as compare_nesting is less than NESTING_LIMIT. This can leave an exponential amount of work to be done to fight back up to NESTING_LIMIT. Leaving stuff in inprogress longer, and consulting inprogress regardless of the value of compare_nesting (provided that's gone over NESTING_LIMIT at least once) slashes the time to triviality. However, it isn't safe: we can't know that the addresses in the dict keys refer to the same objects then. We could if started storing into inprogress from the very start, but that would be a big speed hit for usual-case comparisons. I'd be happy to knock NESTING_LIMIT down more, though. Assigned to Jeremy, as IIRC this was his code originally. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-19 12:30 Message: Logged In: YES user_id=21627 The patch is fine, except that a comment needs to be added explaining what this does and why it does that. It should be understood that this can't fix the very similar case a = [] a.append(a) a.append(a) b = [] b.append(b) b.append(b) a==b This would still take a long time, right? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-19 11:05 Message: Logged In: YES user_id=33168 Attached is a patch which fixes the problem for me. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 19:59 Message: Logged In: YES user_id=33168 Erik, do you still have this problem with 2.2.2? I can't reproduce your problem under Linux. mly can't reproduce the problems with 2.2.1 on Windows (2000). Do you only have the problem on Windows? ---------------------------------------------------------------------- Comment By: Magnus Lyckå (mly) Date: 2002-10-26 19:12 Message: Logged In: YES user_id=95217 I tried the above under Python 2.2.1 (#34, Sep 27 2002, 18:37:42) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. (ActiveState on Win 2000) and Python 2.1.1 (#1, Aug 20 2001, 20:23:29) [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.60mdk)] on linux-i386 In both cases it works correctly. No crash. It takes a lot of time though, Several seconds on Duron 700 w/ Win2k, and tens of seconds on K6-233 w/ Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 From noreply@sourceforge.net Mon Jan 20 20:20:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 12:20:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-625698 ] Errors with recursive objects Message-ID: Bugs item #625698, was opened at 2002-10-19 15:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Erik Andersén (erik_andersen) Assigned to: Jeremy Hylton (jhylton) Summary: Errors with recursive objects Initial Comment: List and dictionaries put Python into an infinite loop if they contain more than one reference to itself >>> d = {} >>> d[1] = d >>> d == d # OK Python can handle one recursion 1 >>> d[2] = d >>> d == d # Crash with two Lists are similar >>> l=[] >>> l.append(l) >>> l==l # OK 1 >>> l.append(l) >>> l==l # Crash >>> l>l # Also crash Tested with ActivePython 2.2.1 under Windows 98 and (the first part) Python 2.2.2 under Linux ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-20 15:20 Message: Logged In: YES user_id=33168 Sorry Tim, I was going to reply to one of your first msgs and forgot. Erik sent me mail which said there wasn't a crash, just that "the statements take horrendously long time to execute." ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 15:09 Message: Logged In: YES user_id=31435 BTW, Erik, what did you mean by "crash"? Nobody else has seen a crash here. You started the report by saying "infinite loop", which isn't the same thing as a crash. There isn't an infinite loop here either, although the algorithm can take astronomical amounts of time to finish (so may appear to be in an infinite loop). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 14:50 Message: Logged In: YES user_id=31435 Equailty for self-consistent recursive objects does a graph isomorphism computation. In your self-inconsistent example, it so happens that False is returned, although True would be returned if the compile-time constant (in object.c) NESTING_LIMIT were odd instead of even. But if you worry about this, you need to get out more . ---------------------------------------------------------------------- Comment By: Erik Andersén (erik_andersen) Date: 2003-01-20 14:24 Message: Logged In: YES user_id=364358 Excuse me for interupting the efficiency discussion, but what is the definition of equality for recursive containers. I am particularly worrided about cases like >>> class A: ... def __eq__(self,other): return not self.u==other.u ... >>> a=A() >>> l=[a] >>> a.u=l >>> l==l # ???? If l==l then a!=a and l[0]!=l[0], so l!=l. If l!=l then a==a and l[0]==l[0], so l==l !!!!!!! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 11:12 Message: Logged In: YES user_id=31435 I deleted my patch -- it didn't make sense. Martin, AFAIK the docs say nothing about the relationship (if any) between "is" and "==". It was deliberate intent that "is" not imply "==" for rich comparisons, though, in part so that IEEE-754 rules for NaN could be implemented by users. >>> class NaN: ... def __eq__(self, other): return False ... >>> n = NaN() >>> n is n True >>> n == n False >>> ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-20 03:20 Message: Logged In: YES user_id=21627 Where does the documentation say that "is" may not imply ==? The check for recursion assumes this implication, anyway: if we meet the very same object, we infer that they are equal. What is the purpose of clear_inprogress_dict in your patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-19 23:28 Message: Logged In: YES user_id=31435 The patch assumes "is" implies "==", which isn't necessarily so for rich comparisons. The attached patch cuts the time about in half, via: 1. Getting rid of the per-thread inprogress dicts, in favor of a shared inprogress dict. 2. Restoring the intent of the code that tuples be exempted (tuples can't be recursive). Rev 2.65 of tupleobject.c gave tuples a tp_as_mapping slot, breaking the intent of the code. 3. Changing the inprogress dict to map a tuple to the smallest value of compare_nesting at which the tuple was seen. delete_token() was changed to leave the token alone if the current compare_nesting value is greater than that. This allows tuples to stay in the dict longer. 4. Cutting NESTING_LIMIT from 20 to 19. This has a huge effect, because the algorithm is still basically exponential- time. The problem remaining is that the inprogress dict is still useless (and empty) so long as compare_nesting is less than NESTING_LIMIT. This can leave an exponential amount of work to be done to fight back up to NESTING_LIMIT. Leaving stuff in inprogress longer, and consulting inprogress regardless of the value of compare_nesting (provided that's gone over NESTING_LIMIT at least once) slashes the time to triviality. However, it isn't safe: we can't know that the addresses in the dict keys refer to the same objects then. We could if started storing into inprogress from the very start, but that would be a big speed hit for usual-case comparisons. I'd be happy to knock NESTING_LIMIT down more, though. Assigned to Jeremy, as IIRC this was his code originally. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-19 12:30 Message: Logged In: YES user_id=21627 The patch is fine, except that a comment needs to be added explaining what this does and why it does that. It should be understood that this can't fix the very similar case a = [] a.append(a) a.append(a) b = [] b.append(b) b.append(b) a==b This would still take a long time, right? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-19 11:05 Message: Logged In: YES user_id=33168 Attached is a patch which fixes the problem for me. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 19:59 Message: Logged In: YES user_id=33168 Erik, do you still have this problem with 2.2.2? I can't reproduce your problem under Linux. mly can't reproduce the problems with 2.2.1 on Windows (2000). Do you only have the problem on Windows? ---------------------------------------------------------------------- Comment By: Magnus Lyckå (mly) Date: 2002-10-26 19:12 Message: Logged In: YES user_id=95217 I tried the above under Python 2.2.1 (#34, Sep 27 2002, 18:37:42) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. (ActiveState on Win 2000) and Python 2.1.1 (#1, Aug 20 2001, 20:23:29) [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.60mdk)] on linux-i386 In both cases it works correctly. No crash. It takes a lot of time though, Several seconds on Duron 700 w/ Win2k, and tens of seconds on K6-233 w/ Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 From noreply@sourceforge.net Mon Jan 20 20:44:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 12:44:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-625698 ] Errors with recursive objects Message-ID: Bugs item #625698, was opened at 2002-10-19 15:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Erik Andersén (erik_andersen) Assigned to: Jeremy Hylton (jhylton) Summary: Errors with recursive objects Initial Comment: List and dictionaries put Python into an infinite loop if they contain more than one reference to itself >>> d = {} >>> d[1] = d >>> d == d # OK Python can handle one recursion 1 >>> d[2] = d >>> d == d # Crash with two Lists are similar >>> l=[] >>> l.append(l) >>> l==l # OK 1 >>> l.append(l) >>> l==l # Crash >>> l>l # Also crash Tested with ActivePython 2.2.1 under Windows 98 and (the first part) Python 2.2.2 under Linux ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-20 15:44 Message: Logged In: YES user_id=31435 Cool. He's right that they can take a horrendously long time. The 2-element list example takes c*2**20 units of time, for some suitable constant c, and if it were extended to 3 elements, it would take c*3**20 units of time, thousands of times longer. As Erik's latest example shows, the outcome isn't always particularly well defined either. An alternative to speeding this silliness is to raise an exception instead when recursive objects are detected. There was some hack value in doing the graph isomorphism bit, but no real practical value I can see. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-20 15:20 Message: Logged In: YES user_id=33168 Sorry Tim, I was going to reply to one of your first msgs and forgot. Erik sent me mail which said there wasn't a crash, just that "the statements take horrendously long time to execute." ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 15:09 Message: Logged In: YES user_id=31435 BTW, Erik, what did you mean by "crash"? Nobody else has seen a crash here. You started the report by saying "infinite loop", which isn't the same thing as a crash. There isn't an infinite loop here either, although the algorithm can take astronomical amounts of time to finish (so may appear to be in an infinite loop). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 14:50 Message: Logged In: YES user_id=31435 Equailty for self-consistent recursive objects does a graph isomorphism computation. In your self-inconsistent example, it so happens that False is returned, although True would be returned if the compile-time constant (in object.c) NESTING_LIMIT were odd instead of even. But if you worry about this, you need to get out more . ---------------------------------------------------------------------- Comment By: Erik Andersén (erik_andersen) Date: 2003-01-20 14:24 Message: Logged In: YES user_id=364358 Excuse me for interupting the efficiency discussion, but what is the definition of equality for recursive containers. I am particularly worrided about cases like >>> class A: ... def __eq__(self,other): return not self.u==other.u ... >>> a=A() >>> l=[a] >>> a.u=l >>> l==l # ???? If l==l then a!=a and l[0]!=l[0], so l!=l. If l!=l then a==a and l[0]==l[0], so l==l !!!!!!! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 11:12 Message: Logged In: YES user_id=31435 I deleted my patch -- it didn't make sense. Martin, AFAIK the docs say nothing about the relationship (if any) between "is" and "==". It was deliberate intent that "is" not imply "==" for rich comparisons, though, in part so that IEEE-754 rules for NaN could be implemented by users. >>> class NaN: ... def __eq__(self, other): return False ... >>> n = NaN() >>> n is n True >>> n == n False >>> ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-20 03:20 Message: Logged In: YES user_id=21627 Where does the documentation say that "is" may not imply ==? The check for recursion assumes this implication, anyway: if we meet the very same object, we infer that they are equal. What is the purpose of clear_inprogress_dict in your patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-19 23:28 Message: Logged In: YES user_id=31435 The patch assumes "is" implies "==", which isn't necessarily so for rich comparisons. The attached patch cuts the time about in half, via: 1. Getting rid of the per-thread inprogress dicts, in favor of a shared inprogress dict. 2. Restoring the intent of the code that tuples be exempted (tuples can't be recursive). Rev 2.65 of tupleobject.c gave tuples a tp_as_mapping slot, breaking the intent of the code. 3. Changing the inprogress dict to map a tuple to the smallest value of compare_nesting at which the tuple was seen. delete_token() was changed to leave the token alone if the current compare_nesting value is greater than that. This allows tuples to stay in the dict longer. 4. Cutting NESTING_LIMIT from 20 to 19. This has a huge effect, because the algorithm is still basically exponential- time. The problem remaining is that the inprogress dict is still useless (and empty) so long as compare_nesting is less than NESTING_LIMIT. This can leave an exponential amount of work to be done to fight back up to NESTING_LIMIT. Leaving stuff in inprogress longer, and consulting inprogress regardless of the value of compare_nesting (provided that's gone over NESTING_LIMIT at least once) slashes the time to triviality. However, it isn't safe: we can't know that the addresses in the dict keys refer to the same objects then. We could if started storing into inprogress from the very start, but that would be a big speed hit for usual-case comparisons. I'd be happy to knock NESTING_LIMIT down more, though. Assigned to Jeremy, as IIRC this was his code originally. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-19 12:30 Message: Logged In: YES user_id=21627 The patch is fine, except that a comment needs to be added explaining what this does and why it does that. It should be understood that this can't fix the very similar case a = [] a.append(a) a.append(a) b = [] b.append(b) b.append(b) a==b This would still take a long time, right? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-19 11:05 Message: Logged In: YES user_id=33168 Attached is a patch which fixes the problem for me. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 19:59 Message: Logged In: YES user_id=33168 Erik, do you still have this problem with 2.2.2? I can't reproduce your problem under Linux. mly can't reproduce the problems with 2.2.1 on Windows (2000). Do you only have the problem on Windows? ---------------------------------------------------------------------- Comment By: Magnus Lyckå (mly) Date: 2002-10-26 19:12 Message: Logged In: YES user_id=95217 I tried the above under Python 2.2.1 (#34, Sep 27 2002, 18:37:42) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. (ActiveState on Win 2000) and Python 2.1.1 (#1, Aug 20 2001, 20:23:29) [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.60mdk)] on linux-i386 In both cases it works correctly. No crash. It takes a lot of time though, Several seconds on Duron 700 w/ Win2k, and tens of seconds on K6-233 w/ Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 From noreply@sourceforge.net Mon Jan 20 21:09:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 13:09:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-653301 ] py_compile does not return error code Message-ID: Bugs item #653301, was opened at 2002-12-13 15:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653301&group_id=5470 Category: Build Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Mark Ferris (mferris1) Assigned to: Nobody/Anonymous (nobody) Summary: py_compile does not return error code Initial Comment: Since py_compile.compile() does not return an error code, the compile_all module does not return an error code and my ant build process continues merrily along even though it should failOnError. This appears to be related to an incomplete fix for bug 412436. The download attached to that defect included changes to py_compile.py and compileall.py. It looks like the py_compile.py changes were not implemented. A simple fix that has been working for me is to change the py_compile.py file as follows. This diff was done against version 1.18 of py_compile.py: 69c69 < return 0 --- > return 83d82 < return 1 ---------------------------------------------------------------------- >Comment By: Mark Ferris (mferris1) Date: 2003-01-20 21:09 Message: Logged In: YES user_id=668563 As long as you include compileall.py 1.13+ version with the py_compile.py 1.24 change that was made, then it looks like the change made will satisfy my needs. Thanks! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-20 18:26 Message: Logged In: YES user_id=33168 An exception is now raised to indicate an error. The doraise flag must be set when calling py_compile.compile(). Does this satisfy your needs? Can we close this bug report? The change was Lib/py_compile.py 1.24 ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-03 12:23 Message: Logged In: YES user_id=92689 It indeed seems the fix for bug #412436 was not checked in completely. I'll add a note there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653301&group_id=5470 From noreply@sourceforge.net Mon Jan 20 21:12:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 13:12:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-653301 ] py_compile does not return error code Message-ID: Bugs item #653301, was opened at 2002-12-13 10:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653301&group_id=5470 Category: Build >Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mark Ferris (mferris1) Assigned to: Nobody/Anonymous (nobody) Summary: py_compile does not return error code Initial Comment: Since py_compile.compile() does not return an error code, the compile_all module does not return an error code and my ant build process continues merrily along even though it should failOnError. This appears to be related to an incomplete fix for bug 412436. The download attached to that defect included changes to py_compile.py and compileall.py. It looks like the py_compile.py changes were not implemented. A simple fix that has been working for me is to change the py_compile.py file as follows. This diff was done against version 1.18 of py_compile.py: 69c69 < return 0 --- > return 83d82 < return 1 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-20 16:12 Message: Logged In: YES user_id=33168 Ok, I'm closing this as Fixed, then. Thanks. ---------------------------------------------------------------------- Comment By: Mark Ferris (mferris1) Date: 2003-01-20 16:09 Message: Logged In: YES user_id=668563 As long as you include compileall.py 1.13+ version with the py_compile.py 1.24 change that was made, then it looks like the change made will satisfy my needs. Thanks! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-20 13:26 Message: Logged In: YES user_id=33168 An exception is now raised to indicate an error. The doraise flag must be set when calling py_compile.compile(). Does this satisfy your needs? Can we close this bug report? The change was Lib/py_compile.py 1.24 ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-03 07:23 Message: Logged In: YES user_id=92689 It indeed seems the fix for bug #412436 was not checked in completely. I'll add a note there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=653301&group_id=5470 From noreply@sourceforge.net Mon Jan 20 22:28:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 14:28:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-662787 ] test_signal hang on some Solaris boxes Message-ID: Bugs item #662787, was opened at 2003-01-05 14:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Anthony Baxter (anthonybaxter) Summary: test_signal hang on some Solaris boxes Initial Comment: Martin, I'm assigning this to you because you checked in the patch which caused this problem. I think your input on fixes will also be valuable. When semaphore support was added to Python/thread_pthread.h in 2.39 originally from patch 525532, it broke tests on some Solaris boxes. I know this affects Solaris 8, not sure if any other versions are affected. I believe on or more of the following Solaris 8 patches (108528, 108827) fixes the problem: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108528&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108827&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on Patches can be gotten from here: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access One way to fix the hang is to add #undef USE_SEMAPHORES at line 113 of Python/thread_pthread.h (ie, after USE_SEMAPHORES may be set). I don't know of any other way to fix this problem. I don't know if we can test for this in configure and set USE_SEMAPHORES appropriately (or if it's worth it). We can always disable USE_SEMAPHORES and allow the user to use it by manually setting the macro. We keep the code as is, and document the problem. Suggestions? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-20 17:28 Message: Logged In: YES user_id=33168 Martin, how do you want to proceed with this problem? ---------------------------------------------------------------------- Comment By: Inyeol Lee (inyeol) Date: 2003-01-10 13:15 Message: Logged In: YES user_id=595280 I patched my Solaris8 box and rebuilt 2.3a1 again. 'make test' still fails at test_signal. Martin's test code also fails. Installed patches are; Patch: 108528-07 Patch: 108528-13 Patch: 108528-18 Patch: 108827-07 Patch: 108827-15 Patch: 108827-35 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-08 12:21 Message: Logged In: YES user_id=33168 Sorry, that's really what I meant, only for Solaris 8. I'm not sure how to do that (figure out that we are on Solaris 8). I agree it would be nice to know the answer and suspect you are right that it's fixed. I don't know how to do that though. Hmmm, I think Anthony Baxter may have had Solaris. I'll assign this to him, in the hopes he can provide some more info. Anythony? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-08 12:15 Message: Logged In: YES user_id=21627 I quite object #2, although I could live with 5) disable USE_SEMAPHORES for Solaris 8 I would still like to find out whether applying all patches solves the problem. I'm quite certain that our code is correct and that there is a bug in Solaris. I'm reasonably certain that the bug has been fixed by now, so I would not want to leave USE_SEMAPHORES disabled forever on Solaris. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-08 12:11 Message: Logged In: YES user_id=33168 Martin, how do you think we should proceed with this problem? Some alternatives include: 1) try to build an autoconf test to find the problem and disable USE_SEMAPHORES 2) always disable USE_SEMAPHORES for Solaris 3) try to find a work-around 4) leave it as-is At least temporarily, I'd like to see #2. The problem is that if we do that, it will probably never get fixed. #1 is probably a lot of work. I can't implement #1 since I don't have access to a machine that works. Do you have any other ideas or possible solutions/work-arounds? ---------------------------------------------------------------------- Comment By: Inyeol Lee (inyeol) Date: 2003-01-06 22:46 Message: Logged In: YES user_id=595280 Neal, This is the patch version of my Solaris8 system you've requested; Patch: 108528-07 Patch: 108528-13 Patch: 108827-07 Patch: 108827-15 Inyeol Lee ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 09:46 Message: Logged In: YES user_id=21627 showrev -p is good, as is patchadd -p (this also shows the patches you could backup to). I notice that my Solaris 9 machine does not experience the problem, so Sun has fixed something. It would be good if a Solaris 8 machine could be brought up-to-date with regard to patches (they recommend -18 and -35 respectively, at the moment). On that machine, either those two patches selectively, or an entire patch cluster (8_Recommended.zip) should be installed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-06 08:44 Message: Logged In: YES user_id=33168 I thought I could not duplicate the hang on our sun, but now it's happening. Your test program also hangs. How do you determine the revision of a patch on solaris? I'm using showrev -p | grep patch-#. I'm not sure that is correct. The way I read it, it says I have 108528-16 and 108827-12. In the snake farm proton has: 108528-12 and 108827-12 fafner has: 108528-13 and 108827-19 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 07:29 Message: Logged In: YES user_id=21627 It would be good to find a system that has 108528-17 installed. I see that this fixes 4498831 system timer stops sending signals ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 07:13 Message: Logged In: YES user_id=21627 I meant revisions of the Sun patches. On one system, I have 108528-16 and 108827-34, and test_signal still hangs. I found that the blocking occurs when test_queue.py is run before, and have distilled this into the following example: import sys import thread import time import signal fsema = thread.allocate_lock() def tfunc(): time.sleep(.1) fsema.release() fsema.acquire() thread.start_new_thread(tfunc,()) fsema.acquire() fsema.release() signal.alarm(3) signal.pause() It appears that the alarm is simply lost; the pause call does not return. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 18:38 Message: Logged In: YES user_id=33168 What do you mean by revision of the patches? CVS revision of thread_pthread.h? I believe 2.38 worked and 2.39 broke. I can test that if you'd like. Do you want me to go back to the revision before the patch for all files affected? Since 2.39 only added the semaphores, in essence, by doing the #undef that should have the same effect as reverting thread_pthread.h to 2.38. Or are you talking about the Solaris patches? If so, they are only a guess, we could compare the patch level on all the Solaris boxes we have access to and see which ones work and which don't. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-05 18:11 Message: Logged In: YES user_id=21627 Could you identify a revision of these patches for which the problem disappears? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 15:57 Message: Logged In: YES user_id=33168 For (possibly) more info, see: http://lists.lysator.liu.se/pipermail/snake-farm/2003-January/000617.html ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 15:38 Message: Logged In: YES user_id=33168 Attaching output of truss (like strace for Solaris) which doesn't provide me with any more info. Hopefully this will help someone else. 2 files attached, one with complete output from; truss ./python -E -tt ./Lib/test/regrtest.py test_queue test_signal the other is just the end. It should correspond to these lines from the test: signal.alarm(20) # Entire test lasts at most 20 sec. signal.signal(5, handlerA) signal.signal(2, handlerB) signal.signal(3, signal.SIG_IGN) signal.signal(signal.SIGALRM, signal.default_int_handler) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 From noreply@sourceforge.net Mon Jan 20 22:45:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 14:45:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-671439 ] fix for 569257 isn't in 2.2.2 - __slots__ still not mangled Message-ID: Bugs item #671439, was opened at 2003-01-20 16:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671439&group_id=5470 Category: Type/class unification Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jess Austin (jessaustin) Assigned to: Nobody/Anonymous (nobody) Summary: fix for 569257 isn't in 2.2.2 - __slots__ still not mangled Initial Comment: hi, Perhaps this isn't the right way to notify you that a patch didn't make it in. If so I'm sorry. I'm concerned that the fix for bug #569257 didn't make it into Python 2.2.2 on Windows. My description of the bug, that I had written before I noticed #569257, follows. The original bug seems to have been resolved last June. I would have expected it to show up in 2.2.2. thanks, Jess Austin Variables listed in __slots__ for a new-style class that start with double underscores are not mangled. Entering the following code: class a(object): __slots__ = ['__x'] def __init__(self, x): self.__x = x m = a(1) Yields the following exception: Traceback (most recent call last): File "", line 1, in ? File "", line 4, in __init__ AttributeError: 'a' object has no attribute '_a__x' Whereas entering the following returns 1 just as one would expect: class b(object): __slots__ = ['_b__x'] def __init__(self, x): self.__x = x n = b(1) n._b__x ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671439&group_id=5470 From noreply@sourceforge.net Mon Jan 20 22:51:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 14:51:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-662787 ] test_signal hang on some Solaris boxes Message-ID: Bugs item #662787, was opened at 2003-01-05 20:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Martin v. Löwis (loewis) Summary: test_signal hang on some Solaris boxes Initial Comment: Martin, I'm assigning this to you because you checked in the patch which caused this problem. I think your input on fixes will also be valuable. When semaphore support was added to Python/thread_pthread.h in 2.39 originally from patch 525532, it broke tests on some Solaris boxes. I know this affects Solaris 8, not sure if any other versions are affected. I believe on or more of the following Solaris 8 patches (108528, 108827) fixes the problem: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108528&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108827&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on Patches can be gotten from here: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access One way to fix the hang is to add #undef USE_SEMAPHORES at line 113 of Python/thread_pthread.h (ie, after USE_SEMAPHORES may be set). I don't know of any other way to fix this problem. I don't know if we can test for this in configure and set USE_SEMAPHORES appropriately (or if it's worth it). We can always disable USE_SEMAPHORES and allow the user to use it by manually setting the macro. We keep the code as is, and document the problem. Suggestions? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-20 23:28 Message: Logged In: YES user_id=33168 Martin, how do you want to proceed with this problem? ---------------------------------------------------------------------- Comment By: Inyeol Lee (inyeol) Date: 2003-01-10 19:15 Message: Logged In: YES user_id=595280 I patched my Solaris8 box and rebuilt 2.3a1 again. 'make test' still fails at test_signal. Martin's test code also fails. Installed patches are; Patch: 108528-07 Patch: 108528-13 Patch: 108528-18 Patch: 108827-07 Patch: 108827-15 Patch: 108827-35 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-08 18:21 Message: Logged In: YES user_id=33168 Sorry, that's really what I meant, only for Solaris 8. I'm not sure how to do that (figure out that we are on Solaris 8). I agree it would be nice to know the answer and suspect you are right that it's fixed. I don't know how to do that though. Hmmm, I think Anthony Baxter may have had Solaris. I'll assign this to him, in the hopes he can provide some more info. Anythony? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-08 18:15 Message: Logged In: YES user_id=21627 I quite object #2, although I could live with 5) disable USE_SEMAPHORES for Solaris 8 I would still like to find out whether applying all patches solves the problem. I'm quite certain that our code is correct and that there is a bug in Solaris. I'm reasonably certain that the bug has been fixed by now, so I would not want to leave USE_SEMAPHORES disabled forever on Solaris. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-08 18:11 Message: Logged In: YES user_id=33168 Martin, how do you think we should proceed with this problem? Some alternatives include: 1) try to build an autoconf test to find the problem and disable USE_SEMAPHORES 2) always disable USE_SEMAPHORES for Solaris 3) try to find a work-around 4) leave it as-is At least temporarily, I'd like to see #2. The problem is that if we do that, it will probably never get fixed. #1 is probably a lot of work. I can't implement #1 since I don't have access to a machine that works. Do you have any other ideas or possible solutions/work-arounds? ---------------------------------------------------------------------- Comment By: Inyeol Lee (inyeol) Date: 2003-01-07 04:46 Message: Logged In: YES user_id=595280 Neal, This is the patch version of my Solaris8 system you've requested; Patch: 108528-07 Patch: 108528-13 Patch: 108827-07 Patch: 108827-15 Inyeol Lee ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 15:46 Message: Logged In: YES user_id=21627 showrev -p is good, as is patchadd -p (this also shows the patches you could backup to). I notice that my Solaris 9 machine does not experience the problem, so Sun has fixed something. It would be good if a Solaris 8 machine could be brought up-to-date with regard to patches (they recommend -18 and -35 respectively, at the moment). On that machine, either those two patches selectively, or an entire patch cluster (8_Recommended.zip) should be installed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-06 14:44 Message: Logged In: YES user_id=33168 I thought I could not duplicate the hang on our sun, but now it's happening. Your test program also hangs. How do you determine the revision of a patch on solaris? I'm using showrev -p | grep patch-#. I'm not sure that is correct. The way I read it, it says I have 108528-16 and 108827-12. In the snake farm proton has: 108528-12 and 108827-12 fafner has: 108528-13 and 108827-19 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 13:29 Message: Logged In: YES user_id=21627 It would be good to find a system that has 108528-17 installed. I see that this fixes 4498831 system timer stops sending signals ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 13:13 Message: Logged In: YES user_id=21627 I meant revisions of the Sun patches. On one system, I have 108528-16 and 108827-34, and test_signal still hangs. I found that the blocking occurs when test_queue.py is run before, and have distilled this into the following example: import sys import thread import time import signal fsema = thread.allocate_lock() def tfunc(): time.sleep(.1) fsema.release() fsema.acquire() thread.start_new_thread(tfunc,()) fsema.acquire() fsema.release() signal.alarm(3) signal.pause() It appears that the alarm is simply lost; the pause call does not return. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-06 00:38 Message: Logged In: YES user_id=33168 What do you mean by revision of the patches? CVS revision of thread_pthread.h? I believe 2.38 worked and 2.39 broke. I can test that if you'd like. Do you want me to go back to the revision before the patch for all files affected? Since 2.39 only added the semaphores, in essence, by doing the #undef that should have the same effect as reverting thread_pthread.h to 2.38. Or are you talking about the Solaris patches? If so, they are only a guess, we could compare the patch level on all the Solaris boxes we have access to and see which ones work and which don't. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 00:11 Message: Logged In: YES user_id=21627 Could you identify a revision of these patches for which the problem disappears? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 21:57 Message: Logged In: YES user_id=33168 For (possibly) more info, see: http://lists.lysator.liu.se/pipermail/snake-farm/2003-January/000617.html ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 21:38 Message: Logged In: YES user_id=33168 Attaching output of truss (like strace for Solaris) which doesn't provide me with any more info. Hopefully this will help someone else. 2 files attached, one with complete output from; truss ./python -E -tt ./Lib/test/regrtest.py test_queue test_signal the other is just the end. It should correspond to these lines from the test: signal.alarm(20) # Entire test lasts at most 20 sec. signal.signal(5, handlerA) signal.signal(2, handlerB) signal.signal(3, signal.SIG_IGN) signal.signal(signal.SIGALRM, signal.default_int_handler) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 From noreply@sourceforge.net Mon Jan 20 22:58:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 14:58:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-671447 ] StringIO doc doesn't say it's sometimes read-only Message-ID: Bugs item #671447, was opened at 2003-01-20 22:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671447&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Orr (hierro) Assigned to: Nobody/Anonymous (nobody) Summary: StringIO doc doesn't say it's sometimes read-only Initial Comment: When StringIO is instantiated with an intial string: StringIO("Hello, world!") it's read-only; the write methods don't exist. The Python Library Reference should mention this. If you instantiate StringIO without an initial string: StringIO() you get both read and write methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671447&group_id=5470 From noreply@sourceforge.net Mon Jan 20 22:58:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 14:58:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-668708 ] Py_NewInterpreter() doesn't work Message-ID: Bugs item #668708, was opened at 2003-01-15 12:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668708&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Geert Jansen (geertj) Assigned to: Nobody/Anonymous (nobody) Summary: Py_NewInterpreter() doesn't work Initial Comment: Hello, mod_python doesn't seem to work with Python 2.3a1. After some debugging, it seems the culprit is Py_NewInterpreter(). The following C program works with Python 2.2 but gives an error with Python 2.3: #include int main() { PyThreadState *tstate; Py_Initialize(); tstate = Py_NewInterpreter(); return 0; } The relevant part of this program's output: geertj@cristina:~$ PYTHONVERBOSE=1 ./a.out # installing zipimport hook import zipimport # builtin [...] import __builtin__ # previously loaded (__builtin__) import sys # previously loaded (sys) 'import site' failed; traceback: ImportError: No module named site It seems that Python is unable to find the module "site". Greetings, Geert Jansen ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2003-01-20 14:58 Message: Logged In: YES user_id=693077 The problem appears to be that meta_path is not being initialized in the new interpreter. Adding _PyImportHooks_Init to Py_NewInterpreter seems to fix the problem, initializing the new import hooks before trying to import modules into the new interpreter. ---------------------------------------------------------------------- Comment By: Geert Jansen (geertj) Date: 2003-01-15 12:19 Message: Logged In: YES user_id=537938 I forgot to mention that the Python version used is 2.3a1. Geert Jansen ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668708&group_id=5470 From noreply@sourceforge.net Mon Jan 20 23:12:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 15:12:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-671439 ] fix for 569257 isn't in 2.2.2 - __slots__ still not mangled Message-ID: Bugs item #671439, was opened at 2003-01-20 17:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671439&group_id=5470 Category: Type/class unification Group: Python 2.2.2 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jess Austin (jessaustin) Assigned to: Nobody/Anonymous (nobody) Summary: fix for 569257 isn't in 2.2.2 - __slots__ still not mangled Initial Comment: hi, Perhaps this isn't the right way to notify you that a patch didn't make it in. If so I'm sorry. I'm concerned that the fix for bug #569257 didn't make it into Python 2.2.2 on Windows. My description of the bug, that I had written before I noticed #569257, follows. The original bug seems to have been resolved last June. I would have expected it to show up in 2.2.2. thanks, Jess Austin Variables listed in __slots__ for a new-style class that start with double underscores are not mangled. Entering the following code: class a(object): __slots__ = ['__x'] def __init__(self, x): self.__x = x m = a(1) Yields the following exception: Traceback (most recent call last): File "", line 1, in ? File "", line 4, in __init__ AttributeError: 'a' object has no attribute '_a__x' Whereas entering the following returns 1 just as one would expect: class b(object): __slots__ = ['_b__x'] def __init__(self, x): self.__x = x n = b(1) n._b__x ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-20 18:12 Message: Logged In: YES user_id=33168 See Guido's comment on 2002-06-19 15:30 in the original bug report. He indicates that using mangled names in __slots__ should be considered a new feature. Therefore, there was no attempt to backport the change. I'm closing this bug for that reason. If you would like to see the feature backported, you should raise the issue on the mailing list python-dev@python.org. Submitting this bug report was fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671439&group_id=5470 From noreply@sourceforge.net Mon Jan 20 23:28:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 15:28:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-668708 ] Py_NewInterpreter() doesn't work Message-ID: Bugs item #668708, was opened at 2003-01-15 12:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668708&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Geert Jansen (geertj) Assigned to: Nobody/Anonymous (nobody) Summary: Py_NewInterpreter() doesn't work Initial Comment: Hello, mod_python doesn't seem to work with Python 2.3a1. After some debugging, it seems the culprit is Py_NewInterpreter(). The following C program works with Python 2.2 but gives an error with Python 2.3: #include int main() { PyThreadState *tstate; Py_Initialize(); tstate = Py_NewInterpreter(); return 0; } The relevant part of this program's output: geertj@cristina:~$ PYTHONVERBOSE=1 ./a.out # installing zipimport hook import zipimport # builtin [...] import __builtin__ # previously loaded (__builtin__) import sys # previously loaded (sys) 'import site' failed; traceback: ImportError: No module named site It seems that Python is unable to find the module "site". Greetings, Geert Jansen ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2003-01-20 15:28 Message: Logged In: YES user_id=693077 Patch 671459 seems to fix the problem. ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2003-01-20 14:58 Message: Logged In: YES user_id=693077 The problem appears to be that meta_path is not being initialized in the new interpreter. Adding _PyImportHooks_Init to Py_NewInterpreter seems to fix the problem, initializing the new import hooks before trying to import modules into the new interpreter. ---------------------------------------------------------------------- Comment By: Geert Jansen (geertj) Date: 2003-01-15 12:19 Message: Logged In: YES user_id=537938 I forgot to mention that the Python version used is 2.3a1. Geert Jansen ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668708&group_id=5470 From noreply@sourceforge.net Tue Jan 21 06:01:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 20 Jan 2003 22:01:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-625698 ] Errors with recursive objects Message-ID: Bugs item #625698, was opened at 2002-10-19 19:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Erik Andersén (erik_andersen) Assigned to: Jeremy Hylton (jhylton) Summary: Errors with recursive objects Initial Comment: List and dictionaries put Python into an infinite loop if they contain more than one reference to itself >>> d = {} >>> d[1] = d >>> d == d # OK Python can handle one recursion 1 >>> d[2] = d >>> d == d # Crash with two Lists are similar >>> l=[] >>> l.append(l) >>> l==l # OK 1 >>> l.append(l) >>> l==l # Crash >>> l>l # Also crash Tested with ActivePython 2.2.1 under Windows 98 and (the first part) Python 2.2.2 under Linux ---------------------------------------------------------------------- Comment By: Till Plewe (llit) Date: 2003-01-21 06:01 Message: Logged In: YES user_id=540660 How about checking for equality by trying to build a bisimulation which "proves" equality. Time complexity is O(nodes(a) x nodes(b)) SAMPLE PYTHON CODE =============================== #! /usr/bin/env python from types import * SeqType=[ListType,DictType,TupleType] def isequal(a,b): if id(a)==id(b): return True compare={(id(a),id(b)):(a,b)} bisimilar={} while compare: (ida,idb),(oba,obb)=compare.popitem() if ida==idb: continue elif type(oba)==type(obb): if type(oba) not in SeqType: if oba!=obb: return False else: continue elif len(oba)!=len(obb): return False elif (ida,idb) not in bisimilar: bisimilar[(ida,idb)]=1 if type(oba)==DictType: for x in oba: #oba and obb have the same number of keys if x not in obb: return False else: compare[(id(oba[x]),id(obb[x]))]=(oba[x],obb[x]) else: for x,y in zip(oba,obb): compare[(id(x),id(y))]=(x,y) else: return False return bisimilar ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 20:44 Message: Logged In: YES user_id=31435 Cool. He's right that they can take a horrendously long time. The 2-element list example takes c*2**20 units of time, for some suitable constant c, and if it were extended to 3 elements, it would take c*3**20 units of time, thousands of times longer. As Erik's latest example shows, the outcome isn't always particularly well defined either. An alternative to speeding this silliness is to raise an exception instead when recursive objects are detected. There was some hack value in doing the graph isomorphism bit, but no real practical value I can see. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-20 20:20 Message: Logged In: YES user_id=33168 Sorry Tim, I was going to reply to one of your first msgs and forgot. Erik sent me mail which said there wasn't a crash, just that "the statements take horrendously long time to execute." ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 20:09 Message: Logged In: YES user_id=31435 BTW, Erik, what did you mean by "crash"? Nobody else has seen a crash here. You started the report by saying "infinite loop", which isn't the same thing as a crash. There isn't an infinite loop here either, although the algorithm can take astronomical amounts of time to finish (so may appear to be in an infinite loop). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 19:50 Message: Logged In: YES user_id=31435 Equailty for self-consistent recursive objects does a graph isomorphism computation. In your self-inconsistent example, it so happens that False is returned, although True would be returned if the compile-time constant (in object.c) NESTING_LIMIT were odd instead of even. But if you worry about this, you need to get out more . ---------------------------------------------------------------------- Comment By: Erik Andersén (erik_andersen) Date: 2003-01-20 19:24 Message: Logged In: YES user_id=364358 Excuse me for interupting the efficiency discussion, but what is the definition of equality for recursive containers. I am particularly worrided about cases like >>> class A: ... def __eq__(self,other): return not self.u==other.u ... >>> a=A() >>> l=[a] >>> a.u=l >>> l==l # ???? If l==l then a!=a and l[0]!=l[0], so l!=l. If l!=l then a==a and l[0]==l[0], so l==l !!!!!!! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 16:12 Message: Logged In: YES user_id=31435 I deleted my patch -- it didn't make sense. Martin, AFAIK the docs say nothing about the relationship (if any) between "is" and "==". It was deliberate intent that "is" not imply "==" for rich comparisons, though, in part so that IEEE-754 rules for NaN could be implemented by users. >>> class NaN: ... def __eq__(self, other): return False ... >>> n = NaN() >>> n is n True >>> n == n False >>> ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-20 08:20 Message: Logged In: YES user_id=21627 Where does the documentation say that "is" may not imply ==? The check for recursion assumes this implication, anyway: if we meet the very same object, we infer that they are equal. What is the purpose of clear_inprogress_dict in your patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 04:28 Message: Logged In: YES user_id=31435 The patch assumes "is" implies "==", which isn't necessarily so for rich comparisons. The attached patch cuts the time about in half, via: 1. Getting rid of the per-thread inprogress dicts, in favor of a shared inprogress dict. 2. Restoring the intent of the code that tuples be exempted (tuples can't be recursive). Rev 2.65 of tupleobject.c gave tuples a tp_as_mapping slot, breaking the intent of the code. 3. Changing the inprogress dict to map a tuple to the smallest value of compare_nesting at which the tuple was seen. delete_token() was changed to leave the token alone if the current compare_nesting value is greater than that. This allows tuples to stay in the dict longer. 4. Cutting NESTING_LIMIT from 20 to 19. This has a huge effect, because the algorithm is still basically exponential- time. The problem remaining is that the inprogress dict is still useless (and empty) so long as compare_nesting is less than NESTING_LIMIT. This can leave an exponential amount of work to be done to fight back up to NESTING_LIMIT. Leaving stuff in inprogress longer, and consulting inprogress regardless of the value of compare_nesting (provided that's gone over NESTING_LIMIT at least once) slashes the time to triviality. However, it isn't safe: we can't know that the addresses in the dict keys refer to the same objects then. We could if started storing into inprogress from the very start, but that would be a big speed hit for usual-case comparisons. I'd be happy to knock NESTING_LIMIT down more, though. Assigned to Jeremy, as IIRC this was his code originally. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-19 17:30 Message: Logged In: YES user_id=21627 The patch is fine, except that a comment needs to be added explaining what this does and why it does that. It should be understood that this can't fix the very similar case a = [] a.append(a) a.append(a) b = [] b.append(b) b.append(b) a==b This would still take a long time, right? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-19 16:05 Message: Logged In: YES user_id=33168 Attached is a patch which fixes the problem for me. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-08 00:59 Message: Logged In: YES user_id=33168 Erik, do you still have this problem with 2.2.2? I can't reproduce your problem under Linux. mly can't reproduce the problems with 2.2.1 on Windows (2000). Do you only have the problem on Windows? ---------------------------------------------------------------------- Comment By: Magnus Lyckå (mly) Date: 2002-10-26 23:12 Message: Logged In: YES user_id=95217 I tried the above under Python 2.2.1 (#34, Sep 27 2002, 18:37:42) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. (ActiveState on Win 2000) and Python 2.1.1 (#1, Aug 20 2001, 20:23:29) [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.60mdk)] on linux-i386 In both cases it works correctly. No crash. It takes a lot of time though, Several seconds on Duron 700 w/ Win2k, and tens of seconds on K6-233 w/ Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 From noreply@sourceforge.net Tue Jan 21 10:18:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 02:18:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-662787 ] test_signal hang on some Solaris boxes Message-ID: Bugs item #662787, was opened at 2003-01-05 20:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Martin v. Löwis (loewis) Summary: test_signal hang on some Solaris boxes Initial Comment: Martin, I'm assigning this to you because you checked in the patch which caused this problem. I think your input on fixes will also be valuable. When semaphore support was added to Python/thread_pthread.h in 2.39 originally from patch 525532, it broke tests on some Solaris boxes. I know this affects Solaris 8, not sure if any other versions are affected. I believe on or more of the following Solaris 8 patches (108528, 108827) fixes the problem: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108528&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F108827&zone_32=signal+%20hang%20%22Sol aris%208%22&wholewords=on Patches can be gotten from here: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access One way to fix the hang is to add #undef USE_SEMAPHORES at line 113 of Python/thread_pthread.h (ie, after USE_SEMAPHORES may be set). I don't know of any other way to fix this problem. I don't know if we can test for this in configure and set USE_SEMAPHORES appropriately (or if it's worth it). We can always disable USE_SEMAPHORES and allow the user to use it by manually setting the macro. We keep the code as is, and document the problem. Suggestions? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-21 11:18 Message: Logged In: YES user_id=21627 This is fixed in configure 1.376 configure.in 1.387 pyconfig.h.in 1.70 thread_pthread.h 2.44 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-20 23:28 Message: Logged In: YES user_id=33168 Martin, how do you want to proceed with this problem? ---------------------------------------------------------------------- Comment By: Inyeol Lee (inyeol) Date: 2003-01-10 19:15 Message: Logged In: YES user_id=595280 I patched my Solaris8 box and rebuilt 2.3a1 again. 'make test' still fails at test_signal. Martin's test code also fails. Installed patches are; Patch: 108528-07 Patch: 108528-13 Patch: 108528-18 Patch: 108827-07 Patch: 108827-15 Patch: 108827-35 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-08 18:21 Message: Logged In: YES user_id=33168 Sorry, that's really what I meant, only for Solaris 8. I'm not sure how to do that (figure out that we are on Solaris 8). I agree it would be nice to know the answer and suspect you are right that it's fixed. I don't know how to do that though. Hmmm, I think Anthony Baxter may have had Solaris. I'll assign this to him, in the hopes he can provide some more info. Anythony? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-08 18:15 Message: Logged In: YES user_id=21627 I quite object #2, although I could live with 5) disable USE_SEMAPHORES for Solaris 8 I would still like to find out whether applying all patches solves the problem. I'm quite certain that our code is correct and that there is a bug in Solaris. I'm reasonably certain that the bug has been fixed by now, so I would not want to leave USE_SEMAPHORES disabled forever on Solaris. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-08 18:11 Message: Logged In: YES user_id=33168 Martin, how do you think we should proceed with this problem? Some alternatives include: 1) try to build an autoconf test to find the problem and disable USE_SEMAPHORES 2) always disable USE_SEMAPHORES for Solaris 3) try to find a work-around 4) leave it as-is At least temporarily, I'd like to see #2. The problem is that if we do that, it will probably never get fixed. #1 is probably a lot of work. I can't implement #1 since I don't have access to a machine that works. Do you have any other ideas or possible solutions/work-arounds? ---------------------------------------------------------------------- Comment By: Inyeol Lee (inyeol) Date: 2003-01-07 04:46 Message: Logged In: YES user_id=595280 Neal, This is the patch version of my Solaris8 system you've requested; Patch: 108528-07 Patch: 108528-13 Patch: 108827-07 Patch: 108827-15 Inyeol Lee ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 15:46 Message: Logged In: YES user_id=21627 showrev -p is good, as is patchadd -p (this also shows the patches you could backup to). I notice that my Solaris 9 machine does not experience the problem, so Sun has fixed something. It would be good if a Solaris 8 machine could be brought up-to-date with regard to patches (they recommend -18 and -35 respectively, at the moment). On that machine, either those two patches selectively, or an entire patch cluster (8_Recommended.zip) should be installed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-06 14:44 Message: Logged In: YES user_id=33168 I thought I could not duplicate the hang on our sun, but now it's happening. Your test program also hangs. How do you determine the revision of a patch on solaris? I'm using showrev -p | grep patch-#. I'm not sure that is correct. The way I read it, it says I have 108528-16 and 108827-12. In the snake farm proton has: 108528-12 and 108827-12 fafner has: 108528-13 and 108827-19 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 13:29 Message: Logged In: YES user_id=21627 It would be good to find a system that has 108528-17 installed. I see that this fixes 4498831 system timer stops sending signals ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 13:13 Message: Logged In: YES user_id=21627 I meant revisions of the Sun patches. On one system, I have 108528-16 and 108827-34, and test_signal still hangs. I found that the blocking occurs when test_queue.py is run before, and have distilled this into the following example: import sys import thread import time import signal fsema = thread.allocate_lock() def tfunc(): time.sleep(.1) fsema.release() fsema.acquire() thread.start_new_thread(tfunc,()) fsema.acquire() fsema.release() signal.alarm(3) signal.pause() It appears that the alarm is simply lost; the pause call does not return. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-06 00:38 Message: Logged In: YES user_id=33168 What do you mean by revision of the patches? CVS revision of thread_pthread.h? I believe 2.38 worked and 2.39 broke. I can test that if you'd like. Do you want me to go back to the revision before the patch for all files affected? Since 2.39 only added the semaphores, in essence, by doing the #undef that should have the same effect as reverting thread_pthread.h to 2.38. Or are you talking about the Solaris patches? If so, they are only a guess, we could compare the patch level on all the Solaris boxes we have access to and see which ones work and which don't. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-06 00:11 Message: Logged In: YES user_id=21627 Could you identify a revision of these patches for which the problem disappears? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 21:57 Message: Logged In: YES user_id=33168 For (possibly) more info, see: http://lists.lysator.liu.se/pipermail/snake-farm/2003-January/000617.html ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-05 21:38 Message: Logged In: YES user_id=33168 Attaching output of truss (like strace for Solaris) which doesn't provide me with any more info. Hopefully this will help someone else. 2 files attached, one with complete output from; truss ./python -E -tt ./Lib/test/regrtest.py test_queue test_signal the other is just the end. It should correspond to these lines from the test: signal.alarm(20) # Entire test lasts at most 20 sec. signal.signal(5, handlerA) signal.signal(2, handlerB) signal.signal(3, signal.SIG_IGN) signal.signal(signal.SIGALRM, signal.default_int_handler) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=662787&group_id=5470 From noreply@sourceforge.net Tue Jan 21 11:14:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 03:14:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-671731 ] time module: time tuple not returned by certain functions Message-ID: Bugs item #671731, was opened at 2003-01-21 03:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671731&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Martin Miller (mrmiller) Assigned to: Nobody/Anonymous (nobody) Summary: time module: time tuple not returned by certain functions Initial Comment: On win32 the gmtime() and localtime() functions in the time module return values of type 'time.time_struct'. I believe the proper return value should be a tuple. This is implied by the documentation (see where it discusses the *time tuple* returned by the various module functions and says it 'is a tuple of 9 integers'. The time_struct value returned does behave like a tuple instance in most respects, except that its type is not type 'tuple'. I think this is something that was changed in the not too distant past, as I noticed the issue after downloading code recently written by others which depends on the type of the return value from these functions being a tuple. If nothing else, if this was changed, it is not backward compatible and the documention ought to be updated. Example: > Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 > Type "help", "copyright", "credits" or "license" for more information. > >>> import time > >>> print time.localtime() > (2003, 1, 21, 3, 3, 2, 1, 21, 0) > >>> print type(time.localtime()) is type(()) > 0 > >>> print type(time.localtime()) > > >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671731&group_id=5470 From noreply@sourceforge.net Tue Jan 21 11:40:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 03:40:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-671731 ] time module: time tuple not returned by certain functions Message-ID: Bugs item #671731, was opened at 2003-01-21 11:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671731&group_id=5470 >Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Martin Miller (mrmiller) Assigned to: Nobody/Anonymous (nobody) Summary: time module: time tuple not returned by certain functions Initial Comment: On win32 the gmtime() and localtime() functions in the time module return values of type 'time.time_struct'. I believe the proper return value should be a tuple. This is implied by the documentation (see where it discusses the *time tuple* returned by the various module functions and says it 'is a tuple of 9 integers'. The time_struct value returned does behave like a tuple instance in most respects, except that its type is not type 'tuple'. I think this is something that was changed in the not too distant past, as I noticed the issue after downloading code recently written by others which depends on the type of the return value from these functions being a tuple. If nothing else, if this was changed, it is not backward compatible and the documention ought to be updated. Example: > Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 > Type "help", "copyright", "credits" or "license" for more information. > >>> import time > >>> print time.localtime() > (2003, 1, 21, 3, 3, 2, 1, 21, 0) > >>> print type(time.localtime()) is type(()) > 0 > >>> print type(time.localtime()) > > >>> ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-01-21 11:40 Message: Logged In: YES user_id=6656 This was very deliberate. It *is* a bit shocking that the docs didn't get updated, though. There's a start of a description in: http://www.python.org/doc/current/whatsnew/node10.html Do you have code that actually broke because of this change? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671731&group_id=5470 From noreply@sourceforge.net Tue Jan 21 12:06:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 04:06:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-671741 ] Tk.IntVar.get fails after set(True) in 2.3a1 Message-ID: Bugs item #671741, was opened at 2003-01-21 12:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671741&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Edward K. Ream (edream) Assigned to: Nobody/Anonymous (nobody) Summary: Tk.IntVar.get fails after set(True) in 2.3a1 Initial Comment: Executing the following fails in 2.3a1. Similar code works in 2.1 and 2.2. def truebug(): import Tkinter Tk = Tkinter top = Tk.Toplevel() f = Tk.Frame(top) f.pack() var = Tk.IntVar() box = Tk.Checkbutton(f, anchor="w", text="box",variable=var) box.pack() var.set(True) val = var.get() Example: Microsoft Windows XP [Version 5.1.2600] ... Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC v.1200 32 bit (Intel)] on win32 ... >>> import truebug >>> truebug.truebug() Traceback (most recent call last): File "", line 1, in ? File "c:\prog\test\truebug.py", line 15, in truebug val = var.get() File "C:\PYTHON23\lib\lib-tk\Tkinter.py", line 239, in get return getint(self._tk.globalgetvar(self._name)) ValueError: invalid literal for int(): True >>> Edward -------------------------------------------------------------------- Edward K. Ream email: edream@tds.net Leo: Literate Editor with Outlines Leo: http://personalpages.tds.net/~edream/front.html -------------------------------------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671741&group_id=5470 From noreply@sourceforge.net Tue Jan 21 13:33:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 05:33:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-671779 ] Error in tzinfo.dst() docs Message-ID: Bugs item #671779, was opened at 2003-01-22 00:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671779&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: Error in tzinfo.dst() docs Initial Comment: Should state 'Return timedelta(0)' instead of 'Return 0'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671779&group_id=5470 From noreply@sourceforge.net Tue Jan 21 14:30:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 06:30:41 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-453506 ] lists should have a copy method Message-ID: Feature Requests item #453506, was opened at 2001-08-20 23:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=453506&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: lists should have a copy method Initial Comment: This is per someone on comp.os.python. It's odd that dictionaries have a copy method (you can say dict.copy()) but to copy a list you have to say list[:] or use copy.copy. I think list.copy() should be added for consistency. ---------------------------------------------------------------------- Comment By: Jesper Hertel (jhmagnus) Date: 2003-01-21 15:30 Message: Logged In: YES user_id=592328 I agree that it would be nice (and consistent) if lists had a copy() method. It would be more convenient. It is always tiresome to have to import modules to do simple stuff like this. The list[:] is a trick that you have to know before you can use it (it doesn't seem obvious to me), but list.copy() seems intuitive to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-23 07:43 Message: Logged In: YES user_id=31435 I doubt Guido would go for it. dicts grew a .copy() method *because* there was no convenient syntax like list[:] that worked for dicts. That's not a reason to add a .copy() method to lists too. Note that if you're too fond of uniformity , don't use any of these: use copy.copy() or copy.deepcopy(). Python doesn't need four ways to spell "copy this list". Oops: make that five. list (somelist) also copies a list. In 2.2, dict(somedict) also copies a dict. Enough already. ---------------------------------------------------------------------- Comment By: Michael Gilfix (mgilfix) Date: 2002-04-23 05:53 Message: Logged In: YES user_id=116038 What's the status of this? It seems pretty useful. I could submit a patch if someone likes... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=453506&group_id=5470 From noreply@sourceforge.net Tue Jan 21 16:48:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 08:48:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-671779 ] Error in tzinfo.dst() docs Message-ID: Bugs item #671779, was opened at 2003-01-21 08:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671779&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stuart Bishop (zenzen) >Assigned to: Tim Peters (tim_one) Summary: Error in tzinfo.dst() docs Initial Comment: Should state 'Return timedelta(0)' instead of 'Return 0'. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-21 11:48 Message: Logged In: YES user_id=31435 Thanks! Fixed in Doc/lib/libdatetime.tex, revision: 1.36. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671779&group_id=5470 From noreply@sourceforge.net Tue Jan 21 19:55:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 11:55:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-660144 ] typeobject provides incorrect __mul__ Message-ID: Bugs item #660144, was opened at 2002-12-30 15:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660144&group_id=5470 Category: Python Interpreter Core Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Neil Schemenauer (nascheme) Summary: typeobject provides incorrect __mul__ Initial Comment: type __mul__ is wierd: >> 'a'.__mul__(3.4) 'aaa' >>> [1].__mul__(3.4) [1, 1, 1] Floating point numbers with fractions should not be accepted. I think the problem is that __mul__ should not be trying to implement sq_repeat behavior (although I haven't dug deeply into this problem yet). Also, I think the code is vulnerable to integer overflow. Should also check __imul__ __add__ __iadd__. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-21 14:55 Message: Logged In: YES user_id=6380 Looks like a good patch. And yes, the other types should be doing this as well. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-01-19 14:35 Message: Logged In: YES user_id=35752 The small patch is attached. I only added the checking for 'i' and 'l'. I wonder if it should be done for the other integer codes as well (e.g. 'b', 'h'). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-16 19:19 Message: Logged In: YES user_id=6380 Yes, this should go into 2.3a2. Your attachment upload failed somehow. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-01-16 18:10 Message: Logged In: YES user_id=35752 Would this be a change for the 2.3 release? I tried adding a PyFloat_Check test to 'i' and 'l' in getargs.c. It looks like all the unit tests pass. I agree that checking for float catches the important cases. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-16 16:57 Message: Logged In: YES user_id=6380 This is an age-old problem that crops up whenever "i" and similar format codes are used. The problem is that on the one hand you want "i" to accept other int-ish types that have an __int__ method. But on the other hand you don't want it to accept float, which also has an __int__ method. Or other float-ish types. I think the "i" format code has to be fixe, but I'm not sure how -- maybe as a start it would be sufficient to test explicitly for float and its subclasses and reject those. That would still allow 3rd party float-ish classes that implement __int__, but that's not so important. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-01-16 16:33 Message: Logged In: YES user_id=35752 I think the problem is that wrap_intargfunc and wrap_intintargfunc use PyArg_ParseTuple(args, "i", &i). This bug also is present in methods like __getitem__: >>> "Python"[1.2] Traceback (most recent call last): File "", line 1, in ? TypeError: sequence index must be integer >>> "Python".__getitem__(1.2) 'y' I think the right fix is to use explictly only allow only ints and longs to wrap_intargfunc and friends. If Guido agrees I will cook up a patch. It seems like we should have a code for PyParse_Tuple that only allows ints and longs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660144&group_id=5470 From noreply@sourceforge.net Tue Jan 21 19:59:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 11:59:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-671741 ] Tk.IntVar.get fails after set(True) in 2.3a1 Message-ID: Bugs item #671741, was opened at 2003-01-21 14:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671741&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Edward K. Ream (edream) Assigned to: Nobody/Anonymous (nobody) Summary: Tk.IntVar.get fails after set(True) in 2.3a1 Initial Comment: Executing the following fails in 2.3a1. Similar code works in 2.1 and 2.2. def truebug(): import Tkinter Tk = Tkinter top = Tk.Toplevel() f = Tk.Frame(top) f.pack() var = Tk.IntVar() box = Tk.Checkbutton(f, anchor="w", text="box",variable=var) box.pack() var.set(True) val = var.get() Example: Microsoft Windows XP [Version 5.1.2600] ... Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC v.1200 32 bit (Intel)] on win32 ... >>> import truebug >>> truebug.truebug() Traceback (most recent call last): File "", line 1, in ? File "c:\prog\test\truebug.py", line 15, in truebug val = var.get() File "C:\PYTHON23\lib\lib-tk\Tkinter.py", line 239, in get return getint(self._tk.globalgetvar(self._name)) ValueError: invalid literal for int(): True >>> Edward -------------------------------------------------------------------- Edward K. Ream email: edream@tds.net Leo: Literate Editor with Outlines Leo: http://personalpages.tds.net/~edream/front.html -------------------------------------------------------------------- ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-01-21 21:59 Message: Logged In: YES user_id=539787 First thought: why not use a BooleanVar? The problem is that if you do a var.set(True), _tkinter translates the argument into a string (_tkinter.c, function SetVar after some levels of calling), because I think everything in tcl is a string. In Python pre-2.2.2, str(True) was still "1". What you get in your case by var.get, is the string "True" (try print int("True") or, if you check the Tkinter.py script, try at the end of your example: m= var._tk.globalgetvar(var._name) and check the type of m. Resolving this (to allow a bool in an IntVar), one could override Tkinter.IntVar.set, perhaps, to allow boolean arguments for integer variables (just converting to int before calling the Tkinter.Variable.set). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671741&group_id=5470 From noreply@sourceforge.net Tue Jan 21 20:24:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 12:24:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-671447 ] StringIO doc doesn't say it's sometimes read-only Message-ID: Bugs item #671447, was opened at 2003-01-21 00:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671447&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Orr (hierro) Assigned to: Nobody/Anonymous (nobody) Summary: StringIO doc doesn't say it's sometimes read-only Initial Comment: When StringIO is instantiated with an intial string: StringIO("Hello, world!") it's read-only; the write methods don't exist. The Python Library Reference should mention this. If you instantiate StringIO without an initial string: StringIO() you get both read and write methods. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-01-21 22:24 Message: Logged In: YES user_id=539787 Did you import StringIO, or cStringIO as StringIO ? This behaviour occurs only in cStringIO... if you do m= cStringIO.StringIO("hello there") n= cStringIO.StringIO() you see that type(m) is cStringIO.StringI and n is cStringIO.StringO. This is documented in the cStringIO module documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671447&group_id=5470 From noreply@sourceforge.net Tue Jan 21 20:24:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 12:24:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-671447 ] StringIO doc doesn't say it's sometimes read-only Message-ID: Bugs item #671447, was opened at 2003-01-21 00:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671447&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Orr (hierro) Assigned to: Nobody/Anonymous (nobody) Summary: StringIO doc doesn't say it's sometimes read-only Initial Comment: When StringIO is instantiated with an intial string: StringIO("Hello, world!") it's read-only; the write methods don't exist. The Python Library Reference should mention this. If you instantiate StringIO without an initial string: StringIO() you get both read and write methods. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-01-21 22:24 Message: Logged In: YES user_id=539787 Did you import StringIO, or cStringIO as StringIO ? This behaviour occurs only in cStringIO... if you do m= cStringIO.StringIO("hello there") n= cStringIO.StringIO() you see that type(m) is cStringIO.StringI and n is cStringIO.StringO. This is documented in the cStringIO module documentation. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-01-21 22:24 Message: Logged In: YES user_id=539787 Did you import StringIO, or cStringIO as StringIO ? This behaviour occurs only in cStringIO... if you do m= cStringIO.StringIO("hello there") n= cStringIO.StringIO() you see that type(m) is cStringIO.StringI and n is cStringIO.StringO. This is documented in the cStringIO module documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671447&group_id=5470 From noreply@sourceforge.net Tue Jan 21 20:42:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 12:42:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-672035 ] Py_Main() does not perform to spec Message-ID: Bugs item #672035, was opened at 2003-01-21 15:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672035&group_id=5470 Category: Extension Modules Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Douglas Napoleone (derivin) Assigned to: Nobody/Anonymous (nobody) Summary: Py_Main() does not perform to spec Initial Comment: I consider this a code bug, not a documentation issue as the documentation is the behavior we want. >From http://www.python.org/doc/current/api/veryhigh.html#l2h- 47 : int Py_Main(int argc, char **argv) The main program for the standard interpreter. This is made available for programs which embed Python. The argc and argv parameters should be prepared exactly as those which are passed to a C program's main() function. It is important to note that the argument list may be modified (but the contents of the strings pointed to by the argument list are not). The return value will be the integer passed to the sys.exit() function, 1 if the interpreter exits due to an exception, or 2 if the parameter list does not represent a valid Python command line. I have checked the code for 2.2, 2.2.1, 2.2.2, and r2.3al In all cases the code will call exit(2) in C when an improper commandline is given instead of returning 2. ALL exit() calls should be removed from this module. The return value should be passed to exit or returned from main() by the caller of Py_Main() and NOT from within this call. python.c's main() would not need to be changed as it already does this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672035&group_id=5470 From noreply@sourceforge.net Tue Jan 21 20:47:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 12:47:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-666958 ] repr.repr not always safe Message-ID: Bugs item #666958, was opened at 2003-01-13 06:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666958&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: repr.repr not always safe Initial Comment: >>> class A: ... def __repr__(self): ... raise Exception ... def someMethod(self): ... pass ... >>> A() Traceback (most recent call last): File "", line 1, in ? File "", line 3, in __repr__ Exception >>> repr.repr(A()) '' >>> repr.repr(A().someMethod) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/repr.py", line 15, in repr return self.repr1(x, self.maxlevel) File "/usr/lib/python2.2/repr.py", line 24, in repr1 s = `x` File "", line ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-01-21 22:47 Message: Logged In: YES user_id=539787 Do you suggest to remove the exception catching in Repr.repr_instance or adding a try clause in the s = `x` line of Repr.repr1 ? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-01-20 16:11 Message: Logged In: YES user_id=139309 It's not my module, it comes with Python (at least in my 2.2, and 2.3 CVS HEAD). Look for yourself! The issue has nothing to do with the fact that it has the same name as the builtin. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-01-20 07:28 Message: Logged In: YES user_id=539787 Did you try to change the module name to, say, repr2 and then run it again? Any specific reason you named the module as an internal function? BTW, what is repr.repr supposed to do? Please supply the repr.py script, along with the full traceback. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-01-13 16:54 Message: Logged In: YES user_id=139309 I say it's a bug because it's inconsistent behavior. You can repr the class instance that throws during a __repr__ just fine ('' ), but you can't __repr__ a bound method of the class instance without throwing an exception. In fact, if the __repr__ of the class instance returns anything but a string, say it returns None for example, then the exception will bubble all the way up and you get no useful output from repr.repr. It's very annoying if you're doing something equivalent to, but more useful than: repr.repr([1, 2, 3, 4, A().someMethod, 6, 7, 8, A()]) Note that repr.repr([1, 2, 3, 4, A(), 6, 7, 8]) does not throw any exceptions. There should be some sort of graceful way to do it, no? I think it ought to handle the bound method broken instance case just like it handles the broken instance case directly. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-13 06:34 Message: Logged In: YES user_id=31435 Why do say this is a bug? If you raise an exception, yes, you get an exception. Most __repr__ *implementations* try hard not to raise any exceptions, but it's never guaranteed that they won't. For example, just about any __repr__ implementation may run out of memory while trying to build its result string, so MemoryError is almost always a possible exception. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666958&group_id=5470 From noreply@sourceforge.net Tue Jan 21 20:50:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 12:50:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-672035 ] Py_Main() does not perform to spec Message-ID: Bugs item #672035, was opened at 2003-01-21 15:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672035&group_id=5470 Category: Extension Modules Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Douglas Napoleone (derivin) Assigned to: Nobody/Anonymous (nobody) Summary: Py_Main() does not perform to spec Initial Comment: I consider this a code bug, not a documentation issue as the documentation is the behavior we want. >From http://www.python.org/doc/current/api/veryhigh.html#l2h- 47 : int Py_Main(int argc, char **argv) The main program for the standard interpreter. This is made available for programs which embed Python. The argc and argv parameters should be prepared exactly as those which are passed to a C program's main() function. It is important to note that the argument list may be modified (but the contents of the strings pointed to by the argument list are not). The return value will be the integer passed to the sys.exit() function, 1 if the interpreter exits due to an exception, or 2 if the parameter list does not represent a valid Python command line. I have checked the code for 2.2, 2.2.1, 2.2.2, and r2.3al In all cases the code will call exit(2) in C when an improper commandline is given instead of returning 2. ALL exit() calls should be removed from this module. The return value should be passed to exit or returned from main() by the caller of Py_Main() and NOT from within this call. python.c's main() would not need to be changed as it already does this. ---------------------------------------------------------------------- Comment By: Douglas Napoleone (derivin) Date: 2003-01-21 15:50 Message: Logged In: YES user_id=541557 The max recursion limit problem in the re module is well-known. Until this limitation in the implementation is removed, to work around it check http://www.python.org/dev/doc/devel/lib/module-re.html http://python/org/sf/493252 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672035&group_id=5470 From noreply@sourceforge.net Tue Jan 21 20:58:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 12:58:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-666958 ] repr.repr not always safe Message-ID: Bugs item #666958, was opened at 2003-01-13 06:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666958&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: repr.repr not always safe Initial Comment: >>> class A: ... def __repr__(self): ... raise Exception ... def someMethod(self): ... pass ... >>> A() Traceback (most recent call last): File "", line 1, in ? File "", line 3, in __repr__ Exception >>> repr.repr(A()) '' >>> repr.repr(A().someMethod) Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/repr.py", line 15, in repr return self.repr1(x, self.maxlevel) File "/usr/lib/python2.2/repr.py", line 24, in repr1 s = `x` File "", line ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-01-21 22:58 Message: Logged In: YES user_id=539787 Sorry, incomplete last post, I clicked in the wrong place (ie SUBMIT) to come back to IE. The case is that repr.py is documented as for debugging use... you suggest that all exceptions are caught, but that would not be consistent with __builtins__.repr . If the module was intended for generic use, I would suggest the opposite; no exceptions should be caught (for consistency). ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-01-21 22:47 Message: Logged In: YES user_id=539787 Do you suggest to remove the exception catching in Repr.repr_instance or adding a try clause in the s = `x` line of Repr.repr1 ? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-01-20 16:11 Message: Logged In: YES user_id=139309 It's not my module, it comes with Python (at least in my 2.2, and 2.3 CVS HEAD). Look for yourself! The issue has nothing to do with the fact that it has the same name as the builtin. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-01-20 07:28 Message: Logged In: YES user_id=539787 Did you try to change the module name to, say, repr2 and then run it again? Any specific reason you named the module as an internal function? BTW, what is repr.repr supposed to do? Please supply the repr.py script, along with the full traceback. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-01-13 16:54 Message: Logged In: YES user_id=139309 I say it's a bug because it's inconsistent behavior. You can repr the class instance that throws during a __repr__ just fine ('' ), but you can't __repr__ a bound method of the class instance without throwing an exception. In fact, if the __repr__ of the class instance returns anything but a string, say it returns None for example, then the exception will bubble all the way up and you get no useful output from repr.repr. It's very annoying if you're doing something equivalent to, but more useful than: repr.repr([1, 2, 3, 4, A().someMethod, 6, 7, 8, A()]) Note that repr.repr([1, 2, 3, 4, A(), 6, 7, 8]) does not throw any exceptions. There should be some sort of graceful way to do it, no? I think it ought to handle the bound method broken instance case just like it handles the broken instance case directly. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-13 06:34 Message: Logged In: YES user_id=31435 Why do say this is a bug? If you raise an exception, yes, you get an exception. Most __repr__ *implementations* try hard not to raise any exceptions, but it's never guaranteed that they won't. For example, just about any __repr__ implementation may run out of memory while trying to build its result string, so MemoryError is almost always a possible exception. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666958&group_id=5470 From noreply@sourceforge.net Tue Jan 21 21:09:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 13:09:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-671447 ] StringIO doc doesn't say it's sometimes read-only Message-ID: Bugs item #671447, was opened at 2003-01-20 22:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671447&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Orr (hierro) Assigned to: Nobody/Anonymous (nobody) Summary: StringIO doc doesn't say it's sometimes read-only Initial Comment: When StringIO is instantiated with an intial string: StringIO("Hello, world!") it's read-only; the write methods don't exist. The Python Library Reference should mention this. If you instantiate StringIO without an initial string: StringIO() you get both read and write methods. ---------------------------------------------------------------------- >Comment By: Mike Orr (hierro) Date: 2003-01-21 21:09 Message: Logged In: YES user_id=239757 Yes, it's only cStringIO that does it. However, the statenent about the type does not say anything about which methods are available. Many readers would think, "I never have to compare the type to anything; this doesn't apply to me." How about a statement: If you instantiate cStringIO.StringIO() without an argument, the string is read-write. But if you instantiate it with a string argument: cStringIO.StringIO("abc"), it's read-only and the write methods do not exist. This applies only to cStringIO; the corresponding objects in the StringIO module are read-write in both cases. [Then the paragraph about InputType and OutputType.] ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-01-21 20:24 Message: Logged In: YES user_id=539787 Did you import StringIO, or cStringIO as StringIO ? This behaviour occurs only in cStringIO... if you do m= cStringIO.StringIO("hello there") n= cStringIO.StringIO() you see that type(m) is cStringIO.StringI and n is cStringIO.StringO. This is documented in the cStringIO module documentation. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-01-21 20:24 Message: Logged In: YES user_id=539787 Did you import StringIO, or cStringIO as StringIO ? This behaviour occurs only in cStringIO... if you do m= cStringIO.StringIO("hello there") n= cStringIO.StringIO() you see that type(m) is cStringIO.StringI and n is cStringIO.StringO. This is documented in the cStringIO module documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671447&group_id=5470 From noreply@sourceforge.net Tue Jan 21 21:17:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 13:17:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-671447 ] StringIO doc doesn't say it's sometimes read-only Message-ID: Bugs item #671447, was opened at 2003-01-21 00:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671447&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mike Orr (hierro) Assigned to: Nobody/Anonymous (nobody) Summary: StringIO doc doesn't say it's sometimes read-only Initial Comment: When StringIO is instantiated with an intial string: StringIO("Hello, world!") it's read-only; the write methods don't exist. The Python Library Reference should mention this. If you instantiate StringIO without an initial string: StringIO() you get both read and write methods. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-01-21 23:17 Message: Logged In: YES user_id=539787 I find your suggestion informative, appropriate and nice :) ---------------------------------------------------------------------- Comment By: Mike Orr (hierro) Date: 2003-01-21 23:09 Message: Logged In: YES user_id=239757 Yes, it's only cStringIO that does it. However, the statenent about the type does not say anything about which methods are available. Many readers would think, "I never have to compare the type to anything; this doesn't apply to me." How about a statement: If you instantiate cStringIO.StringIO() without an argument, the string is read-write. But if you instantiate it with a string argument: cStringIO.StringIO("abc"), it's read-only and the write methods do not exist. This applies only to cStringIO; the corresponding objects in the StringIO module are read-write in both cases. [Then the paragraph about InputType and OutputType.] ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-01-21 22:24 Message: Logged In: YES user_id=539787 Did you import StringIO, or cStringIO as StringIO ? This behaviour occurs only in cStringIO... if you do m= cStringIO.StringIO("hello there") n= cStringIO.StringIO() you see that type(m) is cStringIO.StringI and n is cStringIO.StringO. This is documented in the cStringIO module documentation. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-01-21 22:24 Message: Logged In: YES user_id=539787 Did you import StringIO, or cStringIO as StringIO ? This behaviour occurs only in cStringIO... if you do m= cStringIO.StringIO("hello there") n= cStringIO.StringIO() you see that type(m) is cStringIO.StringI and n is cStringIO.StringO. This is documented in the cStringIO module documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671447&group_id=5470 From noreply@sourceforge.net Tue Jan 21 22:10:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 14:10:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-671741 ] Tk.IntVar.get fails after set(True) in 2.3a1 Message-ID: Bugs item #671741, was opened at 2003-01-21 12:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671741&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Edward K. Ream (edream) Assigned to: Nobody/Anonymous (nobody) Summary: Tk.IntVar.get fails after set(True) in 2.3a1 Initial Comment: Executing the following fails in 2.3a1. Similar code works in 2.1 and 2.2. def truebug(): import Tkinter Tk = Tkinter top = Tk.Toplevel() f = Tk.Frame(top) f.pack() var = Tk.IntVar() box = Tk.Checkbutton(f, anchor="w", text="box",variable=var) box.pack() var.set(True) val = var.get() Example: Microsoft Windows XP [Version 5.1.2600] ... Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC v.1200 32 bit (Intel)] on win32 ... >>> import truebug >>> truebug.truebug() Traceback (most recent call last): File "", line 1, in ? File "c:\prog\test\truebug.py", line 15, in truebug val = var.get() File "C:\PYTHON23\lib\lib-tk\Tkinter.py", line 239, in get return getint(self._tk.globalgetvar(self._name)) ValueError: invalid literal for int(): True >>> Edward -------------------------------------------------------------------- Edward K. Ream email: edream@tds.net Leo: Literate Editor with Outlines Leo: http://personalpages.tds.net/~edream/front.html -------------------------------------------------------------------- ---------------------------------------------------------------------- >Comment By: Edward K. Ream (edream) Date: 2003-01-21 22:10 Message: Logged In: YES user_id=14056 Thanks for the explanation. I shall indeed use a BooleanVar. However, it would be nice if tkinter could do what it did before... I asked about this behavior on comp.lang.python and Martin v. Löwis said he thought it was a bug. I'll let you two fight it out :-) Edward ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-01-21 19:59 Message: Logged In: YES user_id=539787 First thought: why not use a BooleanVar? The problem is that if you do a var.set(True), _tkinter translates the argument into a string (_tkinter.c, function SetVar after some levels of calling), because I think everything in tcl is a string. In Python pre-2.2.2, str(True) was still "1". What you get in your case by var.get, is the string "True" (try print int("True") or, if you check the Tkinter.py script, try at the end of your example: m= var._tk.globalgetvar(var._name) and check the type of m. Resolving this (to allow a bool in an IntVar), one could override Tkinter.IntVar.set, perhaps, to allow boolean arguments for integer variables (just converting to int before calling the Tkinter.Variable.set). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671741&group_id=5470 From noreply@sourceforge.net Tue Jan 21 22:18:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 14:18:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-672098 ] Three __contains__ implementations Message-ID: Bugs item #672098, was opened at 2003-01-21 17:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672098&group_id=5470 Category: Python Library Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: Three __contains__ implementations Initial Comment: Several classes in the stdlib implement dict-like interfaces, but do not provide __contains__ definitions. This is mentioned in PEP290 as a "contra-indication" for updating code to use "k in d". The attached patch adds __contains__ implementations for these stdlib classes. As far as I can tell, this brings all the dict-like classes in the stdlib "up to date", so perhaps PEP290 should be updated as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672098&group_id=5470 From noreply@sourceforge.net Tue Jan 21 22:46:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 14:46:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-671741 ] Tk.IntVar.get fails after set(True) in 2.3a1 Message-ID: Bugs item #671741, was opened at 2003-01-21 13:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671741&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Edward K. Ream (edream) Assigned to: Nobody/Anonymous (nobody) Summary: Tk.IntVar.get fails after set(True) in 2.3a1 Initial Comment: Executing the following fails in 2.3a1. Similar code works in 2.1 and 2.2. def truebug(): import Tkinter Tk = Tkinter top = Tk.Toplevel() f = Tk.Frame(top) f.pack() var = Tk.IntVar() box = Tk.Checkbutton(f, anchor="w", text="box",variable=var) box.pack() var.set(True) val = var.get() Example: Microsoft Windows XP [Version 5.1.2600] ... Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC v.1200 32 bit (Intel)] on win32 ... >>> import truebug >>> truebug.truebug() Traceback (most recent call last): File "", line 1, in ? File "c:\prog\test\truebug.py", line 15, in truebug val = var.get() File "C:\PYTHON23\lib\lib-tk\Tkinter.py", line 239, in get return getint(self._tk.globalgetvar(self._name)) ValueError: invalid literal for int(): True >>> Edward -------------------------------------------------------------------- Edward K. Ream email: edream@tds.net Leo: Literate Editor with Outlines Leo: http://personalpages.tds.net/~edream/front.html -------------------------------------------------------------------- ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-21 23:46 Message: Logged In: YES user_id=21627 A BooleanVar won't work for a checkbutton: The -variable argument must have either -onValue or -offValue, which default to 0/1. I do think that an IntVar should accept booleans in .set, and translate them into 0/1. A slightly related bug is that .get of a BooleanVar should probably return False/True, not 0/1. ---------------------------------------------------------------------- Comment By: Edward K. Ream (edream) Date: 2003-01-21 23:10 Message: Logged In: YES user_id=14056 Thanks for the explanation. I shall indeed use a BooleanVar. However, it would be nice if tkinter could do what it did before... I asked about this behavior on comp.lang.python and Martin v. Löwis said he thought it was a bug. I'll let you two fight it out :-) Edward ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-01-21 20:59 Message: Logged In: YES user_id=539787 First thought: why not use a BooleanVar? The problem is that if you do a var.set(True), _tkinter translates the argument into a string (_tkinter.c, function SetVar after some levels of calling), because I think everything in tcl is a string. In Python pre-2.2.2, str(True) was still "1". What you get in your case by var.get, is the string "True" (try print int("True") or, if you check the Tkinter.py script, try at the end of your example: m= var._tk.globalgetvar(var._name) and check the type of m. Resolving this (to allow a bool in an IntVar), one could override Tkinter.IntVar.set, perhaps, to allow boolean arguments for integer variables (just converting to int before calling the Tkinter.Variable.set). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671741&group_id=5470 From noreply@sourceforge.net Tue Jan 21 22:45:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 14:45:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-672115 ] Assignment to __bases__ of direct object subclasses Message-ID: Bugs item #672115, was opened at 2003-01-21 13:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672115&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Assignment to __bases__ of direct object subclasses Initial Comment: I'm not entirely sure this is a bug, but I think it is surprising: Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class A(object): ... pass ... >>> class B(object): ... pass ... >>> B.__bases__ = (A,) Traceback (most recent call last): File "", line 1, in ? TypeError: __bases__ assignment: 'A' deallocator differs from 'object' It seems like you should be able to change the __bases__ of a new-style class (implemented in Python) which inherits directly from object to another new-style class. (Will the deallocator issue ever come into play if the only types involved are HEAPTYPES and object as the ultimate base?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672115&group_id=5470 From noreply@sourceforge.net Tue Jan 21 23:09:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 15:09:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-672132 ] registry functions don't handle null characters Message-ID: Bugs item #672132, was opened at 2003-01-22 10:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672132&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: registry functions don't handle null characters Initial Comment: As determined via http://mail.python.org/pipermail/python-win32/2003-January/000745.html Registry *value names* (not just the data values) can contain embedded NULL characters, and indeed appear to be Unicode - ie, WinNT registry uses Unicode natively, and the value names are MBCS encoded in the "A" API version of these functions. _winreg.EnumValue, _winreg.EnumKey (and the same in the win32api module) are affected. I wonder if a fix to this should actually return Unicode objects if a high-byte exists? At the very least, we must use the "length" of the valuename returned, rather than assuming null termination. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672132&group_id=5470 From noreply@sourceforge.net Wed Jan 22 00:44:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 16:44:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-672098 ] Three __contains__ implementations Message-ID: Bugs item #672098, was opened at 2003-01-21 14:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672098&group_id=5470 Category: Python Library Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: Three __contains__ implementations Initial Comment: Several classes in the stdlib implement dict-like interfaces, but do not provide __contains__ definitions. This is mentioned in PEP290 as a "contra-indication" for updating code to use "k in d". The attached patch adds __contains__ implementations for these stdlib classes. As far as I can tell, this brings all the dict-like classes in the stdlib "up to date", so perhaps PEP290 should be updated as well. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-21 16:44 Message: Logged In: YES user_id=357491 The attached file has no ``__contains__`` definitions for anything. Did you attach the correct file? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672098&group_id=5470 From noreply@sourceforge.net Wed Jan 22 00:55:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 16:55:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-671731 ] time module: time tuple not returned by certain functions Message-ID: Bugs item #671731, was opened at 2003-01-21 03:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671731&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Martin Miller (mrmiller) Assigned to: Nobody/Anonymous (nobody) Summary: time module: time tuple not returned by certain functions Initial Comment: On win32 the gmtime() and localtime() functions in the time module return values of type 'time.time_struct'. I believe the proper return value should be a tuple. This is implied by the documentation (see where it discusses the *time tuple* returned by the various module functions and says it 'is a tuple of 9 integers'. The time_struct value returned does behave like a tuple instance in most respects, except that its type is not type 'tuple'. I think this is something that was changed in the not too distant past, as I noticed the issue after downloading code recently written by others which depends on the type of the return value from these functions being a tuple. If nothing else, if this was changed, it is not backward compatible and the documention ought to be updated. Example: > Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 > Type "help", "copyright", "credits" or "license" for more information. > >>> import time > >>> print time.localtime() > (2003, 1, 21, 3, 3, 2, 1, 21, 0) > >>> print type(time.localtime()) is type(()) > 0 > >>> print type(time.localtime()) > > >>> ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-21 16:55 Message: Logged In: YES user_id=357491 There is a mention of it in the developer docs at http://www.python.org/dev/doc/devel/lib/module-time.html . The note for struct_time says what functions return a struct_time object. A patch for the docs that changed everything else to say it returns a struct_time object instead of a time tuple wouldn't hurt, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-21 03:40 Message: Logged In: YES user_id=6656 This was very deliberate. It *is* a bit shocking that the docs didn't get updated, though. There's a start of a description in: http://www.python.org/doc/current/whatsnew/node10.html Do you have code that actually broke because of this change? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671731&group_id=5470 From noreply@sourceforge.net Wed Jan 22 02:16:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 18:16:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-672098 ] Three __contains__ implementations Message-ID: Bugs item #672098, was opened at 2003-01-21 17:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672098&group_id=5470 Category: Python Library Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: Three __contains__ implementations Initial Comment: Several classes in the stdlib implement dict-like interfaces, but do not provide __contains__ definitions. This is mentioned in PEP290 as a "contra-indication" for updating code to use "k in d". The attached patch adds __contains__ implementations for these stdlib classes. As far as I can tell, this brings all the dict-like classes in the stdlib "up to date", so perhaps PEP290 should be updated as well. ---------------------------------------------------------------------- >Comment By: Jp Calderone (kuran) Date: 2003-01-21 21:16 Message: Logged In: YES user_id=366566 Either mozilla or sf is screwing with me. *grumble* There's no way I selected bisect.py for attachment. Proper file now attached. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-21 19:44 Message: Logged In: YES user_id=357491 The attached file has no ``__contains__`` definitions for anything. Did you attach the correct file? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672098&group_id=5470 From noreply@sourceforge.net Wed Jan 22 03:09:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 19:09:52 -0800 Subject: [Python-bugs-list] [ python-Bugs-625698 ] Errors with recursive objects Message-ID: Bugs item #625698, was opened at 2002-10-19 15:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Erik Andersén (erik_andersen) Assigned to: Jeremy Hylton (jhylton) Summary: Errors with recursive objects Initial Comment: List and dictionaries put Python into an infinite loop if they contain more than one reference to itself >>> d = {} >>> d[1] = d >>> d == d # OK Python can handle one recursion 1 >>> d[2] = d >>> d == d # Crash with two Lists are similar >>> l=[] >>> l.append(l) >>> l==l # OK 1 >>> l.append(l) >>> l==l # Crash >>> l>l # Also crash Tested with ActivePython 2.2.1 under Windows 98 and (the first part) Python 2.2.2 under Linux ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-21 22:09 Message: Logged In: YES user_id=31435 llit, you should study the current code before suggesting an algorithm. The current code would be blazing fast if it were looking for recursion from the start too. But the very process of building that dict with the ids of the objects as keys (which the current algorithm also does) costs more than most comparisons cost in real life. That's why the current code doesn't even try to catch recursion until the comparison level exceeds 20, and that's where the sloth comes from. Stick a gimmick like that in your algorithm, and you'll have similar speed problems. Also note that id(a) == id(b) doesn't imply a == b (see the other note about NaN for an example). ---------------------------------------------------------------------- Comment By: Till Plewe (llit) Date: 2003-01-21 01:01 Message: Logged In: YES user_id=540660 How about checking for equality by trying to build a bisimulation which "proves" equality. Time complexity is O(nodes(a) x nodes(b)) SAMPLE PYTHON CODE =============================== #! /usr/bin/env python from types import * SeqType=[ListType,DictType,TupleType] def isequal(a,b): if id(a)==id(b): return True compare={(id(a),id(b)):(a,b)} bisimilar={} while compare: (ida,idb),(oba,obb)=compare.popitem() if ida==idb: continue elif type(oba)==type(obb): if type(oba) not in SeqType: if oba!=obb: return False else: continue elif len(oba)!=len(obb): return False elif (ida,idb) not in bisimilar: bisimilar[(ida,idb)]=1 if type(oba)==DictType: for x in oba: #oba and obb have the same number of keys if x not in obb: return False else: compare[(id(oba[x]),id(obb[x]))]=(oba[x],obb[x]) else: for x,y in zip(oba,obb): compare[(id(x),id(y))]=(x,y) else: return False return bisimilar ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 15:44 Message: Logged In: YES user_id=31435 Cool. He's right that they can take a horrendously long time. The 2-element list example takes c*2**20 units of time, for some suitable constant c, and if it were extended to 3 elements, it would take c*3**20 units of time, thousands of times longer. As Erik's latest example shows, the outcome isn't always particularly well defined either. An alternative to speeding this silliness is to raise an exception instead when recursive objects are detected. There was some hack value in doing the graph isomorphism bit, but no real practical value I can see. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-20 15:20 Message: Logged In: YES user_id=33168 Sorry Tim, I was going to reply to one of your first msgs and forgot. Erik sent me mail which said there wasn't a crash, just that "the statements take horrendously long time to execute." ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 15:09 Message: Logged In: YES user_id=31435 BTW, Erik, what did you mean by "crash"? Nobody else has seen a crash here. You started the report by saying "infinite loop", which isn't the same thing as a crash. There isn't an infinite loop here either, although the algorithm can take astronomical amounts of time to finish (so may appear to be in an infinite loop). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 14:50 Message: Logged In: YES user_id=31435 Equailty for self-consistent recursive objects does a graph isomorphism computation. In your self-inconsistent example, it so happens that False is returned, although True would be returned if the compile-time constant (in object.c) NESTING_LIMIT were odd instead of even. But if you worry about this, you need to get out more . ---------------------------------------------------------------------- Comment By: Erik Andersén (erik_andersen) Date: 2003-01-20 14:24 Message: Logged In: YES user_id=364358 Excuse me for interupting the efficiency discussion, but what is the definition of equality for recursive containers. I am particularly worrided about cases like >>> class A: ... def __eq__(self,other): return not self.u==other.u ... >>> a=A() >>> l=[a] >>> a.u=l >>> l==l # ???? If l==l then a!=a and l[0]!=l[0], so l!=l. If l!=l then a==a and l[0]==l[0], so l==l !!!!!!! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 11:12 Message: Logged In: YES user_id=31435 I deleted my patch -- it didn't make sense. Martin, AFAIK the docs say nothing about the relationship (if any) between "is" and "==". It was deliberate intent that "is" not imply "==" for rich comparisons, though, in part so that IEEE-754 rules for NaN could be implemented by users. >>> class NaN: ... def __eq__(self, other): return False ... >>> n = NaN() >>> n is n True >>> n == n False >>> ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-20 03:20 Message: Logged In: YES user_id=21627 Where does the documentation say that "is" may not imply ==? The check for recursion assumes this implication, anyway: if we meet the very same object, we infer that they are equal. What is the purpose of clear_inprogress_dict in your patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-19 23:28 Message: Logged In: YES user_id=31435 The patch assumes "is" implies "==", which isn't necessarily so for rich comparisons. The attached patch cuts the time about in half, via: 1. Getting rid of the per-thread inprogress dicts, in favor of a shared inprogress dict. 2. Restoring the intent of the code that tuples be exempted (tuples can't be recursive). Rev 2.65 of tupleobject.c gave tuples a tp_as_mapping slot, breaking the intent of the code. 3. Changing the inprogress dict to map a tuple to the smallest value of compare_nesting at which the tuple was seen. delete_token() was changed to leave the token alone if the current compare_nesting value is greater than that. This allows tuples to stay in the dict longer. 4. Cutting NESTING_LIMIT from 20 to 19. This has a huge effect, because the algorithm is still basically exponential- time. The problem remaining is that the inprogress dict is still useless (and empty) so long as compare_nesting is less than NESTING_LIMIT. This can leave an exponential amount of work to be done to fight back up to NESTING_LIMIT. Leaving stuff in inprogress longer, and consulting inprogress regardless of the value of compare_nesting (provided that's gone over NESTING_LIMIT at least once) slashes the time to triviality. However, it isn't safe: we can't know that the addresses in the dict keys refer to the same objects then. We could if started storing into inprogress from the very start, but that would be a big speed hit for usual-case comparisons. I'd be happy to knock NESTING_LIMIT down more, though. Assigned to Jeremy, as IIRC this was his code originally. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-19 12:30 Message: Logged In: YES user_id=21627 The patch is fine, except that a comment needs to be added explaining what this does and why it does that. It should be understood that this can't fix the very similar case a = [] a.append(a) a.append(a) b = [] b.append(b) b.append(b) a==b This would still take a long time, right? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-19 11:05 Message: Logged In: YES user_id=33168 Attached is a patch which fixes the problem for me. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 19:59 Message: Logged In: YES user_id=33168 Erik, do you still have this problem with 2.2.2? I can't reproduce your problem under Linux. mly can't reproduce the problems with 2.2.1 on Windows (2000). Do you only have the problem on Windows? ---------------------------------------------------------------------- Comment By: Magnus Lyckå (mly) Date: 2002-10-26 19:12 Message: Logged In: YES user_id=95217 I tried the above under Python 2.2.1 (#34, Sep 27 2002, 18:37:42) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. (ActiveState on Win 2000) and Python 2.1.1 (#1, Aug 20 2001, 20:23:29) [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.60mdk)] on linux-i386 In both cases it works correctly. No crash. It takes a lot of time though, Several seconds on Duron 700 w/ Win2k, and tens of seconds on K6-233 w/ Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 From noreply@sourceforge.net Wed Jan 22 04:51:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 21 Jan 2003 20:51:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-672098 ] Three __contains__ implementations Message-ID: Bugs item #672098, was opened at 2003-01-21 14:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672098&group_id=5470 Category: Python Library Group: Not a Bug Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: Three __contains__ implementations Initial Comment: Several classes in the stdlib implement dict-like interfaces, but do not provide __contains__ definitions. This is mentioned in PEP290 as a "contra-indication" for updating code to use "k in d". The attached patch adds __contains__ implementations for these stdlib classes. As far as I can tell, this brings all the dict-like classes in the stdlib "up to date", so perhaps PEP290 should be updated as well. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-21 20:51 Message: Logged In: YES user_id=357491 The code itself looks fine, but I would suggest that instead of copying code from the methods that provide the same that you change them so that the old method calls ``__contains__`` and that ``__contains__`` now takes over as the primary method. So instead of:: def has_key(self, name): return self._attrs.has_key(name) def __contains__(self, name): return self._attrs.has_key(name) do:: def has_key(self, name): return self.__contains__(name) def __contains__(self, name): return self._attrs.has_key(name) Doing it this way minimizes code duplication along with the possibility of someone changing one method and not the other. And as for usefulness of these additions, I can't comment since I use none of the modules patched, but I see no harm in adding the functionality. So +0 from me on applying the patch once the above changes are done. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2003-01-21 18:16 Message: Logged In: YES user_id=366566 Either mozilla or sf is screwing with me. *grumble* There's no way I selected bisect.py for attachment. Proper file now attached. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-21 16:44 Message: Logged In: YES user_id=357491 The attached file has no ``__contains__`` definitions for anything. Did you attach the correct file? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672098&group_id=5470 From noreply@sourceforge.net Wed Jan 22 09:15:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 22 Jan 2003 01:15:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-672132 ] registry functions don't handle null characters Message-ID: Bugs item #672132, was opened at 2003-01-22 00:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672132&group_id=5470 Category: Windows Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: registry functions don't handle null characters Initial Comment: As determined via http://mail.python.org/pipermail/python-win32/2003-January/000745.html Registry *value names* (not just the data values) can contain embedded NULL characters, and indeed appear to be Unicode - ie, WinNT registry uses Unicode natively, and the value names are MBCS encoded in the "A" API version of these functions. _winreg.EnumValue, _winreg.EnumKey (and the same in the win32api module) are affected. I wonder if a fix to this should actually return Unicode objects if a high-byte exists? At the very least, we must use the "length" of the valuename returned, rather than assuming null termination. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-22 10:15 Message: Logged In: YES user_id=21627 The "traditional" Python approach is to return a byte string if possible, for compatibility, and a Unicode object otherwise. "If possible" often means "if the system default encoding permits", or, as in _tkinter, "if the string is plain ASCII". I expect one day people will complain that they can't access certain registry keys, because those use characters not supported in CP_ACP. So it might be reasonable to use the *W functions throughout, and convert to byte strings if they are ASCII, and to Unicode objects otherwise. For incoming byte strings, you probably have to assume they are CP_ACP encoded, for compatibility with earlier Python releases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672132&group_id=5470 From noreply@sourceforge.net Wed Jan 22 09:22:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 22 Jan 2003 01:22:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-671741 ] Tk.IntVar.get fails after set(True) in 2.3a1 Message-ID: Bugs item #671741, was opened at 2003-01-21 13:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671741&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Edward K. Ream (edream) Assigned to: Nobody/Anonymous (nobody) Summary: Tk.IntVar.get fails after set(True) in 2.3a1 Initial Comment: Executing the following fails in 2.3a1. Similar code works in 2.1 and 2.2. def truebug(): import Tkinter Tk = Tkinter top = Tk.Toplevel() f = Tk.Frame(top) f.pack() var = Tk.IntVar() box = Tk.Checkbutton(f, anchor="w", text="box",variable=var) box.pack() var.set(True) val = var.get() Example: Microsoft Windows XP [Version 5.1.2600] ... Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC v.1200 32 bit (Intel)] on win32 ... >>> import truebug >>> truebug.truebug() Traceback (most recent call last): File "", line 1, in ? File "c:\prog\test\truebug.py", line 15, in truebug val = var.get() File "C:\PYTHON23\lib\lib-tk\Tkinter.py", line 239, in get return getint(self._tk.globalgetvar(self._name)) ValueError: invalid literal for int(): True >>> Edward -------------------------------------------------------------------- Edward K. Ream email: edream@tds.net Leo: Literate Editor with Outlines Leo: http://personalpages.tds.net/~edream/front.html -------------------------------------------------------------------- ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-22 10:22 Message: Logged In: YES user_id=21627 This is now fixed in Tkinter.py 1.169 _tkinter.c 1.148 I've also changed BooleanVar.get (indirectly) to return bool objects. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-21 23:46 Message: Logged In: YES user_id=21627 A BooleanVar won't work for a checkbutton: The -variable argument must have either -onValue or -offValue, which default to 0/1. I do think that an IntVar should accept booleans in .set, and translate them into 0/1. A slightly related bug is that .get of a BooleanVar should probably return False/True, not 0/1. ---------------------------------------------------------------------- Comment By: Edward K. Ream (edream) Date: 2003-01-21 23:10 Message: Logged In: YES user_id=14056 Thanks for the explanation. I shall indeed use a BooleanVar. However, it would be nice if tkinter could do what it did before... I asked about this behavior on comp.lang.python and Martin v. Löwis said he thought it was a bug. I'll let you two fight it out :-) Edward ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-01-21 20:59 Message: Logged In: YES user_id=539787 First thought: why not use a BooleanVar? The problem is that if you do a var.set(True), _tkinter translates the argument into a string (_tkinter.c, function SetVar after some levels of calling), because I think everything in tcl is a string. In Python pre-2.2.2, str(True) was still "1". What you get in your case by var.get, is the string "True" (try print int("True") or, if you check the Tkinter.py script, try at the end of your example: m= var._tk.globalgetvar(var._name) and check the type of m. Resolving this (to allow a bool in an IntVar), one could override Tkinter.IntVar.set, perhaps, to allow boolean arguments for integer variables (just converting to int before calling the Tkinter.Variable.set). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671741&group_id=5470 From noreply@sourceforge.net Wed Jan 22 09:33:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 22 Jan 2003 01:33:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-668708 ] Py_NewInterpreter() doesn't work Message-ID: Bugs item #668708, was opened at 2003-01-15 21:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668708&group_id=5470 Category: None Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Geert Jansen (geertj) Assigned to: Nobody/Anonymous (nobody) Summary: Py_NewInterpreter() doesn't work Initial Comment: Hello, mod_python doesn't seem to work with Python 2.3a1. After some debugging, it seems the culprit is Py_NewInterpreter(). The following C program works with Python 2.2 but gives an error with Python 2.3: #include int main() { PyThreadState *tstate; Py_Initialize(); tstate = Py_NewInterpreter(); return 0; } The relevant part of this program's output: geertj@cristina:~$ PYTHONVERBOSE=1 ./a.out # installing zipimport hook import zipimport # builtin [...] import __builtin__ # previously loaded (__builtin__) import sys # previously loaded (sys) 'import site' failed; traceback: ImportError: No module named site It seems that Python is unable to find the module "site". Greetings, Geert Jansen ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-22 10:33 Message: Logged In: YES user_id=21627 This was indeed fixed with that patch. ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2003-01-21 00:28 Message: Logged In: YES user_id=693077 Patch 671459 seems to fix the problem. ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2003-01-20 23:58 Message: Logged In: YES user_id=693077 The problem appears to be that meta_path is not being initialized in the new interpreter. Adding _PyImportHooks_Init to Py_NewInterpreter seems to fix the problem, initializing the new import hooks before trying to import modules into the new interpreter. ---------------------------------------------------------------------- Comment By: Geert Jansen (geertj) Date: 2003-01-15 21:19 Message: Logged In: YES user_id=537938 I forgot to mention that the Python version used is 2.3a1. Geert Jansen ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668708&group_id=5470 From noreply@sourceforge.net Wed Jan 22 10:07:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 22 Jan 2003 02:07:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-663074 ] codec registry and Python embedding problem Message-ID: Bugs item #663074, was opened at 2003-01-06 13:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663074&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: M.-A. Lemburg (lemburg) Summary: codec registry and Python embedding problem Initial Comment: Found by Hartmut Ring: #include int main() { for (int i=0; i<2; i++) { Py_Initialize(); PyRun_SimpleString("a = u'\xe4'.encode('Latin-1')"); Py_Finalize(); } return 0; } First try runs fine, second try gives: Traceback (most recent call last): File "", line 1, in ? LookupError: no codec search functions registered: can't find encoding ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-22 11:07 Message: Logged In: YES user_id=21627 I think the various global variables maintained in codecs.c (_PyCodec_SearchCache, import_encodings_called, ...) need to become part of the interpreter state. Otherwise, a codec registered in one interpreter will be found in another. Also, it appears that import_encodings_called can be eliminated. Instead, a NULL value of _PyCodec_SearchPath could be used to indicate whether initialization has taken place. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-06 13:18 Message: Logged In: YES user_id=38388 This is due to a flag used in codecs.c: /* Flag used for lazy import of the standard encodings package */ static int import_encodings_called = 0; The solution is to reset this flag in Py_Finalize(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663074&group_id=5470 From noreply@sourceforge.net Wed Jan 22 10:08:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 22 Jan 2003 02:08:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-671731 ] time module: time tuple not returned by certain functions Message-ID: Bugs item #671731, was opened at 2003-01-21 11:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671731&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Martin Miller (mrmiller) Assigned to: Nobody/Anonymous (nobody) Summary: time module: time tuple not returned by certain functions Initial Comment: On win32 the gmtime() and localtime() functions in the time module return values of type 'time.time_struct'. I believe the proper return value should be a tuple. This is implied by the documentation (see where it discusses the *time tuple* returned by the various module functions and says it 'is a tuple of 9 integers'. The time_struct value returned does behave like a tuple instance in most respects, except that its type is not type 'tuple'. I think this is something that was changed in the not too distant past, as I noticed the issue after downloading code recently written by others which depends on the type of the return value from these functions being a tuple. If nothing else, if this was changed, it is not backward compatible and the documention ought to be updated. Example: > Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 > Type "help", "copyright", "credits" or "license" for more information. > >>> import time > >>> print time.localtime() > (2003, 1, 21, 3, 3, 2, 1, 21, 0) > >>> print type(time.localtime()) is type(()) > 0 > >>> print type(time.localtime()) > > >>> ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-01-22 10:08 Message: Logged In: YES user_id=6656 Oh yeah. That should *definitely* be backported to the 2.2 docs. Could be more thorough, though. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-22 00:55 Message: Logged In: YES user_id=357491 There is a mention of it in the developer docs at http://www.python.org/dev/doc/devel/lib/module-time.html . The note for struct_time says what functions return a struct_time object. A patch for the docs that changed everything else to say it returns a struct_time object instead of a time tuple wouldn't hurt, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-21 11:40 Message: Logged In: YES user_id=6656 This was very deliberate. It *is* a bit shocking that the docs didn't get updated, though. There's a start of a description in: http://www.python.org/doc/current/whatsnew/node10.html Do you have code that actually broke because of this change? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671731&group_id=5470 From noreply@sourceforge.net Wed Jan 22 11:50:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 22 Jan 2003 03:50:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-672115 ] Assignment to __bases__ of direct object subclasses Message-ID: Bugs item #672115, was opened at 2003-01-21 22:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672115&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) >Assigned to: Michael Hudson (mwh) Summary: Assignment to __bases__ of direct object subclasses Initial Comment: I'm not entirely sure this is a bug, but I think it is surprising: Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class A(object): ... pass ... >>> class B(object): ... pass ... >>> B.__bases__ = (A,) Traceback (most recent call last): File "", line 1, in ? TypeError: __bases__ assignment: 'A' deallocator differs from 'object' It seems like you should be able to change the __bases__ of a new-style class (implemented in Python) which inherits directly from object to another new-style class. (Will the deallocator issue ever come into play if the only types involved are HEAPTYPES and object as the ultimate base?) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-01-22 11:50 Message: Logged In: YES user_id=6656 I agree this is a bit surprising. When I was writing this code I went for the conservative-as-possible approach as I didn't want to introduce instabilities to Python. It certainly may be that I've overdone it. In this case I probably have; if the tp_dealloc of the class being adjusted is subtype_dealloc and the tp_dealloc that ultimately gets invoked is the same we're probably OK. But I'm not sure and it's been a while since I thought about this. It also happens that my motivating use-case for this isn't troubled by this restriction. I don't understand your last, parenthetical, comment. HEAPTYPES as such doesn't come into it, does it? You might be right that we don't need to worry about tp_dealloc if the ultimate solid_base doesn't change and all the tp_deallocs on the way there are subtype_dealloc... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672115&group_id=5470 From noreply@sourceforge.net Wed Jan 22 12:12:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 22 Jan 2003 04:12:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-663074 ] codec registry and Python embedding problem Message-ID: Bugs item #663074, was opened at 2003-01-06 13:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663074&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: M.-A. Lemburg (lemburg) Summary: codec registry and Python embedding problem Initial Comment: Found by Hartmut Ring: #include int main() { for (int i=0; i<2; i++) { Py_Initialize(); PyRun_SimpleString("a = u'\xe4'.encode('Latin-1')"); Py_Finalize(); } return 0; } First try runs fine, second try gives: Traceback (most recent call last): File "", line 1, in ? LookupError: no codec search functions registered: can't find encoding ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-22 13:12 Message: Logged In: YES user_id=38388 Good suggestion. Do you have time to cook up a patch ? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-22 11:07 Message: Logged In: YES user_id=21627 I think the various global variables maintained in codecs.c (_PyCodec_SearchCache, import_encodings_called, ...) need to become part of the interpreter state. Otherwise, a codec registered in one interpreter will be found in another. Also, it appears that import_encodings_called can be eliminated. Instead, a NULL value of _PyCodec_SearchPath could be used to indicate whether initialization has taken place. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-06 13:18 Message: Logged In: YES user_id=38388 This is due to a flag used in codecs.c: /* Flag used for lazy import of the standard encodings package */ static int import_encodings_called = 0; The solution is to reset this flag in Py_Finalize(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663074&group_id=5470 From noreply@sourceforge.net Wed Jan 22 15:28:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 22 Jan 2003 07:28:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-672491 ] 2.3a1 computes lastindex incorrectly Message-ID: Bugs item #672491, was opened at 2003-01-22 16:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672491&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Martin v. Löwis (loewis) Assigned to: Fredrik Lundh (effbot) Summary: 2.3a1 computes lastindex incorrectly Initial Comment: In Python 2.[012], the code import re exp = re.compile("(?P[a-zA-Z_](\w|[_.-])*)") print exp.match("namespace").lastgroup prints "NCName". In Python 2.3a1, it prints "None". The problem is that last index is 2, instead of 1, as it should be. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672491&group_id=5470 From noreply@sourceforge.net Wed Jan 22 17:29:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 22 Jan 2003 09:29:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-672578 ] pydoc does not cope well with lambda Message-ID: Bugs item #672578, was opened at 2003-01-22 09:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672578&group_id=5470 Category: Demos and Tools Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Jim Meyer (purp) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc does not cope well with lambda Initial Comment: pydoc doesn't deal well with lambda expressions. Here's some sample code: ================================================================ #!/usr/bin/env python2 """a bogus program Demonstrate that pydoc doesn't handle lambdas well """ # -------------------------------------------------------------------- # A comment heading # -------------------------------------------------------------------- def foo (optional = 1) : ''' A bogus function ''' return optional bar = lambda opt : foo(opt) ================================================================ ...and here's what pydoc says: ================================================================ > pydoc /tmp/foo.py Python Library Documentation: module foo NAME foo - a bogus program FILE /tmp/foo.py DESCRIPTION Demonstrate that pydoc doesn't handle lambdas well FUNCTIONS lambdaopt # -------------------------------------------------------------------- # A comment heading # -------------------------------------------------------------------- foo(optional=1) A bogus function DATA __file__ = '/tmp/foo.pyc' __name__ = 'foo' ================================================================ I'm looking for the cause now and hope to contribute a patch shortly. --j ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672578&group_id=5470 From noreply@sourceforge.net Wed Jan 22 18:26:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 22 Jan 2003 10:26:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-672614 ] python -S still displays 'Type "help", "cop...' Message-ID: Bugs item #672614, was opened at 2003-01-22 13:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672614&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Douglas Napoleone (derivin) Assigned to: Nobody/Anonymous (nobody) Summary: python -S still displays 'Type "help", "cop...' Initial Comment: $ python -S Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> help Traceback (most recent call last): File "", line 1, in ? NameError: name 'help' is not defined site.py sets up the builtins for help, credits, etc. where this is printed in Py_Main() it is already known wether or not site.py was going to be imported or not. I know its a real nit-pick, but it has bugged me for some time. should be set to a LOW priority. (and yes, the bug is still there in 2.3a1) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672614&group_id=5470 From noreply@sourceforge.net Wed Jan 22 18:26:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 22 Jan 2003 10:26:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-672614 ] python -S still displays 'Type "help", "cop...' Message-ID: Bugs item #672614, was opened at 2003-01-22 13:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672614&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None >Priority: 2 Submitted By: Douglas Napoleone (derivin) Assigned to: Nobody/Anonymous (nobody) >Summary: python -S still displays 'Type "help", "cop...' Initial Comment: $ python -S Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> help Traceback (most recent call last): File "", line 1, in ? NameError: name 'help' is not defined site.py sets up the builtins for help, credits, etc. where this is printed in Py_Main() it is already known wether or not site.py was going to be imported or not. I know its a real nit-pick, but it has bugged me for some time. should be set to a LOW priority. (and yes, the bug is still there in 2.3a1) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672614&group_id=5470 From noreply@sourceforge.net Wed Jan 22 18:26:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 22 Jan 2003 10:26:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-672614 ] python -S still displays 'Type "help", "cop...' Message-ID: Bugs item #672614, was opened at 2003-01-22 13:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672614&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None >Priority: 1 Submitted By: Douglas Napoleone (derivin) Assigned to: Nobody/Anonymous (nobody) >Summary: python -S still displays 'Type "help", "cop...' Initial Comment: $ python -S Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> help Traceback (most recent call last): File "", line 1, in ? NameError: name 'help' is not defined site.py sets up the builtins for help, credits, etc. where this is printed in Py_Main() it is already known wether or not site.py was going to be imported or not. I know its a real nit-pick, but it has bugged me for some time. should be set to a LOW priority. (and yes, the bug is still there in 2.3a1) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672614&group_id=5470 From noreply@sourceforge.net Wed Jan 22 23:33:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 22 Jan 2003 15:33:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-672808 ] Interpreter assertion failure Message-ID: Bugs item #672808, was opened at 2003-01-23 00:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672808&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Tolf (dolda2000) Assigned to: Nobody/Anonymous (nobody) Summary: Interpreter assertion failure Initial Comment: I can't say I know python, I just thought I'd report this bug which I happened to run across. I had decided to try RedHat's hardware browser (for helping a friend with it), which is apparently written is python. It reports that it failed an assertion failure in Objects/stringobject.c:111 (str != ((void *)0)) (Side note: might I ask why you don't write "!= NULL"?). I'm guessing that's part of the interpreter, right? Anyway, this is gdb's bt of the process at the time of the abort signal: #0 0x42028cc1 in kill () from /lib/i686/libc.so.6 #1 0x4002f07d in raise () from /lib/i686/libpthread.so.0 #2 0x4202a019 in abort () from /lib/i686/libc.so.6 #3 0x42021cd6 in __assert_fail () from /lib/i686/libc.so.6 #4 0x0805897b in PyString_FromString () #5 0x409e03d8 in addParallelInfo (dict=0x836b2e4, device=0x40035e20) at kudzumodule.c:141 #6 0x409e0f0f in createDict (probedDevice=0x8357138) at kudzumodule.c:319 #7 0x409e108b in doProbe (self=0x0, args=0x0) at kudzumodule.c:362 #8 0x080ceb13 in PyCFunction_Call () #9 0x080796bc in eval_frame () #10 0x0807a10e in PyEval_EvalCodeEx () #11 0x0807b6a4 in fast_function () #12 0x08079601 in eval_frame () #13 0x0807a10e in PyEval_EvalCodeEx () #14 0x0807b6a4 in fast_function () #15 0x08079601 in eval_frame () #16 0x0807a10e in PyEval_EvalCodeEx () #17 0x080c21bc in function_call () #18 0x080b1557 in PyObject_Call () #19 0x080b827b in instancemethod_call () #20 0x080b1557 in PyObject_Call () #21 0x080687fa in slot_tp_init () ---Type to continue, or q to quit--- #22 0x08060267 in type_call () #23 0x080b1557 in PyObject_Call () #24 0x0807b975 in do_call () #25 0x08079583 in eval_frame () #26 0x0807a10e in PyEval_EvalCodeEx () #27 0x08077025 in PyEval_EvalCode () #28 0x08096a49 in run_node () #29 0x080959c3 in PyRun_SimpleFileExFlags () #30 0x0809530a in PyRun_AnyFileExFlags () #31 0x0805381c in Py_Main () #32 0x08053269 in main () #33 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 Python was run with the arg /usr/share/hwbrowser/DeviceList.py. I'm guessing my version of python is compiled without -g, so I couldn't get much more info at the time. Maybe this bug has been resolved in a later version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672808&group_id=5470 From noreply@sourceforge.net Thu Jan 23 01:55:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 22 Jan 2003 17:55:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-672578 ] pydoc does not cope well with lambda Message-ID: Bugs item #672578, was opened at 2003-01-22 12:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672578&group_id=5470 Category: Demos and Tools Group: Python 2.2.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jim Meyer (purp) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc does not cope well with lambda Initial Comment: pydoc doesn't deal well with lambda expressions. Here's some sample code: ================================================================ #!/usr/bin/env python2 """a bogus program Demonstrate that pydoc doesn't handle lambdas well """ # -------------------------------------------------------------------- # A comment heading # -------------------------------------------------------------------- def foo (optional = 1) : ''' A bogus function ''' return optional bar = lambda opt : foo(opt) ================================================================ ...and here's what pydoc says: ================================================================ > pydoc /tmp/foo.py Python Library Documentation: module foo NAME foo - a bogus program FILE /tmp/foo.py DESCRIPTION Demonstrate that pydoc doesn't handle lambdas well FUNCTIONS lambdaopt # -------------------------------------------------------------------- # A comment heading # -------------------------------------------------------------------- foo(optional=1) A bogus function DATA __file__ = '/tmp/foo.pyc' __name__ = 'foo' ================================================================ I'm looking for the cause now and hope to contribute a patch shortly. --j ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-22 20:55 Message: Logged In: YES user_id=80475 The underlying cause is that the inspect module was not trained to handle lambdas or single line function defintions like: def oneliner(x): return x**2 The problem was fixed in Py2.3 and backported for Py2.2.3. Marking as fixed and closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672578&group_id=5470 From noreply@sourceforge.net Thu Jan 23 02:13:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 22 Jan 2003 18:13:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-672808 ] Interpreter assertion failure Message-ID: Bugs item #672808, was opened at 2003-01-22 18:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672808&group_id=5470 Category: Python Interpreter Core >Group: 3rd Party >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Fredrik Tolf (dolda2000) >Assigned to: Tim Peters (tim_one) Summary: Interpreter assertion failure Initial Comment: I can't say I know python, I just thought I'd report this bug which I happened to run across. I had decided to try RedHat's hardware browser (for helping a friend with it), which is apparently written is python. It reports that it failed an assertion failure in Objects/stringobject.c:111 (str != ((void *)0)) (Side note: might I ask why you don't write "!= NULL"?). I'm guessing that's part of the interpreter, right? Anyway, this is gdb's bt of the process at the time of the abort signal: #0 0x42028cc1 in kill () from /lib/i686/libc.so.6 #1 0x4002f07d in raise () from /lib/i686/libpthread.so.0 #2 0x4202a019 in abort () from /lib/i686/libc.so.6 #3 0x42021cd6 in __assert_fail () from /lib/i686/libc.so.6 #4 0x0805897b in PyString_FromString () #5 0x409e03d8 in addParallelInfo (dict=0x836b2e4, device=0x40035e20) at kudzumodule.c:141 #6 0x409e0f0f in createDict (probedDevice=0x8357138) at kudzumodule.c:319 #7 0x409e108b in doProbe (self=0x0, args=0x0) at kudzumodule.c:362 #8 0x080ceb13 in PyCFunction_Call () #9 0x080796bc in eval_frame () #10 0x0807a10e in PyEval_EvalCodeEx () #11 0x0807b6a4 in fast_function () #12 0x08079601 in eval_frame () #13 0x0807a10e in PyEval_EvalCodeEx () #14 0x0807b6a4 in fast_function () #15 0x08079601 in eval_frame () #16 0x0807a10e in PyEval_EvalCodeEx () #17 0x080c21bc in function_call () #18 0x080b1557 in PyObject_Call () #19 0x080b827b in instancemethod_call () #20 0x080b1557 in PyObject_Call () #21 0x080687fa in slot_tp_init () ---Type to continue, or q to quit--- #22 0x08060267 in type_call () #23 0x080b1557 in PyObject_Call () #24 0x0807b975 in do_call () #25 0x08079583 in eval_frame () #26 0x0807a10e in PyEval_EvalCodeEx () #27 0x08077025 in PyEval_EvalCode () #28 0x08096a49 in run_node () #29 0x080959c3 in PyRun_SimpleFileExFlags () #30 0x0809530a in PyRun_AnyFileExFlags () #31 0x0805381c in Py_Main () #32 0x08053269 in main () #33 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 Python was run with the arg /usr/share/hwbrowser/DeviceList.py. I'm guessing my version of python is compiled without -g, so I couldn't get much more info at the time. Maybe this bug has been resolved in a later version? ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-22 21:13 Message: Logged In: YES user_id=31435 stringobject.c is part of the interpreter, and the code does use str != NULL. The debugger is showing you what the C preprocessor transformed NULL into. PyString_FromString() is part of Python's C API, and the assert is verifying that its caller is calling it correctly -- it explicitly doesn't allow a NULL argument. It was called by addParallelInfo() in kudzumodule.c, which is not part of Python, and must be a C extension module written for the app you're using. The app is buggy if it calls PyString_FromString with a NULL argument, so closing this as 3rd-Party, WontFix (we can't fix it -- there's no sign of a Python bug here, and a clear sign of a bug in kudzumodule.c). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672808&group_id=5470 From noreply@sourceforge.net Thu Jan 23 04:48:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 22 Jan 2003 20:48:31 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-481962 ] Make modules callable Message-ID: Feature Requests item #481962, was opened at 2001-11-14 23:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=481962&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Justin Shaw (justinshaw) Assigned to: Nobody/Anonymous (nobody) Summary: Make modules callable Initial Comment: Many modules are have the same name as the main class they contain. I.E. gnu = Gnuplot.Gnuplot() Why not make modules callable. That is if a module contains a function called "__init__()" then that fucntion gets called whenever the code x = module(args) is encountered. Just an idea. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-22 23:48 Message: Logged In: YES user_id=80475 I don't think this shortcut gives an advantage over: from Gnuplot import Gnuplot . . . x = Gnuplot(args) ---------------------------------------------------------------------- Comment By: Andrew Bennetts (spiv) Date: 2002-06-27 02:51 Message: Logged In: YES user_id=50945 Wouldn't calling a function named "__call__" make more sense than "__init__"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=481962&group_id=5470 From noreply@sourceforge.net Thu Jan 23 04:53:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 22 Jan 2003 20:53:45 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-230359 ] Run script should not appear in shell window Message-ID: Feature Requests item #230359, was opened at 2001-01-28 18:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=230359&group_id=5470 Category: IDLE Group: None >Status: Closed >Resolution: Fixed Priority: 2 Submitted By: Martin v. Löwis (loewis) Assigned to: Neal Norwitz (nnorwitz) Summary: Run script should not appear in shell window Initial Comment: When selecting "Run module" in the shell window, an error message "The buffer Python Shell is not saved..." is produced. Since running the shell window will fail in any case, these menu items should be removed from the shell window. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-22 23:53 Message: Logged In: YES user_id=80475 Was implemented and done for Py2.2.2 and Py2.3a. Marking as fixed and closing. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-26 15:37 Message: Logged In: YES user_id=33168 Reminder to close once IDLEfork is merged. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-03-20 15:06 Message: Logged In: YES user_id=6380 Good suggestion. A revamping of the entire IDLE "run program" interface is planned, but won't be ready in time for 2.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=230359&group_id=5470 From noreply@sourceforge.net Thu Jan 23 04:55:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 22 Jan 2003 20:55:08 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-441833 ] Rule-based logic Message-ID: Feature Requests item #441833, was opened at 2001-07-16 17:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=441833&group_id=5470 Category: None Group: None >Status: Closed Resolution: Rejected Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Rule-based logic Initial Comment: It would be awesome to make Python understand rule- based statements like those in JESS, CLIPS, LISP, and PROLOG. In addition to procedural and object-oriented principles, Python should use non-algorithmic concepts such as facts, rules, constraints, etc. This will allow building expert systems in Python and making "executable pseudocode" truly high-level. All of logic-based systems use the Rete algorithm and lisp- like syntax. Perhaps with Python's economical, intuitive syntax and strong typing the results will be better than in other languages. References: JESS: http://herzberg.ca.sandia.gov/jess/ CLIPS: http://www.ghg.net/clips/CLIPS.html LISP: http://www.norvig.com/lisp_talk_final.htm PROLOG: http://www.amzi.com/articles/prolog_books_tutorials.htm Thank you! ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-07-17 08:49 Message: Logged In: YES user_id=6380 Sorry, this is just too vague. Why don't you make a concrete proposal instead? World peace would be nice too, you know... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=441833&group_id=5470 From noreply@sourceforge.net Thu Jan 23 15:21:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 23 Jan 2003 07:21:26 -0800 Subject: [Python-bugs-list] [ python-Bugs-673115 ] causes crash on Windows2000 Message-ID: Bugs item #673115, was opened at 2003-01-23 09:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=673115&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Toru Furukawa (torufurukawa) Assigned to: Nobody/Anonymous (nobody) Summary: causes crash on Windows2000 Initial Comment: When using a mouse wheel on the code below, I got the error message dialog, saying "Program Error python.exe has generated errors and will be closed by Windows. You will need to restart the program. An error log is being created. [OK]" #---- def foo(event): print "foo" import Tkinter win = Tkinter.Tk() win.bind("", foo) win.mainloop() #---- It happens on Windows2000SP1 + Python 2.2.2. It works on WindowsXP + Python 2.2.2. Other events, like , works fine on Windows2k. The attached file is the log file created at the crash. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=673115&group_id=5470 From noreply@sourceforge.net Thu Jan 23 17:03:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 23 Jan 2003 09:03:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-672115 ] Assignment to __bases__ of direct object subclasses Message-ID: Bugs item #672115, was opened at 2003-01-21 13:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672115&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Michael Hudson (mwh) Summary: Assignment to __bases__ of direct object subclasses Initial Comment: I'm not entirely sure this is a bug, but I think it is surprising: Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class A(object): ... pass ... >>> class B(object): ... pass ... >>> B.__bases__ = (A,) Traceback (most recent call last): File "", line 1, in ? TypeError: __bases__ assignment: 'A' deallocator differs from 'object' It seems like you should be able to change the __bases__ of a new-style class (implemented in Python) which inherits directly from object to another new-style class. (Will the deallocator issue ever come into play if the only types involved are HEAPTYPES and object as the ultimate base?) ---------------------------------------------------------------------- >Comment By: Greg Chapman (glchapman) Date: 2003-01-23 08:03 Message: Logged In: YES user_id=86307 Sorry about the parenthetical comment; I think what I was trying to say is basically what you have in your last paragraph. As for use cases, I don't have any myself (I ran into this with some test code for a metaclass which "overrides" __bases__). However, grepping through the standard library, I note that one place where assignment to __bases__ is used is in xmlrpclib.SlowParser. It appears to me that if SlowParser and xmllib.XMLParser (neither of which has a base class) were converted to new-style classes, the assignment to __bases__ would generate this exception. Of course, that shouldn't be too hard to work around if that turns out to be necessary. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-22 02:50 Message: Logged In: YES user_id=6656 I agree this is a bit surprising. When I was writing this code I went for the conservative-as-possible approach as I didn't want to introduce instabilities to Python. It certainly may be that I've overdone it. In this case I probably have; if the tp_dealloc of the class being adjusted is subtype_dealloc and the tp_dealloc that ultimately gets invoked is the same we're probably OK. But I'm not sure and it's been a while since I thought about this. It also happens that my motivating use-case for this isn't troubled by this restriction. I don't understand your last, parenthetical, comment. HEAPTYPES as such doesn't come into it, does it? You might be right that we don't need to worry about tp_dealloc if the ultimate solid_base doesn't change and all the tp_deallocs on the way there are subtype_dealloc... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672115&group_id=5470 From noreply@sourceforge.net Thu Jan 23 18:08:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 23 Jan 2003 10:08:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-661340 ] test_httplib fails on the mac Message-ID: Bugs item #661340, was opened at 2003-01-02 22:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661340&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Jeremy Hylton (jhylton) Summary: test_httplib fails on the mac Initial Comment: test_httplib fails on MacPython-OS9. This is because the output contains \r and \n characters, and this fails on MacOS9. There are two problems really: 1. output/test_httplib is checked in as a text file, while it is a binary file (it contains some \r\n data) or even (brrr:-) mixed-mode (it also contains \n lineendings). 2. The output file is opened in text mode (when re-reading the data), so this can probably not be fixed by a simple cvs admin -kb. I think that putting repr()s in the output in stead of raw strings is probably good enough, but you probably know better what is going on here. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-01-23 18:08 Message: Logged In: YES user_id=31392 Fixed in rev 1.10 of test_httplib.py ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-01-14 21:27 Message: Logged In: YES user_id=31392 I think the actual line-endings are uninteresting as far as what the test is trying to do. I've changed the test so that it doesn't contain \r\n pairs. I think the right thing is to change the way debugging output is generated by httplib, but that's a big project. So I'll just change the test to capture stdout and clean it before printing it. (Checking coming as soon as sourceforge responds.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661340&group_id=5470 From noreply@sourceforge.net Thu Jan 23 18:15:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 23 Jan 2003 10:15:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-625698 ] Errors with recursive objects Message-ID: Bugs item #625698, was opened at 2002-10-19 19:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Erik Andersén (erik_andersen) Assigned to: Jeremy Hylton (jhylton) Summary: Errors with recursive objects Initial Comment: List and dictionaries put Python into an infinite loop if they contain more than one reference to itself >>> d = {} >>> d[1] = d >>> d == d # OK Python can handle one recursion 1 >>> d[2] = d >>> d == d # Crash with two Lists are similar >>> l=[] >>> l.append(l) >>> l==l # OK 1 >>> l.append(l) >>> l==l # Crash >>> l>l # Also crash Tested with ActivePython 2.2.1 under Windows 98 and (the first part) Python 2.2.2 under Linux ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-01-23 18:15 Message: Logged In: YES user_id=31392 Maybe I need to read the code again, but IIRC the code doesn't assume that id(a) == id(b) implies a == b. Rather it uses id(a) and id(b) to look for recursive calls to compare. It assumes that a == b will always produce the same result when invoked recursively within a comparison. I think a decent solution is to create a latch for the nesting limit. If a comparison ever exceeds the recursion limit, the check is done until the comparison is finished. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-22 03:09 Message: Logged In: YES user_id=31435 llit, you should study the current code before suggesting an algorithm. The current code would be blazing fast if it were looking for recursion from the start too. But the very process of building that dict with the ids of the objects as keys (which the current algorithm also does) costs more than most comparisons cost in real life. That's why the current code doesn't even try to catch recursion until the comparison level exceeds 20, and that's where the sloth comes from. Stick a gimmick like that in your algorithm, and you'll have similar speed problems. Also note that id(a) == id(b) doesn't imply a == b (see the other note about NaN for an example). ---------------------------------------------------------------------- Comment By: Till Plewe (llit) Date: 2003-01-21 06:01 Message: Logged In: YES user_id=540660 How about checking for equality by trying to build a bisimulation which "proves" equality. Time complexity is O(nodes(a) x nodes(b)) SAMPLE PYTHON CODE =============================== #! /usr/bin/env python from types import * SeqType=[ListType,DictType,TupleType] def isequal(a,b): if id(a)==id(b): return True compare={(id(a),id(b)):(a,b)} bisimilar={} while compare: (ida,idb),(oba,obb)=compare.popitem() if ida==idb: continue elif type(oba)==type(obb): if type(oba) not in SeqType: if oba!=obb: return False else: continue elif len(oba)!=len(obb): return False elif (ida,idb) not in bisimilar: bisimilar[(ida,idb)]=1 if type(oba)==DictType: for x in oba: #oba and obb have the same number of keys if x not in obb: return False else: compare[(id(oba[x]),id(obb[x]))]=(oba[x],obb[x]) else: for x,y in zip(oba,obb): compare[(id(x),id(y))]=(x,y) else: return False return bisimilar ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 20:44 Message: Logged In: YES user_id=31435 Cool. He's right that they can take a horrendously long time. The 2-element list example takes c*2**20 units of time, for some suitable constant c, and if it were extended to 3 elements, it would take c*3**20 units of time, thousands of times longer. As Erik's latest example shows, the outcome isn't always particularly well defined either. An alternative to speeding this silliness is to raise an exception instead when recursive objects are detected. There was some hack value in doing the graph isomorphism bit, but no real practical value I can see. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-20 20:20 Message: Logged In: YES user_id=33168 Sorry Tim, I was going to reply to one of your first msgs and forgot. Erik sent me mail which said there wasn't a crash, just that "the statements take horrendously long time to execute." ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 20:09 Message: Logged In: YES user_id=31435 BTW, Erik, what did you mean by "crash"? Nobody else has seen a crash here. You started the report by saying "infinite loop", which isn't the same thing as a crash. There isn't an infinite loop here either, although the algorithm can take astronomical amounts of time to finish (so may appear to be in an infinite loop). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 19:50 Message: Logged In: YES user_id=31435 Equailty for self-consistent recursive objects does a graph isomorphism computation. In your self-inconsistent example, it so happens that False is returned, although True would be returned if the compile-time constant (in object.c) NESTING_LIMIT were odd instead of even. But if you worry about this, you need to get out more . ---------------------------------------------------------------------- Comment By: Erik Andersén (erik_andersen) Date: 2003-01-20 19:24 Message: Logged In: YES user_id=364358 Excuse me for interupting the efficiency discussion, but what is the definition of equality for recursive containers. I am particularly worrided about cases like >>> class A: ... def __eq__(self,other): return not self.u==other.u ... >>> a=A() >>> l=[a] >>> a.u=l >>> l==l # ???? If l==l then a!=a and l[0]!=l[0], so l!=l. If l!=l then a==a and l[0]==l[0], so l==l !!!!!!! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 16:12 Message: Logged In: YES user_id=31435 I deleted my patch -- it didn't make sense. Martin, AFAIK the docs say nothing about the relationship (if any) between "is" and "==". It was deliberate intent that "is" not imply "==" for rich comparisons, though, in part so that IEEE-754 rules for NaN could be implemented by users. >>> class NaN: ... def __eq__(self, other): return False ... >>> n = NaN() >>> n is n True >>> n == n False >>> ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-20 08:20 Message: Logged In: YES user_id=21627 Where does the documentation say that "is" may not imply ==? The check for recursion assumes this implication, anyway: if we meet the very same object, we infer that they are equal. What is the purpose of clear_inprogress_dict in your patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 04:28 Message: Logged In: YES user_id=31435 The patch assumes "is" implies "==", which isn't necessarily so for rich comparisons. The attached patch cuts the time about in half, via: 1. Getting rid of the per-thread inprogress dicts, in favor of a shared inprogress dict. 2. Restoring the intent of the code that tuples be exempted (tuples can't be recursive). Rev 2.65 of tupleobject.c gave tuples a tp_as_mapping slot, breaking the intent of the code. 3. Changing the inprogress dict to map a tuple to the smallest value of compare_nesting at which the tuple was seen. delete_token() was changed to leave the token alone if the current compare_nesting value is greater than that. This allows tuples to stay in the dict longer. 4. Cutting NESTING_LIMIT from 20 to 19. This has a huge effect, because the algorithm is still basically exponential- time. The problem remaining is that the inprogress dict is still useless (and empty) so long as compare_nesting is less than NESTING_LIMIT. This can leave an exponential amount of work to be done to fight back up to NESTING_LIMIT. Leaving stuff in inprogress longer, and consulting inprogress regardless of the value of compare_nesting (provided that's gone over NESTING_LIMIT at least once) slashes the time to triviality. However, it isn't safe: we can't know that the addresses in the dict keys refer to the same objects then. We could if started storing into inprogress from the very start, but that would be a big speed hit for usual-case comparisons. I'd be happy to knock NESTING_LIMIT down more, though. Assigned to Jeremy, as IIRC this was his code originally. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-19 17:30 Message: Logged In: YES user_id=21627 The patch is fine, except that a comment needs to be added explaining what this does and why it does that. It should be understood that this can't fix the very similar case a = [] a.append(a) a.append(a) b = [] b.append(b) b.append(b) a==b This would still take a long time, right? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-19 16:05 Message: Logged In: YES user_id=33168 Attached is a patch which fixes the problem for me. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-08 00:59 Message: Logged In: YES user_id=33168 Erik, do you still have this problem with 2.2.2? I can't reproduce your problem under Linux. mly can't reproduce the problems with 2.2.1 on Windows (2000). Do you only have the problem on Windows? ---------------------------------------------------------------------- Comment By: Magnus Lyckå (mly) Date: 2002-10-26 23:12 Message: Logged In: YES user_id=95217 I tried the above under Python 2.2.1 (#34, Sep 27 2002, 18:37:42) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. (ActiveState on Win 2000) and Python 2.1.1 (#1, Aug 20 2001, 20:23:29) [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.60mdk)] on linux-i386 In both cases it works correctly. No crash. It takes a lot of time though, Several seconds on Duron 700 w/ Win2k, and tens of seconds on K6-233 w/ Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 From noreply@sourceforge.net Thu Jan 23 18:57:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 23 Jan 2003 10:57:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-625698 ] Errors with recursive objects Message-ID: Bugs item #625698, was opened at 2002-10-19 15:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Erik Andersén (erik_andersen) Assigned to: Jeremy Hylton (jhylton) Summary: Errors with recursive objects Initial Comment: List and dictionaries put Python into an infinite loop if they contain more than one reference to itself >>> d = {} >>> d[1] = d >>> d == d # OK Python can handle one recursion 1 >>> d[2] = d >>> d == d # Crash with two Lists are similar >>> l=[] >>> l.append(l) >>> l==l # OK 1 >>> l.append(l) >>> l==l # Crash >>> l>l # Also crash Tested with ActivePython 2.2.1 under Windows 98 and (the first part) Python 2.2.2 under Linux ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-23 13:57 Message: Logged In: YES user_id=31435 I'll attach a patch with a simple recursion latch. It handles the small examples fine. Make them bigger and sloth returns, though; e.g., this one takes more than 20 seconds after the patch (but longer than the lifetime of the universe without the patch): N = 1000 print "building a" a = [] for i in range(N): a.append(a) print "building b" b = [] for i in range(N): b.append(b) print "comparing" print a == b So long as inprogress entries don't outlive the comparison call that created them, it still leaves exponentially- compounding overhead to keep on recreating the entries that used to exist. But if an inprogress entry does outlive the comparison that created it, then the cached addresses may end up attached to objects other than the original comparands, and how to get each thread to eventually clear its inprogress dict becomes a puzzle and/or an expense. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-01-23 13:15 Message: Logged In: YES user_id=31392 Maybe I need to read the code again, but IIRC the code doesn't assume that id(a) == id(b) implies a == b. Rather it uses id(a) and id(b) to look for recursive calls to compare. It assumes that a == b will always produce the same result when invoked recursively within a comparison. I think a decent solution is to create a latch for the nesting limit. If a comparison ever exceeds the recursion limit, the check is done until the comparison is finished. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-21 22:09 Message: Logged In: YES user_id=31435 llit, you should study the current code before suggesting an algorithm. The current code would be blazing fast if it were looking for recursion from the start too. But the very process of building that dict with the ids of the objects as keys (which the current algorithm also does) costs more than most comparisons cost in real life. That's why the current code doesn't even try to catch recursion until the comparison level exceeds 20, and that's where the sloth comes from. Stick a gimmick like that in your algorithm, and you'll have similar speed problems. Also note that id(a) == id(b) doesn't imply a == b (see the other note about NaN for an example). ---------------------------------------------------------------------- Comment By: Till Plewe (llit) Date: 2003-01-21 01:01 Message: Logged In: YES user_id=540660 How about checking for equality by trying to build a bisimulation which "proves" equality. Time complexity is O(nodes(a) x nodes(b)) SAMPLE PYTHON CODE =============================== #! /usr/bin/env python from types import * SeqType=[ListType,DictType,TupleType] def isequal(a,b): if id(a)==id(b): return True compare={(id(a),id(b)):(a,b)} bisimilar={} while compare: (ida,idb),(oba,obb)=compare.popitem() if ida==idb: continue elif type(oba)==type(obb): if type(oba) not in SeqType: if oba!=obb: return False else: continue elif len(oba)!=len(obb): return False elif (ida,idb) not in bisimilar: bisimilar[(ida,idb)]=1 if type(oba)==DictType: for x in oba: #oba and obb have the same number of keys if x not in obb: return False else: compare[(id(oba[x]),id(obb[x]))]=(oba[x],obb[x]) else: for x,y in zip(oba,obb): compare[(id(x),id(y))]=(x,y) else: return False return bisimilar ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 15:44 Message: Logged In: YES user_id=31435 Cool. He's right that they can take a horrendously long time. The 2-element list example takes c*2**20 units of time, for some suitable constant c, and if it were extended to 3 elements, it would take c*3**20 units of time, thousands of times longer. As Erik's latest example shows, the outcome isn't always particularly well defined either. An alternative to speeding this silliness is to raise an exception instead when recursive objects are detected. There was some hack value in doing the graph isomorphism bit, but no real practical value I can see. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-20 15:20 Message: Logged In: YES user_id=33168 Sorry Tim, I was going to reply to one of your first msgs and forgot. Erik sent me mail which said there wasn't a crash, just that "the statements take horrendously long time to execute." ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 15:09 Message: Logged In: YES user_id=31435 BTW, Erik, what did you mean by "crash"? Nobody else has seen a crash here. You started the report by saying "infinite loop", which isn't the same thing as a crash. There isn't an infinite loop here either, although the algorithm can take astronomical amounts of time to finish (so may appear to be in an infinite loop). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 14:50 Message: Logged In: YES user_id=31435 Equailty for self-consistent recursive objects does a graph isomorphism computation. In your self-inconsistent example, it so happens that False is returned, although True would be returned if the compile-time constant (in object.c) NESTING_LIMIT were odd instead of even. But if you worry about this, you need to get out more . ---------------------------------------------------------------------- Comment By: Erik Andersén (erik_andersen) Date: 2003-01-20 14:24 Message: Logged In: YES user_id=364358 Excuse me for interupting the efficiency discussion, but what is the definition of equality for recursive containers. I am particularly worrided about cases like >>> class A: ... def __eq__(self,other): return not self.u==other.u ... >>> a=A() >>> l=[a] >>> a.u=l >>> l==l # ???? If l==l then a!=a and l[0]!=l[0], so l!=l. If l!=l then a==a and l[0]==l[0], so l==l !!!!!!! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 11:12 Message: Logged In: YES user_id=31435 I deleted my patch -- it didn't make sense. Martin, AFAIK the docs say nothing about the relationship (if any) between "is" and "==". It was deliberate intent that "is" not imply "==" for rich comparisons, though, in part so that IEEE-754 rules for NaN could be implemented by users. >>> class NaN: ... def __eq__(self, other): return False ... >>> n = NaN() >>> n is n True >>> n == n False >>> ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-20 03:20 Message: Logged In: YES user_id=21627 Where does the documentation say that "is" may not imply ==? The check for recursion assumes this implication, anyway: if we meet the very same object, we infer that they are equal. What is the purpose of clear_inprogress_dict in your patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-19 23:28 Message: Logged In: YES user_id=31435 The patch assumes "is" implies "==", which isn't necessarily so for rich comparisons. The attached patch cuts the time about in half, via: 1. Getting rid of the per-thread inprogress dicts, in favor of a shared inprogress dict. 2. Restoring the intent of the code that tuples be exempted (tuples can't be recursive). Rev 2.65 of tupleobject.c gave tuples a tp_as_mapping slot, breaking the intent of the code. 3. Changing the inprogress dict to map a tuple to the smallest value of compare_nesting at which the tuple was seen. delete_token() was changed to leave the token alone if the current compare_nesting value is greater than that. This allows tuples to stay in the dict longer. 4. Cutting NESTING_LIMIT from 20 to 19. This has a huge effect, because the algorithm is still basically exponential- time. The problem remaining is that the inprogress dict is still useless (and empty) so long as compare_nesting is less than NESTING_LIMIT. This can leave an exponential amount of work to be done to fight back up to NESTING_LIMIT. Leaving stuff in inprogress longer, and consulting inprogress regardless of the value of compare_nesting (provided that's gone over NESTING_LIMIT at least once) slashes the time to triviality. However, it isn't safe: we can't know that the addresses in the dict keys refer to the same objects then. We could if started storing into inprogress from the very start, but that would be a big speed hit for usual-case comparisons. I'd be happy to knock NESTING_LIMIT down more, though. Assigned to Jeremy, as IIRC this was his code originally. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-19 12:30 Message: Logged In: YES user_id=21627 The patch is fine, except that a comment needs to be added explaining what this does and why it does that. It should be understood that this can't fix the very similar case a = [] a.append(a) a.append(a) b = [] b.append(b) b.append(b) a==b This would still take a long time, right? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-19 11:05 Message: Logged In: YES user_id=33168 Attached is a patch which fixes the problem for me. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 19:59 Message: Logged In: YES user_id=33168 Erik, do you still have this problem with 2.2.2? I can't reproduce your problem under Linux. mly can't reproduce the problems with 2.2.1 on Windows (2000). Do you only have the problem on Windows? ---------------------------------------------------------------------- Comment By: Magnus Lyckå (mly) Date: 2002-10-26 19:12 Message: Logged In: YES user_id=95217 I tried the above under Python 2.2.1 (#34, Sep 27 2002, 18:37:42) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. (ActiveState on Win 2000) and Python 2.1.1 (#1, Aug 20 2001, 20:23:29) [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.60mdk)] on linux-i386 In both cases it works correctly. No crash. It takes a lot of time though, Several seconds on Duron 700 w/ Win2k, and tens of seconds on K6-233 w/ Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 From noreply@sourceforge.net Thu Jan 23 21:50:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 23 Jan 2003 13:50:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-660872 ] datetimetz constructors behave counterintuitively (2.3a1) Message-ID: Bugs item #660872, was opened at 2003-01-01 19:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660872&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Phillip J. Eby (pje) Assigned to: Tim Peters (tim_one) Summary: datetimetz constructors behave counterintuitively (2.3a1) Initial Comment: datetimetz.fromtimestamp(timestamp,tzinfo) creates a datetime which has the localtime() value of timestamp, with the tzinfo attached as its timezone. But this produces a counterintuitive result. Instead of getting the UTC time represented by timestamp, converted to the tzinfo timezone, one only ends up with a correct value if tzinfo is a perfect match for whatever 'localtime' is. This seems useless as well as counterintuitive, since one must therefore do this: datetimetz.fromtimestamp(stamp,localtime_tz).astimezone(tzinfo) to get what's desired. Or, one can do: datetimetz.utcfromtimestamp(stamp).replace(tzinfo=utc).astimezone(tzinfo) Both of these seem unreasonably complex ways of doing something simple: render this UTC timestamp as a datetime in a specified timezone. Similarly, I would expect datetimetz.now(tzinfo) to return the current time in the zone specified by tzinfo, but again this is not what it does. Similarly, you must do: datetimetz.now(localtime_tz).astimezone(tzinfo) or: datetimetz.utcnow().replace(tzinfo=utc).astimezone(tzinfo) to get the current time in the zone specified by tzinfo. Given that these constructors *know* what the UTC time is, why don't they behave more meaningfully? It seems to me that finding the current time in a timezone, or rendering a timestamp as it would be seen in a timezone, are common enough use cases, but I cannot think of any use cases for what the constructors actually do instead. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-23 16:50 Message: Logged In: YES user_id=31435 now() and fromtimestamp() now do "the right thing" with their optional tzinfo argument. The argument name was changed to "tz", BTW, as "tzinfo" had enough meanings already. Appropriate changes were checked into the Python datetimemodule.c and Zope3 _datetime.py implementations, + their test suites and LaTeX docs. Guido, your complaint about astimezone() was incidentally fixed in checkins prior to this -- astimezone() no longer supports converting between naive and aware datetimes, and also complains if the tzinfo object's utcoffset() or dst() methods return None. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-02 11:46 Message: Logged In: YES user_id=6380 I think that Phillip's proposal is reasonable: when you give a tzinfo argument to datetimetz.fromtimestamp(), it should *convert* to the given tzinfo. I think the proper semantics are specified by this expression: datetimetz.utcfromtimestamp(stamp).replace(tzinfo=utc).astimezone(tzinfo) The rule for now() follows from this. BTW, I think it was a mistake to let astimezone() convert from/to naive times. It should only be used for conversion between tz-aware times; conversion from/to naive time should be done using dt.replace(tzinfo=...). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-01 23:47 Message: Logged In: YES user_id=31435 I think Guido has more energy for this than I have (I'm pretty much burned out on this module), so assigned it to him. At the time fromtimestamp() was added, there wasn't any reasonable way to simply attach a tzinfo object to a datetimetz. About the best you could do is new = datetimetz(old.year, old.month, old.day, old.hour, old.minute, old.second, old.microsecond, tzinfo) So the use case of *simply* getting a local datetimetz out of a timestamp was quite a pain. datetimetz.fromtimestamp grew an optional tzinfo arg to ease that pain. There was no notion of timezone conversion at that time either, so of course none of the methods were intended to do any sort of conversion. Note that the primary constructor-- datetimetz --also takes all of its arguments as being in local time. It would strike me as inconsistent if fromtimestamp() didn't also take its argument as being in local time. Things changed since then, and I at least agree the docs should be clarified. But rather than make the constructors even more complicated, I'd rather drop the optional tzinfo arguments from fromtimestamp() and now(). There are at least two easy ways to attach a tzinfo tz to a datetimetz now: new = old.astimezone(tz) # no conversion if old was naive new = old.replace(tzinfo=tz) # no conversion ever and there's also an explict time zone conversion method. ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2003-01-01 22:40 Message: Logged In: YES user_id=56214 But in your use case, if the timezone they attach is in fact equivalent to localtime, then the conversion would be a no-op anyway, right? So how would a conversion in the general case be wrong? At the very least, this is a documentation bug. If these constructors only produce meaningful results for a tzinfo that's exactly equivalent to the system's localtime(), then the docs should say so. Otherwise, someone can write code that appears to work, for example, on their own machine, and then fails when run on a machine with a different concept of localtime(). Now, if you can actually come up with a sensible use case for *wrongly* translating a UTC-based timestamp to a particular timezone, with the degree of wrongness depending on the difference between localtime() and the specified timezone, that might justify the constructor behavior. :) As it is, I find it hard to believe that whatever you come up with will be a more common need than rendering a UTC timestamp as a datetime value in a specified timezone. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-01 20:14 Message: Logged In: YES user_id=31435 I always figured the use case for fromtimestamp(stamp, tz) was indeed so the user had a dead-easy way to attach their own local time tzinfo class to a timestamp, and that's all. I would find the behavior you describe counterintuitive instead: if I want a conversion, I'd rather ask for one explicitly (via astimezone()). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660872&group_id=5470 From noreply@sourceforge.net Thu Jan 23 23:06:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 23 Jan 2003 15:06:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-654558 ] make error reporting better like cgi Message-ID: Bugs item #654558, was opened at 2002-12-16 06:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654558&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None >Priority: 6 Submitted By: Hunter Peress (hfastedge) Assigned to: Nobody/Anonymous (nobody) Summary: make error reporting better like cgi Initial Comment: do something bad in something that uses cgitb, it will show you actual values of the variables at that point in the error message....and a host of useful info. I think this should be done normally as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654558&group_id=5470 From noreply@sourceforge.net Thu Jan 23 23:20:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 23 Jan 2003 15:20:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-654558 ] make error reporting better like cgi Message-ID: Bugs item #654558, was opened at 2002-12-16 06:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654558&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None >Priority: 7 Submitted By: Hunter Peress (hfastedge) Assigned to: Nobody/Anonymous (nobody) Summary: make error reporting better like cgi Initial Comment: do something bad in something that uses cgitb, it will show you actual values of the variables at that point in the error message....and a host of useful info. I think this should be done normally as well. ---------------------------------------------------------------------- >Comment By: Hunter Peress (hfastedge) Date: 2003-01-23 18:20 Message: Logged In: YES user_id=479934 HOW TO REPRODUCE: We are going to test a basic piece of logic. In normal interpreter (from cmdline), and in cgi mode. We will see just how different the error reporting is: FIRST the basic LOGIC: l=[1,2,3,4,5] for i in range(len(l)): print i,l[i],l ; del l[i] Next implement it in CGI: #!/usr/bin/python2.2 import sys,commands,os,re,string,cgi,cgitb cgitb.enable(1) print "Content-type: text/html\n\n" LOGIC GOES HERE NOW Observe how nice the error is: /home/hperes/public_html/cgi-bin/cgiShow.cgi 4 print "Content-type: text/html\n\n" 5 print "HI" 6 l=[1,2,3,4,5] 7 for i in range(len(l)): 8 print i,l[i],l ; del l[i] i = 3, l = [2, 4] IndexError: list index out of range __doc__ = 'Sequence index out of range.' __getitem__ = > __init__ = > __module__ = 'exceptions' __str__ = > args = ('list index out of range',) See how you can see the values of all the variables on the line?? Next implement it in cmdline: 0 1 [1, 2, 3, 4, 5] 1 3 [2, 3, 4, 5] 2 5 [2, 4, 5] 3 Traceback (most recent call last): File "s", line 5, in ? print i,l[i],l ; del l[i] IndexError: list index out of range See how much more useless that is? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654558&group_id=5470 From noreply@sourceforge.net Thu Jan 23 23:21:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 23 Jan 2003 15:21:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-654558 ] make error reporting better like cgi Message-ID: Bugs item #654558, was opened at 2002-12-16 06:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654558&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None >Priority: 9 Submitted By: Hunter Peress (hfastedge) Assigned to: Nobody/Anonymous (nobody) Summary: make error reporting better like cgi Initial Comment: do something bad in something that uses cgitb, it will show you actual values of the variables at that point in the error message....and a host of useful info. I think this should be done normally as well. ---------------------------------------------------------------------- Comment By: Hunter Peress (hfastedge) Date: 2003-01-23 18:20 Message: Logged In: YES user_id=479934 HOW TO REPRODUCE: We are going to test a basic piece of logic. In normal interpreter (from cmdline), and in cgi mode. We will see just how different the error reporting is: FIRST the basic LOGIC: l=[1,2,3,4,5] for i in range(len(l)): print i,l[i],l ; del l[i] Next implement it in CGI: #!/usr/bin/python2.2 import sys,commands,os,re,string,cgi,cgitb cgitb.enable(1) print "Content-type: text/html\n\n" LOGIC GOES HERE NOW Observe how nice the error is: /home/hperes/public_html/cgi-bin/cgiShow.cgi 4 print "Content-type: text/html\n\n" 5 print "HI" 6 l=[1,2,3,4,5] 7 for i in range(len(l)): 8 print i,l[i],l ; del l[i] i = 3, l = [2, 4] IndexError: list index out of range __doc__ = 'Sequence index out of range.' __getitem__ = > __init__ = > __module__ = 'exceptions' __str__ = > args = ('list index out of range',) See how you can see the values of all the variables on the line?? Next implement it in cmdline: 0 1 [1, 2, 3, 4, 5] 1 3 [2, 3, 4, 5] 2 5 [2, 4, 5] 3 Traceback (most recent call last): File "s", line 5, in ? print i,l[i],l ; del l[i] IndexError: list index out of range See how much more useless that is? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654558&group_id=5470 From noreply@sourceforge.net Fri Jan 24 00:19:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 23 Jan 2003 16:19:43 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-481962 ] Make modules callable Message-ID: Feature Requests item #481962, was opened at 2001-11-14 23:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=481962&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Justin Shaw (justinshaw) Assigned to: Nobody/Anonymous (nobody) Summary: Make modules callable Initial Comment: Many modules are have the same name as the main class they contain. I.E. gnu = Gnuplot.Gnuplot() Why not make modules callable. That is if a module contains a function called "__init__()" then that fucntion gets called whenever the code x = module(args) is encountered. Just an idea. ---------------------------------------------------------------------- >Comment By: Thomas Justin Shaw (justinshaw) Date: 2003-01-23 19:19 Message: Logged In: YES user_id=135558 The problem with: from Gnuplot import Gnuplot is that now you cannot do: d = Gnuplot.Data() Yes, I agree "__call__" is more explicit. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-22 23:48 Message: Logged In: YES user_id=80475 I don't think this shortcut gives an advantage over: from Gnuplot import Gnuplot . . . x = Gnuplot(args) ---------------------------------------------------------------------- Comment By: Andrew Bennetts (spiv) Date: 2002-06-27 03:51 Message: Logged In: YES user_id=50945 Wouldn't calling a function named "__call__" make more sense than "__init__"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=481962&group_id=5470 From noreply@sourceforge.net Fri Jan 24 03:58:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 23 Jan 2003 19:58:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-673797 ] setting socket timeout crashes SSL? Message-ID: Bugs item #673797, was opened at 2003-01-23 22:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=673797&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Craig Allen (cba037) Assigned to: Nobody/Anonymous (nobody) Summary: setting socket timeout crashes SSL? Initial Comment: First: bravo for compiling SSL support in the 2.3 binaries! I can connect fine to a secure web server using HTTPS. However, when I set a socket default timeout, I get errors: import socket socket.setdefaulttimeout(30.0) import urllib f = urllib.urlopen('https://members.tufts-health.com/memindex.html') print f.read() =================== Traceback (most recent call last): File "testssl.py", line 9, in ? f = urllib.urlopen('https://members.tufts-health.com/memindex.html') File "/usr/lib/python2.3/urllib.py", line 76, in urlopen return opener.open(url) File "/usr/lib/python2.3/urllib.py", line 181, in open return getattr(self, name)(url) File "/usr/lib/python2.3/urllib.py", line 375, in open_https h.endheaders() File "/usr/lib/python2.3/httplib.py", line 695, in endheaders self._send_output() File "/usr/lib/python2.3/httplib.py", line 581, in _send_output self.send(msg) File "/usr/lib/python2.3/httplib.py", line 548, in send self.connect() File "/usr/lib/python2.3/httplib.py", line 945, in connect ssl = socket.ssl(realsock, self.key_file, self.cert_file) socket.sslerror: (2, 'The operation did not complete (read)') =================== This is on Linux; similar behaviour on Win2K. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=673797&group_id=5470 From noreply@sourceforge.net Fri Jan 24 17:17:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 24 Jan 2003 09:17:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-654558 ] make error reporting better like cgi Message-ID: Bugs item #654558, was opened at 2002-12-16 05:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654558&group_id=5470 Category: Python Interpreter Core Group: Feature Request >Status: Closed >Resolution: Invalid >Priority: 5 Submitted By: Hunter Peress (hfastedge) Assigned to: Nobody/Anonymous (nobody) Summary: make error reporting better like cgi Initial Comment: do something bad in something that uses cgitb, it will show you actual values of the variables at that point in the error message....and a host of useful info. I think this should be done normally as well. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-01-24 11:17 Message: Logged In: YES user_id=44345 Please don't needlessly boost priorities. This is hardly of highest priority (it doesn't crash the interpreter, for example). The issue of invoking cgitb functionality automatically was discussed at length when the module was first added to the system. It was decided that the possibility for breakage was too great. After all, other people have almost certainly had to address this problem in their own cgi scripts. Invoking cgitb may thwart those mechanisms, or worse, present clues about the internal workings of the system which would give bad guys help breaking into systems. In short, feel free to import cgitb into your own cgi scripts, but don't force others to use it if they choose not to. ---------------------------------------------------------------------- Comment By: Hunter Peress (hfastedge) Date: 2003-01-23 17:20 Message: Logged In: YES user_id=479934 HOW TO REPRODUCE: We are going to test a basic piece of logic. In normal interpreter (from cmdline), and in cgi mode. We will see just how different the error reporting is: FIRST the basic LOGIC: l=[1,2,3,4,5] for i in range(len(l)): print i,l[i],l ; del l[i] Next implement it in CGI: #!/usr/bin/python2.2 import sys,commands,os,re,string,cgi,cgitb cgitb.enable(1) print "Content-type: text/html\n\n" LOGIC GOES HERE NOW Observe how nice the error is: /home/hperes/public_html/cgi-bin/cgiShow.cgi 4 print "Content-type: text/html\n\n" 5 print "HI" 6 l=[1,2,3,4,5] 7 for i in range(len(l)): 8 print i,l[i],l ; del l[i] i = 3, l = [2, 4] IndexError: list index out of range __doc__ = 'Sequence index out of range.' __getitem__ = > __init__ = > __module__ = 'exceptions' __str__ = > args = ('list index out of range',) See how you can see the values of all the variables on the line?? Next implement it in cmdline: 0 1 [1, 2, 3, 4, 5] 1 3 [2, 3, 4, 5] 2 5 [2, 4, 5] 3 Traceback (most recent call last): File "s", line 5, in ? print i,l[i],l ; del l[i] IndexError: list index out of range See how much more useless that is? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654558&group_id=5470 From noreply@sourceforge.net Fri Jan 24 17:36:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 24 Jan 2003 09:36:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-654558 ] make error reporting better like cgi Message-ID: Bugs item #654558, was opened at 2002-12-16 06:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654558&group_id=5470 Category: Python Interpreter Core Group: Feature Request >Status: Open Resolution: Invalid >Priority: 9 Submitted By: Hunter Peress (hfastedge) Assigned to: Nobody/Anonymous (nobody) Summary: make error reporting better like cgi Initial Comment: do something bad in something that uses cgitb, it will show you actual values of the variables at that point in the error message....and a host of useful info. I think this should be done normally as well. ---------------------------------------------------------------------- >Comment By: Hunter Peress (hfastedge) Date: 2003-01-24 12:36 Message: Logged In: YES user_id=479934 montanaro: FIRST, I put the priority on 9 because I finally added a huge chunk of code to show what I was talking about. Given this , and since this bug was in the system for so long, I flagged it to 9, solely so that it would reget some needed attention, and then expecting one of the powers that be to bring it back down to normal. WELL: not only did you not do this. You closed the bug, AND you completely did not comprehend what its point is. Quickly: i show the the STRENGTHS of the error reporting mechanism in cgitb, and this bug suggests that some (if not all) features should be implemented in the normal interpreter. Most useful is the fact that you get to see values of all variables on the line causing error. As you can see, i reflagged this to 9 solely to get your attention. please bring it back down to 5 when u read this. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-24 12:17 Message: Logged In: YES user_id=44345 Please don't needlessly boost priorities. This is hardly of highest priority (it doesn't crash the interpreter, for example). The issue of invoking cgitb functionality automatically was discussed at length when the module was first added to the system. It was decided that the possibility for breakage was too great. After all, other people have almost certainly had to address this problem in their own cgi scripts. Invoking cgitb may thwart those mechanisms, or worse, present clues about the internal workings of the system which would give bad guys help breaking into systems. In short, feel free to import cgitb into your own cgi scripts, but don't force others to use it if they choose not to. ---------------------------------------------------------------------- Comment By: Hunter Peress (hfastedge) Date: 2003-01-23 18:20 Message: Logged In: YES user_id=479934 HOW TO REPRODUCE: We are going to test a basic piece of logic. In normal interpreter (from cmdline), and in cgi mode. We will see just how different the error reporting is: FIRST the basic LOGIC: l=[1,2,3,4,5] for i in range(len(l)): print i,l[i],l ; del l[i] Next implement it in CGI: #!/usr/bin/python2.2 import sys,commands,os,re,string,cgi,cgitb cgitb.enable(1) print "Content-type: text/html\n\n" LOGIC GOES HERE NOW Observe how nice the error is: /home/hperes/public_html/cgi-bin/cgiShow.cgi 4 print "Content-type: text/html\n\n" 5 print "HI" 6 l=[1,2,3,4,5] 7 for i in range(len(l)): 8 print i,l[i],l ; del l[i] i = 3, l = [2, 4] IndexError: list index out of range __doc__ = 'Sequence index out of range.' __getitem__ = > __init__ = > __module__ = 'exceptions' __str__ = > args = ('list index out of range',) See how you can see the values of all the variables on the line?? Next implement it in cmdline: 0 1 [1, 2, 3, 4, 5] 1 3 [2, 3, 4, 5] 2 5 [2, 4, 5] 3 Traceback (most recent call last): File "s", line 5, in ? print i,l[i],l ; del l[i] IndexError: list index out of range See how much more useless that is? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654558&group_id=5470 From noreply@sourceforge.net Fri Jan 24 17:42:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 24 Jan 2003 09:42:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-654558 ] make error reporting better like cgi Message-ID: Bugs item #654558, was opened at 2002-12-16 05:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654558&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: Invalid >Priority: 5 Submitted By: Hunter Peress (hfastedge) Assigned to: Nobody/Anonymous (nobody) Summary: make error reporting better like cgi Initial Comment: do something bad in something that uses cgitb, it will show you actual values of the variables at that point in the error message....and a host of useful info. I think this should be done normally as well. ---------------------------------------------------------------------- Comment By: Hunter Peress (hfastedge) Date: 2003-01-24 11:36 Message: Logged In: YES user_id=479934 montanaro: FIRST, I put the priority on 9 because I finally added a huge chunk of code to show what I was talking about. Given this , and since this bug was in the system for so long, I flagged it to 9, solely so that it would reget some needed attention, and then expecting one of the powers that be to bring it back down to normal. WELL: not only did you not do this. You closed the bug, AND you completely did not comprehend what its point is. Quickly: i show the the STRENGTHS of the error reporting mechanism in cgitb, and this bug suggests that some (if not all) features should be implemented in the normal interpreter. Most useful is the fact that you get to see values of all variables on the line causing error. As you can see, i reflagged this to 9 solely to get your attention. please bring it back down to 5 when u read this. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-24 11:17 Message: Logged In: YES user_id=44345 Please don't needlessly boost priorities. This is hardly of highest priority (it doesn't crash the interpreter, for example). The issue of invoking cgitb functionality automatically was discussed at length when the module was first added to the system. It was decided that the possibility for breakage was too great. After all, other people have almost certainly had to address this problem in their own cgi scripts. Invoking cgitb may thwart those mechanisms, or worse, present clues about the internal workings of the system which would give bad guys help breaking into systems. In short, feel free to import cgitb into your own cgi scripts, but don't force others to use it if they choose not to. ---------------------------------------------------------------------- Comment By: Hunter Peress (hfastedge) Date: 2003-01-23 17:20 Message: Logged In: YES user_id=479934 HOW TO REPRODUCE: We are going to test a basic piece of logic. In normal interpreter (from cmdline), and in cgi mode. We will see just how different the error reporting is: FIRST the basic LOGIC: l=[1,2,3,4,5] for i in range(len(l)): print i,l[i],l ; del l[i] Next implement it in CGI: #!/usr/bin/python2.2 import sys,commands,os,re,string,cgi,cgitb cgitb.enable(1) print "Content-type: text/html\n\n" LOGIC GOES HERE NOW Observe how nice the error is: /home/hperes/public_html/cgi-bin/cgiShow.cgi 4 print "Content-type: text/html\n\n" 5 print "HI" 6 l=[1,2,3,4,5] 7 for i in range(len(l)): 8 print i,l[i],l ; del l[i] i = 3, l = [2, 4] IndexError: list index out of range __doc__ = 'Sequence index out of range.' __getitem__ = > __init__ = > __module__ = 'exceptions' __str__ = > args = ('list index out of range',) See how you can see the values of all the variables on the line?? Next implement it in cmdline: 0 1 [1, 2, 3, 4, 5] 1 3 [2, 3, 4, 5] 2 5 [2, 4, 5] 3 Traceback (most recent call last): File "s", line 5, in ? print i,l[i],l ; del l[i] IndexError: list index out of range See how much more useless that is? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654558&group_id=5470 From noreply@sourceforge.net Fri Jan 24 17:47:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 24 Jan 2003 09:47:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-654558 ] make error reporting better like cgi Message-ID: Bugs item #654558, was opened at 2002-12-16 11:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654558&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: Invalid Priority: 5 Submitted By: Hunter Peress (hfastedge) Assigned to: Nobody/Anonymous (nobody) Summary: make error reporting better like cgi Initial Comment: do something bad in something that uses cgitb, it will show you actual values of the variables at that point in the error message....and a host of useful info. I think this should be done normally as well. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-01-24 17:46 Message: Logged In: YES user_id=6656 OK, but we don't use priorities like that in this project. All it acheives is winding people up. ---------------------------------------------------------------------- Comment By: Hunter Peress (hfastedge) Date: 2003-01-24 17:36 Message: Logged In: YES user_id=479934 montanaro: FIRST, I put the priority on 9 because I finally added a huge chunk of code to show what I was talking about. Given this , and since this bug was in the system for so long, I flagged it to 9, solely so that it would reget some needed attention, and then expecting one of the powers that be to bring it back down to normal. WELL: not only did you not do this. You closed the bug, AND you completely did not comprehend what its point is. Quickly: i show the the STRENGTHS of the error reporting mechanism in cgitb, and this bug suggests that some (if not all) features should be implemented in the normal interpreter. Most useful is the fact that you get to see values of all variables on the line causing error. As you can see, i reflagged this to 9 solely to get your attention. please bring it back down to 5 when u read this. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-01-24 17:17 Message: Logged In: YES user_id=44345 Please don't needlessly boost priorities. This is hardly of highest priority (it doesn't crash the interpreter, for example). The issue of invoking cgitb functionality automatically was discussed at length when the module was first added to the system. It was decided that the possibility for breakage was too great. After all, other people have almost certainly had to address this problem in their own cgi scripts. Invoking cgitb may thwart those mechanisms, or worse, present clues about the internal workings of the system which would give bad guys help breaking into systems. In short, feel free to import cgitb into your own cgi scripts, but don't force others to use it if they choose not to. ---------------------------------------------------------------------- Comment By: Hunter Peress (hfastedge) Date: 2003-01-23 23:20 Message: Logged In: YES user_id=479934 HOW TO REPRODUCE: We are going to test a basic piece of logic. In normal interpreter (from cmdline), and in cgi mode. We will see just how different the error reporting is: FIRST the basic LOGIC: l=[1,2,3,4,5] for i in range(len(l)): print i,l[i],l ; del l[i] Next implement it in CGI: #!/usr/bin/python2.2 import sys,commands,os,re,string,cgi,cgitb cgitb.enable(1) print "Content-type: text/html\n\n" LOGIC GOES HERE NOW Observe how nice the error is: /home/hperes/public_html/cgi-bin/cgiShow.cgi 4 print "Content-type: text/html\n\n" 5 print "HI" 6 l=[1,2,3,4,5] 7 for i in range(len(l)): 8 print i,l[i],l ; del l[i] i = 3, l = [2, 4] IndexError: list index out of range __doc__ = 'Sequence index out of range.' __getitem__ = > __init__ = > __module__ = 'exceptions' __str__ = > args = ('list index out of range',) See how you can see the values of all the variables on the line?? Next implement it in cmdline: 0 1 [1, 2, 3, 4, 5] 1 3 [2, 3, 4, 5] 2 5 [2, 4, 5] 3 Traceback (most recent call last): File "s", line 5, in ? print i,l[i],l ; del l[i] IndexError: list index out of range See how much more useless that is? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=654558&group_id=5470 From noreply@sourceforge.net Fri Jan 24 17:48:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 24 Jan 2003 09:48:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-664581 ] test_bsddb3 fails when run directly Message-ID: Bugs item #664581, was opened at 2003-01-08 14:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=664581&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Barry A. Warsaw (bwarsaw) Summary: test_bsddb3 fails when run directly Initial Comment: This is Python CVS of 2003-01-08: projects/Python> pythondev Dev-Python/Lib/test/test_bsddb3.py -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Sleepycat Software: Berkeley DB 4.0.14: (November 18, 2001) bsddb.db.version(): (4, 0, 14) bsddb.db.__version__: 4.1.1 bsddb.db.cvsid: $Id: _bsddb.c,v 1.3 2002/12/30 20:53:52 bwarsaw Exp $ python version: 2.3a1 (#1, Jan 6 2003, 02:03:16) [GCC 2.95.3 20010315 (SuSE)] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Traceback (most recent call last): File "Dev-Python/Lib/test/test_bsddb3.py", line 67, in ? unittest.main(defaultTest='suite') File "/home/lemburg/projects/Python/Installation/lib/python2.3/unittest.py", line 710, in __init__ self.parseArgs(argv) File "/home/lemburg/projects/Python/Installation/lib/python2.3/unittest.py", line 737, in parseArgs self.createTests() File "/home/lemburg/projects/Python/Installation/lib/python2.3/unittest.py", line 743, in createTests self.module) File "/home/lemburg/projects/Python/Installation/lib/python2.3/unittest.py", line 509, in loadTestsFromNames suites.append(self.loadTestsFromName(name, module)) File "/home/lemburg/projects/Python/Installation/lib/python2.3/unittest.py", line 494, in loadTestsFromName test = obj() File "Dev-Python/Lib/test/test_bsddb3.py", line 44, in suite module = __import__("bsddb.test."+name, globals(), locals(), name) ImportError: No module named test.test_associate Looking at the installed bsddb package, there is no subpackage 'test' in there. It is available in the source tree, though. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-24 12:48 Message: Logged In: YES user_id=12800 I believe this has been fixed in current 2.3cvs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=664581&group_id=5470 From noreply@sourceforge.net Fri Jan 24 20:36:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 24 Jan 2003 12:36:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-674264 ] re.compile fails for verbose re with more than one group Message-ID: Bugs item #674264, was opened at 2003-01-24 20:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674264&group_id=5470 Category: Regular Expressions Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Garth Corral (gcorral) Assigned to: Fredrik Lundh (effbot) Summary: re.compile fails for verbose re with more than one group Initial Comment: The third of the following three regular expressions fails to compile with "unbalanced parenthesis" error: [foo.py] import re _good_re = re.compile(r'\s*(elif|else|except|finally).*:\s*(#.*)$') _also_good_re = re.compile(r''' \s* ( elif | else | except | finally ) .*: ''', re.VERBOSE) _bad_re = re.compile(r''' \s* ( elif | else | except | finally ) .*:\s*(#.*)?$ ''', re.VERBOSE) >>> import foo Traceback (most recent call last): File "", line 1, in ? File "zzz.py", line 15, in ? _bad_re = re.compile(r''' File "/usr/local/lib/python2.2/sre.py", line 178, in compile return _compile(pattern, flags) File "/usr/local/lib/python2.2/sre.py", line 228, in _compile raise error, v # invalid expression sre_constants.error: unbalanced parenthesis ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674264&group_id=5470 From noreply@sourceforge.net Fri Jan 24 20:46:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 24 Jan 2003 12:46:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-669838 ] Seg fault in gcmodule.c Message-ID: Bugs item #669838, was opened at 2003-01-17 12:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669838&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gregory Popovitch (greg7mdp) Assigned to: Nobody/Anonymous (nobody) Summary: Seg fault in gcmodule.c Initial Comment: Using Python 2.2.2 on Linux Redhat 7.2: Python 2.2.2 (#1, Oct 21 2002, 22:19:12) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 I have a crash which happens somewhat randomly (for example it goes away if I add a print statement somewhere). Here is some gdb info. lnx:0:usr/greg/ib> gdb python2.2 GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run rules.py > xx Starting program: /usr/local/bin/python2.2 rules.py > xx [New Thread 1024 (LWP 30182)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 30182)] 0x080996f8 in visit_decref (op=0x1000000, data=0x0) at Modules/gcmodule.c:185 185 if (op && PyObject_IS_GC(op)) { (gdb) print op $1 = (PyObject *) 0x1000000 (gdb) print data $2 = (void *) 0x0 (gdb) where 20 #0 0x080996f8 in visit_decref (op=0x1000000, data=0x0) at Modules/gcmodule.c:185 #1 0x080c9abb in dict_traverse (op=0x827bc34, visit=0x80996ec , arg=0x0) at Objects/dictobject.c:1589 #2 0x0809897e in collect (young=0x80ee5a0, old=0x80ee5ac) at Modules/gcmodule.c:201 #3 0x08099062 in collect_generations () at Modules/gcmodule.c:518 #4 0x08099576 in _PyObject_GC_New (tp=0x80f8ae0) at Modules/gcmodule.c:879 #5 0x080c7b75 in PyDict_New () at Objects/dictobject.c:161 #6 0x080869d5 in symtable_init () at Python/compile.c:4671 #7 0x08086910 in symtable_build (c=0xbfffea90, n=0x8240e68) at Python/compile.c:4261 #8 0x08084109 in jcompile (n=0x8240e68, filename=0x81f83ec "", base=0x0, flags=0xbfffebe4) at Python/compile.c:4111 #9 0x0808665e in PyNode_CompileFlags (n=0x8240e68, filename=0x81f83ec "", flags=0xbfffebe4) at Python/compile.c:4042 #10 0x080945c7 in Py_CompileStringFlags ( str=0x811f8bc "agrepy(\epreuve photographique\, 22, t, len(t), 0, re[0]) and re[1].search(t)", filename=0x81f83ec "", start=258, flags=0xbfffebe4) at Python/pythonrun.c:1133 #11 0x080cc4cc in builtin_compile (self=0x0, args=0x8241a04) at Python/bltinmodule.c:398 #12 0x080ca7cc in PyCFunction_Call (func=0x8105fb0, arg=0x8241a04, kw=0x0) at Objects/methodobject.c:100 #13 0x08077918 in eval_frame (f=0x81a6fbc) at Python/ceval.c:2014 #14 0x0807892b in PyEval_EvalCodeEx (co=0x81f8750, globals=0x8111ecc, locals=0x0, args=0x82ffe14, argcount=2, kws=0x82ffe1c, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2595 #15 0x0807aa43 in fast_function (func=0x815f754, pp_stack=0xbfffee14, n=2, na=2, nk=0) at Python/ceval.c:3173 #16 0x080779b5 in eval_frame (f=0x82ffc8c) at Python/ceval.c:2034 #17 0x0807892b in PyEval_EvalCodeEx (co=0x81f9768, globals=0x8111ecc, locals=0x0, args=0x81cc34c, argcount=3, kws=0x81cc358, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2595 #18 0x0807aa43 in fast_function (func=0x815f78c, pp_stack=0xbfffef74, n=3, na=3, nk=0) at Python/ceval.c:3173 #19 0x080779b5 in eval_frame (f=0x81cc1f4) at Python/ceval.c:2034 (More stack frames follow...) ---------------------------------------------------------------------- >Comment By: Gregory Popovitch (greg7mdp) Date: 2003-01-24 15:46 Message: Logged In: YES user_id=222034 It is hard to reproduce... I realized that the bug may be in a module I use called AGREPY downloadable from http://www.bio.cam.ac.uk/~mw263/pyagrep.html. I tried to reproduce my Python 2.2.2 install with "./configure --with- pydebug" as suggested, but then I get the following error: /usr/greg/soft/linux/python/Python-2.2.2/python rules.py Adding parser accelerators ... Done. Traceback (most recent call last): File "rules.py", line 39, in ? import string, os, agrepy ImportError: /usr/greg/soft/linux/python/Python- 2.2.2/build/lib.linux-i686-2.2/agrepy.so: undefined symbol: Py_InitModule4 [6589 refs] I was mistaken to suspect my use of the "exec" statement, which I replaced with "eval" and the problem still happened. It is not easy to come up with a reasonably small piece of code reproducing the problem! gregory ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-17 13:43 Message: Logged In: YES user_id=33168 Can you post any code which causes the crash, even if it only crashes sometimes? Can you build python with ./configure --with-pydebug and run your program? This may find the problem closer to the cause. ---------------------------------------------------------------------- Comment By: Gregory Popovitch (greg7mdp) Date: 2003-01-17 12:05 Message: Logged In: YES user_id=222034 I forgot to mention that this program is using the "exec()" builtin heavily, and I believe that the crash is related to this. gregory ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669838&group_id=5470 From noreply@sourceforge.net Fri Jan 24 20:55:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 24 Jan 2003 12:55:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-671731 ] time module: time tuple not returned by certain functions Message-ID: Bugs item #671731, was opened at 2003-01-21 03:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671731&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None >Priority: 3 Submitted By: Martin Miller (mrmiller) Assigned to: Nobody/Anonymous (nobody) Summary: time module: time tuple not returned by certain functions Initial Comment: On win32 the gmtime() and localtime() functions in the time module return values of type 'time.time_struct'. I believe the proper return value should be a tuple. This is implied by the documentation (see where it discusses the *time tuple* returned by the various module functions and says it 'is a tuple of 9 integers'. The time_struct value returned does behave like a tuple instance in most respects, except that its type is not type 'tuple'. I think this is something that was changed in the not too distant past, as I noticed the issue after downloading code recently written by others which depends on the type of the return value from these functions being a tuple. If nothing else, if this was changed, it is not backward compatible and the documention ought to be updated. Example: > Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 > Type "help", "copyright", "credits" or "license" for more information. > >>> import time > >>> print time.localtime() > (2003, 1, 21, 3, 3, 2, 1, 21, 0) > >>> print type(time.localtime()) is type(()) > 0 > >>> print type(time.localtime()) > > >>> ---------------------------------------------------------------------- >Comment By: Martin Miller (mrmiller) Date: 2003-01-24 12:55 Message: Logged In: YES user_id=257085 The strcut_time return value change broke a module I had downloaded called NormalDate by Jeff Bauer . Fixing it myself turned out to be relatively easy, once I determined what was the problem (which was a little time-consuming, considering the fact that the docs hadn't been updated). Later I located an updated version of module (v1.3) that had been fixed by the author. The technique he used was to create a private module attribute set to the type of value returned from localtime(), so the updated module would still work with versions of Python < 2.2. The struct_time pseudo-sequence now returned by the functions now sounds like a useful improvement, provided that this fact is documented along with a description of what the type is, which would allow others to also take advantage of its attribute fetching behavior if they wished. This could be done by copying the description in into the developer documentation for the the time module (and backporting that into the 2.2 documentation. I'm lowering the priorty to 3 and marking it as a documentation bug. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-22 02:08 Message: Logged In: YES user_id=6656 Oh yeah. That should *definitely* be backported to the 2.2 docs. Could be more thorough, though. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-21 16:55 Message: Logged In: YES user_id=357491 There is a mention of it in the developer docs at http://www.python.org/dev/doc/devel/lib/module-time.html . The note for struct_time says what functions return a struct_time object. A patch for the docs that changed everything else to say it returns a struct_time object instead of a time tuple wouldn't hurt, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-21 03:40 Message: Logged In: YES user_id=6656 This was very deliberate. It *is* a bit shocking that the docs didn't get updated, though. There's a start of a description in: http://www.python.org/doc/current/whatsnew/node10.html Do you have code that actually broke because of this change? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671731&group_id=5470 From noreply@sourceforge.net Fri Jan 24 21:01:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 24 Jan 2003 13:01:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-669838 ] Seg fault in gcmodule.c Message-ID: Bugs item #669838, was opened at 2003-01-17 12:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669838&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gregory Popovitch (greg7mdp) Assigned to: Nobody/Anonymous (nobody) Summary: Seg fault in gcmodule.c Initial Comment: Using Python 2.2.2 on Linux Redhat 7.2: Python 2.2.2 (#1, Oct 21 2002, 22:19:12) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 I have a crash which happens somewhat randomly (for example it goes away if I add a print statement somewhere). Here is some gdb info. lnx:0:usr/greg/ib> gdb python2.2 GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run rules.py > xx Starting program: /usr/local/bin/python2.2 rules.py > xx [New Thread 1024 (LWP 30182)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 30182)] 0x080996f8 in visit_decref (op=0x1000000, data=0x0) at Modules/gcmodule.c:185 185 if (op && PyObject_IS_GC(op)) { (gdb) print op $1 = (PyObject *) 0x1000000 (gdb) print data $2 = (void *) 0x0 (gdb) where 20 #0 0x080996f8 in visit_decref (op=0x1000000, data=0x0) at Modules/gcmodule.c:185 #1 0x080c9abb in dict_traverse (op=0x827bc34, visit=0x80996ec , arg=0x0) at Objects/dictobject.c:1589 #2 0x0809897e in collect (young=0x80ee5a0, old=0x80ee5ac) at Modules/gcmodule.c:201 #3 0x08099062 in collect_generations () at Modules/gcmodule.c:518 #4 0x08099576 in _PyObject_GC_New (tp=0x80f8ae0) at Modules/gcmodule.c:879 #5 0x080c7b75 in PyDict_New () at Objects/dictobject.c:161 #6 0x080869d5 in symtable_init () at Python/compile.c:4671 #7 0x08086910 in symtable_build (c=0xbfffea90, n=0x8240e68) at Python/compile.c:4261 #8 0x08084109 in jcompile (n=0x8240e68, filename=0x81f83ec "", base=0x0, flags=0xbfffebe4) at Python/compile.c:4111 #9 0x0808665e in PyNode_CompileFlags (n=0x8240e68, filename=0x81f83ec "", flags=0xbfffebe4) at Python/compile.c:4042 #10 0x080945c7 in Py_CompileStringFlags ( str=0x811f8bc "agrepy(\epreuve photographique\, 22, t, len(t), 0, re[0]) and re[1].search(t)", filename=0x81f83ec "", start=258, flags=0xbfffebe4) at Python/pythonrun.c:1133 #11 0x080cc4cc in builtin_compile (self=0x0, args=0x8241a04) at Python/bltinmodule.c:398 #12 0x080ca7cc in PyCFunction_Call (func=0x8105fb0, arg=0x8241a04, kw=0x0) at Objects/methodobject.c:100 #13 0x08077918 in eval_frame (f=0x81a6fbc) at Python/ceval.c:2014 #14 0x0807892b in PyEval_EvalCodeEx (co=0x81f8750, globals=0x8111ecc, locals=0x0, args=0x82ffe14, argcount=2, kws=0x82ffe1c, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2595 #15 0x0807aa43 in fast_function (func=0x815f754, pp_stack=0xbfffee14, n=2, na=2, nk=0) at Python/ceval.c:3173 #16 0x080779b5 in eval_frame (f=0x82ffc8c) at Python/ceval.c:2034 #17 0x0807892b in PyEval_EvalCodeEx (co=0x81f9768, globals=0x8111ecc, locals=0x0, args=0x81cc34c, argcount=3, kws=0x81cc358, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2595 #18 0x0807aa43 in fast_function (func=0x815f78c, pp_stack=0xbfffef74, n=3, na=3, nk=0) at Python/ceval.c:3173 #19 0x080779b5 in eval_frame (f=0x81cc1f4) at Python/ceval.c:2034 (More stack frames follow...) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-24 16:01 Message: Logged In: YES user_id=33168 After running configure, you must remove all the modules and rebuild them too. This doesn't happen by default. You can also do rm build/*/*.o build/*/*.so to remove the modules. make clean should also work. Have you tried running valgrind, purify, electric fence, or some other memory checker on the code. Perhaps there is a memory problem in the pyagrep module? ---------------------------------------------------------------------- Comment By: Gregory Popovitch (greg7mdp) Date: 2003-01-24 15:46 Message: Logged In: YES user_id=222034 It is hard to reproduce... I realized that the bug may be in a module I use called AGREPY downloadable from http://www.bio.cam.ac.uk/~mw263/pyagrep.html. I tried to reproduce my Python 2.2.2 install with "./configure --with- pydebug" as suggested, but then I get the following error: /usr/greg/soft/linux/python/Python-2.2.2/python rules.py Adding parser accelerators ... Done. Traceback (most recent call last): File "rules.py", line 39, in ? import string, os, agrepy ImportError: /usr/greg/soft/linux/python/Python- 2.2.2/build/lib.linux-i686-2.2/agrepy.so: undefined symbol: Py_InitModule4 [6589 refs] I was mistaken to suspect my use of the "exec" statement, which I replaced with "eval" and the problem still happened. It is not easy to come up with a reasonably small piece of code reproducing the problem! gregory ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-17 13:43 Message: Logged In: YES user_id=33168 Can you post any code which causes the crash, even if it only crashes sometimes? Can you build python with ./configure --with-pydebug and run your program? This may find the problem closer to the cause. ---------------------------------------------------------------------- Comment By: Gregory Popovitch (greg7mdp) Date: 2003-01-17 12:05 Message: Logged In: YES user_id=222034 I forgot to mention that this program is using the "exec()" builtin heavily, and I believe that the crash is related to this. gregory ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669838&group_id=5470 From noreply@sourceforge.net Fri Jan 24 22:20:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 24 Jan 2003 14:20:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-660144 ] typeobject provides incorrect __mul__ Message-ID: Bugs item #660144, was opened at 2002-12-30 20:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660144&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Neil Schemenauer (nascheme) Summary: typeobject provides incorrect __mul__ Initial Comment: type __mul__ is wierd: >> 'a'.__mul__(3.4) 'aaa' >>> [1].__mul__(3.4) [1, 1, 1] Floating point numbers with fractions should not be accepted. I think the problem is that __mul__ should not be trying to implement sq_repeat behavior (although I haven't dug deeply into this problem yet). Also, I think the code is vulnerable to integer overflow. Should also check __imul__ __add__ __iadd__. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2003-01-24 22:20 Message: Logged In: YES user_id=35752 I added the check for the other integer codes. All the tests pass so I checked it in. Hope that's okay. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-21 19:55 Message: Logged In: YES user_id=6380 Looks like a good patch. And yes, the other types should be doing this as well. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-01-19 19:35 Message: Logged In: YES user_id=35752 The small patch is attached. I only added the checking for 'i' and 'l'. I wonder if it should be done for the other integer codes as well (e.g. 'b', 'h'). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-17 00:19 Message: Logged In: YES user_id=6380 Yes, this should go into 2.3a2. Your attachment upload failed somehow. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-01-16 23:10 Message: Logged In: YES user_id=35752 Would this be a change for the 2.3 release? I tried adding a PyFloat_Check test to 'i' and 'l' in getargs.c. It looks like all the unit tests pass. I agree that checking for float catches the important cases. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-16 21:57 Message: Logged In: YES user_id=6380 This is an age-old problem that crops up whenever "i" and similar format codes are used. The problem is that on the one hand you want "i" to accept other int-ish types that have an __int__ method. But on the other hand you don't want it to accept float, which also has an __int__ method. Or other float-ish types. I think the "i" format code has to be fixe, but I'm not sure how -- maybe as a start it would be sufficient to test explicitly for float and its subclasses and reject those. That would still allow 3rd party float-ish classes that implement __int__, but that's not so important. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-01-16 21:33 Message: Logged In: YES user_id=35752 I think the problem is that wrap_intargfunc and wrap_intintargfunc use PyArg_ParseTuple(args, "i", &i). This bug also is present in methods like __getitem__: >>> "Python"[1.2] Traceback (most recent call last): File "", line 1, in ? TypeError: sequence index must be integer >>> "Python".__getitem__(1.2) 'y' I think the right fix is to use explictly only allow only ints and longs to wrap_intargfunc and friends. If Guido agrees I will cook up a patch. It seems like we should have a code for PyParse_Tuple that only allows ints and longs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660144&group_id=5470 From noreply@sourceforge.net Fri Jan 24 22:23:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 24 Jan 2003 14:23:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-671731 ] time module: time tuple not returned by certain functions Message-ID: Bugs item #671731, was opened at 2003-01-21 03:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671731&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 3 Submitted By: Martin Miller (mrmiller) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: time module: time tuple not returned by certain functions Initial Comment: On win32 the gmtime() and localtime() functions in the time module return values of type 'time.time_struct'. I believe the proper return value should be a tuple. This is implied by the documentation (see where it discusses the *time tuple* returned by the various module functions and says it 'is a tuple of 9 integers'. The time_struct value returned does behave like a tuple instance in most respects, except that its type is not type 'tuple'. I think this is something that was changed in the not too distant past, as I noticed the issue after downloading code recently written by others which depends on the type of the return value from these functions being a tuple. If nothing else, if this was changed, it is not backward compatible and the documention ought to be updated. Example: > Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 > Type "help", "copyright", "credits" or "license" for more information. > >>> import time > >>> print time.localtime() > (2003, 1, 21, 3, 3, 2, 1, 21, 0) > >>> print type(time.localtime()) is type(()) > 0 > >>> print type(time.localtime()) > > >>> ---------------------------------------------------------------------- >Comment By: Martin Miller (mrmiller) Date: 2003-01-24 14:23 Message: Logged In: YES user_id=257085 Looks like a duplicate of closed bug 604128 "time.struct_time undocumented" which was assigned and fixed by fdrake on 2002-11-13. However I've looked at the Doc/lib/libtime.tex file that included with 2.2.2 and see nothing written about the type. I'll try assigning this bug to him since I can't find the fix. ---------------------------------------------------------------------- Comment By: Martin Miller (mrmiller) Date: 2003-01-24 12:55 Message: Logged In: YES user_id=257085 The strcut_time return value change broke a module I had downloaded called NormalDate by Jeff Bauer . Fixing it myself turned out to be relatively easy, once I determined what was the problem (which was a little time-consuming, considering the fact that the docs hadn't been updated). Later I located an updated version of module (v1.3) that had been fixed by the author. The technique he used was to create a private module attribute set to the type of value returned from localtime(), so the updated module would still work with versions of Python < 2.2. The struct_time pseudo-sequence now returned by the functions now sounds like a useful improvement, provided that this fact is documented along with a description of what the type is, which would allow others to also take advantage of its attribute fetching behavior if they wished. This could be done by copying the description in into the developer documentation for the the time module (and backporting that into the 2.2 documentation. I'm lowering the priorty to 3 and marking it as a documentation bug. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-22 02:08 Message: Logged In: YES user_id=6656 Oh yeah. That should *definitely* be backported to the 2.2 docs. Could be more thorough, though. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-21 16:55 Message: Logged In: YES user_id=357491 There is a mention of it in the developer docs at http://www.python.org/dev/doc/devel/lib/module-time.html . The note for struct_time says what functions return a struct_time object. A patch for the docs that changed everything else to say it returns a struct_time object instead of a time tuple wouldn't hurt, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-21 03:40 Message: Logged In: YES user_id=6656 This was very deliberate. It *is* a bit shocking that the docs didn't get updated, though. There's a start of a description in: http://www.python.org/doc/current/whatsnew/node10.html Do you have code that actually broke because of this change? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671731&group_id=5470 From noreply@sourceforge.net Sat Jan 25 01:13:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 24 Jan 2003 17:13:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-674404 ] repr of type and class objects Message-ID: Bugs item #674404, was opened at 2003-01-25 02:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674404&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: repr of type and class objects Initial Comment: I've recently faced a shortcoming of my (our :-) favourite prog. lang. related to "repr-ing" type and class objects. Let's define a helper function to show the problem: def F(o): return eval(repr(o))==o Then try this: >>> F(1) 1 >>> F('x') 1 >>> F(int) Traceback (most recent call last): File "", line 1, in ? File "", line 1, in F File "", line 1 ^ SyntaxError: invalid syntax >>> str(int) "" >>> repr(int) "" In the case of str(int) returning "" is ok, since str() should return human-readable representation. But repr() should return a python expression can be evaluated into an object with the same "value" in the same context, so returning "" is a mistake. repr() should return just "int" to satisfy the philosophy behind repr. F(int) should return 1, since: >>> int==int 1 Generally, repr() should return the __name__ attribute if called with a class object (not an instance of a class). I had to solve the problem by treating type objects specially, but it isn't an elegant solution. I know, that fixing this problem may break some (badly written) code, but accoring to my view, it's better to check the type of an object by checking the return value of type() instead of parsing the output of repr(). In my opinion, this could be fixed easily in version 2.3. Best regards, Complex ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674404&group_id=5470 From noreply@sourceforge.net Sat Jan 25 03:30:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 24 Jan 2003 19:30:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-672098 ] Three __contains__ implementations Message-ID: Bugs item #672098, was opened at 2003-01-21 17:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672098&group_id=5470 Category: Python Library Group: Not a Bug Status: Open >Resolution: Accepted Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: Three __contains__ implementations Initial Comment: Several classes in the stdlib implement dict-like interfaces, but do not provide __contains__ definitions. This is mentioned in PEP290 as a "contra-indication" for updating code to use "k in d". The attached patch adds __contains__ implementations for these stdlib classes. As far as I can tell, this brings all the dict-like classes in the stdlib "up to date", so perhaps PEP290 should be updated as well. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-24 22:30 Message: Logged In: YES user_id=80475 This patch is fine as it stands. Brett's point is well taken, but using 'in' should never result in a reduced performance. IMO, the additional layer of indirection isn't worth it. PEP 290 needs to stay "as is" because it still applies to home-grown and third-party modules. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-21 23:51 Message: Logged In: YES user_id=357491 The code itself looks fine, but I would suggest that instead of copying code from the methods that provide the same that you change them so that the old method calls ``__contains__`` and that ``__contains__`` now takes over as the primary method. So instead of:: def has_key(self, name): return self._attrs.has_key(name) def __contains__(self, name): return self._attrs.has_key(name) do:: def has_key(self, name): return self.__contains__(name) def __contains__(self, name): return self._attrs.has_key(name) Doing it this way minimizes code duplication along with the possibility of someone changing one method and not the other. And as for usefulness of these additions, I can't comment since I use none of the modules patched, but I see no harm in adding the functionality. So +0 from me on applying the patch once the above changes are done. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2003-01-21 21:16 Message: Logged In: YES user_id=366566 Either mozilla or sf is screwing with me. *grumble* There's no way I selected bisect.py for attachment. Proper file now attached. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-21 19:44 Message: Logged In: YES user_id=357491 The attached file has no ``__contains__`` definitions for anything. Did you attach the correct file? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672098&group_id=5470 From noreply@sourceforge.net Sat Jan 25 03:47:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 24 Jan 2003 19:47:32 -0800 Subject: [Python-bugs-list] [ python-Bugs-665835 ] filter() treatment of str and tuple inconsistent Message-ID: Bugs item #665835, was opened at 2003-01-10 11:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665835&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Guido van Rossum (gvanrossum) Summary: filter() treatment of str and tuple inconsistent Initial Comment: class tuple2(tuple): · def __getitem__(self, index): · · return 2*tuple.__getitem__(self, index) class str2(str): · def __getitem__(self, index): · · return chr(ord(str.__getitem__(self, index))+1) print filter(lambda x: x>1, tuple2((1, 2))) print filter(lambda x: x>"a", str2("ab")) this prints: (2,) bc i.e. the overwritten __getitem__ is ignored in the first case, but honored in the second. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-24 22:47 Message: Logged In: YES user_id=80475 The problem isn't with filter() which correctly calls iter() in both cases. Tuple object have their own iterator which loops over elements directly and has no intervening calls to __getitem__(). String objects do not define a custom iterator, so iter() wraps itself around consecutive calls to __getitem__(). The resolution is to provide string objects with their own iterator. As a side benefit, iteration will run just a tiny bit faster. The same applies to unicode objects. Guido, do you care about this and want me to fix it or would you like to close it as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665835&group_id=5470 From noreply@sourceforge.net Sat Jan 25 04:00:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 24 Jan 2003 20:00:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-665761 ] reduce() masks exception Message-ID: Bugs item #665761, was opened at 2003-01-10 09:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665761&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 3 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: reduce() masks exception Initial Comment: In the following test script ----- class Test: def __iter__(self): raise IOError reduce(lambda x,y: x+y, Test()) ----- the real IOError exception is masked, i.e. the traceback is ----- Traceback (most recent call last): File "test.py", line 5, in ? reduce(lambda x,y: x+y, Test()) TypeError: reduce() arg 2 must support iteration ----- but IMHO should be ----- Traceback (most recent call last): File "test.py", line 3, in ? raise IOError IOError ----- This can be fixed by removing the PyErr_SetString(PyExc_TypeError, "reduce() arg 2 must support iteration") call in bltinmodule.c/buildtin_reduce(). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-24 23:00 Message: Logged In: YES user_id=80475 There's a lot of this going around. map() and zip() have the same issue. I recommend fixing them all. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-13 08:18 Message: Logged In: YES user_id=89016 The point is that Python/bltinmodule.c/builtin_reduce() masks the error returned from PyObject_GetIter(). Errors from PyIter_Next() are not masked. What about the following example: class LazyFile: def __init__(self, name, mode="r"): self.name = name self.mode = mode def __iter__(self): return open(self.name, self.mode) import operator f = LazyFile("does not exist") s = reduce(operator.add, f) LazyFile *does* support iteration, but the underlying problem of the non existing file is masked. Removing the call PyErr_SetString(PyExc_TypeError, "reduce() arg 2 must support iteration"); in builtin_reduce(), will produce the original exception "IOError: [Errno 2] No such file or directory: 'does not exist'" and when the second argument is not iteratable, the original exception is just as good: >>> reduce(lambda x,y: x+y, 42) Traceback (most recent call last): File "", line 1, in ? TypeError: iteration over non-sequence ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2003-01-11 12:08 Message: Logged In: YES user_id=366566 the __iter__ method is supposed to return an object that defines a 'next' method. The returned object is the one used for iteration, not the original. So I believe the error message is correct - Test does not support iteration. If you change the code to: >>> class test: ... def __iter__(self): ... return self ... def next(self): ... raise IOError ... >>> reduce(operator.add, test()) You get the expected result... Traceback (most recent call last):   File "", line 1, in ?   File "", line 5, in next IOError ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665761&group_id=5470 From noreply@sourceforge.net Sat Jan 25 13:36:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 25 Jan 2003 05:36:15 -0800 Subject: [Python-bugs-list] [ python-Bugs-665835 ] filter() treatment of str and tuple inconsistent Message-ID: Bugs item #665835, was opened at 2003-01-10 11:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665835&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Raymond Hettinger (rhettinger) Summary: filter() treatment of str and tuple inconsistent Initial Comment: class tuple2(tuple): · def __getitem__(self, index): · · return 2*tuple.__getitem__(self, index) class str2(str): · def __getitem__(self, index): · · return chr(ord(str.__getitem__(self, index))+1) print filter(lambda x: x>1, tuple2((1, 2))) print filter(lambda x: x>"a", str2("ab")) this prints: (2,) bc i.e. the overwritten __getitem__ is ignored in the first case, but honored in the second. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-25 08:36 Message: Logged In: YES user_id=6380 I don't know which Python sources Raymond has been reading, but in the sources I've got in front of me, there are special cases for strings and tuples, and these *don't* use iter(). It so happens that the tuple special-case calls PyTuple_GetItem(), which doesn't call your __getitem__, while the string special-case calls the sq_item slot function, which (in your case) will be a wrapper that calls your __getitem__. A minimal fix would be to only call filtertuple for strict tuples -- although this changes the output type, but I don't think one should count on filter() of a tuple subclass returning a tuple (and it can't be made to return an instance of the subclass either -- we don't know the constructor signature). Similar fixes probably need to be made to map() and maybe reduce(). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-24 22:47 Message: Logged In: YES user_id=80475 The problem isn't with filter() which correctly calls iter() in both cases. Tuple object have their own iterator which loops over elements directly and has no intervening calls to __getitem__(). String objects do not define a custom iterator, so iter() wraps itself around consecutive calls to __getitem__(). The resolution is to provide string objects with their own iterator. As a side benefit, iteration will run just a tiny bit faster. The same applies to unicode objects. Guido, do you care about this and want me to fix it or would you like to close it as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665835&group_id=5470 From noreply@sourceforge.net Sat Jan 25 13:45:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 25 Jan 2003 05:45:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-665835 ] filter() treatment of str and tuple inconsistent Message-ID: Bugs item #665835, was opened at 2003-01-10 11:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665835&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: filter() treatment of str and tuple inconsistent Initial Comment: class tuple2(tuple): · def __getitem__(self, index): · · return 2*tuple.__getitem__(self, index) class str2(str): · def __getitem__(self, index): · · return chr(ord(str.__getitem__(self, index))+1) print filter(lambda x: x>1, tuple2((1, 2))) print filter(lambda x: x>"a", str2("ab")) this prints: (2,) bc i.e. the overwritten __getitem__ is ignored in the first case, but honored in the second. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-25 08:45 Message: Logged In: YES user_id=31435 Just noting that filter() is unique in special-casing the type of the input. It's always been surprising that way, and, e.g., filtering a string produces a string, but filtering a Unicode string produces a list. map() and reduce() don't play games like that, and always use the iteration protocol to march over their inputs. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-25 08:36 Message: Logged In: YES user_id=6380 I don't know which Python sources Raymond has been reading, but in the sources I've got in front of me, there are special cases for strings and tuples, and these *don't* use iter(). It so happens that the tuple special-case calls PyTuple_GetItem(), which doesn't call your __getitem__, while the string special-case calls the sq_item slot function, which (in your case) will be a wrapper that calls your __getitem__. A minimal fix would be to only call filtertuple for strict tuples -- although this changes the output type, but I don't think one should count on filter() of a tuple subclass returning a tuple (and it can't be made to return an instance of the subclass either -- we don't know the constructor signature). Similar fixes probably need to be made to map() and maybe reduce(). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-24 22:47 Message: Logged In: YES user_id=80475 The problem isn't with filter() which correctly calls iter() in both cases. Tuple object have their own iterator which loops over elements directly and has no intervening calls to __getitem__(). String objects do not define a custom iterator, so iter() wraps itself around consecutive calls to __getitem__(). The resolution is to provide string objects with their own iterator. As a side benefit, iteration will run just a tiny bit faster. The same applies to unicode objects. Guido, do you care about this and want me to fix it or would you like to close it as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665835&group_id=5470 From noreply@sourceforge.net Sat Jan 25 13:51:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 25 Jan 2003 05:51:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-665835 ] filter() treatment of str and tuple inconsistent Message-ID: Bugs item #665835, was opened at 2003-01-10 11:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665835&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: filter() treatment of str and tuple inconsistent Initial Comment: class tuple2(tuple): · def __getitem__(self, index): · · return 2*tuple.__getitem__(self, index) class str2(str): · def __getitem__(self, index): · · return chr(ord(str.__getitem__(self, index))+1) print filter(lambda x: x>1, tuple2((1, 2))) print filter(lambda x: x>"a", str2("ab")) this prints: (2,) bc i.e. the overwritten __getitem__ is ignored in the first case, but honored in the second. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-25 08:51 Message: Logged In: YES user_id=6380 (But in addition th that, I don't mind having a custom string iterator -- as long as it calls __getitem__ properly. Hm, shouldn't the tuple iterator call __getitem__ properly too?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-25 08:45 Message: Logged In: YES user_id=31435 Just noting that filter() is unique in special-casing the type of the input. It's always been surprising that way, and, e.g., filtering a string produces a string, but filtering a Unicode string produces a list. map() and reduce() don't play games like that, and always use the iteration protocol to march over their inputs. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-25 08:36 Message: Logged In: YES user_id=6380 I don't know which Python sources Raymond has been reading, but in the sources I've got in front of me, there are special cases for strings and tuples, and these *don't* use iter(). It so happens that the tuple special-case calls PyTuple_GetItem(), which doesn't call your __getitem__, while the string special-case calls the sq_item slot function, which (in your case) will be a wrapper that calls your __getitem__. A minimal fix would be to only call filtertuple for strict tuples -- although this changes the output type, but I don't think one should count on filter() of a tuple subclass returning a tuple (and it can't be made to return an instance of the subclass either -- we don't know the constructor signature). Similar fixes probably need to be made to map() and maybe reduce(). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-24 22:47 Message: Logged In: YES user_id=80475 The problem isn't with filter() which correctly calls iter() in both cases. Tuple object have their own iterator which loops over elements directly and has no intervening calls to __getitem__(). String objects do not define a custom iterator, so iter() wraps itself around consecutive calls to __getitem__(). The resolution is to provide string objects with their own iterator. As a side benefit, iteration will run just a tiny bit faster. The same applies to unicode objects. Guido, do you care about this and want me to fix it or would you like to close it as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665835&group_id=5470 From noreply@sourceforge.net Sat Jan 25 14:15:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 25 Jan 2003 06:15:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-674574 ] Access to serial devices through Carbon.CF Message-ID: Bugs item #674574, was opened at 2003-01-25 15:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674574&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pascal Oberndoerfer (pascal_efi) Assigned to: Jack Jansen (jackjansen) Summary: Access to serial devices through Carbon.CF Initial Comment: There is currently no wrapper to access serial RS232 devices (e.g. Keyspan USB-serial adaptor) through Carbon.CF on MacOS X. This was my short and dirty hack to get a list of currently available (Keyspan) serial devices: #!/usr/bin/env python import os import string PRE = 'cu' #PRE = 'tty' device_list = filter(lambda s: string.count(s, PRE+'.USA'), os.listdir('/dev/')) print device_list But as Jack said: Anything that is in CF but not wrapped in the Carbon.CF module should be considered a bug. I know there's still quite a bit missing, but if people put bug reports up on sourceforge that will influence the order in which I add stuff to the CF module. It would help a lot if you mentioned the data structure and/or some of the routines you need. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - Dan Grassi supposed (slightly paraphrased) to do the folowing on MacOS X with IORegistryExplorer (inside /Applications/Utilities) > Search for IOSerialBSDClient with a key of > IOSerialBSDClientType > with a value of IORS232SerialStream. > Then get the value of the > IODialinDevice (/dev/tty.*) or IOCalloutDevice (/dev/cu.*) ... For a single serial device this can result in: { CFBundleIdentifier = com.apple.iokit.IOSerialFamily; IOCalloutDevice = /dev/cu.USA19QW21P1.1; IOClass = IOSerialBSDClient; IODialinDevice = /dev/tty.USA19QW21P1.1; IOMatchCategory = IODefaultMatchCategory; IOPersonalityName = IOSerialBSDClientSync; IOProbeScore = 1000; IOProviderClass = IOSerialStreamSync; IOResourceMatch = IOBSD; IOSerialBSDClientType = IORS232SerialStream; IOTTYBaseName = USA19QW21P1.; IOTTYDevice = USA19QW21P1.1; IOTTYSuffix = 1; ParentKey = "KEXTBundle?com.apple.iokit.IOSerialFamily"; } So maybe return a list of dictionaries? Pascal (MacOS X, MacPython 2.3a1 [Framework Install]) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674574&group_id=5470 From noreply@sourceforge.net Sat Jan 25 14:16:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 25 Jan 2003 06:16:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-674574 ] Access to serial devices through Carbon.CF Message-ID: Bugs item #674574, was opened at 2003-01-25 15:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674574&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Pascal Oberndoerfer (pascal_efi) Assigned to: Jack Jansen (jackjansen) Summary: Access to serial devices through Carbon.CF Initial Comment: There is currently no wrapper to access serial RS232 devices (e.g. Keyspan USB-serial adaptor) through Carbon.CF on MacOS X. This was my short and dirty hack to get a list of currently available (Keyspan) serial devices: #!/usr/bin/env python import os import string PRE = 'cu' #PRE = 'tty' device_list = filter(lambda s: string.count(s, PRE+'.USA'), os.listdir('/dev/')) print device_list But as Jack said: Anything that is in CF but not wrapped in the Carbon.CF module should be considered a bug. I know there's still quite a bit missing, but if people put bug reports up on sourceforge that will influence the order in which I add stuff to the CF module. It would help a lot if you mentioned the data structure and/or some of the routines you need. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - Dan Grassi supposed (slightly paraphrased) to do the folowing on MacOS X with IORegistryExplorer (inside /Applications/Utilities) > Search for IOSerialBSDClient with a key of > IOSerialBSDClientType > with a value of IORS232SerialStream. > Then get the value of the > IODialinDevice (/dev/tty.*) or IOCalloutDevice (/dev/cu.*) ... For a single serial device this can result in: { CFBundleIdentifier = com.apple.iokit.IOSerialFamily; IOCalloutDevice = /dev/cu.USA19QW21P1.1; IOClass = IOSerialBSDClient; IODialinDevice = /dev/tty.USA19QW21P1.1; IOMatchCategory = IODefaultMatchCategory; IOPersonalityName = IOSerialBSDClientSync; IOProbeScore = 1000; IOProviderClass = IOSerialStreamSync; IOResourceMatch = IOBSD; IOSerialBSDClientType = IORS232SerialStream; IOTTYBaseName = USA19QW21P1.; IOTTYDevice = USA19QW21P1.1; IOTTYSuffix = 1; ParentKey = "KEXTBundle?com.apple.iokit.IOSerialFamily"; } So maybe return a list of dictionaries? Pascal (MacOS X, MacPython 2.3a1 [Framework Install]) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674574&group_id=5470 From noreply@sourceforge.net Sat Jan 25 16:45:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 25 Jan 2003 08:45:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-665835 ] filter() treatment of str and tuple inconsistent Message-ID: Bugs item #665835, was opened at 2003-01-10 11:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665835&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Raymond Hettinger (rhettinger) Summary: filter() treatment of str and tuple inconsistent Initial Comment: class tuple2(tuple): · def __getitem__(self, index): · · return 2*tuple.__getitem__(self, index) class str2(str): · def __getitem__(self, index): · · return chr(ord(str.__getitem__(self, index))+1) print filter(lambda x: x>1, tuple2((1, 2))) print filter(lambda x: x>"a", str2("ab")) this prints: (2,) bc i.e. the overwritten __getitem__ is ignored in the first case, but honored in the second. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-25 11:45 Message: Logged In: YES user_id=80475 None of the existing iterators (incl dicts, lists, tuples, and files) use __getitem__. Most likely, user defined iterators also access the data structure directly (for flexiblity and speed). Also, anything that uses PyTuple_GET_ITEM bypasses __getitem__. If string/unicode iterators are added, they should also go directly to the underlying data; otherwise, there is no point to it. Also, the proposal to change filtertuple(), doesn't solve inconsistencies within filterstring() which uses __getitem__ when there is a function call, but bypasses it when the function parameter is Py_None. I think the right answer is to change filterstring() to use an iterator and to implement string/unicode iterators that access the data directly (not using __getitem__). FYI for Tim: MvL noticed and fixed the unicode vs string difference. His patch, SF #636005, has not been applied yet. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-25 08:51 Message: Logged In: YES user_id=6380 (But in addition th that, I don't mind having a custom string iterator -- as long as it calls __getitem__ properly. Hm, shouldn't the tuple iterator call __getitem__ properly too?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-25 08:45 Message: Logged In: YES user_id=31435 Just noting that filter() is unique in special-casing the type of the input. It's always been surprising that way, and, e.g., filtering a string produces a string, but filtering a Unicode string produces a list. map() and reduce() don't play games like that, and always use the iteration protocol to march over their inputs. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-25 08:36 Message: Logged In: YES user_id=6380 I don't know which Python sources Raymond has been reading, but in the sources I've got in front of me, there are special cases for strings and tuples, and these *don't* use iter(). It so happens that the tuple special-case calls PyTuple_GetItem(), which doesn't call your __getitem__, while the string special-case calls the sq_item slot function, which (in your case) will be a wrapper that calls your __getitem__. A minimal fix would be to only call filtertuple for strict tuples -- although this changes the output type, but I don't think one should count on filter() of a tuple subclass returning a tuple (and it can't be made to return an instance of the subclass either -- we don't know the constructor signature). Similar fixes probably need to be made to map() and maybe reduce(). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-24 22:47 Message: Logged In: YES user_id=80475 The problem isn't with filter() which correctly calls iter() in both cases. Tuple object have their own iterator which loops over elements directly and has no intervening calls to __getitem__(). String objects do not define a custom iterator, so iter() wraps itself around consecutive calls to __getitem__(). The resolution is to provide string objects with their own iterator. As a side benefit, iteration will run just a tiny bit faster. The same applies to unicode objects. Guido, do you care about this and want me to fix it or would you like to close it as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665835&group_id=5470 From noreply@sourceforge.net Sat Jan 25 19:44:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 25 Jan 2003 11:44:54 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-674689 ] enhancements for doctest Message-ID: Feature Requests item #674689, was opened at 2003-01-25 14:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=674689&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 4 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Tim Peters (tim_one) Summary: enhancements for doctest Initial Comment: 1) Add a method, doctest.regen(outputfile, module=None), which creates a copy of the module but with the test results unconditionally updated. This is similar in spirit to the -g option for regrtest.py. The principal use case is to handle a situation where only the output formatting has changed, but the internal logic is unchanged (suppose, for instance, that L stopped appearing at the end of long integers). 2) Add options for sloppy test matches: doctest.testmod(mymod, strictdictorder=False, exactfloats=False). The default should continue to be strict. The goal is to make doctest easier to use and produce more readable documentation by eliminating the gyrations to avoid dependencies on dictionary order or exact floating point results. Replace this: >>> r = mydict.items() >>> r.sort() >>> r [('eggs',1), ('spam', 2)] >>> round(1./7, 5) 0.14285999999999999 with this: >>> mydict.items() [('eggs',1), ('spam', 2)] >>> 1./7 0.14285714285714285 3) Since the interactive session may have been produced in IDLE instead of the command line, don't depend on PS2 being equal to "...". If the first line after '>>>' startswith('...'), then continue to use '...', but if it doesn't, then continue to read input until a black line is encountered (i.e. match the logic used by IDLE). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=674689&group_id=5470 From noreply@sourceforge.net Sat Jan 25 20:23:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 25 Jan 2003 12:23:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-674700 ] problems in new XML code Message-ID: Bugs item #674700, was opened at 2003-01-25 15:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674700&group_id=5470 Category: XML Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Martin v. Löwis (loewis) Summary: problems in new XML code Initial Comment: Martin, I'm not sure if I should enter a bug report for these problems in Python or PyXML. I ran pychecker over the code you checked in to python Lib/xml/*. Here's the most likely problems: xml/dom/expatbuilder.py:337: No global (curNode) found xml/dom/minidom.py:59: Invalid arguments to (writexml), got 5, expected between 1 and 4 xml/dom/minidom.py:388: Local variable (nsuri) not usedxml/dom/minidom.py:390: No global (XMLNS_NAMESPACE) found xml/dom/minidom.py:394: No global (prefix) found xml/dom/minidom.py:1011: Using __slots__ in classic class Text has no effect, consider deriving from object xml/dom/minidom.py:1135: Using __slots__ in classic class CDATASection has no effect, consider deriving from objectxml/dom/minidom.py:1215: Using __slots__ in classic class Identified has no effect, consider deriving from object xml/dom/minidom.py:1930: No global (domreg) found There are many parameters not used. I'm not sure how __slots__ when used as mixins. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674700&group_id=5470 From noreply@sourceforge.net Sat Jan 25 20:27:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 25 Jan 2003 12:27:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-665835 ] filter() treatment of str and tuple inconsistent Message-ID: Bugs item #665835, was opened at 2003-01-10 11:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665835&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Guido van Rossum (gvanrossum) Summary: filter() treatment of str and tuple inconsistent Initial Comment: class tuple2(tuple): · def __getitem__(self, index): · · return 2*tuple.__getitem__(self, index) class str2(str): · def __getitem__(self, index): · · return chr(ord(str.__getitem__(self, index))+1) print filter(lambda x: x>1, tuple2((1, 2))) print filter(lambda x: x>"a", str2("ab")) this prints: (2,) bc i.e. the overwritten __getitem__ is ignored in the first case, but honored in the second. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-25 11:45 Message: Logged In: YES user_id=80475 None of the existing iterators (incl dicts, lists, tuples, and files) use __getitem__. Most likely, user defined iterators also access the data structure directly (for flexiblity and speed). Also, anything that uses PyTuple_GET_ITEM bypasses __getitem__. If string/unicode iterators are added, they should also go directly to the underlying data; otherwise, there is no point to it. Also, the proposal to change filtertuple(), doesn't solve inconsistencies within filterstring() which uses __getitem__ when there is a function call, but bypasses it when the function parameter is Py_None. I think the right answer is to change filterstring() to use an iterator and to implement string/unicode iterators that access the data directly (not using __getitem__). FYI for Tim: MvL noticed and fixed the unicode vs string difference. His patch, SF #636005, has not been applied yet. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-25 08:51 Message: Logged In: YES user_id=6380 (But in addition th that, I don't mind having a custom string iterator -- as long as it calls __getitem__ properly. Hm, shouldn't the tuple iterator call __getitem__ properly too?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-25 08:45 Message: Logged In: YES user_id=31435 Just noting that filter() is unique in special-casing the type of the input. It's always been surprising that way, and, e.g., filtering a string produces a string, but filtering a Unicode string produces a list. map() and reduce() don't play games like that, and always use the iteration protocol to march over their inputs. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-25 08:36 Message: Logged In: YES user_id=6380 I don't know which Python sources Raymond has been reading, but in the sources I've got in front of me, there are special cases for strings and tuples, and these *don't* use iter(). It so happens that the tuple special-case calls PyTuple_GetItem(), which doesn't call your __getitem__, while the string special-case calls the sq_item slot function, which (in your case) will be a wrapper that calls your __getitem__. A minimal fix would be to only call filtertuple for strict tuples -- although this changes the output type, but I don't think one should count on filter() of a tuple subclass returning a tuple (and it can't be made to return an instance of the subclass either -- we don't know the constructor signature). Similar fixes probably need to be made to map() and maybe reduce(). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-24 22:47 Message: Logged In: YES user_id=80475 The problem isn't with filter() which correctly calls iter() in both cases. Tuple object have their own iterator which loops over elements directly and has no intervening calls to __getitem__(). String objects do not define a custom iterator, so iter() wraps itself around consecutive calls to __getitem__(). The resolution is to provide string objects with their own iterator. As a side benefit, iteration will run just a tiny bit faster. The same applies to unicode objects. Guido, do you care about this and want me to fix it or would you like to close it as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665835&group_id=5470 From noreply@sourceforge.net Sat Jan 25 21:36:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 25 Jan 2003 13:36:40 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-668905 ] logging module documentation Message-ID: Feature Requests item #668905, was opened at 2003-01-16 00:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=668905&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: logging module documentation Initial Comment: I believe the logging module documentation needs to give an example of how to simply log to a file. The following example snippet could be appropriate: import logging logger = logging.getLogger('myapp') hdlr = FileHandler('/var/myapp/debug.log') hdlr.setFormatter(Formatter('%(asctime)s %(level)s %(message)s')) logger.addHandler(hdlr) logger.setLevel(DEBUG) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-25 16:36 Message: Logged In: YES user_id=33168 I just updated the logging documentation. Could you please review for accuracy and completeness? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=668905&group_id=5470 From noreply@sourceforge.net Sat Jan 25 22:09:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 25 Jan 2003 14:09:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-637847 ] logging package undocumented Message-ID: Bugs item #637847, was opened at 2002-11-13 10:33 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637847&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Skip Montanaro (montanaro) Summary: logging package undocumented Initial Comment: Someone needs to convert the available documentation to LaTeX. Volunteers are encouraged. ;-) ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-01-25 16:09 Message: Logged In: YES user_id=44345 See #638299. Neal checked in Vinay's latest stuff. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-11-14 09:15 Message: Logged In: YES user_id=44345 taking it back - fred ya gotta be quick around here! ;-) Got some new content from Vinay which I'll either merge with what I did or use to replace it in its entirety... See http://python.org/sf/638299 ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-11-13 22:02 Message: Logged In: YES user_id=44345 Assigning back to Fred. Initial cut at liblogging.tex is checked in. It's essentially just a mechanical translation of pydoc.help(logging). Note that Vinay's documentation at http://www.red-dove.com/python_logging.html has not been converted. This still needs to be done. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-11-13 15:14 Message: Logged In: YES user_id=11375 Snarfed! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=637847&group_id=5470 From noreply@sourceforge.net Sat Jan 25 22:46:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 25 Jan 2003 14:46:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-674574 ] Access to serial devices through Carbon.CF Message-ID: Bugs item #674574, was opened at 2003-01-25 15:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674574&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pascal Oberndoerfer (pascal_efi) Assigned to: Jack Jansen (jackjansen) Summary: Access to serial devices through Carbon.CF Initial Comment: There is currently no wrapper to access serial RS232 devices (e.g. Keyspan USB-serial adaptor) through Carbon.CF on MacOS X. This was my short and dirty hack to get a list of currently available (Keyspan) serial devices: #!/usr/bin/env python import os import string PRE = 'cu' #PRE = 'tty' device_list = filter(lambda s: string.count(s, PRE+'.USA'), os.listdir('/dev/')) print device_list But as Jack said: Anything that is in CF but not wrapped in the Carbon.CF module should be considered a bug. I know there's still quite a bit missing, but if people put bug reports up on sourceforge that will influence the order in which I add stuff to the CF module. It would help a lot if you mentioned the data structure and/or some of the routines you need. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - Dan Grassi supposed (slightly paraphrased) to do the folowing on MacOS X with IORegistryExplorer (inside /Applications/Utilities) > Search for IOSerialBSDClient with a key of > IOSerialBSDClientType > with a value of IORS232SerialStream. > Then get the value of the > IODialinDevice (/dev/tty.*) or IOCalloutDevice (/dev/cu.*) ... For a single serial device this can result in: { CFBundleIdentifier = com.apple.iokit.IOSerialFamily; IOCalloutDevice = /dev/cu.USA19QW21P1.1; IOClass = IOSerialBSDClient; IODialinDevice = /dev/tty.USA19QW21P1.1; IOMatchCategory = IODefaultMatchCategory; IOPersonalityName = IOSerialBSDClientSync; IOProbeScore = 1000; IOProviderClass = IOSerialStreamSync; IOResourceMatch = IOBSD; IOSerialBSDClientType = IORS232SerialStream; IOTTYBaseName = USA19QW21P1.; IOTTYDevice = USA19QW21P1.1; IOTTYSuffix = 1; ParentKey = "KEXTBundle?com.apple.iokit.IOSerialFamily"; } So maybe return a list of dictionaries? Pascal (MacOS X, MacPython 2.3a1 [Framework Install]) ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-01-25 23:46 Message: Logged In: YES user_id=45365 Pascal, could you tell me which bits of CF you need? I asume CFBundle, but would you need all of it, or just a part? Would you need anything more than CFBundle? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674574&group_id=5470 From noreply@sourceforge.net Sun Jan 26 01:06:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 25 Jan 2003 17:06:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-674404 ] repr of type and class objects Message-ID: Bugs item #674404, was opened at 2003-01-25 02:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674404&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: repr of type and class objects Initial Comment: I've recently faced a shortcoming of my (our :-) favourite prog. lang. related to "repr-ing" type and class objects. Let's define a helper function to show the problem: def F(o): return eval(repr(o))==o Then try this: >>> F(1) 1 >>> F('x') 1 >>> F(int) Traceback (most recent call last): File "", line 1, in ? File "", line 1, in F File "", line 1 ^ SyntaxError: invalid syntax >>> str(int) "" >>> repr(int) "" In the case of str(int) returning "" is ok, since str() should return human-readable representation. But repr() should return a python expression can be evaluated into an object with the same "value" in the same context, so returning "" is a mistake. repr() should return just "int" to satisfy the philosophy behind repr. F(int) should return 1, since: >>> int==int 1 Generally, repr() should return the __name__ attribute if called with a class object (not an instance of a class). I had to solve the problem by treating type objects specially, but it isn't an elegant solution. I know, that fixing this problem may break some (badly written) code, but accoring to my view, it's better to check the type of an object by checking the return value of type() instead of parsing the output of repr(). In my opinion, this could be fixed easily in version 2.3. Best regards, Complex ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-26 02:06 Message: Logged In: YES user_id=21627 You are misunderstanding the philosophy of repr. repr should, most of all, return an unambiguous representation of the object (i.e. one that you can't easily mistake for some other object). Only if possible, it should produce something that you can pass to eval(). Now, since int.__class__ is type, one would expect that repr (int) behaves similar to repr(any_other_type). In general, it is not possible to know how a certain type object is bound, so you cannot change repr for the general case. Changing it for the specific case of the types that also happen to be builtins is of questionable value. Unless you can bring a real-world application that can't possibly work unless repr is changed, I'm closing this as Won't Fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674404&group_id=5470 From noreply@sourceforge.net Sun Jan 26 01:08:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 25 Jan 2003 17:08:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-672614 ] python -S still displays 'Type "help", "cop...' Message-ID: Bugs item #672614, was opened at 2003-01-22 19:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672614&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 1 Submitted By: Douglas Napoleone (derivin) Assigned to: Nobody/Anonymous (nobody) >Summary: python -S still displays 'Type "help", "cop...' Initial Comment: $ python -S Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> help Traceback (most recent call last): File "", line 1, in ? NameError: name 'help' is not defined site.py sets up the builtins for help, credits, etc. where this is printed in Py_Main() it is already known wether or not site.py was going to be imported or not. I know its a real nit-pick, but it has bugged me for some time. should be set to a LOW priority. (and yes, the bug is still there in 2.3a1) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-26 02:08 Message: Logged In: YES user_id=21627 Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672614&group_id=5470 From noreply@sourceforge.net Sun Jan 26 07:31:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 25 Jan 2003 23:31:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-672614 ] python -S still displays 'Type "help", "cop...' Message-ID: Bugs item #672614, was opened at 2003-01-22 13:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672614&group_id=5470 Category: Extension Modules Group: Python 2.2 Status: Open Resolution: None Priority: 1 Submitted By: Douglas Napoleone (derivin) Assigned to: Nobody/Anonymous (nobody) >Summary: python -S still displays 'Type "help", "cop...' Initial Comment: $ python -S Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> help Traceback (most recent call last): File "", line 1, in ? NameError: name 'help' is not defined site.py sets up the builtins for help, credits, etc. where this is printed in Py_Main() it is already known wether or not site.py was going to be imported or not. I know its a real nit-pick, but it has bugged me for some time. should be set to a LOW priority. (and yes, the bug is still there in 2.3a1) ---------------------------------------------------------------------- >Comment By: Douglas Napoleone (derivin) Date: 2003-01-26 02:31 Message: Logged In: YES user_id=541557 um sure.... its just: if(!Py_NoSiteFlag) { fprintf(stderr, "%s\n" COPYRIGHT); } I'll put up a dicc -c patch on monday after I test it... seen to many patches that dont compile ^_^ ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-25 20:08 Message: Logged In: YES user_id=21627 Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672614&group_id=5470 From noreply@sourceforge.net Sun Jan 26 07:53:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 25 Jan 2003 23:53:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-674574 ] Access to serial devices through Carbon.CF Message-ID: Bugs item #674574, was opened at 2003-01-25 15:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674574&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 3 Submitted By: Pascal Oberndoerfer (pascal_efi) Assigned to: Jack Jansen (jackjansen) Summary: Access to serial devices through Carbon.CF Initial Comment: There is currently no wrapper to access serial RS232 devices (e.g. Keyspan USB-serial adaptor) through Carbon.CF on MacOS X. This was my short and dirty hack to get a list of currently available (Keyspan) serial devices: #!/usr/bin/env python import os import string PRE = 'cu' #PRE = 'tty' device_list = filter(lambda s: string.count(s, PRE+'.USA'), os.listdir('/dev/')) print device_list But as Jack said: Anything that is in CF but not wrapped in the Carbon.CF module should be considered a bug. I know there's still quite a bit missing, but if people put bug reports up on sourceforge that will influence the order in which I add stuff to the CF module. It would help a lot if you mentioned the data structure and/or some of the routines you need. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - Dan Grassi supposed (slightly paraphrased) to do the folowing on MacOS X with IORegistryExplorer (inside /Applications/Utilities) > Search for IOSerialBSDClient with a key of > IOSerialBSDClientType > with a value of IORS232SerialStream. > Then get the value of the > IODialinDevice (/dev/tty.*) or IOCalloutDevice (/dev/cu.*) ... For a single serial device this can result in: { CFBundleIdentifier = com.apple.iokit.IOSerialFamily; IOCalloutDevice = /dev/cu.USA19QW21P1.1; IOClass = IOSerialBSDClient; IODialinDevice = /dev/tty.USA19QW21P1.1; IOMatchCategory = IODefaultMatchCategory; IOPersonalityName = IOSerialBSDClientSync; IOProbeScore = 1000; IOProviderClass = IOSerialStreamSync; IOResourceMatch = IOBSD; IOSerialBSDClientType = IORS232SerialStream; IOTTYBaseName = USA19QW21P1.; IOTTYDevice = USA19QW21P1.1; IOTTYSuffix = 1; ParentKey = "KEXTBundle?com.apple.iokit.IOSerialFamily"; } So maybe return a list of dictionaries? Pascal (MacOS X, MacPython 2.3a1 [Framework Install]) ---------------------------------------------------------------------- >Comment By: Pascal Oberndoerfer (pascal_efi) Date: 2003-01-26 08:53 Message: Logged In: YES user_id=688343 Jack, (sorry, quite long again) I was afraid you would ask -- because I don't know. So I went to the Apple docs and found some information that made me doubt if it's really Carbon.CF I am looking for. http://developer.apple.com/techpubs/macosx/Darwin/General/AccessingHardware/AH_Intro As I need "only" a list of accessible serial devices and the paths to their device files two chapters sounded interesting to me: 1. I/O Kit Hardware Access > • Using a Device Interface to Access a Device > - Finding Devices 2. Working With Serial I/O > • Working With a Serial Port Modem > - Setting Up Your Programming Environment - Setting Up a Main Function - Finding All Serial Port Modems - Getting the Path to the Device File for a Modem Finding all available serial ports and getting the path(s) to their respective device files. Opening, working with, and closing the ports is all done with pyserial. If I only understood the docs! (have I ever been in the need of an excellent example why I prefer Python over any other programming language? ;-) I found some sample code at Apple as well: http://developer.apple.com/samplecode/Sample_Code/Devices_and_Hardware/Serial/SerialPortSample.htm But again: I am not a professional programmer (especially not C) so I have no idea what it means or what to do with it. Hmm... Actually, if it is not possible to access this from CF then -- according to your definition -- it's not a bug but a feature request I guess. The reason it would be extremly nice to have this way to scan for the serial ports is that they disappear completely with the removal of the USB-adapter. But as there is a workaround priority is really low, low, low! Pascal PS: my motivation behind all this is a small data logging utility I need to write. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-01-25 23:46 Message: Logged In: YES user_id=45365 Pascal, could you tell me which bits of CF you need? I asume CFBundle, but would you need all of it, or just a part? Would you need anything more than CFBundle? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674574&group_id=5470 From noreply@sourceforge.net Sun Jan 26 09:07:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 26 Jan 2003 01:07:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-674700 ] problems in new XML code Message-ID: Bugs item #674700, was opened at 2003-01-25 21:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674700&group_id=5470 Category: XML Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Martin v. Löwis (loewis) Summary: problems in new XML code Initial Comment: Martin, I'm not sure if I should enter a bug report for these problems in Python or PyXML. I ran pychecker over the code you checked in to python Lib/xml/*. Here's the most likely problems: xml/dom/expatbuilder.py:337: No global (curNode) found xml/dom/minidom.py:59: Invalid arguments to (writexml), got 5, expected between 1 and 4 xml/dom/minidom.py:388: Local variable (nsuri) not usedxml/dom/minidom.py:390: No global (XMLNS_NAMESPACE) found xml/dom/minidom.py:394: No global (prefix) found xml/dom/minidom.py:1011: Using __slots__ in classic class Text has no effect, consider deriving from object xml/dom/minidom.py:1135: Using __slots__ in classic class CDATASection has no effect, consider deriving from objectxml/dom/minidom.py:1215: Using __slots__ in classic class Identified has no effect, consider deriving from object xml/dom/minidom.py:1930: No global (domreg) found There are many parameters not used. I'm not sure how __slots__ when used as mixins. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-26 10:07 Message: Logged In: YES user_id=21627 This is fixed in minidom.py 1.50, expatbuilder.py 1.2. The message about writexml is bogus: there are different writexml versions, and one that takes 5 arguments. The parameters-not-used warnings probably are fine as well: the interface is mandated by W3C, it might well be that we don't need all parameters. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674700&group_id=5470 From noreply@sourceforge.net Sun Jan 26 10:45:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 26 Jan 2003 02:45:00 -0800 Subject: [Python-bugs-list] [ python-Bugs-630494 ] expat causes a core dump Message-ID: Bugs item #630494, was opened at 2002-10-29 15:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=630494&group_id=5470 Category: XML Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: MM Zeeman (mmzeeman) Assigned to: Martin v. Löwis (loewis) Summary: expat causes a core dump Initial Comment: Raising an exception inside a StartNamespaceDeclHandler causes python to dump core. The attached program will cause a segmentation fault. Note it is possible to raise exception in the StartElementHandler and EndElementHandler with Python 2.0 >python2.0 expat_testje.py None 123 Segmentation fault (core dumped) with Python 2.2.1 >python2 expat_testje.py None 123 Segmentation fault (core dumped) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-26 11:45 Message: Logged In: YES user_id=21627 It appears to be fixed in 2.3, although I haven't investigated which particular change has fixed it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-29 23:14 Message: Logged In: YES user_id=33168 This core dumps on 2.2.2 and 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=630494&group_id=5470 From noreply@sourceforge.net Sun Jan 26 16:25:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 26 Jan 2003 08:25:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-674987 ] seg fault on exit in import module Message-ID: Bugs item #674987, was opened at 2003-01-26 11:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674987&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Just van Rossum (jvr) Summary: seg fault on exit in import module Initial Comment: Just, I'm guessing this has to do with the import modifications you made, although I really don't know. I just started getting a crash which originates in _PyImport_Fini(). When I run: ./python -E -tt ./Lib/test/regrtest.py test_logging I get a core dump. Here's the stack trace from a debug build. The same problem occurs in a normal (non-debug) build. (gdb) bt #0 0x08080e09 in _Py_ForgetReference (op=0x407887c0) at Objects/object.c:1949 #1 0x08080e79 in _Py_Dealloc (op=0x407887c0) at Objects/object.c:1970 #2 0x08079e7e in dict_dealloc (mp=0x4026b214) at Objects/dictobject.c:690 #3 0x08080e87 in _Py_Dealloc (op=0x4026b214) at Objects/object.c:1971 #4 0x08079e7e in dict_dealloc (mp=0x401bea34) at Objects/dictobject.c:690 #5 0x08080e87 in _Py_Dealloc (op=0x401bea34) at Objects/object.c:1971 #6 0x080d5d66 in _PyImport_Fini () at Python/import.c:224 #7 0x080dff7a in Py_Finalize () at Python/pythonrun.c:233 #8 0x08055146 in Py_Main (argc=4, argv=0xbffff814) at Modules/main.c:465 #9 0x08054884 in main (argc=4, argv=0xbffff814) at Modules/python.c:23 Any ideas? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674987&group_id=5470 From noreply@sourceforge.net Sun Jan 26 21:08:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 26 Jan 2003 13:08:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-674987 ] seg fault on exit in import module Message-ID: Bugs item #674987, was opened at 2003-01-26 17:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674987&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Just van Rossum (jvr) Summary: seg fault on exit in import module Initial Comment: Just, I'm guessing this has to do with the import modifications you made, although I really don't know. I just started getting a crash which originates in _PyImport_Fini(). When I run: ./python -E -tt ./Lib/test/regrtest.py test_logging I get a core dump. Here's the stack trace from a debug build. The same problem occurs in a normal (non-debug) build. (gdb) bt #0 0x08080e09 in _Py_ForgetReference (op=0x407887c0) at Objects/object.c:1949 #1 0x08080e79 in _Py_Dealloc (op=0x407887c0) at Objects/object.c:1970 #2 0x08079e7e in dict_dealloc (mp=0x4026b214) at Objects/dictobject.c:690 #3 0x08080e87 in _Py_Dealloc (op=0x4026b214) at Objects/object.c:1971 #4 0x08079e7e in dict_dealloc (mp=0x401bea34) at Objects/dictobject.c:690 #5 0x08080e87 in _Py_Dealloc (op=0x401bea34) at Objects/object.c:1971 #6 0x080d5d66 in _PyImport_Fini () at Python/import.c:224 #7 0x080dff7a in Py_Finalize () at Python/pythonrun.c:233 #8 0x08055146 in Py_Main (argc=4, argv=0xbffff814) at Modules/main.c:465 #9 0x08054884 in main (argc=4, argv=0xbffff814) at Modules/python.c:23 Any ideas? ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-01-26 22:08 Message: Logged In: YES user_id=92689 Hm, I wish I could reproduce this on my OSX box, but I can't: the loggin test passes just fine. I also doubt it has to do with my mods, as _PyImport_Fini doesn't touch anything that has anything to do with import hooks directly. Of course it's still not impossible I caused this, but right now I don't see how it could. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674987&group_id=5470 From noreply@sourceforge.net Sun Jan 26 21:58:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 26 Jan 2003 13:58:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-660144 ] typeobject provides incorrect __mul__ Message-ID: Bugs item #660144, was opened at 2002-12-30 21:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660144&group_id=5470 Category: Python Interpreter Core Group: None >Status: Open Resolution: Accepted Priority: 5 Submitted By: Neil Schemenauer (nascheme) Assigned to: Neil Schemenauer (nascheme) Summary: typeobject provides incorrect __mul__ Initial Comment: type __mul__ is wierd: >> 'a'.__mul__(3.4) 'aaa' >>> [1].__mul__(3.4) [1, 1, 1] Floating point numbers with fractions should not be accepted. I think the problem is that __mul__ should not be trying to implement sq_repeat behavior (although I haven't dug deeply into this problem yet). Also, I think the code is vulnerable to integer overflow. Should also check __imul__ __add__ __iadd__. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-01-26 22:58 Message: Logged In: YES user_id=45365 Neil, your mod to PyArg_Parse is far too aggressive. Apparently the integer formats have accepted floating point arguments since day one, and all weekend I'm running across places where floats are passed to integers. For example, the MacPython IDE does this all the time, and I wouldn't be surprised if there's lots of windowing code that does this (compute pixel positions in floating point and then passing them to something expecting an integer). If this is fixed in this way (disallowing floats where integers are expected) it should at least be done with a DeprecationWarning for one release cycle. I think the fix probably is a good idea in the long run, but it will break large bodies of code... ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-01-24 23:20 Message: Logged In: YES user_id=35752 I added the check for the other integer codes. All the tests pass so I checked it in. Hope that's okay. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-21 20:55 Message: Logged In: YES user_id=6380 Looks like a good patch. And yes, the other types should be doing this as well. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-01-19 20:35 Message: Logged In: YES user_id=35752 The small patch is attached. I only added the checking for 'i' and 'l'. I wonder if it should be done for the other integer codes as well (e.g. 'b', 'h'). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-17 01:19 Message: Logged In: YES user_id=6380 Yes, this should go into 2.3a2. Your attachment upload failed somehow. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-01-17 00:10 Message: Logged In: YES user_id=35752 Would this be a change for the 2.3 release? I tried adding a PyFloat_Check test to 'i' and 'l' in getargs.c. It looks like all the unit tests pass. I agree that checking for float catches the important cases. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-16 22:57 Message: Logged In: YES user_id=6380 This is an age-old problem that crops up whenever "i" and similar format codes are used. The problem is that on the one hand you want "i" to accept other int-ish types that have an __int__ method. But on the other hand you don't want it to accept float, which also has an __int__ method. Or other float-ish types. I think the "i" format code has to be fixe, but I'm not sure how -- maybe as a start it would be sufficient to test explicitly for float and its subclasses and reject those. That would still allow 3rd party float-ish classes that implement __int__, but that's not so important. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-01-16 22:33 Message: Logged In: YES user_id=35752 I think the problem is that wrap_intargfunc and wrap_intintargfunc use PyArg_ParseTuple(args, "i", &i). This bug also is present in methods like __getitem__: >>> "Python"[1.2] Traceback (most recent call last): File "", line 1, in ? TypeError: sequence index must be integer >>> "Python".__getitem__(1.2) 'y' I think the right fix is to use explictly only allow only ints and longs to wrap_intargfunc and friends. If Guido agrees I will cook up a patch. It seems like we should have a code for PyParse_Tuple that only allows ints and longs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660144&group_id=5470 From noreply@sourceforge.net Mon Jan 27 00:01:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 26 Jan 2003 16:01:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-675187 ] bsddb hangs with recno/source sync Message-ID: Bugs item #675187, was opened at 2003-01-27 01:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675187&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Magnus Lie Hetland (mlh) Assigned to: Nobody/Anonymous (nobody) Summary: bsddb hangs with recno/source sync Initial Comment: I just tried to use bsddb with the source argument to have flat backing file. Creating a database with such a backing file as source was not problematic, but after I had modified it, the sync() and close() method would hang. For example: from bsddb import rnopen r = rnopen('test.dat', source='test.txt') r[1] = 'foobar' r.sync() # Hangs here... After running this, test.txt will be empty (even though it wasn't before). Running the code above without the source argument works just fine. I'm running Python 2.3 cvs version (slightly earlier than the first alpha) on SunOS 5.9. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675187&group_id=5470 From noreply@sourceforge.net Mon Jan 27 00:17:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 26 Jan 2003 16:17:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-665835 ] filter() treatment of str and tuple inconsistent Message-ID: Bugs item #665835, was opened at 2003-01-10 11:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665835&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Raymond Hettinger (rhettinger) Summary: filter() treatment of str and tuple inconsistent Initial Comment: class tuple2(tuple): · def __getitem__(self, index): · · return 2*tuple.__getitem__(self, index) class str2(str): · def __getitem__(self, index): · · return chr(ord(str.__getitem__(self, index))+1) print filter(lambda x: x>1, tuple2((1, 2))) print filter(lambda x: x>"a", str2("ab")) this prints: (2,) bc i.e. the overwritten __getitem__ is ignored in the first case, but honored in the second. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-26 19:17 Message: Logged In: YES user_id=6380 Hm... that means that iter() of *amy* built-in type subclass overriding __getitem__ bypasses the override, unless the subclass also overrides __iter__. This sounds like a step in the wrong direction. I think the built-in iterators should be aware of subclasses overriding __getitem__ one way or another. I hadn't realized this when we started the trend of creating faster iterators for built-in types. :-( ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-25 11:45 Message: Logged In: YES user_id=80475 None of the existing iterators (incl dicts, lists, tuples, and files) use __getitem__. Most likely, user defined iterators also access the data structure directly (for flexiblity and speed). Also, anything that uses PyTuple_GET_ITEM bypasses __getitem__. If string/unicode iterators are added, they should also go directly to the underlying data; otherwise, there is no point to it. Also, the proposal to change filtertuple(), doesn't solve inconsistencies within filterstring() which uses __getitem__ when there is a function call, but bypasses it when the function parameter is Py_None. I think the right answer is to change filterstring() to use an iterator and to implement string/unicode iterators that access the data directly (not using __getitem__). FYI for Tim: MvL noticed and fixed the unicode vs string difference. His patch, SF #636005, has not been applied yet. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-25 08:51 Message: Logged In: YES user_id=6380 (But in addition th that, I don't mind having a custom string iterator -- as long as it calls __getitem__ properly. Hm, shouldn't the tuple iterator call __getitem__ properly too?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-25 08:45 Message: Logged In: YES user_id=31435 Just noting that filter() is unique in special-casing the type of the input. It's always been surprising that way, and, e.g., filtering a string produces a string, but filtering a Unicode string produces a list. map() and reduce() don't play games like that, and always use the iteration protocol to march over their inputs. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-25 08:36 Message: Logged In: YES user_id=6380 I don't know which Python sources Raymond has been reading, but in the sources I've got in front of me, there are special cases for strings and tuples, and these *don't* use iter(). It so happens that the tuple special-case calls PyTuple_GetItem(), which doesn't call your __getitem__, while the string special-case calls the sq_item slot function, which (in your case) will be a wrapper that calls your __getitem__. A minimal fix would be to only call filtertuple for strict tuples -- although this changes the output type, but I don't think one should count on filter() of a tuple subclass returning a tuple (and it can't be made to return an instance of the subclass either -- we don't know the constructor signature). Similar fixes probably need to be made to map() and maybe reduce(). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-24 22:47 Message: Logged In: YES user_id=80475 The problem isn't with filter() which correctly calls iter() in both cases. Tuple object have their own iterator which loops over elements directly and has no intervening calls to __getitem__(). String objects do not define a custom iterator, so iter() wraps itself around consecutive calls to __getitem__(). The resolution is to provide string objects with their own iterator. As a side benefit, iteration will run just a tiny bit faster. The same applies to unicode objects. Guido, do you care about this and want me to fix it or would you like to close it as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665835&group_id=5470 From noreply@sourceforge.net Mon Jan 27 00:54:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 26 Jan 2003 16:54:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-665835 ] filter() treatment of str and tuple inconsistent Message-ID: Bugs item #665835, was opened at 2003-01-10 11:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665835&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) >Assigned to: Guido van Rossum (gvanrossum) Summary: filter() treatment of str and tuple inconsistent Initial Comment: class tuple2(tuple): · def __getitem__(self, index): · · return 2*tuple.__getitem__(self, index) class str2(str): · def __getitem__(self, index): · · return chr(ord(str.__getitem__(self, index))+1) print filter(lambda x: x>1, tuple2((1, 2))) print filter(lambda x: x>"a", str2("ab")) this prints: (2,) bc i.e. the overwritten __getitem__ is ignored in the first case, but honored in the second. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-26 19:54 Message: Logged In: YES user_id=80475 I understand. Ideally, *all* methods would respond to a single overridden method, but I think this is just a fact of life in object oriented programming. I can't remember where you gave an example of a d.__getitem__() subclass override, but you were careful to point out that other methods, like d.get() also needed to be overridden so that the modified access applied everywhere. Likewise, __iter__() or any other object access method must be assumed to access the underlying data structure directly and must be overridden. For instance, creating a dictionary with case insensitive lookups entails overriding __getitem__(k), get(k,default), and pop(k) -- no one of them can be presumed to inform the others. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-26 19:17 Message: Logged In: YES user_id=6380 Hm... that means that iter() of *amy* built-in type subclass overriding __getitem__ bypasses the override, unless the subclass also overrides __iter__. This sounds like a step in the wrong direction. I think the built-in iterators should be aware of subclasses overriding __getitem__ one way or another. I hadn't realized this when we started the trend of creating faster iterators for built-in types. :-( ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-25 11:45 Message: Logged In: YES user_id=80475 None of the existing iterators (incl dicts, lists, tuples, and files) use __getitem__. Most likely, user defined iterators also access the data structure directly (for flexiblity and speed). Also, anything that uses PyTuple_GET_ITEM bypasses __getitem__. If string/unicode iterators are added, they should also go directly to the underlying data; otherwise, there is no point to it. Also, the proposal to change filtertuple(), doesn't solve inconsistencies within filterstring() which uses __getitem__ when there is a function call, but bypasses it when the function parameter is Py_None. I think the right answer is to change filterstring() to use an iterator and to implement string/unicode iterators that access the data directly (not using __getitem__). FYI for Tim: MvL noticed and fixed the unicode vs string difference. His patch, SF #636005, has not been applied yet. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-25 08:51 Message: Logged In: YES user_id=6380 (But in addition th that, I don't mind having a custom string iterator -- as long as it calls __getitem__ properly. Hm, shouldn't the tuple iterator call __getitem__ properly too?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-25 08:45 Message: Logged In: YES user_id=31435 Just noting that filter() is unique in special-casing the type of the input. It's always been surprising that way, and, e.g., filtering a string produces a string, but filtering a Unicode string produces a list. map() and reduce() don't play games like that, and always use the iteration protocol to march over their inputs. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-25 08:36 Message: Logged In: YES user_id=6380 I don't know which Python sources Raymond has been reading, but in the sources I've got in front of me, there are special cases for strings and tuples, and these *don't* use iter(). It so happens that the tuple special-case calls PyTuple_GetItem(), which doesn't call your __getitem__, while the string special-case calls the sq_item slot function, which (in your case) will be a wrapper that calls your __getitem__. A minimal fix would be to only call filtertuple for strict tuples -- although this changes the output type, but I don't think one should count on filter() of a tuple subclass returning a tuple (and it can't be made to return an instance of the subclass either -- we don't know the constructor signature). Similar fixes probably need to be made to map() and maybe reduce(). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-24 22:47 Message: Logged In: YES user_id=80475 The problem isn't with filter() which correctly calls iter() in both cases. Tuple object have their own iterator which loops over elements directly and has no intervening calls to __getitem__(). String objects do not define a custom iterator, so iter() wraps itself around consecutive calls to __getitem__(). The resolution is to provide string objects with their own iterator. As a side benefit, iteration will run just a tiny bit faster. The same applies to unicode objects. Guido, do you care about this and want me to fix it or would you like to close it as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665835&group_id=5470 From noreply@sourceforge.net Mon Jan 27 01:13:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 26 Jan 2003 17:13:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-665835 ] filter() treatment of str and tuple inconsistent Message-ID: Bugs item #665835, was opened at 2003-01-10 11:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665835&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: filter() treatment of str and tuple inconsistent Initial Comment: class tuple2(tuple): · def __getitem__(self, index): · · return 2*tuple.__getitem__(self, index) class str2(str): · def __getitem__(self, index): · · return chr(ord(str.__getitem__(self, index))+1) print filter(lambda x: x>1, tuple2((1, 2))) print filter(lambda x: x>"a", str2("ab")) this prints: (2,) bc i.e. the overwritten __getitem__ is ignored in the first case, but honored in the second. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-26 20:13 Message: Logged In: YES user_id=80475 One other thought: A major reason for implementing __iter__ in the first place is that objects were overriding __getitem__ and disregarding the index -- the __getitem__ interface just didn't make sense for iteration in some situations. __iter__ was supposed to provide enormous flexibility in various ways to loop over a collection (inorder, preorder, postorder, priorityorder, sortedorder, hashorder, randomorder, etc). Making iter() default to using __getitem__ was only supposed to be an expedient for backwards compatability. Always using __getitem__ diminishes the flexibility and speed advantages. Maybe the discussion belongs on python-dev. I'm sure a number of people feel strongly one way or the other. The question might as well be addressed head-on before 2.3 goes out the door. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-26 19:54 Message: Logged In: YES user_id=80475 I understand. Ideally, *all* methods would respond to a single overridden method, but I think this is just a fact of life in object oriented programming. I can't remember where you gave an example of a d.__getitem__() subclass override, but you were careful to point out that other methods, like d.get() also needed to be overridden so that the modified access applied everywhere. Likewise, __iter__() or any other object access method must be assumed to access the underlying data structure directly and must be overridden. For instance, creating a dictionary with case insensitive lookups entails overriding __getitem__(k), get(k,default), and pop(k) -- no one of them can be presumed to inform the others. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-26 19:17 Message: Logged In: YES user_id=6380 Hm... that means that iter() of *amy* built-in type subclass overriding __getitem__ bypasses the override, unless the subclass also overrides __iter__. This sounds like a step in the wrong direction. I think the built-in iterators should be aware of subclasses overriding __getitem__ one way or another. I hadn't realized this when we started the trend of creating faster iterators for built-in types. :-( ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-25 11:45 Message: Logged In: YES user_id=80475 None of the existing iterators (incl dicts, lists, tuples, and files) use __getitem__. Most likely, user defined iterators also access the data structure directly (for flexiblity and speed). Also, anything that uses PyTuple_GET_ITEM bypasses __getitem__. If string/unicode iterators are added, they should also go directly to the underlying data; otherwise, there is no point to it. Also, the proposal to change filtertuple(), doesn't solve inconsistencies within filterstring() which uses __getitem__ when there is a function call, but bypasses it when the function parameter is Py_None. I think the right answer is to change filterstring() to use an iterator and to implement string/unicode iterators that access the data directly (not using __getitem__). FYI for Tim: MvL noticed and fixed the unicode vs string difference. His patch, SF #636005, has not been applied yet. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-25 08:51 Message: Logged In: YES user_id=6380 (But in addition th that, I don't mind having a custom string iterator -- as long as it calls __getitem__ properly. Hm, shouldn't the tuple iterator call __getitem__ properly too?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-25 08:45 Message: Logged In: YES user_id=31435 Just noting that filter() is unique in special-casing the type of the input. It's always been surprising that way, and, e.g., filtering a string produces a string, but filtering a Unicode string produces a list. map() and reduce() don't play games like that, and always use the iteration protocol to march over their inputs. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-25 08:36 Message: Logged In: YES user_id=6380 I don't know which Python sources Raymond has been reading, but in the sources I've got in front of me, there are special cases for strings and tuples, and these *don't* use iter(). It so happens that the tuple special-case calls PyTuple_GetItem(), which doesn't call your __getitem__, while the string special-case calls the sq_item slot function, which (in your case) will be a wrapper that calls your __getitem__. A minimal fix would be to only call filtertuple for strict tuples -- although this changes the output type, but I don't think one should count on filter() of a tuple subclass returning a tuple (and it can't be made to return an instance of the subclass either -- we don't know the constructor signature). Similar fixes probably need to be made to map() and maybe reduce(). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-24 22:47 Message: Logged In: YES user_id=80475 The problem isn't with filter() which correctly calls iter() in both cases. Tuple object have their own iterator which loops over elements directly and has no intervening calls to __getitem__(). String objects do not define a custom iterator, so iter() wraps itself around consecutive calls to __getitem__(). The resolution is to provide string objects with their own iterator. As a side benefit, iteration will run just a tiny bit faster. The same applies to unicode objects. Guido, do you care about this and want me to fix it or would you like to close it as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665835&group_id=5470 From noreply@sourceforge.net Mon Jan 27 03:21:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 26 Jan 2003 19:21:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-675222 ] time.daylight badly defined Message-ID: Bugs item #675222, was opened at 2003-01-27 14:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675222&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: time.daylight badly defined Initial Comment: 'Nonzero if a DST timezone is defined' is meaningless if the timezone automatically switches into DST. A better definition might be 'Nonzero if the current local time is in DST' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675222&group_id=5470 From noreply@sourceforge.net Mon Jan 27 04:32:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 26 Jan 2003 20:32:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-675222 ] time.daylight badly defined Message-ID: Bugs item #675222, was opened at 2003-01-26 22:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675222&group_id=5470 Category: Documentation >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Stuart Bishop (zenzen) >Assigned to: Tim Peters (tim_one) Summary: time.daylight badly defined Initial Comment: 'Nonzero if a DST timezone is defined' is meaningless if the timezone automatically switches into DST. A better definition might be 'Nonzero if the current local time is in DST' ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-26 23:32 Message: Logged In: YES user_id=31435 "daylight" was originally defined by X/Open, and taken over by POSIX. Python defines it the same way they do. It's not there to tell you whether it's *currently* daylight saving ime (get a struct tm for the time you're interested in and look at tm_isdst for that), it's only there to tell whether time.altzone should be used when tm_isdst is > 0. The SCO docs are clearer than most on these points: http://osr5doc.ca.caldera.com:457/cgi-bin/man/man? ctime+S but note that the tm_tzadj and tm_name documented there are non-portable extensions. C's time zone facilities are a x-platform mess, but I expect you're figuring that out . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675222&group_id=5470 From noreply@sourceforge.net Mon Jan 27 04:42:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 26 Jan 2003 20:42:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-675222 ] time.daylight badly defined Message-ID: Bugs item #675222, was opened at 2003-01-27 14:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675222&group_id=5470 Category: Documentation Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Tim Peters (tim_one) Summary: time.daylight badly defined Initial Comment: 'Nonzero if a DST timezone is defined' is meaningless if the timezone automatically switches into DST. A better definition might be 'Nonzero if the current local time is in DST' ---------------------------------------------------------------------- >Comment By: Stuart Bishop (zenzen) Date: 2003-01-27 15:42 Message: Logged In: YES user_id=46639 So it would be fair to say daylight == (tzname[0] != tzname[1]) If so, this makes it easier on me and is actually testable behavior :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-27 15:32 Message: Logged In: YES user_id=31435 "daylight" was originally defined by X/Open, and taken over by POSIX. Python defines it the same way they do. It's not there to tell you whether it's *currently* daylight saving ime (get a struct tm for the time you're interested in and look at tm_isdst for that), it's only there to tell whether time.altzone should be used when tm_isdst is > 0. The SCO docs are clearer than most on these points: http://osr5doc.ca.caldera.com:457/cgi-bin/man/man? ctime+S but note that the tm_tzadj and tm_name documented there are non-portable extensions. C's time zone facilities are a x-platform mess, but I expect you're figuring that out . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675222&group_id=5470 From noreply@sourceforge.net Mon Jan 27 05:02:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 26 Jan 2003 21:02:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-675222 ] time.daylight badly defined Message-ID: Bugs item #675222, was opened at 2003-01-26 22:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675222&group_id=5470 Category: Documentation Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Tim Peters (tim_one) Summary: time.daylight badly defined Initial Comment: 'Nonzero if a DST timezone is defined' is meaningless if the timezone automatically switches into DST. A better definition might be 'Nonzero if the current local time is in DST' ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-27 00:02 Message: Logged In: YES user_id=31435 I don't think any standard requires that the two tznames differ if a time zone has a notion of daylight time. I know that Brett Cannon got in trouble with the 2.3a1 all-Python strptime() implementation simply for assuming that at least one tzname value wasn't an empty string! The perversity of OSes is (unfortunately) unbounded here -- and ANSI C refused to standardize any of the time zone stuff. ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-01-26 23:42 Message: Logged In: YES user_id=46639 So it would be fair to say daylight == (tzname[0] != tzname[1]) If so, this makes it easier on me and is actually testable behavior :-) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-26 23:32 Message: Logged In: YES user_id=31435 "daylight" was originally defined by X/Open, and taken over by POSIX. Python defines it the same way they do. It's not there to tell you whether it's *currently* daylight saving ime (get a struct tm for the time you're interested in and look at tm_isdst for that), it's only there to tell whether time.altzone should be used when tm_isdst is > 0. The SCO docs are clearer than most on these points: http://osr5doc.ca.caldera.com:457/cgi-bin/man/man? ctime+S but note that the tm_tzadj and tm_name documented there are non-portable extensions. C's time zone facilities are a x-platform mess, but I expect you're figuring that out . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675222&group_id=5470 From noreply@sourceforge.net Mon Jan 27 05:39:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 26 Jan 2003 21:39:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-675259 ] os.environ leaks under FreeBSD and Mac OS X Message-ID: Bugs item #675259, was opened at 2003-01-27 16:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675259&group_id=5470 Category: Documentation Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: os.environ leaks under FreeBSD and Mac OS X Initial Comment: If this sort if thing is documented anywhere, the putenv(3) method leaks under FreeBSD and Mac OS X (Mac OS X documents it as a bug they inherited from the FreeBSD codebase in the man page). So don't set environment variables in a loop. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675259&group_id=5470 From noreply@sourceforge.net Mon Jan 27 05:57:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 26 Jan 2003 21:57:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-660144 ] typeobject provides incorrect __mul__ Message-ID: Bugs item #660144, was opened at 2002-12-30 20:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660144&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Neil Schemenauer (nascheme) >Assigned to: Guido van Rossum (gvanrossum) Summary: typeobject provides incorrect __mul__ Initial Comment: type __mul__ is wierd: >> 'a'.__mul__(3.4) 'aaa' >>> [1].__mul__(3.4) [1, 1, 1] Floating point numbers with fractions should not be accepted. I think the problem is that __mul__ should not be trying to implement sq_repeat behavior (although I haven't dug deeply into this problem yet). Also, I think the code is vulnerable to integer overflow. Should also check __imul__ __add__ __iadd__. ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2003-01-27 05:57 Message: Logged In: YES user_id=35752 Attached is a patch that signals a DepreciationWarning instead of rasing a TypeError. I used a static function to avoid duplication of code. My version of GCC inlines it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-01-26 21:58 Message: Logged In: YES user_id=45365 Neil, your mod to PyArg_Parse is far too aggressive. Apparently the integer formats have accepted floating point arguments since day one, and all weekend I'm running across places where floats are passed to integers. For example, the MacPython IDE does this all the time, and I wouldn't be surprised if there's lots of windowing code that does this (compute pixel positions in floating point and then passing them to something expecting an integer). If this is fixed in this way (disallowing floats where integers are expected) it should at least be done with a DeprecationWarning for one release cycle. I think the fix probably is a good idea in the long run, but it will break large bodies of code... ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-01-24 22:20 Message: Logged In: YES user_id=35752 I added the check for the other integer codes. All the tests pass so I checked it in. Hope that's okay. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-21 19:55 Message: Logged In: YES user_id=6380 Looks like a good patch. And yes, the other types should be doing this as well. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-01-19 19:35 Message: Logged In: YES user_id=35752 The small patch is attached. I only added the checking for 'i' and 'l'. I wonder if it should be done for the other integer codes as well (e.g. 'b', 'h'). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-17 00:19 Message: Logged In: YES user_id=6380 Yes, this should go into 2.3a2. Your attachment upload failed somehow. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-01-16 23:10 Message: Logged In: YES user_id=35752 Would this be a change for the 2.3 release? I tried adding a PyFloat_Check test to 'i' and 'l' in getargs.c. It looks like all the unit tests pass. I agree that checking for float catches the important cases. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-16 21:57 Message: Logged In: YES user_id=6380 This is an age-old problem that crops up whenever "i" and similar format codes are used. The problem is that on the one hand you want "i" to accept other int-ish types that have an __int__ method. But on the other hand you don't want it to accept float, which also has an __int__ method. Or other float-ish types. I think the "i" format code has to be fixe, but I'm not sure how -- maybe as a start it would be sufficient to test explicitly for float and its subclasses and reject those. That would still allow 3rd party float-ish classes that implement __int__, but that's not so important. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-01-16 21:33 Message: Logged In: YES user_id=35752 I think the problem is that wrap_intargfunc and wrap_intintargfunc use PyArg_ParseTuple(args, "i", &i). This bug also is present in methods like __getitem__: >>> "Python"[1.2] Traceback (most recent call last): File "", line 1, in ? TypeError: sequence index must be integer >>> "Python".__getitem__(1.2) 'y' I think the right fix is to use explictly only allow only ints and longs to wrap_intargfunc and friends. If Guido agrees I will cook up a patch. It seems like we should have a code for PyParse_Tuple that only allows ints and longs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660144&group_id=5470 From noreply@sourceforge.net Mon Jan 27 10:32:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 27 Jan 2003 02:32:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-675341 ] momory fault on exit Message-ID: Bugs item #675341, was opened at 2003-01-27 11:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675341&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Martin v. Löwis (loewis) Summary: momory fault on exit Initial Comment: Martin, I think this has to do with your changes to iconv_codec. After cvs update; configure; make, I get a seg fault on exit of the interpreter after doing nothing other than typing ctrl-D. This is on Linux (RedHat 8.0). + ./python Python 2.3a1 (#1, Jan 27 2003, 11:06:58) [GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> Memory fault However: + ./python -S Python 2.3a1 (#1, Jan 27 2003, 11:06:58) [GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> + Stack trace: (gdb) bt #0 0x0808606c in type_dealloc (type=0x4001d400) at ../Objects/typeobject.c:1998 #1 0x08073179 in dict_dealloc (mp=0x400f4a44) at ../Objects/dictobject.c:686 #2 0x08073179 in dict_dealloc (mp=0x4009a8ac) at ../Objects/dictobject.c:686 #3 0x080bcb1d in _PyImport_Fini () at ../Python/import.c:224 #4 0x080c57b4 in Py_Finalize () at ../Python/pythonrun.c:232 #5 0x08054b1d in Py_Main (argc=1, argv=0xbffff5e4) at ../Modules/main.c:457 #6 0x0805431a in main (argc=1, argv=0xbffff5e4) at ../Modules/python.c:23 #7 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 And the reason I think Martin has something to do with it (note the tp_name field): (gdb) p *type $2 = {ob_refcnt = 0, ob_type = 0x8104b20, ob_size = 0, tp_name = 0x4001cbf2 "iconvcodec", tp_basicsize = 20, tp_itemsize = 0, tp_dealloc = 0x4001c81e , tp_print = 0, tp_getattr = 0, tp_setattr = 0, tp_compare = 0, tp_repr = 0x4001c8ca , tp_as_number = 0x0, tp_as_sequence = 0x0, tp_as_mapping = 0x0, tp_hash = 0, tp_call = 0, tp_str = 0, tp_getattro = 0x807786a , tp_setattro = 0, tp_as_buffer = 0x0, tp_flags = 17899, tp_doc = 0x4001d020 "iconvcodec object", tp_traverse = 0, tp_clear = 0, tp_richcompare = 0, tp_weaklistoffset = 0, tp_iter = 0, tp_iternext = 0, tp_methods = 0x4001d3c0, tp_members = 0x0, tp_getset = 0x0, tp_base = 0x0, tp_dict = 0x0, tp_descr_get = 0, tp_descr_set = 0, tp_dictoffset = 0, tp_init = 0, tp_alloc = 0x80833e6 , tp_new = 0x4001c5c4 , tp_free = 0x80ccc0e , tp_is_gc = 0, tp_bases = 0x0, tp_mro = 0x0, tp_cache = 0x0, tp_subclasses = 0x0, tp_weaklist = 0x0, tp_del = 0} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675341&group_id=5470 From noreply@sourceforge.net Mon Jan 27 11:45:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 27 Jan 2003 03:45:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-675341 ] momory fault on exit Message-ID: Bugs item #675341, was opened at 2003-01-27 11:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675341&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Martin v. Löwis (loewis) Summary: momory fault on exit Initial Comment: Martin, I think this has to do with your changes to iconv_codec. After cvs update; configure; make, I get a seg fault on exit of the interpreter after doing nothing other than typing ctrl-D. This is on Linux (RedHat 8.0). + ./python Python 2.3a1 (#1, Jan 27 2003, 11:06:58) [GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> Memory fault However: + ./python -S Python 2.3a1 (#1, Jan 27 2003, 11:06:58) [GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> + Stack trace: (gdb) bt #0 0x0808606c in type_dealloc (type=0x4001d400) at ../Objects/typeobject.c:1998 #1 0x08073179 in dict_dealloc (mp=0x400f4a44) at ../Objects/dictobject.c:686 #2 0x08073179 in dict_dealloc (mp=0x4009a8ac) at ../Objects/dictobject.c:686 #3 0x080bcb1d in _PyImport_Fini () at ../Python/import.c:224 #4 0x080c57b4 in Py_Finalize () at ../Python/pythonrun.c:232 #5 0x08054b1d in Py_Main (argc=1, argv=0xbffff5e4) at ../Modules/main.c:457 #6 0x0805431a in main (argc=1, argv=0xbffff5e4) at ../Modules/python.c:23 #7 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 And the reason I think Martin has something to do with it (note the tp_name field): (gdb) p *type $2 = {ob_refcnt = 0, ob_type = 0x8104b20, ob_size = 0, tp_name = 0x4001cbf2 "iconvcodec", tp_basicsize = 20, tp_itemsize = 0, tp_dealloc = 0x4001c81e , tp_print = 0, tp_getattr = 0, tp_setattr = 0, tp_compare = 0, tp_repr = 0x4001c8ca , tp_as_number = 0x0, tp_as_sequence = 0x0, tp_as_mapping = 0x0, tp_hash = 0, tp_call = 0, tp_str = 0, tp_getattro = 0x807786a , tp_setattro = 0, tp_as_buffer = 0x0, tp_flags = 17899, tp_doc = 0x4001d020 "iconvcodec object", tp_traverse = 0, tp_clear = 0, tp_richcompare = 0, tp_weaklistoffset = 0, tp_iter = 0, tp_iternext = 0, tp_methods = 0x4001d3c0, tp_members = 0x0, tp_getset = 0x0, tp_base = 0x0, tp_dict = 0x0, tp_descr_get = 0, tp_descr_set = 0, tp_dictoffset = 0, tp_init = 0, tp_alloc = 0x80833e6 , tp_new = 0x4001c5c4 , tp_free = 0x80ccc0e , tp_is_gc = 0, tp_bases = 0x0, tp_mro = 0x0, tp_cache = 0x0, tp_subclasses = 0x0, tp_weaklist = 0x0, tp_del = 0} ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-01-27 12:45 Message: Logged In: YES user_id=21627 This is fixed in _iconv_codec.c 1.4. I'm surprised that it happens in this way for you, though, since normally, importing site.py won't import _iconv_codec. The only explanation is that you have changed site.py in some way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675341&group_id=5470 From noreply@sourceforge.net Mon Jan 27 12:18:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 27 Jan 2003 04:18:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-675341 ] momory fault on exit Message-ID: Bugs item #675341, was opened at 2003-01-27 11:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675341&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Martin v. Löwis (loewis) Summary: momory fault on exit Initial Comment: Martin, I think this has to do with your changes to iconv_codec. After cvs update; configure; make, I get a seg fault on exit of the interpreter after doing nothing other than typing ctrl-D. This is on Linux (RedHat 8.0). + ./python Python 2.3a1 (#1, Jan 27 2003, 11:06:58) [GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> Memory fault However: + ./python -S Python 2.3a1 (#1, Jan 27 2003, 11:06:58) [GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> + Stack trace: (gdb) bt #0 0x0808606c in type_dealloc (type=0x4001d400) at ../Objects/typeobject.c:1998 #1 0x08073179 in dict_dealloc (mp=0x400f4a44) at ../Objects/dictobject.c:686 #2 0x08073179 in dict_dealloc (mp=0x4009a8ac) at ../Objects/dictobject.c:686 #3 0x080bcb1d in _PyImport_Fini () at ../Python/import.c:224 #4 0x080c57b4 in Py_Finalize () at ../Python/pythonrun.c:232 #5 0x08054b1d in Py_Main (argc=1, argv=0xbffff5e4) at ../Modules/main.c:457 #6 0x0805431a in main (argc=1, argv=0xbffff5e4) at ../Modules/python.c:23 #7 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 And the reason I think Martin has something to do with it (note the tp_name field): (gdb) p *type $2 = {ob_refcnt = 0, ob_type = 0x8104b20, ob_size = 0, tp_name = 0x4001cbf2 "iconvcodec", tp_basicsize = 20, tp_itemsize = 0, tp_dealloc = 0x4001c81e , tp_print = 0, tp_getattr = 0, tp_setattr = 0, tp_compare = 0, tp_repr = 0x4001c8ca , tp_as_number = 0x0, tp_as_sequence = 0x0, tp_as_mapping = 0x0, tp_hash = 0, tp_call = 0, tp_str = 0, tp_getattro = 0x807786a , tp_setattro = 0, tp_as_buffer = 0x0, tp_flags = 17899, tp_doc = 0x4001d020 "iconvcodec object", tp_traverse = 0, tp_clear = 0, tp_richcompare = 0, tp_weaklistoffset = 0, tp_iter = 0, tp_iternext = 0, tp_methods = 0x4001d3c0, tp_members = 0x0, tp_getset = 0x0, tp_base = 0x0, tp_dict = 0x0, tp_descr_get = 0, tp_descr_set = 0, tp_dictoffset = 0, tp_init = 0, tp_alloc = 0x80833e6 , tp_new = 0x4001c5c4 , tp_free = 0x80ccc0e , tp_is_gc = 0, tp_bases = 0x0, tp_mro = 0x0, tp_cache = 0x0, tp_subclasses = 0x0, tp_weaklist = 0x0, tp_del = 0} ---------------------------------------------------------------------- >Comment By: Sjoerd Mullender (sjoerd) Date: 2003-01-27 13:18 Message: Logged In: YES user_id=43607 The reason _iconv_codec got imported is because I have JapanesCodecs installed which is imported by addpackage in site.py. And JapaneseCodecs imports encodings which in turn imports iconv_codecs. Things work now thanks to your fix. Thanks. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-27 12:45 Message: Logged In: YES user_id=21627 This is fixed in _iconv_codec.c 1.4. I'm surprised that it happens in this way for you, though, since normally, importing site.py won't import _iconv_codec. The only explanation is that you have changed site.py in some way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675341&group_id=5470 From noreply@sourceforge.net Mon Jan 27 12:24:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 27 Jan 2003 04:24:02 -0800 Subject: [Python-bugs-list] [ python-Bugs-665835 ] filter() treatment of str and tuple inconsistent Message-ID: Bugs item #665835, was opened at 2003-01-10 17:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665835&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Walter Dörwald (doerwalter) Assigned to: Guido van Rossum (gvanrossum) Summary: filter() treatment of str and tuple inconsistent Initial Comment: class tuple2(tuple): · def __getitem__(self, index): · · return 2*tuple.__getitem__(self, index) class str2(str): · def __getitem__(self, index): · · return chr(ord(str.__getitem__(self, index))+1) print filter(lambda x: x>1, tuple2((1, 2))) print filter(lambda x: x>"a", str2("ab")) this prints: (2,) bc i.e. the overwritten __getitem__ is ignored in the first case, but honored in the second. ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-01-27 13:24 Message: Logged In: YES user_id=89016 Another problem with filter() is that filterstring() (and the new filterunicode()) blindly assume that tp_as_sequence->sq_item returns a str or unicode object with len==1. This might fail with str or unicode subclasses: ---- class badstr(str): def __getitem__(self, index): return 42 s = filter(lambda x: x>=42, badstr("1234")) print len(s), repr(s) ---- This prints 4 '\x00\x00\x00\x00' ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-27 02:13 Message: Logged In: YES user_id=80475 One other thought: A major reason for implementing __iter__ in the first place is that objects were overriding __getitem__ and disregarding the index -- the __getitem__ interface just didn't make sense for iteration in some situations. __iter__ was supposed to provide enormous flexibility in various ways to loop over a collection (inorder, preorder, postorder, priorityorder, sortedorder, hashorder, randomorder, etc). Making iter() default to using __getitem__ was only supposed to be an expedient for backwards compatability. Always using __getitem__ diminishes the flexibility and speed advantages. Maybe the discussion belongs on python-dev. I'm sure a number of people feel strongly one way or the other. The question might as well be addressed head-on before 2.3 goes out the door. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-27 01:54 Message: Logged In: YES user_id=80475 I understand. Ideally, *all* methods would respond to a single overridden method, but I think this is just a fact of life in object oriented programming. I can't remember where you gave an example of a d.__getitem__() subclass override, but you were careful to point out that other methods, like d.get() also needed to be overridden so that the modified access applied everywhere. Likewise, __iter__() or any other object access method must be assumed to access the underlying data structure directly and must be overridden. For instance, creating a dictionary with case insensitive lookups entails overriding __getitem__(k), get(k,default), and pop(k) -- no one of them can be presumed to inform the others. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-27 01:17 Message: Logged In: YES user_id=6380 Hm... that means that iter() of *amy* built-in type subclass overriding __getitem__ bypasses the override, unless the subclass also overrides __iter__. This sounds like a step in the wrong direction. I think the built-in iterators should be aware of subclasses overriding __getitem__ one way or another. I hadn't realized this when we started the trend of creating faster iterators for built-in types. :-( ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-25 17:45 Message: Logged In: YES user_id=80475 None of the existing iterators (incl dicts, lists, tuples, and files) use __getitem__. Most likely, user defined iterators also access the data structure directly (for flexiblity and speed). Also, anything that uses PyTuple_GET_ITEM bypasses __getitem__. If string/unicode iterators are added, they should also go directly to the underlying data; otherwise, there is no point to it. Also, the proposal to change filtertuple(), doesn't solve inconsistencies within filterstring() which uses __getitem__ when there is a function call, but bypasses it when the function parameter is Py_None. I think the right answer is to change filterstring() to use an iterator and to implement string/unicode iterators that access the data directly (not using __getitem__). FYI for Tim: MvL noticed and fixed the unicode vs string difference. His patch, SF #636005, has not been applied yet. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-25 14:51 Message: Logged In: YES user_id=6380 (But in addition th that, I don't mind having a custom string iterator -- as long as it calls __getitem__ properly. Hm, shouldn't the tuple iterator call __getitem__ properly too?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-25 14:45 Message: Logged In: YES user_id=31435 Just noting that filter() is unique in special-casing the type of the input. It's always been surprising that way, and, e.g., filtering a string produces a string, but filtering a Unicode string produces a list. map() and reduce() don't play games like that, and always use the iteration protocol to march over their inputs. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-25 14:36 Message: Logged In: YES user_id=6380 I don't know which Python sources Raymond has been reading, but in the sources I've got in front of me, there are special cases for strings and tuples, and these *don't* use iter(). It so happens that the tuple special-case calls PyTuple_GetItem(), which doesn't call your __getitem__, while the string special-case calls the sq_item slot function, which (in your case) will be a wrapper that calls your __getitem__. A minimal fix would be to only call filtertuple for strict tuples -- although this changes the output type, but I don't think one should count on filter() of a tuple subclass returning a tuple (and it can't be made to return an instance of the subclass either -- we don't know the constructor signature). Similar fixes probably need to be made to map() and maybe reduce(). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-25 04:47 Message: Logged In: YES user_id=80475 The problem isn't with filter() which correctly calls iter() in both cases. Tuple object have their own iterator which loops over elements directly and has no intervening calls to __getitem__(). String objects do not define a custom iterator, so iter() wraps itself around consecutive calls to __getitem__(). The resolution is to provide string objects with their own iterator. As a side benefit, iteration will run just a tiny bit faster. The same applies to unicode objects. Guido, do you care about this and want me to fix it or would you like to close it as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665835&group_id=5470 From noreply@sourceforge.net Mon Jan 27 13:40:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 27 Jan 2003 05:40:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-675420 ] email.Header() encoding does not work properly Message-ID: Bugs item #675420, was opened at 2003-01-27 08:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675420&group_id=5470 Category: Extension Modules Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: email.Header() encoding does not work properly Initial Comment: CMFCollectorNG uses email.Header() to encode the Subject of notification emails. In some case we discovered that Evolution and Mutt displayed an empty subject. The Subject "[CMFCollectorNG] #31 (Comment): noch: ein test" is converted to Subject: =?iso-8859-1?q?=5BCMFCollectorNG=5D_=2331_=28Comment=29=3A_ein=3A_test?= The problem seems to occur if there is more than one colon inside the subject. Mailings with "[CMFCollectorNG] #31 (Comment): noch ein test" as subject are recognized by the mail readers and being displayed. Upgrading to the latest email packages from the Python HEAD did not solve the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675420&group_id=5470 From noreply@sourceforge.net Mon Jan 27 14:05:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 27 Jan 2003 06:05:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-675420 ] email.Header() encoding does not work properly Message-ID: Bugs item #675420, was opened at 2003-01-27 08:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675420&group_id=5470 >Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Header() encoding does not work properly Initial Comment: CMFCollectorNG uses email.Header() to encode the Subject of notification emails. In some case we discovered that Evolution and Mutt displayed an empty subject. The Subject "[CMFCollectorNG] #31 (Comment): noch: ein test" is converted to Subject: =?iso-8859-1?q?=5BCMFCollectorNG=5D_=2331_=28Comment=29=3A_ein=3A_test?= The problem seems to occur if there is more than one colon inside the subject. Mailings with "[CMFCollectorNG] #31 (Comment): noch ein test" as subject are recognized by the mail readers and being displayed. Upgrading to the latest email packages from the Python HEAD did not solve the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675420&group_id=5470 From noreply@sourceforge.net Mon Jan 27 14:34:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 27 Jan 2003 06:34:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-674987 ] seg fault on exit in import module Message-ID: Bugs item #674987, was opened at 2003-01-26 17:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674987&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Just van Rossum (jvr) Summary: seg fault on exit in import module Initial Comment: Just, I'm guessing this has to do with the import modifications you made, although I really don't know. I just started getting a crash which originates in _PyImport_Fini(). When I run: ./python -E -tt ./Lib/test/regrtest.py test_logging I get a core dump. Here's the stack trace from a debug build. The same problem occurs in a normal (non-debug) build. (gdb) bt #0 0x08080e09 in _Py_ForgetReference (op=0x407887c0) at Objects/object.c:1949 #1 0x08080e79 in _Py_Dealloc (op=0x407887c0) at Objects/object.c:1970 #2 0x08079e7e in dict_dealloc (mp=0x4026b214) at Objects/dictobject.c:690 #3 0x08080e87 in _Py_Dealloc (op=0x4026b214) at Objects/object.c:1971 #4 0x08079e7e in dict_dealloc (mp=0x401bea34) at Objects/dictobject.c:690 #5 0x08080e87 in _Py_Dealloc (op=0x401bea34) at Objects/object.c:1971 #6 0x080d5d66 in _PyImport_Fini () at Python/import.c:224 #7 0x080dff7a in Py_Finalize () at Python/pythonrun.c:233 #8 0x08055146 in Py_Main (argc=4, argv=0xbffff814) at Modules/main.c:465 #9 0x08054884 in main (argc=4, argv=0xbffff814) at Modules/python.c:23 Any ideas? ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-01-27 15:34 Message: Logged In: YES user_id=45365 Could this be a duplicate of #675341? You can check this by updating: Martin just fixed that bug, which was in a new unicode codec. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-26 22:08 Message: Logged In: YES user_id=92689 Hm, I wish I could reproduce this on my OSX box, but I can't: the loggin test passes just fine. I also doubt it has to do with my mods, as _PyImport_Fini doesn't touch anything that has anything to do with import hooks directly. Of course it's still not impossible I caused this, but right now I don't see how it could. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674987&group_id=5470 From noreply@sourceforge.net Mon Jan 27 15:31:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 27 Jan 2003 07:31:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-674987 ] seg fault on exit in import module Message-ID: Bugs item #674987, was opened at 2003-01-26 11:25 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674987&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Just van Rossum (jvr) Summary: seg fault on exit in import module Initial Comment: Just, I'm guessing this has to do with the import modifications you made, although I really don't know. I just started getting a crash which originates in _PyImport_Fini(). When I run: ./python -E -tt ./Lib/test/regrtest.py test_logging I get a core dump. Here's the stack trace from a debug build. The same problem occurs in a normal (non-debug) build. (gdb) bt #0 0x08080e09 in _Py_ForgetReference (op=0x407887c0) at Objects/object.c:1949 #1 0x08080e79 in _Py_Dealloc (op=0x407887c0) at Objects/object.c:1970 #2 0x08079e7e in dict_dealloc (mp=0x4026b214) at Objects/dictobject.c:690 #3 0x08080e87 in _Py_Dealloc (op=0x4026b214) at Objects/object.c:1971 #4 0x08079e7e in dict_dealloc (mp=0x401bea34) at Objects/dictobject.c:690 #5 0x08080e87 in _Py_Dealloc (op=0x401bea34) at Objects/object.c:1971 #6 0x080d5d66 in _PyImport_Fini () at Python/import.c:224 #7 0x080dff7a in Py_Finalize () at Python/pythonrun.c:233 #8 0x08055146 in Py_Main (argc=4, argv=0xbffff814) at Modules/main.c:465 #9 0x08054884 in main (argc=4, argv=0xbffff814) at Modules/python.c:23 Any ideas? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-27 10:31 Message: Logged In: YES user_id=33168 This works now, so I'm closing. Since the problem occurred after iconv, it was most likely related to that and Martin fixed it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-01-27 09:34 Message: Logged In: YES user_id=45365 Could this be a duplicate of #675341? You can check this by updating: Martin just fixed that bug, which was in a new unicode codec. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-26 16:08 Message: Logged In: YES user_id=92689 Hm, I wish I could reproduce this on my OSX box, but I can't: the loggin test passes just fine. I also doubt it has to do with my mods, as _PyImport_Fini doesn't touch anything that has anything to do with import hooks directly. Of course it's still not impossible I caused this, but right now I don't see how it could. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674987&group_id=5470 From noreply@sourceforge.net Mon Jan 27 16:54:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 27 Jan 2003 08:54:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-675552 ] settimeout with httplib and SSL is broken Message-ID: Bugs item #675552, was opened at 2003-01-27 11:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675552&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Geoff Talvola (gtalvola) Assigned to: Nobody/Anonymous (nobody) Summary: settimeout with httplib and SSL is broken Initial Comment: This is with Python 2.3a1 on Windows NT. Assume that Pause30.cgi is a CGI script that just waits 30 seconds and then returns a simple response. This code works fine: import httplib conn = httplib.HTTPConnection('ncsdevtest.nameconnector.com', 80) conn.connect() conn.sock.settimeout(TIMEOUT) conn.request('GET', '/cgi-bin/Pause30.cgi') response = conn.getresponse() print response.status, response.reason data = response.read() print 'read', len(data), 'bytes' conn.close() If TIMEOUT is less than 30 seconds, I get a timeout, otherwise I get the response as expected. This is all good. If I change HTTPConnection to HTTPSConnection and 80 to 443, I have trouble -- my CPU usage goes up to 100%, the python process sucks up more and more memory, and it doesn't time out even if TIMEOUT is less than 30. (This might be related to bug 673797.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675552&group_id=5470 From noreply@sourceforge.net Mon Jan 27 19:20:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 27 Jan 2003 11:20:13 -0800 Subject: [Python-bugs-list] [ python-Bugs-675671 ] PyImport_ImportModule fails in subthread/subinterpreter Message-ID: Bugs item #675671, was opened at 2003-01-27 11:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675671&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dave Kuhlman (dkuhlman) Assigned to: Nobody/Anonymous (nobody) Summary: PyImport_ImportModule fails in subthread/subinterpreter Initial Comment: PyImport_ImportModule() fails when called after a new sub-interpreter has been created. The property "meta_path" is missing from the sys module, causing PyImport_ImportModule() to fail (down in Python/import.c). You can reproduce this error by running the importexc demo in the Demo/embed directory. And the attached file is a modified version of Demo/embed/importexc that prints out the contents of the sys module (dir(sys)) twice. "meta_path" is missing after the call to Py_NewInterpreter(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675671&group_id=5470 From noreply@sourceforge.net Mon Jan 27 19:53:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 27 Jan 2003 11:53:03 -0800 Subject: [Python-bugs-list] [ python-Bugs-675671 ] PyImport_ImportModule fails in subthread/subinterpreter Message-ID: Bugs item #675671, was opened at 2003-01-27 14:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675671&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dave Kuhlman (dkuhlman) >Assigned to: Neal Norwitz (nnorwitz) Summary: PyImport_ImportModule fails in subthread/subinterpreter Initial Comment: PyImport_ImportModule() fails when called after a new sub-interpreter has been created. The property "meta_path" is missing from the sys module, causing PyImport_ImportModule() to fail (down in Python/import.c). You can reproduce this error by running the importexc demo in the Demo/embed directory. And the attached file is a modified version of Demo/embed/importexc that prints out the contents of the sys module (dir(sys)) twice. "meta_path" is missing after the call to Py_NewInterpreter(). ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-27 14:53 Message: Logged In: YES user_id=33168 I believe this was fixed with patch #671459 Python/pythonrun.c 2.175. I no longer see the behavior described. If you have the problem with current CVS or 2.3a2 when it's released, please re-open. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675671&group_id=5470 From noreply@sourceforge.net Mon Jan 27 21:40:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 27 Jan 2003 13:40:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-675745 ] unix link to framework python Message-ID: Bugs item #675745, was opened at 2003-01-27 13:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675745&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Jack Jansen (jackjansen) Summary: unix link to framework python Initial Comment: Jack asked me to submit this: In the 2.3 framework build /usr/local/bin/python is linked to the python inside the framework. I think it would be better if the link was "python2.3" and then there could be a separate link from "python" to "python2.3" as well. This would allow command line (or #!) users to specify either "python2.2" or "python2.3" to get the one they want. I expect that it would also allow installation of the unix links/scripts into /usr/bin... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675745&group_id=5470 From noreply@sourceforge.net Mon Jan 27 21:56:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 27 Jan 2003 13:56:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-675552 ] settimeout with httplib and SSL is broken Message-ID: Bugs item #675552, was opened at 2003-01-27 11:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675552&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Geoff Talvola (gtalvola) Assigned to: Nobody/Anonymous (nobody) Summary: settimeout with httplib and SSL is broken Initial Comment: This is with Python 2.3a1 on Windows NT. Assume that Pause30.cgi is a CGI script that just waits 30 seconds and then returns a simple response. This code works fine: import httplib conn = httplib.HTTPConnection('ncsdevtest.nameconnector.com', 80) conn.connect() conn.sock.settimeout(TIMEOUT) conn.request('GET', '/cgi-bin/Pause30.cgi') response = conn.getresponse() print response.status, response.reason data = response.read() print 'read', len(data), 'bytes' conn.close() If TIMEOUT is less than 30 seconds, I get a timeout, otherwise I get the response as expected. This is all good. If I change HTTPConnection to HTTPSConnection and 80 to 443, I have trouble -- my CPU usage goes up to 100%, the python process sucks up more and more memory, and it doesn't time out even if TIMEOUT is less than 30. (This might be related to bug 673797.) ---------------------------------------------------------------------- >Comment By: Geoff Talvola (gtalvola) Date: 2003-01-27 16:56 Message: Logged In: YES user_id=88162 I've uploaded patch 675750 which seems to do the trick. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675552&group_id=5470 From noreply@sourceforge.net Mon Jan 27 21:57:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 27 Jan 2003 13:57:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-675552 ] settimeout with httplib and SSL is broken Message-ID: Bugs item #675552, was opened at 2003-01-27 11:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675552&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Geoff Talvola (gtalvola) >Assigned to: Guido van Rossum (gvanrossum) Summary: settimeout with httplib and SSL is broken Initial Comment: This is with Python 2.3a1 on Windows NT. Assume that Pause30.cgi is a CGI script that just waits 30 seconds and then returns a simple response. This code works fine: import httplib conn = httplib.HTTPConnection('ncsdevtest.nameconnector.com', 80) conn.connect() conn.sock.settimeout(TIMEOUT) conn.request('GET', '/cgi-bin/Pause30.cgi') response = conn.getresponse() print response.status, response.reason data = response.read() print 'read', len(data), 'bytes' conn.close() If TIMEOUT is less than 30 seconds, I get a timeout, otherwise I get the response as expected. This is all good. If I change HTTPConnection to HTTPSConnection and 80 to 443, I have trouble -- my CPU usage goes up to 100%, the python process sucks up more and more memory, and it doesn't time out even if TIMEOUT is less than 30. (This might be related to bug 673797.) ---------------------------------------------------------------------- Comment By: Geoff Talvola (gtalvola) Date: 2003-01-27 16:56 Message: Logged In: YES user_id=88162 I've uploaded patch 675750 which seems to do the trick. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675552&group_id=5470 From noreply@sourceforge.net Mon Jan 27 22:25:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 27 Jan 2003 14:25:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-675552 ] settimeout with httplib and SSL is broken Message-ID: Bugs item #675552, was opened at 2003-01-27 11:54 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675552&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Geoff Talvola (gtalvola) Assigned to: Guido van Rossum (gvanrossum) Summary: settimeout with httplib and SSL is broken Initial Comment: This is with Python 2.3a1 on Windows NT. Assume that Pause30.cgi is a CGI script that just waits 30 seconds and then returns a simple response. This code works fine: import httplib conn = httplib.HTTPConnection('ncsdevtest.nameconnector.com', 80) conn.connect() conn.sock.settimeout(TIMEOUT) conn.request('GET', '/cgi-bin/Pause30.cgi') response = conn.getresponse() print response.status, response.reason data = response.read() print 'read', len(data), 'bytes' conn.close() If TIMEOUT is less than 30 seconds, I get a timeout, otherwise I get the response as expected. This is all good. If I change HTTPConnection to HTTPSConnection and 80 to 443, I have trouble -- my CPU usage goes up to 100%, the python process sucks up more and more memory, and it doesn't time out even if TIMEOUT is less than 30. (This might be related to bug 673797.) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-27 17:25 Message: Logged In: YES user_id=6380 Thanks, your fix is checked in now. ---------------------------------------------------------------------- Comment By: Geoff Talvola (gtalvola) Date: 2003-01-27 16:56 Message: Logged In: YES user_id=88162 I've uploaded patch 675750 which seems to do the trick. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675552&group_id=5470 From noreply@sourceforge.net Tue Jan 28 02:00:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 27 Jan 2003 18:00:38 -0800 Subject: [Python-bugs-list] [ python-Bugs-675864 ] patch for new func. string.findall Message-ID: Bugs item #675864, was opened at 2003-01-27 21:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675864&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hunter Peress (hfastedge) Assigned to: Nobody/Anonymous (nobody) Summary: patch for new func. string.findall Initial Comment: this finds all indices of a substring in a string returning in list form. Its not in pydoc2.3. This "patch" contains unittests. #!/usr/bin/python import string def findall(sub,s): if s =='' or sub =='': return [] ret=[] findval=0 pos=0 while findval != -1: findval = s.find(sub,pos) if findval != -1: ret.append(findval) pos = findval + len(sub) return ret if __name__ == '__main__': units = [ 'asdsad','l', 'l','asdlsds', 'l','lsdlsds', 'l','lsdsds', 'l','sdsds', 'l','sdsdsl', 'l','lsdsdsl', 'l','lsdlsdsl', 'l','l', 'l','ll', 'l','lll', 'lo','llollol', 'lo','llollolo', '','', '','asdasd', 'asdsad','' ] for i in range(0,len(units),2): sub,s = units[i],units[i+1] print "'%s' in '%s':"%(sub,s) print findall(sub,s) print "-"*30 print 'done' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675864&group_id=5470 From noreply@sourceforge.net Tue Jan 28 02:01:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 27 Jan 2003 18:01:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-675864 ] patch for new func. string.findall Message-ID: Bugs item #675864, was opened at 2003-01-27 21:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675864&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hunter Peress (hfastedge) Assigned to: Nobody/Anonymous (nobody) Summary: patch for new func. string.findall Initial Comment: this finds all indices of a substring in a string returning in list form. Its not in pydoc2.3. This "patch" contains unittests. #!/usr/bin/python import string def findall(sub,s): if s =='' or sub =='': return [] ret=[] findval=0 pos=0 while findval != -1: findval = s.find(sub,pos) if findval != -1: ret.append(findval) pos = findval + len(sub) return ret if __name__ == '__main__': units = [ 'asdsad','l', 'l','asdlsds', 'l','lsdlsds', 'l','lsdsds', 'l','sdsds', 'l','sdsdsl', 'l','lsdsdsl', 'l','lsdlsdsl', 'l','l', 'l','ll', 'l','lll', 'lo','llollol', 'lo','llollolo', '','', '','asdasd', 'asdsad','' ] for i in range(0,len(units),2): sub,s = units[i],units[i+1] print "'%s' in '%s':"%(sub,s) print findall(sub,s) print "-"*30 print 'done' ---------------------------------------------------------------------- >Comment By: Hunter Peress (hfastedge) Date: 2003-01-27 21:01 Message: Logged In: YES user_id=479934 This might be done as an iterator as well, as re.findall also is complemented by an re.finditer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675864&group_id=5470 From noreply@sourceforge.net Tue Jan 28 06:06:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 27 Jan 2003 22:06:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-675928 ] Have exception arguments keep their type Message-ID: Bugs item #675928, was opened at 2003-01-27 22:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675928&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Have exception arguments keep their type Initial Comment: If you execute the following code:: try: raise Exception('a string') except Exception, err: print type(err) it prints out that ``err`` is a type 'instance'. It would be nice if it returned the type of the actual argument (in this case, type 'str'). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675928&group_id=5470 From noreply@sourceforge.net Tue Jan 28 09:21:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 01:21:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-610556 ] mhlib does not obey MHCONTEXT env var Message-ID: Bugs item #610556, was opened at 2002-09-17 15:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=610556&group_id=5470 Category: Python Library Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Nobody/Anonymous (nobody) Summary: mhlib does not obey MHCONTEXT env var Initial Comment: All programs in the (N)MH suite of programs use the MHCONTEXT environment variable to find the so-called context file where the current folder is remembered. mhlib should do the same, so that it can be used in combination with the standard (N)MH programs. Also, when writing the context file, mhlib should replace the Current-Folder line but keep the other lines in tact. The attached patch fixes both problems. It introduces a new method for the class MH called getcontextfile which uses the MHCONTEXT environment variable to find the context file, and it uses the already existing function updateline to update the context file. Some questions concerning this patch: - should I document the new method or should it be an internal method only? - should the fix be ported to older Python versions? With the patch it does behave differently if you have an MHCONTEXT environment variable. ---------------------------------------------------------------------- >Comment By: Sjoerd Mullender (sjoerd) Date: 2003-01-28 10:21 Message: Logged In: YES user_id=43607 Created patch 675976 to be duplicate of this item since it contains a patch. By the way, how is it possible for a bug to stay unnoticed for 4 months? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=610556&group_id=5470 From noreply@sourceforge.net Tue Jan 28 13:32:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 05:32:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-676072 ] rfc822.Message() doesn't support __contains__() (+patch) Message-ID: Bugs item #676072, was opened at 2003-01-28 14:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676072&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michal Vitecek (fufsource) Assigned to: Nobody/Anonymous (nobody) Summary: rfc822.Message() doesn't support __contains__() (+patch) Initial Comment: class rfc822.Message() should behave like a dictionary but it doesn't define method __contains__() so it's not possible to use form: 'header' in messageInstance attached is a simple patch that fixes this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676072&group_id=5470 From noreply@sourceforge.net Tue Jan 28 13:41:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 05:41:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-676072 ] rfc822.Message() doesn't support __contains__() (+patch) Message-ID: Bugs item #676072, was opened at 2003-01-28 13:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676072&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michal Vitecek (fufsource) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: rfc822.Message() doesn't support __contains__() (+patch) Initial Comment: class rfc822.Message() should behave like a dictionary but it doesn't define method __contains__() so it's not possible to use form: 'header' in messageInstance attached is a simple patch that fixes this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676072&group_id=5470 From noreply@sourceforge.net Tue Jan 28 13:42:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 05:42:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-610556 ] mhlib does not obey MHCONTEXT env var Message-ID: Bugs item #610556, was opened at 2002-09-17 14:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=610556&group_id=5470 Category: Python Library Group: None Status: Closed Resolution: None Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Nobody/Anonymous (nobody) Summary: mhlib does not obey MHCONTEXT env var Initial Comment: All programs in the (N)MH suite of programs use the MHCONTEXT environment variable to find the so-called context file where the current folder is remembered. mhlib should do the same, so that it can be used in combination with the standard (N)MH programs. Also, when writing the context file, mhlib should replace the Current-Folder line but keep the other lines in tact. The attached patch fixes both problems. It introduces a new method for the class MH called getcontextfile which uses the MHCONTEXT environment variable to find the context file, and it uses the already existing function updateline to update the context file. Some questions concerning this patch: - should I document the new method or should it be an internal method only? - should the fix be ported to older Python versions? With the patch it does behave differently if you have an MHCONTEXT environment variable. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-01-28 13:42 Message: Logged In: YES user_id=6656 > how is it possible for a bug to stay unnoticed > for 4 months? You're a developer on this project too: how many bug reports have you triaged in the last four months? I'm also guessing none of the other developers use mhlib (I certainly don't). ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2003-01-28 09:21 Message: Logged In: YES user_id=43607 Created patch 675976 to be duplicate of this item since it contains a patch. By the way, how is it possible for a bug to stay unnoticed for 4 months? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=610556&group_id=5470 From noreply@sourceforge.net Tue Jan 28 15:52:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 07:52:46 -0800 Subject: [Python-bugs-list] [ python-Bugs-675928 ] Have exception arguments keep their type Message-ID: Bugs item #675928, was opened at 2003-01-28 01:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675928&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Have exception arguments keep their type Initial Comment: If you execute the following code:: try: raise Exception('a string') except Exception, err: print type(err) it prints out that ``err`` is a type 'instance'. It would be nice if it returned the type of the actual argument (in this case, type 'str'). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-28 10:52 Message: Logged In: YES user_id=31435 I'm a bit baffled by this, Brett: when you instantiate a class, you can pass any number of arguments to its constructor. You happened to pass a single string argument when building an instance of Exception here, but you could have passed any number of arguments. Why should the first argument be special? (Or maybe you think the last argument should be special ). Or what if you didn't pass any arguments at all? Having "the detail" bound to the instance object raised is a feature, and a major one. If you're in the habit of passing a single string to Exception directly, note that you can already get it back via doing str(err) in the "except" clause. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675928&group_id=5470 From noreply@sourceforge.net Tue Jan 28 15:55:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 07:55:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-676155 ] RuntimeWarning with tp_compare Message-ID: Bugs item #676155, was opened at 2003-01-28 08:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676155&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Nobody/Anonymous (nobody) Summary: RuntimeWarning with tp_compare Initial Comment: >From the latest CVS, as of the morning of Jan. 28 2003 >>> s = "12345" * 1000 >>> float(s) == int(s) __main__:1: RuntimeWarning: tp_compare didn't return -1 or -2 for exception Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to float >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676155&group_id=5470 From noreply@sourceforge.net Tue Jan 28 17:15:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 09:15:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-676155 ] RuntimeWarning with tp_compare Message-ID: Bugs item #676155, was opened at 2003-01-28 15:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676155&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Nobody/Anonymous (nobody) Summary: RuntimeWarning with tp_compare Initial Comment: >From the latest CVS, as of the morning of Jan. 28 2003 >>> s = "12345" * 1000 >>> float(s) == int(s) __main__:1: RuntimeWarning: tp_compare didn't return -1 or -2 for exception Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to float >>> ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-01-28 17:15 Message: Logged In: YES user_id=6656 Hmm, wierd. I think there may be a case of something setting an exception and then not returning NULL (or whatever). You can certainly get some wierd tracebacks. Buggered if I know where though -- "you are in a maze of twisty function calls, all alike" :-/ Some playing with a debug build and gdb coming up... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676155&group_id=5470 From noreply@sourceforge.net Tue Jan 28 17:23:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 09:23:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-676155 ] RuntimeWarning with tp_compare Message-ID: Bugs item #676155, was opened at 2003-01-28 10:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676155&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Nobody/Anonymous (nobody) Summary: RuntimeWarning with tp_compare Initial Comment: >From the latest CVS, as of the morning of Jan. 28 2003 >>> s = "12345" * 1000 >>> float(s) == int(s) __main__:1: RuntimeWarning: tp_compare didn't return -1 or -2 for exception Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to float >>> ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 12:23 Message: Logged In: YES user_id=33168 I thought I fixed the problem in one place (patch attached). That fixes this problem: coerce(0.5, int(s)) With this patch, I get: XXX undetected error (why=3) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-28 12:15 Message: Logged In: YES user_id=6656 Hmm, wierd. I think there may be a case of something setting an exception and then not returning NULL (or whatever). You can certainly get some wierd tracebacks. Buggered if I know where though -- "you are in a maze of twisty function calls, all alike" :-/ Some playing with a debug build and gdb coming up... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676155&group_id=5470 From noreply@sourceforge.net Tue Jan 28 17:33:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 09:33:35 -0800 Subject: [Python-bugs-list] [ python-Bugs-676155 ] RuntimeWarning with tp_compare Message-ID: Bugs item #676155, was opened at 2003-01-28 15:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676155&group_id=5470 Category: None Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Andrew Dalke (dalke) >Assigned to: Neal Norwitz (nnorwitz) Summary: RuntimeWarning with tp_compare Initial Comment: >From the latest CVS, as of the morning of Jan. 28 2003 >>> s = "12345" * 1000 >>> float(s) == int(s) __main__:1: RuntimeWarning: tp_compare didn't return -1 or -2 for exception Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to float >>> ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-01-28 17:33 Message: Logged In: YES user_id=6656 That looks like the fix to me. Presumably you meant "*without* this patch I get..."? I suggest you check it in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 17:23 Message: Logged In: YES user_id=33168 I thought I fixed the problem in one place (patch attached). That fixes this problem: coerce(0.5, int(s)) With this patch, I get: XXX undetected error (why=3) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-28 17:15 Message: Logged In: YES user_id=6656 Hmm, wierd. I think there may be a case of something setting an exception and then not returning NULL (or whatever). You can certainly get some wierd tracebacks. Buggered if I know where though -- "you are in a maze of twisty function calls, all alike" :-/ Some playing with a debug build and gdb coming up... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676155&group_id=5470 From noreply@sourceforge.net Tue Jan 28 17:39:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 09:39:10 -0800 Subject: [Python-bugs-list] [ python-Bugs-534108 ] AIX 3.2.5 Has No chroot/fsync Prototypes Message-ID: Bugs item #534108, was opened at 2002-03-23 20:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=534108&group_id=5470 Category: Build Group: Python 2.2.1 candidate >Status: Closed Resolution: None Priority: 5 Submitted By: Ralph Corderoy (ralph) Assigned to: Michael Hudson (mwh) Summary: AIX 3.2.5 Has No chroot/fsync Prototypes Initial Comment: `make' fails for Python-2.2.1c1 under AIX 3.2.5 due to lack of prototypes for chroot and fsync in Modules/posixmodule.c. configure.in uses AC_CHECK_FUNCS to check these two can be linked into an executable, and configure correctly determines they can. $ egrep 'chroot|fsync' config.cache ac_cv_func_chroot=${ac_cv_func_chroot='yes'} ac_cv_func_fsync=${ac_cv_func_fsync='yes'} However, AC_CHECK_FUNCS essentially compiles and links #include "confdefs.h" #include char chroot(); int main() { chroot(); ; return 0; } which under AIX 3.2.5 works fine. But chroot isn't prototyped in *any* system include file, nor is fsync. Consequently, Modules/posixmodule.c has problems when it attempts to use both chroot and fsync as an rvalue for a pointer to a function. return posix_1str(args, "et:chroot", chroot); return posix_int(args, "i:fsync", fsync); Both lines cause `Undeclared identifier' errors. The solution is to conditionally add prototypes for these two functions. Modules/posixmodule.c has an icky set of conditional prototypes at the start but they rely heavily on __IBMC__, __sun__, etc, preprocessor symbols. These could be expanded to cover AIX 3.2.5's case but it may be better to use autoconf's AC_CHECK_DECLS macro, http://www.gnu.org/manual/autoconf/html_chapter/autoconf_5.html#SEC52. By manually adding two prototypes at the start of the source file I've confirmed the source file builds successfully. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-17 16:51 Message: Logged In: YES user_id=6656 I'm going to close this by mid January if there's no activity. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-03-31 21:13 Message: Logged In: YES user_id=6656 Ralph, want do you want to do here? Can you supply a way of identifying aix 3 with the preprocessor? I'm worried that just bunging prototypes for chroot & fsync inside a "#if _AIX" might break AIX 4. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-03-27 12:54 Message: Logged In: YES user_id=21627 AC_CHECK_DECLS is not supported in autoconf 2.13, so it is not available for use in Python 2.2. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-03-25 13:41 Message: Logged In: YES user_id=6656 Hmm, AC_CHECK_DECLS might well be useful (and not just for these declarations). However, I'm not an autoconf guru, and really don't want to have to become one. Is there a way to identify AIX 3 using the preprocessor? Or does AIX 4 not have these prototypes either? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=534108&group_id=5470 From noreply@sourceforge.net Tue Jan 28 17:41:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 09:41:51 -0800 Subject: [Python-bugs-list] [ python-Bugs-676155 ] RuntimeWarning with tp_compare Message-ID: Bugs item #676155, was opened at 2003-01-28 10:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676155&group_id=5470 Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Andrew Dalke (dalke) >Assigned to: Nobody/Anonymous (nobody) Summary: RuntimeWarning with tp_compare Initial Comment: >From the latest CVS, as of the morning of Jan. 28 2003 >>> s = "12345" * 1000 >>> float(s) == int(s) __main__:1: RuntimeWarning: tp_compare didn't return -1 or -2 for exception Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to float >>> ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 12:41 Message: Logged In: YES user_id=33168 Let me try that again, this time without confusing the issues. Sorry about that. The patch does fix the coerce problem I mentioned. The patch also fixes the bug report problem in that now an OverflowError is raised. However, even with the patch I get the undetected error: >>> float(s) == int(s) False XXX undetected error Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to float I'll keep working on the problem. Should be pretty shallow now, I hope. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-28 12:33 Message: Logged In: YES user_id=6656 That looks like the fix to me. Presumably you meant "*without* this patch I get..."? I suggest you check it in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 12:23 Message: Logged In: YES user_id=33168 I thought I fixed the problem in one place (patch attached). That fixes this problem: coerce(0.5, int(s)) With this patch, I get: XXX undetected error (why=3) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-28 12:15 Message: Logged In: YES user_id=6656 Hmm, wierd. I think there may be a case of something setting an exception and then not returning NULL (or whatever). You can certainly get some wierd tracebacks. Buggered if I know where though -- "you are in a maze of twisty function calls, all alike" :-/ Some playing with a debug build and gdb coming up... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676155&group_id=5470 From noreply@sourceforge.net Tue Jan 28 17:47:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 09:47:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-676155 ] RuntimeWarning with tp_compare Message-ID: Bugs item #676155, was opened at 2003-01-28 10:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676155&group_id=5470 Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Andrew Dalke (dalke) >Assigned to: Neal Norwitz (nnorwitz) Summary: RuntimeWarning with tp_compare Initial Comment: >From the latest CVS, as of the morning of Jan. 28 2003 >>> s = "12345" * 1000 >>> float(s) == int(s) __main__:1: RuntimeWarning: tp_compare didn't return -1 or -2 for exception Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to float >>> ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-28 12:47 Message: Logged In: YES user_id=31435 The patch definitely fixes a bug, and maybe even this bug . At one time, nobody ever checked PyLong_AsDouble for an error return, and at that time I checked & repaired all call sites in the core. Added this NEWS blurb at the time: """ Note that PyLong_AsDouble can fail! This has always been true, but no callers checked for it. It's more likely to fail now, because overflow errors are properly detected now. The proper way to check:: double x = PyLong_AsDouble(some_long_object); if (x == -1.0 && PyErr_Occurred()) { /* The conversion failed. */ } """ Maybe I missed this one then, or maybe it's newer code. Whatever, +1 on fixing it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 12:41 Message: Logged In: YES user_id=33168 Let me try that again, this time without confusing the issues. Sorry about that. The patch does fix the coerce problem I mentioned. The patch also fixes the bug report problem in that now an OverflowError is raised. However, even with the patch I get the undetected error: >>> float(s) == int(s) False XXX undetected error Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to float I'll keep working on the problem. Should be pretty shallow now, I hope. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-28 12:33 Message: Logged In: YES user_id=6656 That looks like the fix to me. Presumably you meant "*without* this patch I get..."? I suggest you check it in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 12:23 Message: Logged In: YES user_id=33168 I thought I fixed the problem in one place (patch attached). That fixes this problem: coerce(0.5, int(s)) With this patch, I get: XXX undetected error (why=3) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-28 12:15 Message: Logged In: YES user_id=6656 Hmm, wierd. I think there may be a case of something setting an exception and then not returning NULL (or whatever). You can certainly get some wierd tracebacks. Buggered if I know where though -- "you are in a maze of twisty function calls, all alike" :-/ Some playing with a debug build and gdb coming up... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676155&group_id=5470 From noreply@sourceforge.net Tue Jan 28 18:10:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 10:10:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-676155 ] RuntimeWarning with tp_compare Message-ID: Bugs item #676155, was opened at 2003-01-28 15:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676155&group_id=5470 Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Neal Norwitz (nnorwitz) Summary: RuntimeWarning with tp_compare Initial Comment: >From the latest CVS, as of the morning of Jan. 28 2003 >>> s = "12345" * 1000 >>> float(s) == int(s) __main__:1: RuntimeWarning: tp_compare didn't return -1 or -2 for exception Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to float >>> ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-01-28 18:10 Message: Logged In: YES user_id=6656 Here's a guess. Caveat emptor & all. The thing is, returning 1 from a nb_coerce means "I can't do it", not "I tried and there was an exception", so presumably whatever code is calling it just goes off and calls the other types nb_coerce method. So I think your patch needs to return -1. But then the other type never gets a chance to see the objects. IOW, this is a crock. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-28 17:47 Message: Logged In: YES user_id=31435 The patch definitely fixes a bug, and maybe even this bug . At one time, nobody ever checked PyLong_AsDouble for an error return, and at that time I checked & repaired all call sites in the core. Added this NEWS blurb at the time: """ Note that PyLong_AsDouble can fail! This has always been true, but no callers checked for it. It's more likely to fail now, because overflow errors are properly detected now. The proper way to check:: double x = PyLong_AsDouble(some_long_object); if (x == -1.0 && PyErr_Occurred()) { /* The conversion failed. */ } """ Maybe I missed this one then, or maybe it's newer code. Whatever, +1 on fixing it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 17:41 Message: Logged In: YES user_id=33168 Let me try that again, this time without confusing the issues. Sorry about that. The patch does fix the coerce problem I mentioned. The patch also fixes the bug report problem in that now an OverflowError is raised. However, even with the patch I get the undetected error: >>> float(s) == int(s) False XXX undetected error Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to float I'll keep working on the problem. Should be pretty shallow now, I hope. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-28 17:33 Message: Logged In: YES user_id=6656 That looks like the fix to me. Presumably you meant "*without* this patch I get..."? I suggest you check it in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 17:23 Message: Logged In: YES user_id=33168 I thought I fixed the problem in one place (patch attached). That fixes this problem: coerce(0.5, int(s)) With this patch, I get: XXX undetected error (why=3) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-28 17:15 Message: Logged In: YES user_id=6656 Hmm, wierd. I think there may be a case of something setting an exception and then not returning NULL (or whatever). You can certainly get some wierd tracebacks. Buggered if I know where though -- "you are in a maze of twisty function calls, all alike" :-/ Some playing with a debug build and gdb coming up... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676155&group_id=5470 From noreply@sourceforge.net Tue Jan 28 18:15:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 10:15:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-676233 ] bsddb doc error Message-ID: Bugs item #676233, was opened at 2003-01-28 13:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676233&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Barry A. Warsaw (bwarsaw) Summary: bsddb doc error Initial Comment: Email from Magnus Lie Hetland to python-docs: While browsing the docs on the bsddb module and reading the source, I found that the signature of the rnopen (and probably the other open functions) is (are) incorrect in the docs. I don't really have a doc patch (sorry about that), but I suppose the error should be easy to fix...? Also, the description that the arguments are passed to the low-level dbopen function is not correct -- they are passed to several different methods. (I noticed this, as I looked for the set_re_source method, which is handled by the source argument, as it turns out.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676233&group_id=5470 From noreply@sourceforge.net Tue Jan 28 18:17:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 10:17:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation. Message-ID: Bugs item #555817, was opened at 2002-05-14 10:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Graham Horler (grahamh) >Assigned to: Martin v. Löwis (loewis) Summary: Flawed fcntl.ioctl implementation. Initial Comment: I'm doing some USB user-space driver programming in Python 2.1.3 under Linux 2.4. When using a particular ioctl (HIDIOCGNAME), the return value as well as the (copy_to_user) binary data is significant. Here is the code from line 547 of hiddev.c (kernel 2.4.19-pre7): if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) { int len; if (!hid->name) return 0; len = strlen(hid->name) + 1; if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd); return copy_to_user((char *) arg, hid->name, len) ? -EFAULT : len; } So here is the problem: fcntl.ioctl() will only give me one or the other value, but not both. I can work around this by initialising the input buffer to all chr(0), and then strip them off after. But there will be a time when an ioctl call *requires* both values. Until now I have appreciated the simple ioctl interface, but now it is shown to be an oversimplification. It may be that POSIX, or some standard somewhere says that ioctl should not be used to do this, but maybe Python should support it anyway. I suggest either: 1. A new function ioctl2(fd, op, arg) that returns a 2-tuple of (return_value, binary_buffer) and does not try to interpret the return value. 2. An optional 4th parameter whose presence (but not value) requests the 2-tuple mentioned in (1). Gotta love Python! ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-01-28 18:17 Message: Logged In: YES user_id=6656 Argh, how does SF CVS know to slow down just as I start to work on my bugs? Anyway, I think this patch will do. Adds a test, docs, and beats up on ioctl's docstring. The only issue left that I know about is the error message that you get when none of the PyArg_ParseTuples pass -- but telling the full story would make the error message ridiculously long, so I don't much care. Tempted to change it to ioctl: ha ha, you stuffed up! read the docstring . Martin, can you review? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-02 16:55 Message: Logged In: YES user_id=6656 Assign to me in the hope that I'll stop forgetting about it (sigh). I'm about 70% of the way through what's needed I'd guess. Try to finish for 2.3a2... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-13 15:09 Message: Logged In: YES user_id=21627 The patch looks good, in principle, so please correct it, and provide documentation (do mention that you need to pass 1024 bytes to avoid copying). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-13 14:40 Message: Logged In: YES user_id=6656 I'd like to either move this forward or close it. Is/was there agreement that my patch would be OK if brushed up as described below, i.e. add tests, docs, provide better error messages? (actually, I note that my patch's use of Py_BEGIN_ALLOW_THREADS is amusingly broken... gotta love the C preprocessor). ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-06-12 11:38 Message: Logged In: YES user_id=543663 Still here... Thanks for the help people. Things have been a bit crazy ATM, but should be back to working with this again soon, so I'll let you know how it goes. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-16 13:15 Message: Logged In: YES user_id=29957 There's a very simple test_ioctl.py in patch #555883 (the ioctl2() sample implementation). It does a getpgrp(), then a TIOCGPGRP and checks it gets the same stuff. No, it won't work on Windows. I'm going to close off #555883 as Invalid. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 12:41 Message: Logged In: YES user_id=6656 Try the attached. (a) should have docs. This is getting hairy (if this then that, but if this and not that then the other...). (b) I've made no attempt to get this to hand out sane error messages (see above). (c) would be nice to have tests. how on earth do you test ioctl? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 12:03 Message: Logged In: YES user_id=6656 OK, that would seem to be easy enough to implement (well, the handling of writeable buffers, not all the optional hair). I like this: >>> buf = array.array('h', [0]*4) [19139 refs] >>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf) 0 [19139 refs] >>> buf array('h', [47, 137, 841, 615]) [19139 refs] I like this less: >>> import array, fcntl [19089 refs] >>> buf = array.array('h', [0]*3) [19093 refs] >>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf) 0 [19095 refs] >>> del buf Debug memory block at address p=0x401c3cb8: 6 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x401c3cbe are not all FORBIDDENBYTE (0xfb): at tail+0: 0x67 *** OUCH at tail+1: 0x02 *** OUCH at tail+2: 0xfb at tail+3: 0xfb The block was made by call #16015 to debug malloc/realloc. Data at p: 2f 00 89 00 49 03 Fatal Python error: bad trailing pad byte Aborted I'm not sure what we can possibly do about this? Copy into a fixed buffer like we do today, then copy out again after the ioctl? Probably the best option. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-16 11:43 Message: Logged In: YES user_id=21627 I'm in favour of a you-may-mutate-the-buffer flag. A transition strategy would be: - in 2.3, make the flag optional, with default 0 - in 2.4, warn if it is not specified - in 2.5, change the default All the time, if the buffer isn't mutable, specifying the flag should not be required. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-16 11:34 Message: Logged In: YES user_id=29957 Hm. The solaris /proc lib I did in python, I used 'struct' to dismantle C structures, but I did consider using byte arrays. So that's one data point. (ok, it's not ioctls, but it's similar sort of data). I'm loathe to go down the 'argument is mutable' optional flag, but I really would prefer to make this work rather than the ioctl2() approach, which really ain't that nice. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 10:21 Message: Logged In: YES user_id=6656 I'm not *trying* to be a party-pooper, but there's another problem: the point of passing a mutable array is so that fcntl.ioctl can return ioctl(2)'s return code rather than the string it returns now. So if someone does use arrays (or I guess Numeric.arrays?) for ioctls this would very likely cause breakage. I don't know how likely that is. Probably not very. But I know that if this change broke my code, I'd be a bit miffed. All this is a bit annoying, as mutating arrays is clearly the right solution -- where's that time machine? ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-15 23:50 Message: Logged In: YES user_id=543663 I just realised - using array objects and changing in-place oversomes the arbitrary limit of 1024 bytes. We could then achieve the full 16384 byte nirvana - hurrah! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 18:21 Message: Logged In: YES user_id=21627 I would not be concerned about the backwards compatibility, either: if anybody is passing arrays, there is a good chance that the ioctl does not modify the buffer, or that the caller would not worry about the (missing) modification - or else we had seen reports before. So documenting in Misc/NEWS and the documentation that mutable objects supporting the (write) buffer interface may now mutate seems sufficient. ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-15 17:32 Message: Logged In: YES user_id=543663 Thanks Michael, its all incredibly clear now (sorry Martin). I think using arrays sounds a great idea. IMVHO as to backward compatibility, AFAICT its not documented that arrays can be passed to ioctl() anyway (only says int and string no?), so it's only breaking undocumented behaviour. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-15 16:38 Message: Logged In: YES user_id=6656 grahamh: I think Martin understood you fine. Remember that arrays are mutable, whereas strings are not. So the idea would be that you'd write buf = array.array('c', '\000'*256) ret = fcntl.ioctl(fd, IOCTL_NUMBER, buf) then the first "ret" bytes of "buf" would be valid. However this possibly breaks backwards compatibility, as you can already pass arrays into the ioctl function and they are not modified. ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-15 15:44 Message: Logged In: YES user_id=543663 Re Loewis: Not sure what you mean, perhaps an example of the problem from me would help: In C: char buf[256], strbuf[256]; int ret, fd; fd = open(...) ret = ioctl(fd, IOCTL_NUMBER, buf); strncpy(strbuf, buf, ret); This is impossible with the current fcntl module: buf = "X" * struct.calcsize("256s") buf = fcntl.ioctl(fd, IOCTL_NUMBER, buf) # The positive ioctl() return value is lost, and # hence I dont know how much of buf is significant Extract from asm/unistd.h: #define __syscall_return(type, res) \ do { \ if ((unsigned long)(res) >= (unsigned long)(-125)) { \ errno = -(res); \ res = -1; \ } \ return (type) (res); \ } while (0) So positive values are valid, but are being lost. Anthony's patch looks good (thanks, I have not had a chance to test it myself yet), and the above example would be: buf = "X" * struct.calcsize("256s") ret, buf = fcntl.ioctl2(fd, IOCTL_NUMBER, buf) strbuf = buf[:ret] # Result! Now, to test my understanding of your last comment about array objects Loewis, do you mean: - pass in a mutable list that gets changed in place to [ret, buf] - return (ret, buf) if called like this: ioctl(fd, IOC, [buf]) - or something else - please give example. Thanks people. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 13:04 Message: Logged In: YES user_id=21627 Thinking about the problem again, I think the right solution would be to support array objects as arguments to ioctl - those would then be passed into the system call. Am I correctly understanding the problem, that this would not require a new function? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-14 13:06 Message: Logged In: YES user_id=29957 possible patch at http://sourceforge.net/tracker/index.php?func=detail&aid=555883&group_id=5470&atid=305470 I've only lightly tested it, not with any calls that return useful values in the return code (couldn't find any easily, didn't feel like figuring out userspace drivers right now :) Give it a whirl... ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-14 11:10 Message: Logged In: YES user_id=29957 Ouch. I think you're right - and I think that the ioctl2() implementation is probably the only solution. (I'm not so keen on the name, but I guess it kinda follows the 'standard' of other python functions, e.g. popen) I know changing the return of ioctl would be mega-ugly, unless there was a new, optional "return a tuple" argument. I doubt that's the appropriate fix. If the former approach is the appropriate one, it should be simple enough to add an ioctl2() to the C source. I can probably whip it up now... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470 From noreply@sourceforge.net Tue Jan 28 18:43:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 10:43:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-676155 ] RuntimeWarning with tp_compare Message-ID: Bugs item #676155, was opened at 2003-01-28 10:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676155&group_id=5470 >Category: Python Interpreter Core Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Neal Norwitz (nnorwitz) Summary: RuntimeWarning with tp_compare Initial Comment: >From the latest CVS, as of the morning of Jan. 28 2003 >>> s = "12345" * 1000 >>> float(s) == int(s) __main__:1: RuntimeWarning: tp_compare didn't return -1 or -2 for exception Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to float >>> ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 13:43 Message: Logged In: YES user_id=33168 Returning -1 from float_coerce() fixes the original problem of comparing float(s) == int(s) as well as the coerce() problem. Is that correct though? It seems all other nb_coerce's return only 0 or 1. Might returning -1 create other problems? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-28 13:10 Message: Logged In: YES user_id=6656 Here's a guess. Caveat emptor & all. The thing is, returning 1 from a nb_coerce means "I can't do it", not "I tried and there was an exception", so presumably whatever code is calling it just goes off and calls the other types nb_coerce method. So I think your patch needs to return -1. But then the other type never gets a chance to see the objects. IOW, this is a crock. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-28 12:47 Message: Logged In: YES user_id=31435 The patch definitely fixes a bug, and maybe even this bug . At one time, nobody ever checked PyLong_AsDouble for an error return, and at that time I checked & repaired all call sites in the core. Added this NEWS blurb at the time: """ Note that PyLong_AsDouble can fail! This has always been true, but no callers checked for it. It's more likely to fail now, because overflow errors are properly detected now. The proper way to check:: double x = PyLong_AsDouble(some_long_object); if (x == -1.0 && PyErr_Occurred()) { /* The conversion failed. */ } """ Maybe I missed this one then, or maybe it's newer code. Whatever, +1 on fixing it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 12:41 Message: Logged In: YES user_id=33168 Let me try that again, this time without confusing the issues. Sorry about that. The patch does fix the coerce problem I mentioned. The patch also fixes the bug report problem in that now an OverflowError is raised. However, even with the patch I get the undetected error: >>> float(s) == int(s) False XXX undetected error Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to float I'll keep working on the problem. Should be pretty shallow now, I hope. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-28 12:33 Message: Logged In: YES user_id=6656 That looks like the fix to me. Presumably you meant "*without* this patch I get..."? I suggest you check it in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 12:23 Message: Logged In: YES user_id=33168 I thought I fixed the problem in one place (patch attached). That fixes this problem: coerce(0.5, int(s)) With this patch, I get: XXX undetected error (why=3) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-28 12:15 Message: Logged In: YES user_id=6656 Hmm, wierd. I think there may be a case of something setting an exception and then not returning NULL (or whatever). You can certainly get some wierd tracebacks. Buggered if I know where though -- "you are in a maze of twisty function calls, all alike" :-/ Some playing with a debug build and gdb coming up... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676155&group_id=5470 From noreply@sourceforge.net Tue Jan 28 19:09:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 11:09:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-676273 ] BaseHTTPServer; HTTP/1.1 spec not "vague" Message-ID: Bugs item #676273, was opened at 2003-01-28 12:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676273&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Nobody/Anonymous (nobody) Summary: BaseHTTPServer; HTTP/1.1 spec not "vague" Initial Comment: The module docstring for BaseHTTPServer says The protocol is vague about whether lines are separated by LF characters or by CRLF pairs -- for compatibility with the widest range of clients, both should be accepted. Similarly, whitespace in the request line should be treated sensibly (allowing multiple spaces between components and allowing trailing whitespace). HTTP/1.1 is not vague. It says in section 2.2 of the spec HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body but with the suggestion in 19.3 that Clients SHOULD be tolerant in parsing the Status-Line and servers tolerant when parsing the Request-Line. In particular, they SHOULD accept any amount of SP or HT characters between fields, even though only a single SP is required. The line terminator for message-header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers, recognize a single LF as a line terminator and ignore the leading CR. This means that 1) the spec is not vague and 2) the Python code works according to the spec. So my suggestion is to remove the comment about being "vague" from the spec. A diff is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676273&group_id=5470 From noreply@sourceforge.net Tue Jan 28 19:21:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 11:21:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-676155 ] RuntimeWarning with tp_compare Message-ID: Bugs item #676155, was opened at 2003-01-28 10:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676155&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Neal Norwitz (nnorwitz) Summary: RuntimeWarning with tp_compare Initial Comment: >From the latest CVS, as of the morning of Jan. 28 2003 >>> s = "12345" * 1000 >>> float(s) == int(s) __main__:1: RuntimeWarning: tp_compare didn't return -1 or -2 for exception Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to float >>> ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-28 14:21 Message: Logged In: YES user_id=31435 nb_coerce is called from only a couple places in the core, and they're happy with a -1 return. Note that complex_coerce can already return -1 (and for the same reason: long->double overflow). It's a general rule than every number-returning C API function returns -1 to indicate error. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 13:43 Message: Logged In: YES user_id=33168 Returning -1 from float_coerce() fixes the original problem of comparing float(s) == int(s) as well as the coerce() problem. Is that correct though? It seems all other nb_coerce's return only 0 or 1. Might returning -1 create other problems? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-28 13:10 Message: Logged In: YES user_id=6656 Here's a guess. Caveat emptor & all. The thing is, returning 1 from a nb_coerce means "I can't do it", not "I tried and there was an exception", so presumably whatever code is calling it just goes off and calls the other types nb_coerce method. So I think your patch needs to return -1. But then the other type never gets a chance to see the objects. IOW, this is a crock. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-28 12:47 Message: Logged In: YES user_id=31435 The patch definitely fixes a bug, and maybe even this bug . At one time, nobody ever checked PyLong_AsDouble for an error return, and at that time I checked & repaired all call sites in the core. Added this NEWS blurb at the time: """ Note that PyLong_AsDouble can fail! This has always been true, but no callers checked for it. It's more likely to fail now, because overflow errors are properly detected now. The proper way to check:: double x = PyLong_AsDouble(some_long_object); if (x == -1.0 && PyErr_Occurred()) { /* The conversion failed. */ } """ Maybe I missed this one then, or maybe it's newer code. Whatever, +1 on fixing it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 12:41 Message: Logged In: YES user_id=33168 Let me try that again, this time without confusing the issues. Sorry about that. The patch does fix the coerce problem I mentioned. The patch also fixes the bug report problem in that now an OverflowError is raised. However, even with the patch I get the undetected error: >>> float(s) == int(s) False XXX undetected error Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to float I'll keep working on the problem. Should be pretty shallow now, I hope. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-28 12:33 Message: Logged In: YES user_id=6656 That looks like the fix to me. Presumably you meant "*without* this patch I get..."? I suggest you check it in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 12:23 Message: Logged In: YES user_id=33168 I thought I fixed the problem in one place (patch attached). That fixes this problem: coerce(0.5, int(s)) With this patch, I get: XXX undetected error (why=3) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-28 12:15 Message: Logged In: YES user_id=6656 Hmm, wierd. I think there may be a case of something setting an exception and then not returning NULL (or whatever). You can certainly get some wierd tracebacks. Buggered if I know where though -- "you are in a maze of twisty function calls, all alike" :-/ Some playing with a debug build and gdb coming up... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676155&group_id=5470 From noreply@sourceforge.net Tue Jan 28 19:38:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 11:38:01 -0800 Subject: [Python-bugs-list] [ python-Bugs-676292 ] BaseHTTPServer incorrectly parses protocol Message-ID: Bugs item #676292, was opened at 2003-01-28 12:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676292&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Nobody/Anonymous (nobody) Summary: BaseHTTPServer incorrectly parses protocol Initial Comment: The code in BaseHTTPServer.BaseHTTPRequestHandler.parse_request says try: version_number = float(version.split('/', 1)[1]) except ValueError: self.send_error(400, "Bad request version (%s)" % `version`) return False if version_number >= 1.1 and self.protocol_version >= "HTTP/1.1": self.close_connection = 0 if version_number >= 2.0: self.send_error(505, "Invalid HTTP Version (%f)" % version_number) This does not agree with the HTTP/1.1 spec which states Note that the major and minor numbers MUST be treated as separate integers and that each MAY be incremented higher than a single digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and MUST NOT be sent. I also noticed there were errors if the version string was "HTTP/1.2.3" or even simply "BLAH". I've fixed them so they don't give tracebacks. Finally, if there is an error in the parsing, it calls the 'send_error' method, which does a check if 'self.command' is a HEAD. However, if there's an error parsing the first line of the HTTP request the self.command wasn't yet set, so I forced self.command to initialized to None before doing anything which can yield an error. Patch is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676292&group_id=5470 From noreply@sourceforge.net Tue Jan 28 19:47:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 11:47:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-676155 ] RuntimeWarning with tp_compare Message-ID: Bugs item #676155, was opened at 2003-01-28 10:55 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676155&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Neal Norwitz (nnorwitz) Summary: RuntimeWarning with tp_compare Initial Comment: >From the latest CVS, as of the morning of Jan. 28 2003 >>> s = "12345" * 1000 >>> float(s) == int(s) __main__:1: RuntimeWarning: tp_compare didn't return -1 or -2 for exception Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to float >>> ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 14:47 Message: Logged In: YES user_id=33168 Works for me. I just wanted to make sure. Checked in as: Misc/NEWS: 1.631 1.337.2.4.2.57 Lib/test/test_builtin.py: 1.6 Lib/test/test_b1.py: 1.42.4.6 Lib/test/test_long.py: 1.22 1.15.14.1 Objects/floatobject.c: 2.119 2.110.6.3 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-28 14:21 Message: Logged In: YES user_id=31435 nb_coerce is called from only a couple places in the core, and they're happy with a -1 return. Note that complex_coerce can already return -1 (and for the same reason: long->double overflow). It's a general rule than every number-returning C API function returns -1 to indicate error. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 13:43 Message: Logged In: YES user_id=33168 Returning -1 from float_coerce() fixes the original problem of comparing float(s) == int(s) as well as the coerce() problem. Is that correct though? It seems all other nb_coerce's return only 0 or 1. Might returning -1 create other problems? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-28 13:10 Message: Logged In: YES user_id=6656 Here's a guess. Caveat emptor & all. The thing is, returning 1 from a nb_coerce means "I can't do it", not "I tried and there was an exception", so presumably whatever code is calling it just goes off and calls the other types nb_coerce method. So I think your patch needs to return -1. But then the other type never gets a chance to see the objects. IOW, this is a crock. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-28 12:47 Message: Logged In: YES user_id=31435 The patch definitely fixes a bug, and maybe even this bug . At one time, nobody ever checked PyLong_AsDouble for an error return, and at that time I checked & repaired all call sites in the core. Added this NEWS blurb at the time: """ Note that PyLong_AsDouble can fail! This has always been true, but no callers checked for it. It's more likely to fail now, because overflow errors are properly detected now. The proper way to check:: double x = PyLong_AsDouble(some_long_object); if (x == -1.0 && PyErr_Occurred()) { /* The conversion failed. */ } """ Maybe I missed this one then, or maybe it's newer code. Whatever, +1 on fixing it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 12:41 Message: Logged In: YES user_id=33168 Let me try that again, this time without confusing the issues. Sorry about that. The patch does fix the coerce problem I mentioned. The patch also fixes the bug report problem in that now an OverflowError is raised. However, even with the patch I get the undetected error: >>> float(s) == int(s) False XXX undetected error Traceback (most recent call last): File "", line 1, in ? OverflowError: long int too large to convert to float I'll keep working on the problem. Should be pretty shallow now, I hope. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-28 12:33 Message: Logged In: YES user_id=6656 That looks like the fix to me. Presumably you meant "*without* this patch I get..."? I suggest you check it in. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 12:23 Message: Logged In: YES user_id=33168 I thought I fixed the problem in one place (patch attached). That fixes this problem: coerce(0.5, int(s)) With this patch, I get: XXX undetected error (why=3) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-28 12:15 Message: Logged In: YES user_id=6656 Hmm, wierd. I think there may be a case of something setting an exception and then not returning NULL (or whatever). You can certainly get some wierd tracebacks. Buggered if I know where though -- "you are in a maze of twisty function calls, all alike" :-/ Some playing with a debug build and gdb coming up... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676155&group_id=5470 From noreply@sourceforge.net Tue Jan 28 20:38:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 12:38:44 -0800 Subject: [Python-bugs-list] [ python-Bugs-665761 ] reduce() masks exception Message-ID: Bugs item #665761, was opened at 2003-01-10 15:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665761&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 3 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: reduce() masks exception Initial Comment: In the following test script ----- class Test: def __iter__(self): raise IOError reduce(lambda x,y: x+y, Test()) ----- the real IOError exception is masked, i.e. the traceback is ----- Traceback (most recent call last): File "test.py", line 5, in ? reduce(lambda x,y: x+y, Test()) TypeError: reduce() arg 2 must support iteration ----- but IMHO should be ----- Traceback (most recent call last): File "test.py", line 3, in ? raise IOError IOError ----- This can be fixed by removing the PyErr_SetString(PyExc_TypeError, "reduce() arg 2 must support iteration") call in bltinmodule.c/buildtin_reduce(). ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-01-28 21:38 Message: Logged In: YES user_id=89016 Attached is a patch that fixes reduce(), map() and zip(). Unfortunately this loses the information about which argument triggered the exception (in map() and zip()) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-25 05:00 Message: Logged In: YES user_id=80475 There's a lot of this going around. map() and zip() have the same issue. I recommend fixing them all. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-13 14:18 Message: Logged In: YES user_id=89016 The point is that Python/bltinmodule.c/builtin_reduce() masks the error returned from PyObject_GetIter(). Errors from PyIter_Next() are not masked. What about the following example: class LazyFile: def __init__(self, name, mode="r"): self.name = name self.mode = mode def __iter__(self): return open(self.name, self.mode) import operator f = LazyFile("does not exist") s = reduce(operator.add, f) LazyFile *does* support iteration, but the underlying problem of the non existing file is masked. Removing the call PyErr_SetString(PyExc_TypeError, "reduce() arg 2 must support iteration"); in builtin_reduce(), will produce the original exception "IOError: [Errno 2] No such file or directory: 'does not exist'" and when the second argument is not iteratable, the original exception is just as good: >>> reduce(lambda x,y: x+y, 42) Traceback (most recent call last): File "", line 1, in ? TypeError: iteration over non-sequence ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2003-01-11 18:08 Message: Logged In: YES user_id=366566 the __iter__ method is supposed to return an object that defines a 'next' method. The returned object is the one used for iteration, not the original. So I believe the error message is correct - Test does not support iteration. If you change the code to: >>> class test: ... def __iter__(self): ... return self ... def next(self): ... raise IOError ... >>> reduce(operator.add, test()) You get the expected result... Traceback (most recent call last):   File "", line 1, in ?   File "", line 5, in next IOError ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665761&group_id=5470 From noreply@sourceforge.net Tue Jan 28 20:53:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 12:53:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-676342 ] after using pdb readline does not work correctly Message-ID: Bugs item #676342, was opened at 2003-01-28 20:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676342&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Nobody/Anonymous (nobody) Summary: after using pdb readline does not work correctly Initial Comment: After I use pdb in the interpreter my readline settings are messed up. It only knows about the pdb readline stuff forever afterward. In fact, this happens as soon as a Pdb object is instantiated, regardless of whether or not you use it. This is a result of some aspects of the Cmd object in Lib/cmd.py. Currently Cmd registers a new readline completer as soon as a Cmd object is instantiated. This is probably incorrect. I believe the correct place to register the new handler is in the preloop hook. That way the new readline completer is only used while the Cmd object is actually responsible for processing user input. Next, the old readline completer should probably be re-registered in the postloop hook. In order to do this, a new call must be added to the readline module to return the current completer so it can be saved and later restored. The files included patch readline.c (version 2.41.64) and cmd.py (version 1.26.16.2) to make the changes described above. After this patch readline works as expected in the interpreter. Let me know what you think of it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676342&group_id=5470 From noreply@sourceforge.net Tue Jan 28 20:57:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 12:57:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-675928 ] Have exception arguments keep their type Message-ID: Bugs item #675928, was opened at 2003-01-27 22:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675928&group_id=5470 Category: Python Interpreter Core Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Nobody/Anonymous (nobody) Summary: Have exception arguments keep their type Initial Comment: If you execute the following code:: try: raise Exception('a string') except Exception, err: print type(err) it prints out that ``err`` is a type 'instance'. It would be nice if it returned the type of the actual argument (in this case, type 'str'). ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-01-28 12:57 Message: Logged In: YES user_id=357491 I must be misunderstanding how exceptions handle passed-in values at instantiation. I know you can pass in multiple values (I assume it's ``def __init__(*args, **kwargs)`` for Exception), but I was not expecting an instance type. I think I was expecting the values from ``.args`` to be unpacked and stored in the variables instead of an actual exception object to returned in there with a smart ``__str__`` method. Perhaps the docs should clarify that you receive actual copies of the exception object with its ``args`` attribute set to the argument? The tutorial, as-is, says "the except clause may specify a variable after the exception name (or list) to receive the argument's value" which suggests to me that I will get the physical argument I passed into the exception; I expected tuple unpacking of the ``args`` attribute. In other words I see why it is the way it is, but perhaps we should clarify in the tutorial that it is an exception instance storing the arguments and not the arguments themselves? And I actually used ``str(err)`` to get my code to work, although now that I know that it actually is an instance of an exception it really isn't needed since I will just test for an exception. =) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-28 07:52 Message: Logged In: YES user_id=31435 I'm a bit baffled by this, Brett: when you instantiate a class, you can pass any number of arguments to its constructor. You happened to pass a single string argument when building an instance of Exception here, but you could have passed any number of arguments. Why should the first argument be special? (Or maybe you think the last argument should be special ). Or what if you didn't pass any arguments at all? Having "the detail" bound to the instance object raised is a feature, and a major one. If you're in the habit of passing a single string to Exception directly, note that you can already get it back via doing str(err) in the "except" clause. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675928&group_id=5470 From noreply@sourceforge.net Tue Jan 28 20:59:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 12:59:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-676346 ] String formatting operation Unicode problem. Message-ID: Bugs item #676346, was opened at 2003-01-28 15:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676346&group_id=5470 Category: Unicode Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: David M. Grimes (dmgrime) Assigned to: M.-A. Lemburg (lemburg) Summary: String formatting operation Unicode problem. Initial Comment: When performing a string formatting operation using %s and a unicode argument, the argument evaluation is performed more than once. In certain environments (see example) this leads to excessive calls. It seems Python-2.2.2:Objects/stringobject.c:3394 is where PyObject_GetItem is used (for dictionary-like formatting args). Later, at :3509, there is a"goto unicode" when a string argument is actually unicode. At this point, everything resets and we do it all over again in PyUnicode_Format. There is an underlying assumption that the cost of the call to PyObject_GetItem is very low (since we're going to do them all again for unicode). We've got a Python-based templating system which uses a very simple Mix-In class to facilitate flexible page generation. At the core is a simple __getitem__ implementation which maps calls to getattr(): class mixin: def __getitem__(self, name): print '%r::__getitem__(%s)' % (self, name) hook = getattr(self, name) if callable(hook): return hook() else: return hook Obviously, the print is diagnostic. So, this basic mechanism allows one to write hierarchical templates filling in content found in "%(xxxx)s" escapes with functions returning strings. It has worked extremely well for us. BUT, we recently did some XML-based work which uncovered this strange unicode behaviour. Given the following classes: class w1u(mixin): v1 = u'v1' class w2u(mixin): def v2(self): return '%(v1)s' % w1u() class w3u(mixin): def v3(self): return '%(v2)s' % w2u() class w1(mixin): v1 = 'v1' class w2(mixin): def v2(self): return '%(v1)s' % w1() class w3(mixin): def v3(self): return '%(v2)s' % w2() And test case: print 'All string:' print '%(v3)s' % w3() print print 'Unicode injected at w1u:' print '%(v3)s' % w3u() print As we can see, the only difference between the w{1,2,3} and w{1,2,3}u classes is that w1u defines v1 as unicode where w1 uses a "normal" string. What we see is the string-based one shows 3 calls, as expected: All string: <__main__.w3 instance at 0x8150524>::__getitem__(v3) <__main__.w2 instance at 0x814effc>::__getitem__(v2) <__main__.w1 instance at 0x814f024>::__getitem__(v1) v1 But the unicode causes a tree-like recursion: Unicode injected at w1u: <__main__.w3u instance at 0x8150524>::__getitem__(v3) <__main__.w2u instance at 0x814effc>::__getitem__(v2) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w2u instance at 0x814effc>::__getitem__(v2) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w3u instance at 0x8150524>::__getitem__(v3) <__main__.w2u instance at 0x814effc>::__getitem__(v2) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w2u instance at 0x814effc>::__getitem__(v2) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w1u instance at 0x814f024>::__getitem__(v1) v1 I'm sure this isn't a "common" use of the string formatting mechanism, but it seems that evaluating the arguments multiple times could be a bad thing. It certainly is for us 8^) We're running this on a RedHat 7.3/8.0 setup, not that it appears to matter (from looking in stringojbect.c). Also appears to still be a problem in 2.3a1. Any comments? Help? Questions? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676346&group_id=5470 From noreply@sourceforge.net Tue Jan 28 21:17:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 13:17:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-676358 ] Have PythonLauncher use #! line Message-ID: Bugs item #676358, was opened at 2003-01-28 13:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676358&group_id=5470 Category: Macintosh Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Christopher Barker (chrishbarker) Assigned to: Jack Jansen (jackjansen) Summary: Have PythonLauncher use #! line Initial Comment: As discussed on the mailing list, it would be great it the PythonLauncher applet had a preference: Honour #! lines in scripts That way, one could have different versions of Python on a machine, and any script could have an appropriate #! line, and it would get launched with the correct python. -thanks, Chris ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676358&group_id=5470 From noreply@sourceforge.net Tue Jan 28 21:50:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 13:50:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-675745 ] unix link to framework python Message-ID: Bugs item #675745, was opened at 2003-01-27 22:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675745&group_id=5470 Category: Macintosh Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Jack Jansen (jackjansen) Summary: unix link to framework python Initial Comment: Jack asked me to submit this: In the 2.3 framework build /usr/local/bin/python is linked to the python inside the framework. I think it would be better if the link was "python2.3" and then there could be a separate link from "python" to "python2.3" as well. This would allow command line (or #!) users to specify either "python2.2" or "python2.3" to get the one they want. I expect that it would also allow installation of the unix links/scripts into /usr/bin... ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-01-28 22:50 Message: Logged In: YES user_id=45365 Fixed in Mac/OSX/Makefile rev. 1.33. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675745&group_id=5470 From noreply@sourceforge.net Tue Jan 28 22:23:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 14:23:11 -0800 Subject: [Python-bugs-list] [ python-Bugs-676346 ] String formatting operation Unicode problem. Message-ID: Bugs item #676346, was opened at 2003-01-28 21:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676346&group_id=5470 Category: Unicode Group: Python 2.2.2 Status: Open Resolution: None >Priority: 3 Submitted By: David M. Grimes (dmgrime) Assigned to: M.-A. Lemburg (lemburg) Summary: String formatting operation Unicode problem. Initial Comment: When performing a string formatting operation using %s and a unicode argument, the argument evaluation is performed more than once. In certain environments (see example) this leads to excessive calls. It seems Python-2.2.2:Objects/stringobject.c:3394 is where PyObject_GetItem is used (for dictionary-like formatting args). Later, at :3509, there is a"goto unicode" when a string argument is actually unicode. At this point, everything resets and we do it all over again in PyUnicode_Format. There is an underlying assumption that the cost of the call to PyObject_GetItem is very low (since we're going to do them all again for unicode). We've got a Python-based templating system which uses a very simple Mix-In class to facilitate flexible page generation. At the core is a simple __getitem__ implementation which maps calls to getattr(): class mixin: def __getitem__(self, name): print '%r::__getitem__(%s)' % (self, name) hook = getattr(self, name) if callable(hook): return hook() else: return hook Obviously, the print is diagnostic. So, this basic mechanism allows one to write hierarchical templates filling in content found in "%(xxxx)s" escapes with functions returning strings. It has worked extremely well for us. BUT, we recently did some XML-based work which uncovered this strange unicode behaviour. Given the following classes: class w1u(mixin): v1 = u'v1' class w2u(mixin): def v2(self): return '%(v1)s' % w1u() class w3u(mixin): def v3(self): return '%(v2)s' % w2u() class w1(mixin): v1 = 'v1' class w2(mixin): def v2(self): return '%(v1)s' % w1() class w3(mixin): def v3(self): return '%(v2)s' % w2() And test case: print 'All string:' print '%(v3)s' % w3() print print 'Unicode injected at w1u:' print '%(v3)s' % w3u() print As we can see, the only difference between the w{1,2,3} and w{1,2,3}u classes is that w1u defines v1 as unicode where w1 uses a "normal" string. What we see is the string-based one shows 3 calls, as expected: All string: <__main__.w3 instance at 0x8150524>::__getitem__(v3) <__main__.w2 instance at 0x814effc>::__getitem__(v2) <__main__.w1 instance at 0x814f024>::__getitem__(v1) v1 But the unicode causes a tree-like recursion: Unicode injected at w1u: <__main__.w3u instance at 0x8150524>::__getitem__(v3) <__main__.w2u instance at 0x814effc>::__getitem__(v2) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w2u instance at 0x814effc>::__getitem__(v2) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w3u instance at 0x8150524>::__getitem__(v3) <__main__.w2u instance at 0x814effc>::__getitem__(v2) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w2u instance at 0x814effc>::__getitem__(v2) <__main__.w1u instance at 0x814f024>::__getitem__(v1) <__main__.w1u instance at 0x814f024>::__getitem__(v1) v1 I'm sure this isn't a "common" use of the string formatting mechanism, but it seems that evaluating the arguments multiple times could be a bad thing. It certainly is for us 8^) We're running this on a RedHat 7.3/8.0 setup, not that it appears to matter (from looking in stringojbect.c). Also appears to still be a problem in 2.3a1. Any comments? Help? Questions? ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-01-28 23:23 Message: Logged In: YES user_id=38388 I don't see how you can avoid fetching the Unicode argument a second time without restructuring the formatting code altogether. If you know that your arguments can be Unicode, you should start with a Unicode formatting string to begin with. That's faster and doesn't involve a fallback solution. If you still want to see this fixed, I'd suggest to submit a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676346&group_id=5470 From noreply@sourceforge.net Tue Jan 28 23:59:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 15:59:58 -0800 Subject: [Python-bugs-list] [ python-Bugs-665761 ] reduce() masks exception Message-ID: Bugs item #665761, was opened at 2003-01-10 09:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665761&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 3 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: reduce() masks exception Initial Comment: In the following test script ----- class Test: def __iter__(self): raise IOError reduce(lambda x,y: x+y, Test()) ----- the real IOError exception is masked, i.e. the traceback is ----- Traceback (most recent call last): File "test.py", line 5, in ? reduce(lambda x,y: x+y, Test()) TypeError: reduce() arg 2 must support iteration ----- but IMHO should be ----- Traceback (most recent call last): File "test.py", line 3, in ? raise IOError IOError ----- This can be fixed by removing the PyErr_SetString(PyExc_TypeError, "reduce() arg 2 must support iteration") call in bltinmodule.c/buildtin_reduce(). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-28 18:59 Message: Logged In: YES user_id=80475 One way to mitigate the information loss is to mimic the style in zip() which only traps TypeErrors but passes through things like the IOError in your original example. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-28 15:38 Message: Logged In: YES user_id=89016 Attached is a patch that fixes reduce(), map() and zip(). Unfortunately this loses the information about which argument triggered the exception (in map() and zip()) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-24 23:00 Message: Logged In: YES user_id=80475 There's a lot of this going around. map() and zip() have the same issue. I recommend fixing them all. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-13 08:18 Message: Logged In: YES user_id=89016 The point is that Python/bltinmodule.c/builtin_reduce() masks the error returned from PyObject_GetIter(). Errors from PyIter_Next() are not masked. What about the following example: class LazyFile: def __init__(self, name, mode="r"): self.name = name self.mode = mode def __iter__(self): return open(self.name, self.mode) import operator f = LazyFile("does not exist") s = reduce(operator.add, f) LazyFile *does* support iteration, but the underlying problem of the non existing file is masked. Removing the call PyErr_SetString(PyExc_TypeError, "reduce() arg 2 must support iteration"); in builtin_reduce(), will produce the original exception "IOError: [Errno 2] No such file or directory: 'does not exist'" and when the second argument is not iteratable, the original exception is just as good: >>> reduce(lambda x,y: x+y, 42) Traceback (most recent call last): File "", line 1, in ? TypeError: iteration over non-sequence ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2003-01-11 12:08 Message: Logged In: YES user_id=366566 the __iter__ method is supposed to return an object that defines a 'next' method. The returned object is the one used for iteration, not the original. So I believe the error message is correct - Test does not support iteration. If you change the code to: >>> class test: ... def __iter__(self): ... return self ... def next(self): ... raise IOError ... >>> reduce(operator.add, test()) You get the expected result... Traceback (most recent call last):   File "", line 1, in ?   File "", line 5, in next IOError ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665761&group_id=5470 From noreply@sourceforge.net Wed Jan 29 00:15:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 16:15:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-675259 ] os.environ leaks under FreeBSD and Mac OS X Message-ID: Bugs item #675259, was opened at 2003-01-27 16:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675259&group_id=5470 Category: Documentation Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: os.environ leaks under FreeBSD and Mac OS X Initial Comment: If this sort if thing is documented anywhere, the putenv(3) method leaks under FreeBSD and Mac OS X (Mac OS X documents it as a bug they inherited from the FreeBSD codebase in the man page). So don't set environment variables in a loop. ---------------------------------------------------------------------- >Comment By: Stuart Bishop (zenzen) Date: 2003-01-29 11:15 Message: Logged In: YES user_id=46639 Relevant URL's: http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/19406 http://www.freebsd.org/cgi/query-pr.cgi?pr=10341 http://www.freebsd.org/cgi/query-pr.cgi?pr=5604 An alternative may be to bypass the putenv(3) method on these platforms and manipulate environ manually in which case this is not a documentation bug but a feature request. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675259&group_id=5470 From noreply@sourceforge.net Wed Jan 29 00:31:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 16:31:03 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-676478 ] PythonLauncher to honour #! Message-ID: Feature Requests item #676478, was opened at 2003-01-28 16:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=676478&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Nobody/Anonymous (nobody) Summary: PythonLauncher to honour #! Initial Comment: >From pythonmac-sig: >> We are still missing a step however. If I have it right, you can tell >> finder that you want a *.py or *.pyw file opened with (*and run by) the >> python interpreter. What would be great is if that file go opened be a >> samll utility that looked at the #! line and opened it with the correct >> interpreter (I suppose that utility could be a simple shell script, come >> to think of it). That way, one could have programs written for various >> versions of Python all on one machine, and be able to run them easily >> from the GUI. I suppose BuildApplet (if it exists for OS-X) can do the >> same thing, but I kind of like the cross-platform elegance of the #! >> line. The Windows folks could do the same thing as well... > > > It's not quite the same but if you set the properties such that you are using the PythonLauncher from 2.3 then if you hold down the Alt key while double clicking a .py or .pyw file in Finder then you will get an opportunity to specify which python is executed. I missed the original post (or was it to another mailing list?), but I think that a PythonLauncher preference "Honour #! lines in scripts" is a good idea. If you file a feature request on sourceforge I won't forget about it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=676478&group_id=5470 From noreply@sourceforge.net Wed Jan 29 02:05:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 18:05:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-673115 ] causes crash on Windows2000 Message-ID: Bugs item #673115, was opened at 2003-01-23 10:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=673115&group_id=5470 Category: Tkinter Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Toru Furukawa (torufurukawa) Assigned to: Nobody/Anonymous (nobody) Summary: causes crash on Windows2000 Initial Comment: When using a mouse wheel on the code below, I got the error message dialog, saying "Program Error python.exe has generated errors and will be closed by Windows. You will need to restart the program. An error log is being created. [OK]" #---- def foo(event): print "foo" import Tkinter win = Tkinter.Tk() win.bind("", foo) win.mainloop() #---- It happens on Windows2000SP1 + Python 2.2.2. It works on WindowsXP + Python 2.2.2. Other events, like , works fine on Windows2k. The attached file is the log file created at the crash. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 21:05 Message: Logged In: YES user_id=33168 This is most likely a Tk library problem (not Tkinter). You can verify this if you have tcl/tk installed. The tcl program below is roughly the same as the python code. The tcl command interpreter name is wish. wish #---- tcl program starts here % proc foo { args } { puts "foo" } % bind . "" foo #---- Can you test this? Can you test with 2.3a1? I believe this comes with a different version of Tk. That may also fix the problem. BTW, there is no file attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=673115&group_id=5470 From noreply@sourceforge.net Wed Jan 29 02:17:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 18:17:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-602627 ] pydoc -g dumps core on Solaris 2.8 Message-ID: Bugs item #602627, was opened at 2002-08-30 16:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602627&group_id=5470 Category: Demos and Tools Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc -g dumps core on Solaris 2.8 Initial Comment: Python 2.2.1, Solaris 2.8, gcc 3.2, binutils 2.12.1 When I execute "pydoc -g", it pops up a dialog box saying "Starting server" and "Search for", and then dumps core before I have time to type anything. The same problem happens on Solaris 2.7 The traceback: Core was generated by `/usr/gnu/bin/python /usr/gnu/bin/pydoc -g'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libsocket.so.1...done. Loaded symbols for /usr/lib/libsocket.so.1 Reading symbols from /usr/lib/libnsl.so.1...done. Loaded symbols for /usr/lib/libnsl.so.1 Reading symbols from /usr/lib/libdl.so.1...done. Loaded symbols for /usr/lib/libdl.so.1 Reading symbols from /usr/lib/libpthread.so.1...done. Loaded symbols for /usr/lib/libpthread.so.1 Reading symbols from /usr/lib/libthread.so.1...done. Loaded symbols for /usr/lib/libthread.so.1 Reading symbols from /usr/gnu/lib/libreadline.so.4...done. Loaded symbols for /usr/gnu/lib/libreadline.so.4 Reading symbols from /usr/lib/libcurses.so.1...done. Loaded symbols for /usr/lib/libcurses.so.1 Reading symbols from /usr/lib/libcrypt_i.so.1...done. Loaded symbols for /usr/lib/libcrypt_i.so.1 Reading symbols from /usr/gnu/lib/libtk8.3.so...done. Loaded symbols for /usr/gnu/lib/libtk8.3.so Reading symbols from /usr/gnu/lib/libtcl8.3.so...done. Loaded symbols for /usr/gnu/lib/libtcl8.3.so Reading symbols from /usr/lib/libX11.so.4...done. Loaded symbols for /usr/lib/libX11.so.4 Reading symbols from /usr/lib/libm.so.1...done. Loaded symbols for /usr/lib/libm.so.1 Reading symbols from /usr/lib/libc.so.1...done. Loaded symbols for /usr/lib/libc.so.1 Reading symbols from /usr/gnu/lib/libgcc_s.so.1...done. Loaded symbols for /usr/gnu/lib/libgcc_s.so.1 Reading symbols from /usr/lib/libmp.so.2...done. Loaded symbols for /usr/lib/libmp.so.2 Reading symbols from /usr/lib/libgen.so.1...done. Loaded symbols for /usr/lib/libgen.so.1 Reading symbols from /usr/openwin/lib/libXext.so.0...done. Loaded symbols for /usr/openwin/lib/libXext.so.0 Reading symbols from /usr/openwin/lib/libdga.so.1...done. Loaded symbols for /usr/openwin/lib/libdga.so.1 Reading symbols from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1...done. Loaded symbols for /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1 Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/strop.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/strop.so Reading symbols from /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2...done. Loaded symbols for /usr/lib/locale/en_US.ISO8859-1/en_US.ISO8859-1.so.2 Reading symbols from /usr/openwin/lib/locale/common/xlibi18n.so.2...done. Loaded symbols for /usr/openwin/lib/locale/common/xlibi18n.so.2 Reading symbols from /usr/openwin/lib/locale/common/ximlocal.so.2...done. Loaded symbols for /usr/openwin/lib/locale/common/ximlocal.so.2 Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/time.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/time.so Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/errno.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/errno.so Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/_socket.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/_socket.so Reading symbols from /usr/gnu/lib/python2.2/lib-dynload/select.so...done. Loaded symbols for /usr/gnu/lib/python2.2/lib-dynload/select.so #0 0xff0b2be0 in Tk_FreeGC () from /usr/gnu/lib/libtk8.3.so (gdb) bt #0 0xff0b2be0 in Tk_FreeGC () from /usr/gnu/lib/libtk8.3.so #1 0xff0da71c in TkButtonWorldChanged () from /usr/gnu/lib/libtk8.3.so #2 0xff0da66c in ConfigureButton () from /usr/gnu/lib/libtk8.3.so #3 0xff0d9dc8 in ButtonWidgetObjCmd () from /usr/gnu/lib/libtk8.3.so #4 0xfefe0b50 in EvalObjv () from /usr/gnu/lib/libtcl8.3.so #5 0xfefe0c80 in Tcl_EvalObjv () from /usr/gnu/lib/libtcl8.3.so #6 0x0008deb8 in Tkapp_Call (self=0x159c88, args=0x2c60d8) at Modules/_tkinter.c:619 #7 0x00049e28 in fast_cfunction (func=0x159c88, pp_stack=0xfe908780, na=1089160) at Python/ceval.c:3131 #8 0x00047ea0 in eval_frame (f=0x1cc7c0) at Python/ceval.c:2007 #9 0x00048b30 in PyEval_EvalCodeEx (co=0x220340, globals=0x1cc7c0, locals=0x0, args=0x8, argcount=1, kws=0x1c1dd8, kwcount=1, defs=0x1d76ec, defcount=1, closure=0x0) at Python/ceval.c:2585 #10 0x00049f20 in fast_function (func=0x1, pp_stack=0x8, n=1842656, na=1, nk=1) at Python/ceval.c:3161 #11 0x00047de0 in eval_frame (f=0x1c1c80) at Python/ceval.c:2024 #12 0x00048b30 in PyEval_EvalCodeEx (co=0x1983a8, globals=0x1c1c80, locals=0x0, args=0x30fd50, argcount=2, kws=0x30fd58, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #13 0x00049f20 in fast_function (func=0x0, pp_stack=0x30fd50, n=3210584, na=2, nk=0) at Python/ceval.c:3161 #14 0x00047de0 in eval_frame (f=0x30fc00) at Python/ceval.c:2024 #15 0x00048b30 in PyEval_EvalCodeEx (co=0x12f788, globals=0x30fc00, locals=0x0, args=0x1c0bc8, argcount=1, kws=0x1c0bcc, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #16 0x00049f20 in fast_function (func=0x0, pp_stack=0x1c0bc8, n=1838028, na=1, nk=0) at Python/ceval.c:3161 #17 0x00047de0 in eval_frame (f=0x1c0a70) at Python/ceval.c:2024 #18 0x00048b30 in PyEval_EvalCodeEx (co=0x300058, globals=0x1c0a70, locals=0x0, args=0x301a6c, argcount=3, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #19 0x000aaa9c in function_call (func=0x2fc3c0, arg=0x301a60, kw=0x0) at Objects/funcobject.c:374 #20 0x00095d00 in PyObject_Call (func=0x2fc3c0, arg=0x301a60, kw=0x0) at Objects/abstract.c:1684 #21 0x0009e644 in instancemethod_call (func=0x2fc3c0, arg=0x301a60, kw=0x0) at Objects/classobject.c:2276 #22 0x00095d00 in PyObject_Call (func=0x2fc3c0, arg=0x301a60, kw=0x0) at Objects/abstract.c:1684 #23 0x00049fe4 in do_call (func=0x2c5718, pp_stack=0xfe908fd8, na=3, nk=3152480) at Python/ceval.c:3262 #24 0x00047d28 in eval_frame (f=0x1cc5f8) at Python/ceval.c:2027 #25 0x00048b30 in PyEval_EvalCodeEx (co=0x12f398, globals=0x1cc5f8, locals=0x0, args=0x2cba54, argcount=3, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #26 0x000aaa9c in function_call (func=0x301bf0, arg=0x2cba48, kw=0x0) at Objects/funcobject.c:374 #27 0x00095d00 in PyObject_Call (func=0x301bf0, arg=0x2cba48, kw=0x0) at Objects/abstract.c:1684 #28 0x0009e644 in instancemethod_call (func=0x301bf0, arg=0x2cba48, kw=0x0) at Objects/classobject.c:2276 #29 0x00095d00 in PyObject_Call (func=0x301bf0, arg=0x2e3bb0, kw=0x0) at Objects/abstract.c:1684 #30 0x00049c94 in PyEval_CallObjectWithKeywords (func=0x2da810, arg=0x2e3bb0, kw=0x0) at Python/ceval.c:3049 #31 0x00097d9c in PyInstance_New (klass=0x2da810, arg=0x2e3bb0, kw=0x0) at Objects/classobject.c:557 #32 0x00095d00 in PyObject_Call (func=0x2da810, arg=0x2e3bb0, kw=0x0) at Objects/abstract.c:1684 #33 0x00049fe4 in do_call (func=0x316828, pp_stack=0xfe9094a0, na=2, nk=3029936) at Python/ceval.c:3262 #34 0x00047d28 in eval_frame (f=0x1a3d20) at Python/ceval.c:2027 #35 0x00048b30 in PyEval_EvalCodeEx (co=0x12fab0, globals=0x1a3d20, locals=0x0, args=0x186414, argcount=3, kws=0x2b1228, kwcount=0, defs=0x1cd87c, defcount=2, closure=0x0) at Python/ceval.c:2585 #36 0x000aaa9c in function_call (func=0x1d1dc8, arg=0x186408, kw=0x2d6238) at Objects/funcobject.c:374 #37 0x00095d00 in PyObject_Call (func=0x1d1dc8, arg=0x186408, kw=0x2d6238) at Objects/abstract.c:1684 #38 0x00049c94 in PyEval_CallObjectWithKeywords (func=0x1d1dc8, arg=0x186408, kw=0x2d6238) at Python/ceval.c:3049 #39 0x000bcb3c in builtin_apply (self=0x0, args=0x1d1dc8) at Python/bltinmodule.c:95 #40 0x000ba398 in PyCFunction_Call (func=0x101d18, arg=0x1c4910, kw=0x0) at Objects/methodobject.c:69 #41 0x00047ec8 in eval_frame (f=0x1a4078) at Python/ceval.c:2004 #42 0x00048b30 in PyEval_EvalCodeEx (co=0x2c86c8, globals=0x1a4078, locals=0x0, args=0x1612d4, argcount=1, kws=0x1612d8, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #43 0x00049f20 in fast_function (func=0x0, pp_stack=0x1612d4, n=1446616, na=1, nk=0) at Python/ceval.c:3161 #44 0x00047de0 in eval_frame (f=0x161180) at Python/ceval.c:2024 #45 0x00048b30 in PyEval_EvalCodeEx (co=0x2c8cd0, globals=0x161180, locals=0x0, args=0x265e4c, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2585 #46 0x000aaa9c in function_call (func=0x2d6518, arg=0x265e40, kw=0x0) at Objects/funcobject.c:374 #47 0x00095d00 in PyObject_Call (func=0x2d6518, arg=0x265e40, kw=0x0) at Objects/abstract.c:1684 #48 0x0009e644 in instancemethod_call (func=0x2d6518, arg=0x265e40, kw=0x0) at Objects/classobject.c:2276 #49 0x00095d00 in PyObject_Call (func=0x2d6518, arg=0x100368, kw=0x0) at Objects/abstract.c:1684 #50 0x00049c94 in PyEval_CallObjectWithKeywords (func=0x2d7350, arg=0x100368, kw=0x0) at Python/ceval.c:3049 #51 0x0007f508 in t_bootstrap (boot_raw=0x28bdf8) at Modules/threadmodule.c:190 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 21:17 Message: Logged In: YES user_id=33168 I notice that you are using Tk 8.4. Have you (or can you) tried with Tk 8.3? Do you have the most recent version 8.4.1 from Oct 22, 2002? ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2003-01-06 12:10 Message: Logged In: YES user_id=418174 I rebuilt python with -O0 and it still crashes. The new traceback is attached. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-06 08:46 Message: Logged In: YES user_id=33168 Andrew, could I get you to look at bug 662787? http://python.org/sf/662787 We are having problems with solaris boxes and could use some help. Thanks. ---------------------------------------------------------------------- Comment By: Andrew Koenig (arkoenig) Date: 2002-09-17 10:54 Message: Logged In: YES user_id=418174 I rebuilt python from scratch by saying "make configure", then going into Makefile and removing "-O3" from the definition of the OPT macro, then saying "make". The resulting python still dumps core when executing "./python Lib/pydoc.py -g". Of course there could still be a platform or optimization dependency in tcl, or tk, or some other library. Suggestions? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-13 21:30 Message: Logged In: YES user_id=33168 I built python 2.2.1+ w/gcc 2.95.3 and did not have the problem. So I think this may be specific to gcc 3.2. Can you try building w/lower optimization or turning off optimization? -O1, -O0 or no -O option? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=602627&group_id=5470 From noreply@sourceforge.net Wed Jan 29 02:22:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 18:22:50 -0800 Subject: [Python-bugs-list] [ python-Bugs-583477 ] wrong dest size Message-ID: Bugs item #583477, was opened at 2002-07-18 14:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=583477&group_id=5470 Category: Unicode Group: Python 2.2.1 Status: Open Resolution: None Priority: 5 Submitted By: Doug Marien (dougslug) Assigned to: Mark Hammond (mhammond) Summary: wrong dest size Initial Comment: OS: nt (win2k) In getpathp.c on line 325 in the call to WideCharToMultiByte(), the destination size should be reqdSize+1 and not dataSize+1. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 21:22 Message: Logged In: YES user_id=33168 Mark, I'm just pinging you. The suggestion looks like it could be correct. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-07-26 12:33 Message: Logged In: YES user_id=38388 Passed on to Mark ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=583477&group_id=5470 From noreply@sourceforge.net Wed Jan 29 02:24:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 18:24:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-576711 ] Windows binary missing SSL Message-ID: Bugs item #576711, was opened at 2002-07-02 22:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576711&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: Accepted Priority: 5 Submitted By: Dave Schuyler (parameter) Assigned to: Mark Hammond (mhammond) Summary: Windows binary missing SSL Initial Comment: The Windows binary build from www.python.org appears to be missing SSL support (-DUSE_SSL ?). Please consider including SSL/HTTPS support "out of the box" for Windows users. Here's an example of what I tried (although I changed the server name): Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> import httplib >>> conn=httplib.HTTPSConnection ("some.secure.server.com") >>> conn.request("GET", "/index.php") Traceback (most recent call last): File "", line 1, in ? conn.request("GET", "/index.php") File "C:\Python22\lib\httplib.py", line 537, in request self._send_request(method, url, body, headers) File "C:\Python22\lib\httplib.py", line 553, in _send_request self.putrequest(method, url) File "C:\Python22\lib\httplib.py", line 453, in putrequest self.send(str) File "C:\Python22\lib\httplib.py", line 395, in send self.connect() File "C:\Python22\lib\httplib.py", line 688, in connect ssl = socket.ssl(realsock, self.key_file, self.cert_file) AttributeError: 'module' object has no attribute 'ssl' ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 21:24 Message: Logged In: YES user_id=33168 Tim/Mark, should this be closed? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-03 23:22 Message: Logged In: YES user_id=31435 Great work, Mark! I hit some snags doing this stuff on Win98SE, but got it all working and checked in. There's no reason I can see to keep this report open anymore. BTW, is test_socket_ssl.py the only test we've got for this? It passes here, so if that's all there is, I can't think of anything else remaining to do. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-12-03 01:36 Message: Logged In: YES user_id=14198 OK - all checked in and ready to close once the dust settles. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-02 23:14 Message: Logged In: YES user_id=31435 Check it in -- that's a good way to force the issue. I certainly approve of the concept . ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-07-23 01:46 Message: Logged In: YES user_id=14198 Sorry Tim, but you are the Windows build god . I assume this wont be looked at until closer to an RC, which is fine by me. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-07-09 01:22 Message: Logged In: YES user_id=14198 OK - here we go :) Attaching a hack to try and get SSL working without too much pain! There is a .py file that attempts to locate an OpenSSL installation to use. As these seem to be released often, the script looks for the latest non-beta OpenSSL directory. If the OpenSSL directory does not have makefiles, it attempts to generate these makefiles (which uses Perl). Unfortunately, you need ActivePerl for this to work, and I try and make some effort towards ensuring a working perl is found and is used. Once done, this script then simply invokes a makefile to build the SSL module itself. An integrated patch will come after feedback. But for now, to test this you can: * Download and install OpenSSL, and install this in the same place other libs used by Python are installed, such as zlib. This should be in the "..\.." directory relative to the "PCBuild" directory. * Ensure ActivePerl is installed on your box, and is either on your path, or in "\perl\bin" or "c:\perl\bin" * Install the 3 files in this patch (_ssl.mak, build_ssl.py and _ssl.dsp) in the "PCBuild" directory. * In your Python MSVC workspace, add this new "_ssl.dsp" as a project, and make it depend on the "pythoncore" project. * Build the new project. If all goes well, OpenSSL will be configured and have makefiles generated, be built, and then have the _ssl.pyd module built. Lemme know how it goes! ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-07-04 01:28 Message: Logged In: YES user_id=163326 I've successfully built socket.pyd against OpenSSL on win32: Build OpenSSL: read the README that's included. You basically need Perl and I also use NASM to build the highly optimized version of it. Add the OpenSSL include path (inc32, IIRC) for the socket module. Add the OpenSSL library path (lib32, IIRC) for the socket module. Add the two .lib files that can be found in lib32 to the libraries to link against. I think this is all that's involved. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-07-02 22:50 Message: Logged In: YES user_id=31435 Mark, does this interest you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576711&group_id=5470 From noreply@sourceforge.net Wed Jan 29 02:28:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 18:28:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-676521 ] parser module validation failure Message-ID: Bugs item #676521, was opened at 2003-01-28 20:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676521&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Grant T. Olson (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: parser module validation failure Initial Comment: C:\>c:\python23\python Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import parser >>> a = file('c:\python23\lib\base64.py').read() >>> b = parser.suite(a) >>> c = parser.ast2tuple(b) >>> d = parser.sequence2ast(c) Traceback (most recent call last): File "", line 1, in ? parser.ParserError: VALIDATION FAILURE: report this to the maintainer! >>> ^Z C:\> Problem also occurred on Python 2.2.2 on WinXP and RedHat 7.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676521&group_id=5470 From noreply@sourceforge.net Wed Jan 29 02:36:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 18:36:04 -0800 Subject: [Python-bugs-list] [ python-Bugs-474986 ] minidom doesn't implement importNode() Message-ID: Bugs item #474986, was opened at 2001-10-25 14:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474986&group_id=5470 Category: XML Group: Feature Request Status: Open Resolution: None Priority: 4 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: minidom doesn't implement importNode() Initial Comment: The Document.importNode() method has not been implemented; this would be very useful for many applications. See: http://mail.python.org/pipermail/xml-sig/2001-October/006252.html ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 21:36 Message: Logged In: YES user_id=33168 Now that PyXML has been integrated, should this be closed? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-09 18:58 Message: Logged In: YES user_id=3066 This has been fixed in PyXML 0.8, and will be integrated in Python before the 2.3 release cycle begins. Left open so I don't forget. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474986&group_id=5470 From noreply@sourceforge.net Wed Jan 29 02:41:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 18:41:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-413144 ] sdist can't create empty directories Message-ID: Bugs item #413144, was opened at 2001-04-02 11:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=413144&group_id=5470 Category: Distutils Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: sdist can't create empty directories Initial Comment: If a file fails an os.path.isfile() check, sdist.py skips it and prints a warning. That's probably worth loosening so an empty directory can be created in a source distribution by listing it in the MANIFEST. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 21:41 Message: Logged In: YES user_id=33168 amk, should this be fixed? Is the problem at line 420 in distutils/command/sdist.py? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=413144&group_id=5470 From noreply@sourceforge.net Wed Jan 29 02:39:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 18:39:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-576711 ] Windows binary missing SSL Message-ID: Bugs item #576711, was opened at 2002-07-03 12:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576711&group_id=5470 Category: Windows Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dave Schuyler (parameter) Assigned to: Mark Hammond (mhammond) Summary: Windows binary missing SSL Initial Comment: The Windows binary build from www.python.org appears to be missing SSL support (-DUSE_SSL ?). Please consider including SSL/HTTPS support "out of the box" for Windows users. Here's an example of what I tried (although I changed the server name): Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> import httplib >>> conn=httplib.HTTPSConnection ("some.secure.server.com") >>> conn.request("GET", "/index.php") Traceback (most recent call last): File "", line 1, in ? conn.request("GET", "/index.php") File "C:\Python22\lib\httplib.py", line 537, in request self._send_request(method, url, body, headers) File "C:\Python22\lib\httplib.py", line 553, in _send_request self.putrequest(method, url) File "C:\Python22\lib\httplib.py", line 453, in putrequest self.send(str) File "C:\Python22\lib\httplib.py", line 395, in send self.connect() File "C:\Python22\lib\httplib.py", line 688, in connect ssl = socket.ssl(realsock, self.key_file, self.cert_file) AttributeError: 'module' object has no attribute 'ssl' ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-01-29 13:39 Message: Logged In: YES user_id=14198 yep :) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-29 13:24 Message: Logged In: YES user_id=33168 Tim/Mark, should this be closed? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-04 15:22 Message: Logged In: YES user_id=31435 Great work, Mark! I hit some snags doing this stuff on Win98SE, but got it all working and checked in. There's no reason I can see to keep this report open anymore. BTW, is test_socket_ssl.py the only test we've got for this? It passes here, so if that's all there is, I can't think of anything else remaining to do. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-12-03 17:36 Message: Logged In: YES user_id=14198 OK - all checked in and ready to close once the dust settles. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-12-03 15:14 Message: Logged In: YES user_id=31435 Check it in -- that's a good way to force the issue. I certainly approve of the concept . ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-07-23 15:46 Message: Logged In: YES user_id=14198 Sorry Tim, but you are the Windows build god . I assume this wont be looked at until closer to an RC, which is fine by me. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2002-07-09 15:22 Message: Logged In: YES user_id=14198 OK - here we go :) Attaching a hack to try and get SSL working without too much pain! There is a .py file that attempts to locate an OpenSSL installation to use. As these seem to be released often, the script looks for the latest non-beta OpenSSL directory. If the OpenSSL directory does not have makefiles, it attempts to generate these makefiles (which uses Perl). Unfortunately, you need ActivePerl for this to work, and I try and make some effort towards ensuring a working perl is found and is used. Once done, this script then simply invokes a makefile to build the SSL module itself. An integrated patch will come after feedback. But for now, to test this you can: * Download and install OpenSSL, and install this in the same place other libs used by Python are installed, such as zlib. This should be in the "..\.." directory relative to the "PCBuild" directory. * Ensure ActivePerl is installed on your box, and is either on your path, or in "\perl\bin" or "c:\perl\bin" * Install the 3 files in this patch (_ssl.mak, build_ssl.py and _ssl.dsp) in the "PCBuild" directory. * In your Python MSVC workspace, add this new "_ssl.dsp" as a project, and make it depend on the "pythoncore" project. * Build the new project. If all goes well, OpenSSL will be configured and have makefiles generated, be built, and then have the _ssl.pyd module built. Lemme know how it goes! ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-07-04 15:28 Message: Logged In: YES user_id=163326 I've successfully built socket.pyd against OpenSSL on win32: Build OpenSSL: read the README that's included. You basically need Perl and I also use NASM to build the highly optimized version of it. Add the OpenSSL include path (inc32, IIRC) for the socket module. Add the OpenSSL library path (lib32, IIRC) for the socket module. Add the two .lib files that can be found in lib32 to the libraries to link against. I think this is all that's involved. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-07-03 12:50 Message: Logged In: YES user_id=31435 Mark, does this interest you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=576711&group_id=5470 From noreply@sourceforge.net Wed Jan 29 02:46:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 18:46:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-676521 ] parser module validation failure Message-ID: Bugs item #676521, was opened at 2003-01-28 21:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676521&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: parser module validation failure Initial Comment: C:\>c:\python23\python Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import parser >>> a = file('c:\python23\lib\base64.py').read() >>> b = parser.suite(a) >>> c = parser.ast2tuple(b) >>> d = parser.sequence2ast(c) Traceback (most recent call last): File "", line 1, in ? parser.ParserError: VALIDATION FAILURE: report this to the maintainer! >>> ^Z C:\> Problem also occurred on Python 2.2.2 on WinXP and RedHat 7.3 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 21:46 Message: Logged In: YES user_id=33168 The problem is floor division // on the line: MAXBINSIZE = (MAXLINESIZE//4)*3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676521&group_id=5470 From noreply@sourceforge.net Wed Jan 29 04:12:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 28 Jan 2003 20:12:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-474986 ] minidom doesn't implement importNode() Message-ID: Bugs item #474986, was opened at 2001-10-25 14:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474986&group_id=5470 Category: XML Group: Feature Request >Status: Closed >Resolution: Fixed Priority: 4 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: minidom doesn't implement importNode() Initial Comment: The Document.importNode() method has not been implemented; this would be very useful for many applications. See: http://mail.python.org/pipermail/xml-sig/2001-October/006252.html ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-28 23:12 Message: Logged In: YES user_id=3066 Yes, and done. Thanks for the tickle! ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 21:36 Message: Logged In: YES user_id=33168 Now that PyXML has been integrated, should this be closed? ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-08-09 18:58 Message: Logged In: YES user_id=3066 This has been fixed in PyXML 0.8, and will be integrated in Python before the 2.3 release cycle begins. Left open so I don't forget. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474986&group_id=5470 From noreply@sourceforge.net Wed Jan 29 09:50:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 29 Jan 2003 01:50:31 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-676478 ] PythonLauncher to honour #! Message-ID: Feature Requests item #676478, was opened at 2003-01-29 01:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=676478&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Nobody/Anonymous (nobody) Summary: PythonLauncher to honour #! Initial Comment: >From pythonmac-sig: >> We are still missing a step however. If I have it right, you can tell >> finder that you want a *.py or *.pyw file opened with (*and run by) the >> python interpreter. What would be great is if that file go opened be a >> samll utility that looked at the #! line and opened it with the correct >> interpreter (I suppose that utility could be a simple shell script, come >> to think of it). That way, one could have programs written for various >> versions of Python all on one machine, and be able to run them easily >> from the GUI. I suppose BuildApplet (if it exists for OS-X) can do the >> same thing, but I kind of like the cross-platform elegance of the #! >> line. The Windows folks could do the same thing as well... > > > It's not quite the same but if you set the properties such that you are using the PythonLauncher from 2.3 then if you hold down the Alt key while double clicking a .py or .pyw file in Finder then you will get an opportunity to specify which python is executed. I missed the original post (or was it to another mailing list?), but I think that a PythonLauncher preference "Honour #! lines in scripts" is a good idea. If you file a feature request on sourceforge I won't forget about it. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-01-29 10:50 Message: Logged In: YES user_id=45365 Duplicate of #676358. (Robin, apparently Chris beat you to submitting this;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=676478&group_id=5470 From noreply@sourceforge.net Wed Jan 29 09:59:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 29 Jan 2003 01:59:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-674574 ] Access to serial devices through Carbon.CF Message-ID: Bugs item #674574, was opened at 2003-01-25 15:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674574&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Invalid Priority: 3 Submitted By: Pascal Oberndoerfer (pascal_efi) Assigned to: Jack Jansen (jackjansen) Summary: Access to serial devices through Carbon.CF Initial Comment: There is currently no wrapper to access serial RS232 devices (e.g. Keyspan USB-serial adaptor) through Carbon.CF on MacOS X. This was my short and dirty hack to get a list of currently available (Keyspan) serial devices: #!/usr/bin/env python import os import string PRE = 'cu' #PRE = 'tty' device_list = filter(lambda s: string.count(s, PRE+'.USA'), os.listdir('/dev/')) print device_list But as Jack said: Anything that is in CF but not wrapped in the Carbon.CF module should be considered a bug. I know there's still quite a bit missing, but if people put bug reports up on sourceforge that will influence the order in which I add stuff to the CF module. It would help a lot if you mentioned the data structure and/or some of the routines you need. -- - Jack Jansen http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman - Dan Grassi supposed (slightly paraphrased) to do the folowing on MacOS X with IORegistryExplorer (inside /Applications/Utilities) > Search for IOSerialBSDClient with a key of > IOSerialBSDClientType > with a value of IORS232SerialStream. > Then get the value of the > IODialinDevice (/dev/tty.*) or IOCalloutDevice (/dev/cu.*) ... For a single serial device this can result in: { CFBundleIdentifier = com.apple.iokit.IOSerialFamily; IOCalloutDevice = /dev/cu.USA19QW21P1.1; IOClass = IOSerialBSDClient; IODialinDevice = /dev/tty.USA19QW21P1.1; IOMatchCategory = IODefaultMatchCategory; IOPersonalityName = IOSerialBSDClientSync; IOProbeScore = 1000; IOProviderClass = IOSerialStreamSync; IOResourceMatch = IOBSD; IOSerialBSDClientType = IORS232SerialStream; IOTTYBaseName = USA19QW21P1.; IOTTYDevice = USA19QW21P1.1; IOTTYSuffix = 1; ParentKey = "KEXTBundle?com.apple.iokit.IOSerialFamily"; } So maybe return a list of dictionaries? Pascal (MacOS X, MacPython 2.3a1 [Framework Install]) ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-01-29 10:59 Message: Logged In: YES user_id=45365 I had a look through the documentation you referred to, and you would indeed need an interface to IOKit. I'm closing this report (as the title is misleading), if you really need IOKit file a feature request. But don't expect it to happen soon unless you contribute:-) ---------------------------------------------------------------------- Comment By: Pascal Oberndoerfer (pascal_efi) Date: 2003-01-26 08:53 Message: Logged In: YES user_id=688343 Jack, (sorry, quite long again) I was afraid you would ask -- because I don't know. So I went to the Apple docs and found some information that made me doubt if it's really Carbon.CF I am looking for. http://developer.apple.com/techpubs/macosx/Darwin/General/AccessingHardware/AH_Intro As I need "only" a list of accessible serial devices and the paths to their device files two chapters sounded interesting to me: 1. I/O Kit Hardware Access > • Using a Device Interface to Access a Device > - Finding Devices 2. Working With Serial I/O > • Working With a Serial Port Modem > - Setting Up Your Programming Environment - Setting Up a Main Function - Finding All Serial Port Modems - Getting the Path to the Device File for a Modem Finding all available serial ports and getting the path(s) to their respective device files. Opening, working with, and closing the ports is all done with pyserial. If I only understood the docs! (have I ever been in the need of an excellent example why I prefer Python over any other programming language? ;-) I found some sample code at Apple as well: http://developer.apple.com/samplecode/Sample_Code/Devices_and_Hardware/Serial/SerialPortSample.htm But again: I am not a professional programmer (especially not C) so I have no idea what it means or what to do with it. Hmm... Actually, if it is not possible to access this from CF then -- according to your definition -- it's not a bug but a feature request I guess. The reason it would be extremly nice to have this way to scan for the serial ports is that they disappear completely with the removal of the USB-adapter. But as there is a workaround priority is really low, low, low! Pascal PS: my motivation behind all this is a small data logging utility I need to write. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-01-25 23:46 Message: Logged In: YES user_id=45365 Pascal, could you tell me which bits of CF you need? I asume CFBundle, but would you need all of it, or just a part? Would you need anything more than CFBundle? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=674574&group_id=5470 From noreply@sourceforge.net Wed Jan 29 10:18:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 29 Jan 2003 02:18:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-508437 ] urllib.urlopen results.readline is slow Message-ID: Bugs item #508437, was opened at 2002-01-25 13:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=508437&group_id=5470 Category: Python Library Group: Python 2.2 Status: Deleted Resolution: Duplicate Priority: 5 Submitted By: Keith Davidson (kbdavidson) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlopen results.readline is slow Initial Comment: The socket file object underlying the return from urllib.urlopen() is opened without any buffering resulting in very slow performance of results.readline (). The specific problem is in the httplib.HTTPResponse constructor. It calls sock.makefile() with a 0 for the buffer size. Forcing the buffer size to 4096 results in the time for calling readline() on a 60K character line to go from 16 seconds to .27 seconds (there is other processing going on here but the magnitude of the difference is correct). I am using Python 2.0 so I can not submit a patch easily but the problem appears to still be present in the 2.2 source. The specific change is to change the 0 in sock.makefile() to 4096 or some other reasonable buffer size: class HTTPResponse: def __init__(self, sock, debuglevel=0): self.fp = sock.makefile('rb', 0) <= change to 4096 self.debuglevel = debuglevel ---------------------------------------------------------------------- Comment By: Mike Looijmans (milosoftware) Date: 2003-01-29 10:18 Message: Logged In: YES user_id=698929 I worked around this problem by subclassing HTTPResponse. This will work fine on any Python version 2.x and you won't have to patch anything. Performance increased from 100kB/s to 1500kb/s on my system (factor 15). Setting self.fp 'again' to makefile is dirty, but works thanks to the GC :-) # The following code works around the "bufferless" operation of # HTTPResponse. Its __init__ sets self.fp to sock.makefile('rb',0) # which in fact sets the receive buffer to size 1. This cause so # much CPU overhead, that network performance is slowed down to # unacceptable levels. # This hack can only be used if you are sure that the server will # either close the connection after sending the file, or has a valid # content-length header so that the response object will not attempt # to read past EOF (which may cause deadlock). class FastHTTPResponse(httplib.HTTPResponse): def __init__(self, sock, debuglevel=0): httplib.HTTPResponse.__init__(self, sock, debuglevel) self.fp = sock.makefile('rb', 8192) # Tell the httplib that we want to use our hack. httplib.HTTPConnection.response_class = FastHTTPResponse ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=508437&group_id=5470 From noreply@sourceforge.net Wed Jan 29 10:23:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 29 Jan 2003 02:23:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-426866 ] urllib and socket fail with MS proxy Message-ID: Bugs item #426866, was opened at 2001-05-24 06:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=426866&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: urllib and socket fail with MS proxy Initial Comment: Both urllib and socket fail to work with MS proxy with winsock client install. urllib's proxy detection will correctly detect the existing of the proxy server but fail to work with it. It will return an empty page when an read() is issued. socket will report 1006 winsock error. ---------------------------------------------------------------------- Comment By: Mike Looijmans (milosoftware) Date: 2003-01-29 10:23 Message: Logged In: YES user_id=698929 Maybe this hint helps: The MS proxy apparently uses NT's built-in authorization, not really the 'basic' authentication as in RFC 2068. The distributed.net RC5 client suffered from the same problem, but they managed to work around it. You may find the solution there. The MS Proxy is included with MS Exchange server. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-31 23:44 Message: Logged In: YES user_id=6380 Can you see if the patch from SF bug 503031 (http://www.python.org/sf/503031) solves your problem? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-03-10 01:18 Message: Logged In: YES user_id=44345 Jeremy, I assigned this to you simply because you commented on it. It was submitted anonymously and the OP never responded to your comment. I think it should be marked "invalid" and closed. Whaddya think? Skip ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2001-07-06 16:16 Message: Logged In: YES user_id=31392 Can you provide more details? What is MS proxy? What URLs have you tried and what exactly is the response -- headers would help? Under what conditions does socket raise a winsock error? Do socket and urllib work on your platform without the proxy? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=426866&group_id=5470 From noreply@sourceforge.net Wed Jan 29 10:36:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 29 Jan 2003 02:36:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-676342 ] after using pdb readline does not work correctly Message-ID: Bugs item #676342, was opened at 2003-01-28 20:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676342&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Nobody/Anonymous (nobody) Summary: after using pdb readline does not work correctly Initial Comment: After I use pdb in the interpreter my readline settings are messed up. It only knows about the pdb readline stuff forever afterward. In fact, this happens as soon as a Pdb object is instantiated, regardless of whether or not you use it. This is a result of some aspects of the Cmd object in Lib/cmd.py. Currently Cmd registers a new readline completer as soon as a Cmd object is instantiated. This is probably incorrect. I believe the correct place to register the new handler is in the preloop hook. That way the new readline completer is only used while the Cmd object is actually responsible for processing user input. Next, the old readline completer should probably be re-registered in the postloop hook. In order to do this, a new call must be added to the readline module to return the current completer so it can be saved and later restored. The files included patch readline.c (version 2.41.64) and cmd.py (version 1.26.16.2) to make the changes described above. After this patch readline works as expected in the interpreter. Let me know what you think of it. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-01-29 10:36 Message: Logged In: YES user_id=6656 I approve of this patch in principle. I hadn't done enough investigation to see that it was so easy to get the current completer function! OTOH: return Py_BuildValue("O", completer); is sick. Change that to Py_INCREF(completer); return completer; and if noone else howls, I'll check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676342&group_id=5470 From noreply@sourceforge.net Wed Jan 29 10:52:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 29 Jan 2003 02:52:53 -0800 Subject: [Python-bugs-list] [ python-Bugs-676521 ] parser module validation failure Message-ID: Bugs item #676521, was opened at 2003-01-29 02:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676521&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: parser module validation failure Initial Comment: C:\>c:\python23\python Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import parser >>> a = file('c:\python23\lib\base64.py').read() >>> b = parser.suite(a) >>> c = parser.ast2tuple(b) >>> d = parser.sequence2ast(c) Traceback (most recent call last): File "", line 1, in ? parser.ParserError: VALIDATION FAILURE: report this to the maintainer! >>> ^Z C:\> Problem also occurred on Python 2.2.2 on WinXP and RedHat 7.3 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-01-29 10:52 Message: Logged In: YES user_id=6656 So the attached would be the fix, then? I feel a "How to change Python's grammar" informational PEP coming on... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-29 02:46 Message: Logged In: YES user_id=33168 The problem is floor division // on the line: MAXBINSIZE = (MAXLINESIZE//4)*3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676521&group_id=5470 From noreply@sourceforge.net Wed Jan 29 14:11:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 29 Jan 2003 06:11:39 -0800 Subject: [Python-bugs-list] [ python-Bugs-625698 ] Errors with recursive objects Message-ID: Bugs item #625698, was opened at 2002-10-19 19:27 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Erik Andersén (erik_andersen) Assigned to: Jeremy Hylton (jhylton) Summary: Errors with recursive objects Initial Comment: List and dictionaries put Python into an infinite loop if they contain more than one reference to itself >>> d = {} >>> d[1] = d >>> d == d # OK Python can handle one recursion 1 >>> d[2] = d >>> d == d # Crash with two Lists are similar >>> l=[] >>> l.append(l) >>> l==l # OK 1 >>> l.append(l) >>> l==l # Crash >>> l>l # Also crash Tested with ActivePython 2.2.1 under Windows 98 and (the first part) Python 2.2.2 under Linux ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2003-01-29 14:11 Message: Logged In: YES user_id=4771 Bisimulation is a cool tool that only works in "monotonic" settings, i.e. when the set of pairs of objects known to be equal is always growing and objects cannot become different when other objects are discovered to be equal. So the whole bisimulation thing is inconsistent with user-defined comparisons because these can use negations (there is no negation in the standard list and dict compares). I think the language definition should stick to the simple recursive definition of comparison, and thus be allowed to enter an infinite recursion. The interpreter should be Ctrl-C interruptible and raise a "RuntimeError: maximum recursion depth exceeded". This is similar to instance_call() in classobject.c. In particular I think the interpreter should not try to detect loops explicitely. Consider the case of someone who really wants to implement a bisimulation thing: >>> class X: ... def __eq__(self, other): ... if (self, other) in already_comparing: ... return True ... else: ... ... We must allow the same object's __eq__() method to be entered twice without raising any exception. I would say that the problem is similar to: >>> def f(): ... f() It is not the interpreter's role to detect the loop and raise an exception, but only to crash nicely when the recursion depth becomes critically large. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-23 18:57 Message: Logged In: YES user_id=31435 I'll attach a patch with a simple recursion latch. It handles the small examples fine. Make them bigger and sloth returns, though; e.g., this one takes more than 20 seconds after the patch (but longer than the lifetime of the universe without the patch): N = 1000 print "building a" a = [] for i in range(N): a.append(a) print "building b" b = [] for i in range(N): b.append(b) print "comparing" print a == b So long as inprogress entries don't outlive the comparison call that created them, it still leaves exponentially- compounding overhead to keep on recreating the entries that used to exist. But if an inprogress entry does outlive the comparison that created it, then the cached addresses may end up attached to objects other than the original comparands, and how to get each thread to eventually clear its inprogress dict becomes a puzzle and/or an expense. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-01-23 18:15 Message: Logged In: YES user_id=31392 Maybe I need to read the code again, but IIRC the code doesn't assume that id(a) == id(b) implies a == b. Rather it uses id(a) and id(b) to look for recursive calls to compare. It assumes that a == b will always produce the same result when invoked recursively within a comparison. I think a decent solution is to create a latch for the nesting limit. If a comparison ever exceeds the recursion limit, the check is done until the comparison is finished. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-22 03:09 Message: Logged In: YES user_id=31435 llit, you should study the current code before suggesting an algorithm. The current code would be blazing fast if it were looking for recursion from the start too. But the very process of building that dict with the ids of the objects as keys (which the current algorithm also does) costs more than most comparisons cost in real life. That's why the current code doesn't even try to catch recursion until the comparison level exceeds 20, and that's where the sloth comes from. Stick a gimmick like that in your algorithm, and you'll have similar speed problems. Also note that id(a) == id(b) doesn't imply a == b (see the other note about NaN for an example). ---------------------------------------------------------------------- Comment By: Till Plewe (llit) Date: 2003-01-21 06:01 Message: Logged In: YES user_id=540660 How about checking for equality by trying to build a bisimulation which "proves" equality. Time complexity is O(nodes(a) x nodes(b)) SAMPLE PYTHON CODE =============================== #! /usr/bin/env python from types import * SeqType=[ListType,DictType,TupleType] def isequal(a,b): if id(a)==id(b): return True compare={(id(a),id(b)):(a,b)} bisimilar={} while compare: (ida,idb),(oba,obb)=compare.popitem() if ida==idb: continue elif type(oba)==type(obb): if type(oba) not in SeqType: if oba!=obb: return False else: continue elif len(oba)!=len(obb): return False elif (ida,idb) not in bisimilar: bisimilar[(ida,idb)]=1 if type(oba)==DictType: for x in oba: #oba and obb have the same number of keys if x not in obb: return False else: compare[(id(oba[x]),id(obb[x]))]=(oba[x],obb[x]) else: for x,y in zip(oba,obb): compare[(id(x),id(y))]=(x,y) else: return False return bisimilar ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 20:44 Message: Logged In: YES user_id=31435 Cool. He's right that they can take a horrendously long time. The 2-element list example takes c*2**20 units of time, for some suitable constant c, and if it were extended to 3 elements, it would take c*3**20 units of time, thousands of times longer. As Erik's latest example shows, the outcome isn't always particularly well defined either. An alternative to speeding this silliness is to raise an exception instead when recursive objects are detected. There was some hack value in doing the graph isomorphism bit, but no real practical value I can see. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-20 20:20 Message: Logged In: YES user_id=33168 Sorry Tim, I was going to reply to one of your first msgs and forgot. Erik sent me mail which said there wasn't a crash, just that "the statements take horrendously long time to execute." ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 20:09 Message: Logged In: YES user_id=31435 BTW, Erik, what did you mean by "crash"? Nobody else has seen a crash here. You started the report by saying "infinite loop", which isn't the same thing as a crash. There isn't an infinite loop here either, although the algorithm can take astronomical amounts of time to finish (so may appear to be in an infinite loop). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 19:50 Message: Logged In: YES user_id=31435 Equailty for self-consistent recursive objects does a graph isomorphism computation. In your self-inconsistent example, it so happens that False is returned, although True would be returned if the compile-time constant (in object.c) NESTING_LIMIT were odd instead of even. But if you worry about this, you need to get out more . ---------------------------------------------------------------------- Comment By: Erik Andersén (erik_andersen) Date: 2003-01-20 19:24 Message: Logged In: YES user_id=364358 Excuse me for interupting the efficiency discussion, but what is the definition of equality for recursive containers. I am particularly worrided about cases like >>> class A: ... def __eq__(self,other): return not self.u==other.u ... >>> a=A() >>> l=[a] >>> a.u=l >>> l==l # ???? If l==l then a!=a and l[0]!=l[0], so l!=l. If l!=l then a==a and l[0]==l[0], so l==l !!!!!!! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 16:12 Message: Logged In: YES user_id=31435 I deleted my patch -- it didn't make sense. Martin, AFAIK the docs say nothing about the relationship (if any) between "is" and "==". It was deliberate intent that "is" not imply "==" for rich comparisons, though, in part so that IEEE-754 rules for NaN could be implemented by users. >>> class NaN: ... def __eq__(self, other): return False ... >>> n = NaN() >>> n is n True >>> n == n False >>> ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-20 08:20 Message: Logged In: YES user_id=21627 Where does the documentation say that "is" may not imply ==? The check for recursion assumes this implication, anyway: if we meet the very same object, we infer that they are equal. What is the purpose of clear_inprogress_dict in your patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-20 04:28 Message: Logged In: YES user_id=31435 The patch assumes "is" implies "==", which isn't necessarily so for rich comparisons. The attached patch cuts the time about in half, via: 1. Getting rid of the per-thread inprogress dicts, in favor of a shared inprogress dict. 2. Restoring the intent of the code that tuples be exempted (tuples can't be recursive). Rev 2.65 of tupleobject.c gave tuples a tp_as_mapping slot, breaking the intent of the code. 3. Changing the inprogress dict to map a tuple to the smallest value of compare_nesting at which the tuple was seen. delete_token() was changed to leave the token alone if the current compare_nesting value is greater than that. This allows tuples to stay in the dict longer. 4. Cutting NESTING_LIMIT from 20 to 19. This has a huge effect, because the algorithm is still basically exponential- time. The problem remaining is that the inprogress dict is still useless (and empty) so long as compare_nesting is less than NESTING_LIMIT. This can leave an exponential amount of work to be done to fight back up to NESTING_LIMIT. Leaving stuff in inprogress longer, and consulting inprogress regardless of the value of compare_nesting (provided that's gone over NESTING_LIMIT at least once) slashes the time to triviality. However, it isn't safe: we can't know that the addresses in the dict keys refer to the same objects then. We could if started storing into inprogress from the very start, but that would be a big speed hit for usual-case comparisons. I'd be happy to knock NESTING_LIMIT down more, though. Assigned to Jeremy, as IIRC this was his code originally. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-19 17:30 Message: Logged In: YES user_id=21627 The patch is fine, except that a comment needs to be added explaining what this does and why it does that. It should be understood that this can't fix the very similar case a = [] a.append(a) a.append(a) b = [] b.append(b) b.append(b) a==b This would still take a long time, right? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-19 16:05 Message: Logged In: YES user_id=33168 Attached is a patch which fixes the problem for me. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-08 00:59 Message: Logged In: YES user_id=33168 Erik, do you still have this problem with 2.2.2? I can't reproduce your problem under Linux. mly can't reproduce the problems with 2.2.1 on Windows (2000). Do you only have the problem on Windows? ---------------------------------------------------------------------- Comment By: Magnus Lyckå (mly) Date: 2002-10-26 23:12 Message: Logged In: YES user_id=95217 I tried the above under Python 2.2.1 (#34, Sep 27 2002, 18:37:42) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. (ActiveState on Win 2000) and Python 2.1.1 (#1, Aug 20 2001, 20:23:29) [GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.60mdk)] on linux-i386 In both cases it works correctly. No crash. It takes a lot of time though, Several seconds on Duron 700 w/ Win2k, and tens of seconds on K6-233 w/ Linux. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470 From noreply@sourceforge.net Wed Jan 29 14:17:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 29 Jan 2003 06:17:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-676521 ] parser module validation failure Message-ID: Bugs item #676521, was opened at 2003-01-28 21:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676521&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: parser module validation failure Initial Comment: C:\>c:\python23\python Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import parser >>> a = file('c:\python23\lib\base64.py').read() >>> b = parser.suite(a) >>> c = parser.ast2tuple(b) >>> d = parser.sequence2ast(c) Traceback (most recent call last): File "", line 1, in ? parser.ParserError: VALIDATION FAILURE: report this to the maintainer! >>> ^Z C:\> Problem also occurred on Python 2.2.2 on WinXP and RedHat 7.3 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-29 09:17 Message: Logged In: YES user_id=33168 I'm not familiar with the parser module (this is the first time I've looked at it). But the patch looks correct. As for the PEP, I think it's a good idea. It would help point out many details people (like me) are probably unaware of. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-29 05:52 Message: Logged In: YES user_id=6656 So the attached would be the fix, then? I feel a "How to change Python's grammar" informational PEP coming on... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 21:46 Message: Logged In: YES user_id=33168 The problem is floor division // on the line: MAXBINSIZE = (MAXLINESIZE//4)*3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676521&group_id=5470 From noreply@sourceforge.net Wed Jan 29 14:26:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 29 Jan 2003 06:26:45 -0800 Subject: [Python-bugs-list] [ python-Bugs-676521 ] parser module validation failure Message-ID: Bugs item #676521, was opened at 2003-01-29 02:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676521&group_id=5470 Category: Parser/Compiler Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: logistix (logistix) >Assigned to: Michael Hudson (mwh) Summary: parser module validation failure Initial Comment: C:\>c:\python23\python Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import parser >>> a = file('c:\python23\lib\base64.py').read() >>> b = parser.suite(a) >>> c = parser.ast2tuple(b) >>> d = parser.sequence2ast(c) Traceback (most recent call last): File "", line 1, in ? parser.ParserError: VALIDATION FAILURE: report this to the maintainer! >>> ^Z C:\> Problem also occurred on Python 2.2.2 on WinXP and RedHat 7.3 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-01-29 14:26 Message: Logged In: YES user_id=6656 Checked in as: Modules/parsermodule.c revision 2.75 Lib/test/test_parser.py 1.14 logistix, can you check this works for you? PEP already with editors. It wasn't very long, as it turned out. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-29 14:17 Message: Logged In: YES user_id=33168 I'm not familiar with the parser module (this is the first time I've looked at it). But the patch looks correct. As for the PEP, I think it's a good idea. It would help point out many details people (like me) are probably unaware of. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-29 10:52 Message: Logged In: YES user_id=6656 So the attached would be the fix, then? I feel a "How to change Python's grammar" informational PEP coming on... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-29 02:46 Message: Logged In: YES user_id=33168 The problem is floor division // on the line: MAXBINSIZE = (MAXLINESIZE//4)*3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676521&group_id=5470 From noreply@sourceforge.net Wed Jan 29 15:27:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 29 Jan 2003 07:27:34 -0800 Subject: [Python-bugs-list] [ python-Bugs-676342 ] after using pdb readline does not work correctly Message-ID: Bugs item #676342, was opened at 2003-01-28 20:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676342&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Nobody/Anonymous (nobody) Summary: after using pdb readline does not work correctly Initial Comment: After I use pdb in the interpreter my readline settings are messed up. It only knows about the pdb readline stuff forever afterward. In fact, this happens as soon as a Pdb object is instantiated, regardless of whether or not you use it. This is a result of some aspects of the Cmd object in Lib/cmd.py. Currently Cmd registers a new readline completer as soon as a Cmd object is instantiated. This is probably incorrect. I believe the correct place to register the new handler is in the preloop hook. That way the new readline completer is only used while the Cmd object is actually responsible for processing user input. Next, the old readline completer should probably be re-registered in the postloop hook. In order to do this, a new call must be added to the readline module to return the current completer so it can be saved and later restored. The files included patch readline.c (version 2.41.64) and cmd.py (version 1.26.16.2) to make the changes described above. After this patch readline works as expected in the interpreter. Let me know what you think of it. ---------------------------------------------------------------------- >Comment By: Michael Stone (mbrierst) Date: 2003-01-29 15:27 Message: Logged In: YES user_id=670441 I attached a changed readline.c patch to hopefully get rid of any "sickness". (There was a not-checking-for-null problem too... ouch) I think it's good now. But note, there may not be a way to do this sort of thing perfectly. If you mess around enough with starting debuggers within debuggers (or in general anything that uses a Cmd object) it might be possible to end up with an unexpected completer function in the end. And it looks like under the current system there's no way to get back the completer key that was initially used. But this isn't SUCH a big deal since I think everyone uses tab, right? At any rate, the change is definitely an improvement for me. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-29 10:36 Message: Logged In: YES user_id=6656 I approve of this patch in principle. I hadn't done enough investigation to see that it was so easy to get the current completer function! OTOH: return Py_BuildValue("O", completer); is sick. Change that to Py_INCREF(completer); return completer; and if noone else howls, I'll check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676342&group_id=5470 From noreply@sourceforge.net Wed Jan 29 17:37:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 29 Jan 2003 09:37:14 -0800 Subject: [Python-bugs-list] [ python-Bugs-673115 ] causes crash on Windows2000 Message-ID: Bugs item #673115, was opened at 2003-01-23 09:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=673115&group_id=5470 Category: Tkinter Group: Python 2.2.2 >Status: Closed Resolution: None Priority: 5 Submitted By: Toru Furukawa (torufurukawa) Assigned to: Nobody/Anonymous (nobody) Summary: causes crash on Windows2000 Initial Comment: When using a mouse wheel on the code below, I got the error message dialog, saying "Program Error python.exe has generated errors and will be closed by Windows. You will need to restart the program. An error log is being created. [OK]" #---- def foo(event): print "foo" import Tkinter win = Tkinter.Tk() win.bind("", foo) win.mainloop() #---- It happens on Windows2000SP1 + Python 2.2.2. It works on WindowsXP + Python 2.2.2. Other events, like , works fine on Windows2k. The attached file is the log file created at the crash. ---------------------------------------------------------------------- >Comment By: Toru Furukawa (torufurukawa) Date: 2003-01-29 11:37 Message: Logged In: YES user_id=651026 I found it is Tcl/Tk problem. The tcl code nnorwitz provieded works on Active Tcl 8.3.4. The Python script crashes also on Python2.3a1. I copied *both* tcl83.dll and tk83.dll of Active Tcl onto Python22/DLLs folder, and the Python script works fine. Now, it is clear the problem is Tcl/Tk's. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 20:05 Message: Logged In: YES user_id=33168 This is most likely a Tk library problem (not Tkinter). You can verify this if you have tcl/tk installed. The tcl program below is roughly the same as the python code. The tcl command interpreter name is wish. wish #---- tcl program starts here % proc foo { args } { puts "foo" } % bind . "" foo #---- Can you test this? Can you test with 2.3a1? I believe this comes with a different version of Tk. That may also fix the problem. BTW, there is no file attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=673115&group_id=5470 From noreply@sourceforge.net Wed Jan 29 18:19:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 29 Jan 2003 10:19:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-676342 ] after using pdb readline does not work correctly Message-ID: Bugs item #676342, was opened at 2003-01-28 20:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676342&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Nobody/Anonymous (nobody) Summary: after using pdb readline does not work correctly Initial Comment: After I use pdb in the interpreter my readline settings are messed up. It only knows about the pdb readline stuff forever afterward. In fact, this happens as soon as a Pdb object is instantiated, regardless of whether or not you use it. This is a result of some aspects of the Cmd object in Lib/cmd.py. Currently Cmd registers a new readline completer as soon as a Cmd object is instantiated. This is probably incorrect. I believe the correct place to register the new handler is in the preloop hook. That way the new readline completer is only used while the Cmd object is actually responsible for processing user input. Next, the old readline completer should probably be re-registered in the postloop hook. In order to do this, a new call must be added to the readline module to return the current completer so it can be saved and later restored. The files included patch readline.c (version 2.41.64) and cmd.py (version 1.26.16.2) to make the changes described above. After this patch readline works as expected in the interpreter. Let me know what you think of it. ---------------------------------------------------------------------- >Comment By: Michael Stone (mbrierst) Date: 2003-01-29 18:19 Message: Logged In: YES user_id=670441 Actually, the readline library does have the functionality to get the current binding of the tab key, so it could be saved and restored. However, to do this in python some stuff would have to be added to the readline.c module, to create some python layer that deals with the way readline stores macros, functions, and keymaps. It's probably not worth the effort unless someone wants to do major changes to the readline module to add the full functionality of the underlying library to the python interface. Probably cmd.py shouldn't be rebinding the tab key to complete at all. If the user wants that, won't they have already done it somewhere else, like in their pythonrc or inputrc files? And if they don't it might be impolite to change their bindings. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-29 15:27 Message: Logged In: YES user_id=670441 I attached a changed readline.c patch to hopefully get rid of any "sickness". (There was a not-checking-for-null problem too... ouch) I think it's good now. But note, there may not be a way to do this sort of thing perfectly. If you mess around enough with starting debuggers within debuggers (or in general anything that uses a Cmd object) it might be possible to end up with an unexpected completer function in the end. And it looks like under the current system there's no way to get back the completer key that was initially used. But this isn't SUCH a big deal since I think everyone uses tab, right? At any rate, the change is definitely an improvement for me. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-29 10:36 Message: Logged In: YES user_id=6656 I approve of this patch in principle. I hadn't done enough investigation to see that it was so easy to get the current completer function! OTOH: return Py_BuildValue("O", completer); is sick. Change that to Py_INCREF(completer); return completer; and if noone else howls, I'll check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676342&group_id=5470 From noreply@sourceforge.net Wed Jan 29 19:52:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 29 Jan 2003 11:52:20 -0800 Subject: [Python-bugs-list] [ python-Bugs-676990 ] memory leak in xmlparse.c::doProlog() Message-ID: Bugs item #676990, was opened at 2003-01-29 14:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676990&group_id=5470 Category: XML Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: memory leak in xmlparse.c::doProlog() Initial Comment: Fred, I'm assigning to you since you've seen this once already. :-) Not sure who would know best how to fix this problem. Perhaps Martin, but he's on vacation. As of now, 2003/1/29, there is a memory leak in xmlparse.c::doProlog() line 3979. The XML_Content is dynamically allocated, but never freed in the block. The lifetime of the variable content is not clear. It is passed to elementDeclHandler(). Does content need to be dynamic, or can it be a local (stack) variable? Does elementDeclHandler() take ownership of content? I can make the change in Python (which is where this problem was found from test_minidom). 20 bytes in 1 blocks are definitely lost in loss record 2 of 15 at 0x4015D480: malloc (vg_clientfuncs.c:100) doProlog (Modules/expat/xmlparse.c:3979) prologProcessor (Modules/expat/xmlparse.c:3185) prologInitProcessor (Modules/expat/xmlparse.c:3016) XML_ParseBuffer (Modules/expat/xmlparse.c:1439) XML_Parse (Modules/expat/xmlparse.c:1427) xmlparse_Parse (Modules/pyexpat.c:853) This problem was originally from this bug report in expat: http://sf.net/tracker/?func=detail&atid=110127&aid=676926&group_id=10127 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676990&group_id=5470 From noreply@sourceforge.net Wed Jan 29 20:03:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 29 Jan 2003 12:03:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-676990 ] memory leak in xmlparse.c::doProlog() Message-ID: Bugs item #676990, was opened at 2003-01-29 14:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676990&group_id=5470 Category: XML Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: memory leak in xmlparse.c::doProlog() Initial Comment: Fred, I'm assigning to you since you've seen this once already. :-) Not sure who would know best how to fix this problem. Perhaps Martin, but he's on vacation. As of now, 2003/1/29, there is a memory leak in xmlparse.c::doProlog() line 3979. The XML_Content is dynamically allocated, but never freed in the block. The lifetime of the variable content is not clear. It is passed to elementDeclHandler(). Does content need to be dynamic, or can it be a local (stack) variable? Does elementDeclHandler() take ownership of content? I can make the change in Python (which is where this problem was found from test_minidom). 20 bytes in 1 blocks are definitely lost in loss record 2 of 15 at 0x4015D480: malloc (vg_clientfuncs.c:100) doProlog (Modules/expat/xmlparse.c:3979) prologProcessor (Modules/expat/xmlparse.c:3185) prologInitProcessor (Modules/expat/xmlparse.c:3016) XML_ParseBuffer (Modules/expat/xmlparse.c:1439) XML_Parse (Modules/expat/xmlparse.c:1427) xmlparse_Parse (Modules/pyexpat.c:853) This problem was originally from this bug report in expat: http://sf.net/tracker/?func=detail&atid=110127&aid=676926&group_id=10127 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-29 15:03 Message: Logged In: YES user_id=3066 As noted in the Expat tracker, this is not a memory leak in Expat, but in pyexpat. I've taken a quick look at the relevant code in pyexpat; it won't be hard to fix, but it will take longer than writing this response. I'll try to knock it out tonight. (For the record: this isn't due to any changes in Expat, it's just that the bug in pyexpat has only now been caught.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676990&group_id=5470 From noreply@sourceforge.net Wed Jan 29 21:21:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 29 Jan 2003 13:21:12 -0800 Subject: [Python-bugs-list] [ python-Bugs-676273 ] BaseHTTPServer; HTTP/1.1 spec not "vague" Message-ID: Bugs item #676273, was opened at 2003-01-28 14:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676273&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Nobody/Anonymous (nobody) >Summary: BaseHTTPServer; HTTP/1.1 spec not "vague" Initial Comment: The module docstring for BaseHTTPServer says The protocol is vague about whether lines are separated by LF characters or by CRLF pairs -- for compatibility with the widest range of clients, both should be accepted. Similarly, whitespace in the request line should be treated sensibly (allowing multiple spaces between components and allowing trailing whitespace). HTTP/1.1 is not vague. It says in section 2.2 of the spec HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body but with the suggestion in 19.3 that Clients SHOULD be tolerant in parsing the Status-Line and servers tolerant when parsing the Request-Line. In particular, they SHOULD accept any amount of SP or HT characters between fields, even though only a single SP is required. The line terminator for message-header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers, recognize a single LF as a line terminator and ignore the leading CR. This means that 1) the spec is not vague and 2) the Python code works according to the spec. So my suggestion is to remove the comment about being "vague" from the spec. A diff is attached. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-29 16:21 Message: Logged In: YES user_id=33168 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676273&group_id=5470 From noreply@sourceforge.net Wed Jan 29 21:22:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 29 Jan 2003 13:22:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-676292 ] BaseHTTPServer incorrectly parses protocol Message-ID: Bugs item #676292, was opened at 2003-01-28 14:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676292&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Nobody/Anonymous (nobody) Summary: BaseHTTPServer incorrectly parses protocol Initial Comment: The code in BaseHTTPServer.BaseHTTPRequestHandler.parse_request says try: version_number = float(version.split('/', 1)[1]) except ValueError: self.send_error(400, "Bad request version (%s)" % `version`) return False if version_number >= 1.1 and self.protocol_version >= "HTTP/1.1": self.close_connection = 0 if version_number >= 2.0: self.send_error(505, "Invalid HTTP Version (%f)" % version_number) This does not agree with the HTTP/1.1 spec which states Note that the major and minor numbers MUST be treated as separate integers and that each MAY be incremented higher than a single digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and MUST NOT be sent. I also noticed there were errors if the version string was "HTTP/1.2.3" or even simply "BLAH". I've fixed them so they don't give tracebacks. Finally, if there is an error in the parsing, it calls the 'send_error' method, which does a check if 'self.command' is a HEAD. However, if there's an error parsing the first line of the HTTP request the self.command wasn't yet set, so I forced self.command to initialized to None before doing anything which can yield an error. Patch is attached. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-29 16:22 Message: Logged In: YES user_id=33168 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676292&group_id=5470 From noreply@sourceforge.net Wed Jan 29 22:44:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 29 Jan 2003 14:44:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-583477 ] wrong dest size Message-ID: Bugs item #583477, was opened at 2002-07-19 04:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=583477&group_id=5470 Category: Unicode Group: Python 2.2.1 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Doug Marien (dougslug) Assigned to: Mark Hammond (mhammond) Summary: wrong dest size Initial Comment: OS: nt (win2k) In getpathp.c on line 325 in the call to WideCharToMultiByte(), the destination size should be reqdSize+1 and not dataSize+1. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-01-30 09:44 Message: Logged In: YES user_id=14198 Fixed: Checking in getpathp.c; /cvsroot/python/python/dist/src/PC/getpathp.c,v <-- getpathp.c new revision: 1.31; previous revision: 1.30 Note however that this code block was only used by Windows CE builds, not by the standard core build. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-29 13:22 Message: Logged In: YES user_id=33168 Mark, I'm just pinging you. The suggestion looks like it could be correct. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2002-07-27 02:33 Message: Logged In: YES user_id=38388 Passed on to Mark ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=583477&group_id=5470 From noreply@sourceforge.net Wed Jan 29 23:11:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 29 Jan 2003 15:11:19 -0800 Subject: [Python-bugs-list] [ python-Bugs-676521 ] parser module validation failure Message-ID: Bugs item #676521, was opened at 2003-01-28 20:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676521&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: logistix (logistix) Assigned to: Michael Hudson (mwh) Summary: parser module validation failure Initial Comment: C:\>c:\python23\python Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import parser >>> a = file('c:\python23\lib\base64.py').read() >>> b = parser.suite(a) >>> c = parser.ast2tuple(b) >>> d = parser.sequence2ast(c) Traceback (most recent call last): File "", line 1, in ? parser.ParserError: VALIDATION FAILURE: report this to the maintainer! >>> ^Z C:\> Problem also occurred on Python 2.2.2 on WinXP and RedHat 7.3 ---------------------------------------------------------------------- >Comment By: logistix (logistix) Date: 2003-01-29 17:11 Message: Logged In: YES user_id=699438 Yeah, works fine. Thanks for the prompt action. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-29 08:26 Message: Logged In: YES user_id=6656 Checked in as: Modules/parsermodule.c revision 2.75 Lib/test/test_parser.py 1.14 logistix, can you check this works for you? PEP already with editors. It wasn't very long, as it turned out. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-29 08:17 Message: Logged In: YES user_id=33168 I'm not familiar with the parser module (this is the first time I've looked at it). But the patch looks correct. As for the PEP, I think it's a good idea. It would help point out many details people (like me) are probably unaware of. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-29 04:52 Message: Logged In: YES user_id=6656 So the attached would be the fix, then? I feel a "How to change Python's grammar" informational PEP coming on... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-28 20:46 Message: Logged In: YES user_id=33168 The problem is floor division // on the line: MAXBINSIZE = (MAXLINESIZE//4)*3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676521&group_id=5470 From noreply@sourceforge.net Thu Jan 30 00:12:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 29 Jan 2003 16:12:41 -0800 Subject: [Python-bugs-list] [ python-Bugs-676292 ] BaseHTTPServer incorrectly parses protocol Message-ID: Bugs item #676292, was opened at 2003-01-28 12:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676292&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Nobody/Anonymous (nobody) Summary: BaseHTTPServer incorrectly parses protocol Initial Comment: The code in BaseHTTPServer.BaseHTTPRequestHandler.parse_request says try: version_number = float(version.split('/', 1)[1]) except ValueError: self.send_error(400, "Bad request version (%s)" % `version`) return False if version_number >= 1.1 and self.protocol_version >= "HTTP/1.1": self.close_connection = 0 if version_number >= 2.0: self.send_error(505, "Invalid HTTP Version (%f)" % version_number) This does not agree with the HTTP/1.1 spec which states Note that the major and minor numbers MUST be treated as separate integers and that each MAY be incremented higher than a single digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and MUST NOT be sent. I also noticed there were errors if the version string was "HTTP/1.2.3" or even simply "BLAH". I've fixed them so they don't give tracebacks. Finally, if there is an error in the parsing, it calls the 'send_error' method, which does a check if 'self.command' is a HEAD. However, if there's an error parsing the first line of the HTTP request the self.command wasn't yet set, so I forced self.command to initialized to None before doing anything which can yield an error. Patch is attached. ---------------------------------------------------------------------- >Comment By: Andrew Dalke (dalke) Date: 2003-01-29 17:12 Message: Logged In: YES user_id=190903 Silly interface. Okay, should be attached now. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-29 14:22 Message: Logged In: YES user_id=33168 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676292&group_id=5470 From noreply@sourceforge.net Thu Jan 30 00:24:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 29 Jan 2003 16:24:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-676273 ] BaseHTTPServer; HTTP/1.1 spec not "vague" Message-ID: Bugs item #676273, was opened at 2003-01-28 12:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676273&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Nobody/Anonymous (nobody) >Summary: BaseHTTPServer; HTTP/1.1 spec not "vague" Initial Comment: The module docstring for BaseHTTPServer says The protocol is vague about whether lines are separated by LF characters or by CRLF pairs -- for compatibility with the widest range of clients, both should be accepted. Similarly, whitespace in the request line should be treated sensibly (allowing multiple spaces between components and allowing trailing whitespace). HTTP/1.1 is not vague. It says in section 2.2 of the spec HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body but with the suggestion in 19.3 that Clients SHOULD be tolerant in parsing the Status-Line and servers tolerant when parsing the Request-Line. In particular, they SHOULD accept any amount of SP or HT characters between fields, even though only a single SP is required. The line terminator for message-header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers, recognize a single LF as a line terminator and ignore the leading CR. This means that 1) the spec is not vague and 2) the Python code works according to the spec. So my suggestion is to remove the comment about being "vague" from the spec. A diff is attached. ---------------------------------------------------------------------- >Comment By: Andrew Dalke (dalke) Date: 2003-01-29 17:24 Message: Logged In: YES user_id=190903 Silly interface ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-29 14:21 Message: Logged In: YES user_id=33168 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676273&group_id=5470 From noreply@sourceforge.net Thu Jan 30 00:24:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 29 Jan 2003 16:24:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-676273 ] BaseHTTPServer; HTTP/1.1 spec not "vague" Message-ID: Bugs item #676273, was opened at 2003-01-28 12:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676273&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Nobody/Anonymous (nobody) >Summary: BaseHTTPServer; HTTP/1.1 spec not "vague" Initial Comment: The module docstring for BaseHTTPServer says The protocol is vague about whether lines are separated by LF characters or by CRLF pairs -- for compatibility with the widest range of clients, both should be accepted. Similarly, whitespace in the request line should be treated sensibly (allowing multiple spaces between components and allowing trailing whitespace). HTTP/1.1 is not vague. It says in section 2.2 of the spec HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body but with the suggestion in 19.3 that Clients SHOULD be tolerant in parsing the Status-Line and servers tolerant when parsing the Request-Line. In particular, they SHOULD accept any amount of SP or HT characters between fields, even though only a single SP is required. The line terminator for message-header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers, recognize a single LF as a line terminator and ignore the leading CR. This means that 1) the spec is not vague and 2) the Python code works according to the spec. So my suggestion is to remove the comment about being "vague" from the spec. A diff is attached. ---------------------------------------------------------------------- >Comment By: Andrew Dalke (dalke) Date: 2003-01-29 17:24 Message: Logged In: YES user_id=190903 Silly interface ---------------------------------------------------------------------- Comment By: Andrew Dalke (dalke) Date: 2003-01-29 17:24 Message: Logged In: YES user_id=190903 Silly interface ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-29 14:21 Message: Logged In: YES user_id=33168 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676273&group_id=5470 From noreply@sourceforge.net Thu Jan 30 01:03:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 29 Jan 2003 17:03:36 -0800 Subject: [Python-bugs-list] [ python-Bugs-672098 ] Three __contains__ implementations Message-ID: Bugs item #672098, was opened at 2003-01-21 17:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672098&group_id=5470 Category: Python Library >Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: Three __contains__ implementations Initial Comment: Several classes in the stdlib implement dict-like interfaces, but do not provide __contains__ definitions. This is mentioned in PEP290 as a "contra-indication" for updating code to use "k in d". The attached patch adds __contains__ implementations for these stdlib classes. As far as I can tell, this brings all the dict-like classes in the stdlib "up to date", so perhaps PEP290 should be updated as well. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-29 20:03 Message: Logged In: YES user_id=80475 Applied as: lib-tk/Canvas.py 1.18 plat-riscos/riscosenv 1.6 xml/sax/xmlreader.py 1.17 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-24 22:30 Message: Logged In: YES user_id=80475 This patch is fine as it stands. Brett's point is well taken, but using 'in' should never result in a reduced performance. IMO, the additional layer of indirection isn't worth it. PEP 290 needs to stay "as is" because it still applies to home-grown and third-party modules. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-21 23:51 Message: Logged In: YES user_id=357491 The code itself looks fine, but I would suggest that instead of copying code from the methods that provide the same that you change them so that the old method calls ``__contains__`` and that ``__contains__`` now takes over as the primary method. So instead of:: def has_key(self, name): return self._attrs.has_key(name) def __contains__(self, name): return self._attrs.has_key(name) do:: def has_key(self, name): return self.__contains__(name) def __contains__(self, name): return self._attrs.has_key(name) Doing it this way minimizes code duplication along with the possibility of someone changing one method and not the other. And as for usefulness of these additions, I can't comment since I use none of the modules patched, but I see no harm in adding the functionality. So +0 from me on applying the patch once the above changes are done. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2003-01-21 21:16 Message: Logged In: YES user_id=366566 Either mozilla or sf is screwing with me. *grumble* There's no way I selected bisect.py for attachment. Proper file now attached. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-01-21 19:44 Message: Logged In: YES user_id=357491 The attached file has no ``__contains__`` definitions for anything. Did you attach the correct file? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672098&group_id=5470 From noreply@sourceforge.net Thu Jan 30 06:15:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 29 Jan 2003 22:15:56 -0800 Subject: [Python-bugs-list] [ python-Bugs-677293 ] Can't build C ext on OS X with 'altinstall' python Message-ID: Bugs item #677293, was opened at 2003-01-30 17:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=677293&group_id=5470 Category: Distutils Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: Can't build C ext on OS X with 'altinstall' python Initial Comment: I think this is OS X specific, but I may be wrong. This also may be a fault of the build/installation scripts and not distutils. After building python 2.3, and installing with 'make altinstall', I am unable to install packages with 'distutils'. gcc is being told to get stuff out of 'python', which doesn't exist (ie. the final component of the python interpreter's path is wrong). gcc -bundle -bundle_loader /usr/local/stow/python-2.3/bin/python build/temp.darwin-6.3-Power_Macintosh-2.3/_PosixTimeZone.o -o build/lib.darwin-6.3-Power_Macintosh-2.3/_PosixTimeZone.so ld: can't open: /usr/local/stow/python-2.3/bin/python (No such file or directory, errno = 2) error: command 'gcc' failed with exit status 1 make: *** [build] Error 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=677293&group_id=5470 From noreply@sourceforge.net Thu Jan 30 10:22:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 30 Jan 2003 02:22:23 -0800 Subject: [Python-bugs-list] [ python-Bugs-676342 ] after using pdb readline does not work correctly Message-ID: Bugs item #676342, was opened at 2003-01-28 20:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676342&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Nobody/Anonymous (nobody) Summary: after using pdb readline does not work correctly Initial Comment: After I use pdb in the interpreter my readline settings are messed up. It only knows about the pdb readline stuff forever afterward. In fact, this happens as soon as a Pdb object is instantiated, regardless of whether or not you use it. This is a result of some aspects of the Cmd object in Lib/cmd.py. Currently Cmd registers a new readline completer as soon as a Cmd object is instantiated. This is probably incorrect. I believe the correct place to register the new handler is in the preloop hook. That way the new readline completer is only used while the Cmd object is actually responsible for processing user input. Next, the old readline completer should probably be re-registered in the postloop hook. In order to do this, a new call must be added to the readline module to return the current completer so it can be saved and later restored. The files included patch readline.c (version 2.41.64) and cmd.py (version 1.26.16.2) to make the changes described above. After this patch readline works as expected in the interpreter. Let me know what you think of it. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-01-30 10:22 Message: Logged In: YES user_id=6656 Thanks for the new patch, it looks OK. There are a couple of things that spring to mind for future patches: - the function should be METH_NOARGS (or you should check the args tuple) - there should be a blank line between the argspec line in the docstring and the description - you should use the PyDoc_STRVAR macro (but this was only used in the CVS trunk's version of readline). I made these changes and checked in revision 2.59 of Modules/readline.c. Wrt the cmd.py changes, I think I'll probably let that sleeping dog lie. I agree with you in general: cmd.py probably shouldn't be rebinding any keys, but 1) the interface is "specify the completion key to get completion", so backwards compatibility raises its head 2) as you say, most people do probably rebind tab anyway so I propose to check in your patchcmd, close the bug and wait for someone to submit a bug report about pdb messing up their bindings. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-29 18:19 Message: Logged In: YES user_id=670441 Actually, the readline library does have the functionality to get the current binding of the tab key, so it could be saved and restored. However, to do this in python some stuff would have to be added to the readline.c module, to create some python layer that deals with the way readline stores macros, functions, and keymaps. It's probably not worth the effort unless someone wants to do major changes to the readline module to add the full functionality of the underlying library to the python interface. Probably cmd.py shouldn't be rebinding the tab key to complete at all. If the user wants that, won't they have already done it somewhere else, like in their pythonrc or inputrc files? And if they don't it might be impolite to change their bindings. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-29 15:27 Message: Logged In: YES user_id=670441 I attached a changed readline.c patch to hopefully get rid of any "sickness". (There was a not-checking-for-null problem too... ouch) I think it's good now. But note, there may not be a way to do this sort of thing perfectly. If you mess around enough with starting debuggers within debuggers (or in general anything that uses a Cmd object) it might be possible to end up with an unexpected completer function in the end. And it looks like under the current system there's no way to get back the completer key that was initially used. But this isn't SUCH a big deal since I think everyone uses tab, right? At any rate, the change is definitely an improvement for me. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-29 10:36 Message: Logged In: YES user_id=6656 I approve of this patch in principle. I hadn't done enough investigation to see that it was so easy to get the current completer function! OTOH: return Py_BuildValue("O", completer); is sick. Change that to Py_INCREF(completer); return completer; and if noone else howls, I'll check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676342&group_id=5470 From noreply@sourceforge.net Thu Jan 30 11:29:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 30 Jan 2003 03:29:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-665761 ] reduce() masks exception Message-ID: Bugs item #665761, was opened at 2003-01-10 15:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665761&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 3 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: reduce() masks exception Initial Comment: In the following test script ----- class Test: def __iter__(self): raise IOError reduce(lambda x,y: x+y, Test()) ----- the real IOError exception is masked, i.e. the traceback is ----- Traceback (most recent call last): File "test.py", line 5, in ? reduce(lambda x,y: x+y, Test()) TypeError: reduce() arg 2 must support iteration ----- but IMHO should be ----- Traceback (most recent call last): File "test.py", line 3, in ? raise IOError IOError ----- This can be fixed by removing the PyErr_SetString(PyExc_TypeError, "reduce() arg 2 must support iteration") call in bltinmodule.c/buildtin_reduce(). ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-01-30 12:29 Message: Logged In: YES user_id=89016 Trapping only TypeError won't help: class LazyFile: def __init__(self, name, mode="r"): self.name = name self.mode = mode def __iter__(self): return open(self.name, self.mode) import operator f = LazyFile(42) s = reduce(operator.add, f) Here the open call will raise a TypeError, that is totally unrelated to the iterator protocol. The cleanest solution would really be exception chaining. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-29 00:59 Message: Logged In: YES user_id=80475 One way to mitigate the information loss is to mimic the style in zip() which only traps TypeErrors but passes through things like the IOError in your original example. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-28 21:38 Message: Logged In: YES user_id=89016 Attached is a patch that fixes reduce(), map() and zip(). Unfortunately this loses the information about which argument triggered the exception (in map() and zip()) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-25 05:00 Message: Logged In: YES user_id=80475 There's a lot of this going around. map() and zip() have the same issue. I recommend fixing them all. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-01-13 14:18 Message: Logged In: YES user_id=89016 The point is that Python/bltinmodule.c/builtin_reduce() masks the error returned from PyObject_GetIter(). Errors from PyIter_Next() are not masked. What about the following example: class LazyFile: def __init__(self, name, mode="r"): self.name = name self.mode = mode def __iter__(self): return open(self.name, self.mode) import operator f = LazyFile("does not exist") s = reduce(operator.add, f) LazyFile *does* support iteration, but the underlying problem of the non existing file is masked. Removing the call PyErr_SetString(PyExc_TypeError, "reduce() arg 2 must support iteration"); in builtin_reduce(), will produce the original exception "IOError: [Errno 2] No such file or directory: 'does not exist'" and when the second argument is not iteratable, the original exception is just as good: >>> reduce(lambda x,y: x+y, 42) Traceback (most recent call last): File "", line 1, in ? TypeError: iteration over non-sequence ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2003-01-11 18:08 Message: Logged In: YES user_id=366566 the __iter__ method is supposed to return an object that defines a 'next' method. The returned object is the one used for iteration, not the original. So I believe the error message is correct - Test does not support iteration. If you change the code to: >>> class test: ... def __iter__(self): ... return self ... def next(self): ... raise IOError ... >>> reduce(operator.add, test()) You get the expected result... Traceback (most recent call last):   File "", line 1, in ?   File "", line 5, in next IOError ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665761&group_id=5470 From noreply@sourceforge.net Thu Jan 30 14:44:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 30 Jan 2003 06:44:42 -0800 Subject: [Python-bugs-list] [ python-Bugs-676990 ] memory leak in pyexpat.c::my_ElementDeclHandler() Message-ID: Bugs item #676990, was opened at 2003-01-29 14:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676990&group_id=5470 Category: XML Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: memory leak in pyexpat.c::my_ElementDeclHandler() Initial Comment: Fred, I'm assigning to you since you've seen this once already. :-) Not sure who would know best how to fix this problem. Perhaps Martin, but he's on vacation. As of now, 2003/1/29, there is a memory leak in xmlparse.c::doProlog() line 3979. The XML_Content is dynamically allocated, but never freed in the block. The lifetime of the variable content is not clear. It is passed to elementDeclHandler(). Does content need to be dynamic, or can it be a local (stack) variable? Does elementDeclHandler() take ownership of content? I can make the change in Python (which is where this problem was found from test_minidom). 20 bytes in 1 blocks are definitely lost in loss record 2 of 15 at 0x4015D480: malloc (vg_clientfuncs.c:100) doProlog (Modules/expat/xmlparse.c:3979) prologProcessor (Modules/expat/xmlparse.c:3185) prologInitProcessor (Modules/expat/xmlparse.c:3016) XML_ParseBuffer (Modules/expat/xmlparse.c:1439) XML_Parse (Modules/expat/xmlparse.c:1427) xmlparse_Parse (Modules/pyexpat.c:853) This problem was originally from this bug report in expat: http://sf.net/tracker/?func=detail&atid=110127&aid=676926&group_id=10127 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-30 09:44 Message: Logged In: YES user_id=3066 Fixed summary. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-29 15:03 Message: Logged In: YES user_id=3066 As noted in the Expat tracker, this is not a memory leak in Expat, but in pyexpat. I've taken a quick look at the relevant code in pyexpat; it won't be hard to fix, but it will take longer than writing this response. I'll try to knock it out tonight. (For the record: this isn't due to any changes in Expat, it's just that the bug in pyexpat has only now been caught.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676990&group_id=5470 From noreply@sourceforge.net Thu Jan 30 15:38:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 30 Jan 2003 07:38:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-676990 ] memory leak in pyexpat.c::my_ElementDeclHandler() Message-ID: Bugs item #676990, was opened at 2003-01-29 14:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676990&group_id=5470 Category: XML Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Neal Norwitz (nnorwitz) Summary: memory leak in pyexpat.c::my_ElementDeclHandler() Initial Comment: Fred, I'm assigning to you since you've seen this once already. :-) Not sure who would know best how to fix this problem. Perhaps Martin, but he's on vacation. As of now, 2003/1/29, there is a memory leak in xmlparse.c::doProlog() line 3979. The XML_Content is dynamically allocated, but never freed in the block. The lifetime of the variable content is not clear. It is passed to elementDeclHandler(). Does content need to be dynamic, or can it be a local (stack) variable? Does elementDeclHandler() take ownership of content? I can make the change in Python (which is where this problem was found from test_minidom). 20 bytes in 1 blocks are definitely lost in loss record 2 of 15 at 0x4015D480: malloc (vg_clientfuncs.c:100) doProlog (Modules/expat/xmlparse.c:3979) prologProcessor (Modules/expat/xmlparse.c:3185) prologInitProcessor (Modules/expat/xmlparse.c:3016) XML_ParseBuffer (Modules/expat/xmlparse.c:1439) XML_Parse (Modules/expat/xmlparse.c:1427) xmlparse_Parse (Modules/pyexpat.c:853) This problem was originally from this bug report in expat: http://sf.net/tracker/?func=detail&atid=110127&aid=676926&group_id=10127 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-30 10:38 Message: Logged In: YES user_id=3066 The attached patch frees the content model passed to the handler. This should fix the leak; please test using whatever tool you used to discover this. Thanks! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-30 09:44 Message: Logged In: YES user_id=3066 Fixed summary. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-29 15:03 Message: Logged In: YES user_id=3066 As noted in the Expat tracker, this is not a memory leak in Expat, but in pyexpat. I've taken a quick look at the relevant code in pyexpat; it won't be hard to fix, but it will take longer than writing this response. I'll try to knock it out tonight. (For the record: this isn't due to any changes in Expat, it's just that the bug in pyexpat has only now been caught.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676990&group_id=5470 From noreply@sourceforge.net Thu Jan 30 16:43:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 30 Jan 2003 08:43:49 -0800 Subject: [Python-bugs-list] [ python-Bugs-527521 ] httplib strict mode fails in 2.2.2 Message-ID: Bugs item #527521, was opened at 2002-03-08 19:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=527521&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: httplib strict mode fails in 2.2.2 Initial Comment: The test() function in the httplib module attempts to connect to SourceForge using SSL. I've tried this with Python 2.1 and up, using OpenSSL 0.9.6. The read call fails with an SSL error, then python dumps core instead OpenSSL. I don't know if this is a Python bug or an SSL bug. At first blush, I'd guess that Python is probably using OpenSSL incorrectly. Here's the Python traceback. Traceback (most recent call last): File "../Lib/httplib.py", line 895, in ? test() File "../Lib/httplib.py", line 884, in test status, reason, headers = hs.getreply() File "../Lib/httplib.py", line 734, in getreply response = self._conn.getresponse() File "../Lib/httplib.py", line 579, in getresponse response = self.response_class(self.sock) File "../Lib/httplib.py", line 99, in __init__ self.fp = sock.makefile('rb', 0) File "../Lib/httplib.py", line 614, in makefile buf = self.__ssl.read() socket.sslerror: (1, 'error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number') And the gdb stack trace. #0 0x401e96d1 in sk_pop_free () from /usr/local/ssl/lib/libcrypto.so.0.9.6 (gdb) bt #0 0x401e96d1 in sk_pop_free () from /usr/local/ssl/lib/libcrypto.so.0.9.6 #1 0x40191068 in __DTOR_END__ () from /usr/local/ssl/lib/libssl.so.0.9.6 #2 0xe853 in ?? () Cannot access memory at address 0x5614ec83. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-30 16:43 Message: Logged In: YES user_id=670441 This actually does its tests by communicating with various web servers (python.org, sourceforge, theopalgroup.com, yahoo.com). This doesn't seem like a very reliable way to do these tests, but it certainly does seem like a 'real-world' test. Apparently yahoo.com/promotions/mom_com97/supermom.html used to give a garbled, non-standard status line, so it was used to give an error case to strict mode. Unsurprisingly this page has gone away and the new Not Found error page is standards compliant. You can either 1) get rid of the tests of the buggy server entirely (all code starting where it mentions yahoo) 2) someone can create a server which ALWAYS gives a garbled status line (maybe on python.org?) but this seems like it's not worth the effort, and there's still no guarantee that server won't go away in the future. 3) Create a mini-server in the test just to spit out a bad status line and make this test work. 4) get rid of these tests all together, as it seems unreliable to rely on external servers for them Option 1) is the least work and probably the best idea. If you want a patch for 1), 3), or 4) I can provide it, or someone else can do it if they want. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 14:47 Message: Logged In: YES user_id=31392 I don't see the coredump either; the C code is very different in 2.1, so it's probably a 2.1-specific bug. But the XXX strict mode problem in 2.2 is probably a bug. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-11 02:25 Message: Logged In: YES user_id=33168 Jeremy, can this bug be closed? www.python.org is down. I tried sf.net and there was no crash. But I did get this exception: XXX strict mode should have failed I'm not sure if that's a problem or not. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-03-19 15:26 Message: Logged In: YES user_id=11375 This looks like a duplicate of bug #531616, though I didn't see Python dump core. Try it with the current httplib in CVS; it should be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=527521&group_id=5470 From noreply@sourceforge.net Thu Jan 30 16:59:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 30 Jan 2003 08:59:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-676342 ] after using pdb readline does not work correctly Message-ID: Bugs item #676342, was opened at 2003-01-28 20:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676342&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Nobody/Anonymous (nobody) Summary: after using pdb readline does not work correctly Initial Comment: After I use pdb in the interpreter my readline settings are messed up. It only knows about the pdb readline stuff forever afterward. In fact, this happens as soon as a Pdb object is instantiated, regardless of whether or not you use it. This is a result of some aspects of the Cmd object in Lib/cmd.py. Currently Cmd registers a new readline completer as soon as a Cmd object is instantiated. This is probably incorrect. I believe the correct place to register the new handler is in the preloop hook. That way the new readline completer is only used while the Cmd object is actually responsible for processing user input. Next, the old readline completer should probably be re-registered in the postloop hook. In order to do this, a new call must be added to the readline module to return the current completer so it can be saved and later restored. The files included patch readline.c (version 2.41.64) and cmd.py (version 1.26.16.2) to make the changes described above. After this patch readline works as expected in the interpreter. Let me know what you think of it. ---------------------------------------------------------------------- >Comment By: Michael Stone (mbrierst) Date: 2003-01-30 16:59 Message: Logged In: YES user_id=670441 That sounds good to me. Go ahead and check in patchcmd. Thanks for your suggestions, I will follow them in future patches. In this one, I was trying to follow the conventions I saw being used in the module, but they were outdated or incorrect (and I didn't always follow them correctly anyway!). Okay that's definitely enough commentary for a few line patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-30 10:22 Message: Logged In: YES user_id=6656 Thanks for the new patch, it looks OK. There are a couple of things that spring to mind for future patches: - the function should be METH_NOARGS (or you should check the args tuple) - there should be a blank line between the argspec line in the docstring and the description - you should use the PyDoc_STRVAR macro (but this was only used in the CVS trunk's version of readline). I made these changes and checked in revision 2.59 of Modules/readline.c. Wrt the cmd.py changes, I think I'll probably let that sleeping dog lie. I agree with you in general: cmd.py probably shouldn't be rebinding any keys, but 1) the interface is "specify the completion key to get completion", so backwards compatibility raises its head 2) as you say, most people do probably rebind tab anyway so I propose to check in your patchcmd, close the bug and wait for someone to submit a bug report about pdb messing up their bindings. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-29 18:19 Message: Logged In: YES user_id=670441 Actually, the readline library does have the functionality to get the current binding of the tab key, so it could be saved and restored. However, to do this in python some stuff would have to be added to the readline.c module, to create some python layer that deals with the way readline stores macros, functions, and keymaps. It's probably not worth the effort unless someone wants to do major changes to the readline module to add the full functionality of the underlying library to the python interface. Probably cmd.py shouldn't be rebinding the tab key to complete at all. If the user wants that, won't they have already done it somewhere else, like in their pythonrc or inputrc files? And if they don't it might be impolite to change their bindings. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-29 15:27 Message: Logged In: YES user_id=670441 I attached a changed readline.c patch to hopefully get rid of any "sickness". (There was a not-checking-for-null problem too... ouch) I think it's good now. But note, there may not be a way to do this sort of thing perfectly. If you mess around enough with starting debuggers within debuggers (or in general anything that uses a Cmd object) it might be possible to end up with an unexpected completer function in the end. And it looks like under the current system there's no way to get back the completer key that was initially used. But this isn't SUCH a big deal since I think everyone uses tab, right? At any rate, the change is definitely an improvement for me. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-29 10:36 Message: Logged In: YES user_id=6656 I approve of this patch in principle. I hadn't done enough investigation to see that it was so easy to get the current completer function! OTOH: return Py_BuildValue("O", completer); is sick. Change that to Py_INCREF(completer); return completer; and if noone else howls, I'll check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676342&group_id=5470 From noreply@sourceforge.net Thu Jan 30 18:53:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 30 Jan 2003 10:53:52 -0800 Subject: [Python-bugs-list] [ python-Feature Requests-677651 ] ConfigParser.read() should return list of files read Message-ID: Feature Requests item #677651, was opened at 2003-01-31 03:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=677651&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Belmonte (jbelmonte) Assigned to: Nobody/Anonymous (nobody) Summary: ConfigParser.read() should return list of files read Initial Comment: Regarding ConfigParser.ConfigParser: When debugging or when the user of a command line tool requests verbose output, it is useful to report exactly which files the configuration has been read from. If this is required, ConfigParser.read() is not useful. Attached is a patch to make ConfigParser.read() return a list of files it has read from. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=677651&group_id=5470 From noreply@sourceforge.net Thu Jan 30 21:00:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 30 Jan 2003 13:00:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-677753 ] python.exe expected in extension builds Message-ID: Bugs item #677753, was opened at 2003-01-30 13:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=677753&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Jack Jansen (jackjansen) Summary: python.exe expected in extension builds Initial Comment: When building on OS X configure senses whether the build filesystem is case sensitive or not and if not builds "python.exe" instead of "python" to avoid conflicting with the "Python" dir. There are some things in doing the framework build that expect to have "python.exe" so i fyou ar building on a case-sensitive filesystem and only have "python" then they fail. Perhaps configure should make a python.exe --> python link. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=677753&group_id=5470 From noreply@sourceforge.net Thu Jan 30 23:40:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 30 Jan 2003 15:40:22 -0800 Subject: [Python-bugs-list] [ python-Bugs-676072 ] rfc822.Message() doesn't support __contains__() (+patch) Message-ID: Bugs item #676072, was opened at 2003-01-28 08:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676072&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michal Vitecek (fufsource) Assigned to: Barry A. Warsaw (bwarsaw) Summary: rfc822.Message() doesn't support __contains__() (+patch) Initial Comment: class rfc822.Message() should behave like a dictionary but it doesn't define method __contains__() so it's not possible to use form: 'header' in messageInstance attached is a simple patch that fixes this. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-30 18:40 Message: Logged In: YES user_id=80475 I've attached my own version of this patch for Py2.3. The same solution was used for shelve so that a single minimal intervention keeps the module fully synced with mapping interface. I know this module is superceded but it doesn't hurt to sync-up its interface for those who still use it. Barry, if it meets your approval please reassign back to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676072&group_id=5470 From noreply@sourceforge.net Fri Jan 31 03:41:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 30 Jan 2003 19:41:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-676072 ] rfc822.Message() doesn't support __contains__() (+patch) Message-ID: Bugs item #676072, was opened at 2003-01-28 08:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676072&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michal Vitecek (fufsource) Assigned to: Barry A. Warsaw (bwarsaw) Summary: rfc822.Message() doesn't support __contains__() (+patch) Initial Comment: class rfc822.Message() should behave like a dictionary but it doesn't define method __contains__() so it's not possible to use form: 'header' in messageInstance attached is a simple patch that fixes this. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-30 22:41 Message: Logged In: YES user_id=12800 It's not entirely clear to me that Messages should have dictionary semantics, or that you should be able to say "header in msginst". I don't think I'd want those semantics for email.Message. Messages are more than just a collection of their headers. Why wouldn't __contains__ test for a subpart in a message tree, or for some text in the body of the message? Also, in email.Message, __getitem__ etc don't have dict semantics on purpose. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-30 18:40 Message: Logged In: YES user_id=80475 I've attached my own version of this patch for Py2.3. The same solution was used for shelve so that a single minimal intervention keeps the module fully synced with mapping interface. I know this module is superceded but it doesn't hurt to sync-up its interface for those who still use it. Barry, if it meets your approval please reassign back to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676072&group_id=5470 From noreply@sourceforge.net Fri Jan 31 04:35:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 30 Jan 2003 20:35:06 -0800 Subject: [Python-bugs-list] [ python-Bugs-676072 ] rfc822.Message() doesn't support __contains__() (+patch) Message-ID: Bugs item #676072, was opened at 2003-01-28 08:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676072&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michal Vitecek (fufsource) Assigned to: Barry A. Warsaw (bwarsaw) Summary: rfc822.Message() doesn't support __contains__() (+patch) Initial Comment: class rfc822.Message() should behave like a dictionary but it doesn't define method __contains__() so it's not possible to use form: 'header' in messageInstance attached is a simple patch that fixes this. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-30 23:35 Message: Logged In: YES user_id=80475 Looking at the Py2.3 source, it looks like someone already implemented many of those dictionary semantics (including "header in msginst"). My thought was to complete this idea expressed in the comment, "Access as a dictionary", which was followed by definitions for len, __getitem__, __setitem__, __delitem__, setdefault, has_key, __contains__, keys, values, and items. So, it looked like it intended but did not succeed in implementing the entire dictionary interface. My patch was a simple way to fill in the blanks. OTOH, I have zero attachment to it and won't be disappointed if it is marked as Wont Fix and closed. It never pays to spend much brainpower on a deprecated module. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-30 22:41 Message: Logged In: YES user_id=12800 It's not entirely clear to me that Messages should have dictionary semantics, or that you should be able to say "header in msginst". I don't think I'd want those semantics for email.Message. Messages are more than just a collection of their headers. Why wouldn't __contains__ test for a subpart in a message tree, or for some text in the body of the message? Also, in email.Message, __getitem__ etc don't have dict semantics on purpose. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-30 18:40 Message: Logged In: YES user_id=80475 I've attached my own version of this patch for Py2.3. The same solution was used for shelve so that a single minimal intervention keeps the module fully synced with mapping interface. I know this module is superceded but it doesn't hurt to sync-up its interface for those who still use it. Barry, if it meets your approval please reassign back to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676072&group_id=5470 From noreply@sourceforge.net Fri Jan 31 04:47:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 30 Jan 2003 20:47:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-676072 ] rfc822.Message() doesn't support __contains__() (+patch) Message-ID: Bugs item #676072, was opened at 2003-01-28 08:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676072&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michal Vitecek (fufsource) Assigned to: Barry A. Warsaw (bwarsaw) Summary: rfc822.Message() doesn't support __contains__() (+patch) Initial Comment: class rfc822.Message() should behave like a dictionary but it doesn't define method __contains__() so it's not possible to use form: 'header' in messageInstance attached is a simple patch that fixes this. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-30 23:47 Message: Logged In: YES user_id=80475 P.S. when I said "someone", I was talking about all of the dictionary interface except for __contains__ which was added by me many months ago based on the idea that where there is a has_key, there should be a __contains__. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-30 23:35 Message: Logged In: YES user_id=80475 Looking at the Py2.3 source, it looks like someone already implemented many of those dictionary semantics (including "header in msginst"). My thought was to complete this idea expressed in the comment, "Access as a dictionary", which was followed by definitions for len, __getitem__, __setitem__, __delitem__, setdefault, has_key, __contains__, keys, values, and items. So, it looked like it intended but did not succeed in implementing the entire dictionary interface. My patch was a simple way to fill in the blanks. OTOH, I have zero attachment to it and won't be disappointed if it is marked as Wont Fix and closed. It never pays to spend much brainpower on a deprecated module. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-30 22:41 Message: Logged In: YES user_id=12800 It's not entirely clear to me that Messages should have dictionary semantics, or that you should be able to say "header in msginst". I don't think I'd want those semantics for email.Message. Messages are more than just a collection of their headers. Why wouldn't __contains__ test for a subpart in a message tree, or for some text in the body of the message? Also, in email.Message, __getitem__ etc don't have dict semantics on purpose. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-30 18:40 Message: Logged In: YES user_id=80475 I've attached my own version of this patch for Py2.3. The same solution was used for shelve so that a single minimal intervention keeps the module fully synced with mapping interface. I know this module is superceded but it doesn't hurt to sync-up its interface for those who still use it. Barry, if it meets your approval please reassign back to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676072&group_id=5470 From noreply@sourceforge.net Fri Jan 31 05:23:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 30 Jan 2003 21:23:29 -0800 Subject: [Python-bugs-list] [ python-Bugs-671447 ] StringIO doc doesn't say it's sometimes read-only Message-ID: Bugs item #671447, was opened at 2003-01-20 17:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671447&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Mike Orr (hierro) Assigned to: Nobody/Anonymous (nobody) Summary: StringIO doc doesn't say it's sometimes read-only Initial Comment: When StringIO is instantiated with an intial string: StringIO("Hello, world!") it's read-only; the write methods don't exist. The Python Library Reference should mention this. If you instantiate StringIO without an initial string: StringIO() you get both read and write methods. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-31 00:23 Message: Logged In: YES user_id=80475 Fixed the docs. See Doc/lib/libstringio.tex 1.7 ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-01-21 16:17 Message: Logged In: YES user_id=539787 I find your suggestion informative, appropriate and nice :) ---------------------------------------------------------------------- Comment By: Mike Orr (hierro) Date: 2003-01-21 16:09 Message: Logged In: YES user_id=239757 Yes, it's only cStringIO that does it. However, the statenent about the type does not say anything about which methods are available. Many readers would think, "I never have to compare the type to anything; this doesn't apply to me." How about a statement: If you instantiate cStringIO.StringIO() without an argument, the string is read-write. But if you instantiate it with a string argument: cStringIO.StringIO("abc"), it's read-only and the write methods do not exist. This applies only to cStringIO; the corresponding objects in the StringIO module are read-write in both cases. [Then the paragraph about InputType and OutputType.] ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-01-21 15:24 Message: Logged In: YES user_id=539787 Did you import StringIO, or cStringIO as StringIO ? This behaviour occurs only in cStringIO... if you do m= cStringIO.StringIO("hello there") n= cStringIO.StringIO() you see that type(m) is cStringIO.StringI and n is cStringIO.StringO. This is documented in the cStringIO module documentation. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-01-21 15:24 Message: Logged In: YES user_id=539787 Did you import StringIO, or cStringIO as StringIO ? This behaviour occurs only in cStringIO... if you do m= cStringIO.StringIO("hello there") n= cStringIO.StringIO() you see that type(m) is cStringIO.StringI and n is cStringIO.StringO. This is documented in the cStringIO module documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=671447&group_id=5470 From noreply@sourceforge.net Fri Jan 31 09:04:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 01:04:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-677753 ] python.exe expected in extension builds Message-ID: Bugs item #677753, was opened at 2003-01-30 22:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=677753&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Jack Jansen (jackjansen) Summary: python.exe expected in extension builds Initial Comment: When building on OS X configure senses whether the build filesystem is case sensitive or not and if not builds "python.exe" instead of "python" to avoid conflicting with the "Python" dir. There are some things in doing the framework build that expect to have "python.exe" so i fyou ar building on a case-sensitive filesystem and only have "python" then they fail. Perhaps configure should make a python.exe --> python link. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-01-31 10:04 Message: Logged In: YES user_id=45365 Robin, could you give an example of something that fails? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=677753&group_id=5470 From noreply@sourceforge.net Fri Jan 31 09:15:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 01:15:27 -0800 Subject: [Python-bugs-list] [ python-Bugs-676072 ] rfc822.Message() doesn't support __contains__() (+patch) Message-ID: Bugs item #676072, was opened at 2003-01-28 14:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676072&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michal Vitecek (fufsource) Assigned to: Barry A. Warsaw (bwarsaw) Summary: rfc822.Message() doesn't support __contains__() (+patch) Initial Comment: class rfc822.Message() should behave like a dictionary but it doesn't define method __contains__() so it's not possible to use form: 'header' in messageInstance attached is a simple patch that fixes this. ---------------------------------------------------------------------- >Comment By: Michal Vitecek (fufsource) Date: 2003-01-31 10:15 Message: Logged In: YES user_id=698198 i don't know, but looking at the source from 2.2.2, there's a comment saying "Access as a dictionary (...)". in that case __contains__ should be implemented as well. from my personal point of view it's inconsistent in its behaviour since GvR said '.has_key()' would most probably be deprecated in his 2002's talk and 'in' should be used instead. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-31 05:47 Message: Logged In: YES user_id=80475 P.S. when I said "someone", I was talking about all of the dictionary interface except for __contains__ which was added by me many months ago based on the idea that where there is a has_key, there should be a __contains__. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-31 05:35 Message: Logged In: YES user_id=80475 Looking at the Py2.3 source, it looks like someone already implemented many of those dictionary semantics (including "header in msginst"). My thought was to complete this idea expressed in the comment, "Access as a dictionary", which was followed by definitions for len, __getitem__, __setitem__, __delitem__, setdefault, has_key, __contains__, keys, values, and items. So, it looked like it intended but did not succeed in implementing the entire dictionary interface. My patch was a simple way to fill in the blanks. OTOH, I have zero attachment to it and won't be disappointed if it is marked as Wont Fix and closed. It never pays to spend much brainpower on a deprecated module. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-31 04:41 Message: Logged In: YES user_id=12800 It's not entirely clear to me that Messages should have dictionary semantics, or that you should be able to say "header in msginst". I don't think I'd want those semantics for email.Message. Messages are more than just a collection of their headers. Why wouldn't __contains__ test for a subpart in a message tree, or for some text in the body of the message? Also, in email.Message, __getitem__ etc don't have dict semantics on purpose. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-31 00:40 Message: Logged In: YES user_id=80475 I've attached my own version of this patch for Py2.3. The same solution was used for shelve so that a single minimal intervention keeps the module fully synced with mapping interface. I know this module is superceded but it doesn't hurt to sync-up its interface for those who still use it. Barry, if it meets your approval please reassign back to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676072&group_id=5470 From noreply@sourceforge.net Fri Jan 31 09:31:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 01:31:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-675864 ] patch for new func. string.findall Message-ID: Bugs item #675864, was opened at 2003-01-27 21:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675864&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hunter Peress (hfastedge) Assigned to: Nobody/Anonymous (nobody) Summary: patch for new func. string.findall Initial Comment: this finds all indices of a substring in a string returning in list form. Its not in pydoc2.3. This "patch" contains unittests. #!/usr/bin/python import string def findall(sub,s): if s =='' or sub =='': return [] ret=[] findval=0 pos=0 while findval != -1: findval = s.find(sub,pos) if findval != -1: ret.append(findval) pos = findval + len(sub) return ret if __name__ == '__main__': units = [ 'asdsad','l', 'l','asdlsds', 'l','lsdlsds', 'l','lsdsds', 'l','sdsds', 'l','sdsdsl', 'l','lsdsdsl', 'l','lsdlsdsl', 'l','l', 'l','ll', 'l','lll', 'lo','llollol', 'lo','llollolo', '','', '','asdasd', 'asdsad','' ] for i in range(0,len(units),2): sub,s = units[i],units[i+1] print "'%s' in '%s':"%(sub,s) print findall(sub,s) print "-"*30 print 'done' ---------------------------------------------------------------------- >Comment By: Hunter Peress (hfastedge) Date: 2003-01-31 04:31 Message: Logged In: YES user_id=479934 Theres now a indented version of that which was pasted above that is attached to this bug. ---------------------------------------------------------------------- Comment By: Hunter Peress (hfastedge) Date: 2003-01-27 21:01 Message: Logged In: YES user_id=479934 This might be done as an iterator as well, as re.findall also is complemented by an re.finditer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=675864&group_id=5470 From noreply@sourceforge.net Fri Jan 31 11:23:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 03:23:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-678077 ] add warning to os.getlogin Message-ID: Bugs item #678077, was opened at 2003-01-31 12:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678077&group_id=5470 Category: Documentation Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gernot Hillier (yoda_gh) Assigned to: Nobody/Anonymous (nobody) Summary: add warning to os.getlogin Initial Comment: I experienced problems when using os.getlogin(). It doesn't work for exmaple after doing a "su". It still reports the old login. Also "man 3 getlogin" tells me on GNU/Linux (SuSE 8.1): "Unfortunately, it is often rather easy to fool getlogin(). Sometimes it does not work at all, because some program messed up the utmp file. Often, it gives only the first 8 characters of the login name. The user currently logged in on the controlling tty of our program need not be the user who started it. Avoid getlogin() for security-related purposes. Nobody knows precisely what cuserid() does - avoid it in portable programs - avoid it altogether - use getpwuid(geteuid()) instead, if that is what you meant. DO NOT USE cuserid()" It would be nice if you could add some warning to the documentation of Python's os.getlogin() telling the user it's better to use "pwd.getpwuid(os.getuid())[0]". That's at least what I do now and it works as expected. TIA! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678077&group_id=5470 From noreply@sourceforge.net Fri Jan 31 13:59:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 05:59:28 -0800 Subject: [Python-bugs-list] [ python-Bugs-676072 ] rfc822.Message() doesn't support __contains__() (+patch) Message-ID: Bugs item #676072, was opened at 2003-01-28 08:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676072&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michal Vitecek (fufsource) >Assigned to: Raymond Hettinger (rhettinger) Summary: rfc822.Message() doesn't support __contains__() (+patch) Initial Comment: class rfc822.Message() should behave like a dictionary but it doesn't define method __contains__() so it's not possible to use form: 'header' in messageInstance attached is a simple patch that fixes this. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-31 08:59 Message: Logged In: YES user_id=12800 I'm still not crazy about the specific behavior requested by this bug, i.e. that "header in msginst" should have meaning. But if everyone else wants this for rfc822.Message, I think Raymond's patch is probably best since it's more thorough. However, please add test cases and updates to the rfc822 documentation. ---------------------------------------------------------------------- Comment By: Michal Vitecek (fufsource) Date: 2003-01-31 04:15 Message: Logged In: YES user_id=698198 i don't know, but looking at the source from 2.2.2, there's a comment saying "Access as a dictionary (...)". in that case __contains__ should be implemented as well. from my personal point of view it's inconsistent in its behaviour since GvR said '.has_key()' would most probably be deprecated in his 2002's talk and 'in' should be used instead. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-30 23:47 Message: Logged In: YES user_id=80475 P.S. when I said "someone", I was talking about all of the dictionary interface except for __contains__ which was added by me many months ago based on the idea that where there is a has_key, there should be a __contains__. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-30 23:35 Message: Logged In: YES user_id=80475 Looking at the Py2.3 source, it looks like someone already implemented many of those dictionary semantics (including "header in msginst"). My thought was to complete this idea expressed in the comment, "Access as a dictionary", which was followed by definitions for len, __getitem__, __setitem__, __delitem__, setdefault, has_key, __contains__, keys, values, and items. So, it looked like it intended but did not succeed in implementing the entire dictionary interface. My patch was a simple way to fill in the blanks. OTOH, I have zero attachment to it and won't be disappointed if it is marked as Wont Fix and closed. It never pays to spend much brainpower on a deprecated module. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-30 22:41 Message: Logged In: YES user_id=12800 It's not entirely clear to me that Messages should have dictionary semantics, or that you should be able to say "header in msginst". I don't think I'd want those semantics for email.Message. Messages are more than just a collection of their headers. Why wouldn't __contains__ test for a subpart in a message tree, or for some text in the body of the message? Also, in email.Message, __getitem__ etc don't have dict semantics on purpose. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-30 18:40 Message: Logged In: YES user_id=80475 I've attached my own version of this patch for Py2.3. The same solution was used for shelve so that a single minimal intervention keeps the module fully synced with mapping interface. I know this module is superceded but it doesn't hurt to sync-up its interface for those who still use it. Barry, if it meets your approval please reassign back to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676072&group_id=5470 From noreply@sourceforge.net Fri Jan 31 14:07:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 06:07:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-666219 ] AssertionErrors in httplib Message-ID: Bugs item #666219, was opened at 2003-01-11 14:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666219&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Jeremy Hylton (jhylton) Summary: AssertionErrors in httplib Initial Comment: I've recently noticed AssertionErrors being raised by httplib.LineAndFileWrapper.read(). It happens reliably when the server exits unexpectedly. Here's an example of an AssertionError in an xmlrpclib client when I kill the server it's talking to: Traceback (most recent call last): File "qa.py", line 22, in ? x = s.query(tmpl, st, en, radius, age) File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 985, in __call__ return self.__send(self.__name, args) File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1269, in __request verbose=self.__verbose File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1036, in request return self._parse_response(h.getfile(), sock) File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1165, in _parse_response response = file.read(1024) File "/Users/skip/local/lib/python2.3/httplib.py", line 1150, in read assert not self._line_consumed and self._line_left AssertionError I don't see a problem with raising an exception in this situation. I just wonder if AssertionError is the best exception to raise (unless of course, the cause is a logic error in the httplib code). If an exception is being raised because the server went away, I think it would be better to raise IncompleteRead. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-01-31 14:07 Message: Logged In: YES user_id=31392 Any more info Skip? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-01-14 21:18 Message: Logged In: YES user_id=31392 It's definitely the case that an AssertionError shouldn't be raised. It was my intention that the assert never fail. Do you know which part of the assert fails? Perhaps you could change the assert to print the values of _line_consumed and _line_left and run some more tests. I can't figure out how this goes wrong. Also, do you know when the server is sending an HTTP/0.9 response? I wonder if there's a bug somewhere else and the client is guessing the wrong protocol version for the response. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666219&group_id=5470 From noreply@sourceforge.net Fri Jan 31 14:14:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 06:14:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-527521 ] httplib strict mode fails in 2.2.2 Message-ID: Bugs item #527521, was opened at 2002-03-08 19:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=527521&group_id=5470 Category: Extension Modules Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Jeremy Hylton (jhylton) Summary: httplib strict mode fails in 2.2.2 Initial Comment: The test() function in the httplib module attempts to connect to SourceForge using SSL. I've tried this with Python 2.1 and up, using OpenSSL 0.9.6. The read call fails with an SSL error, then python dumps core instead OpenSSL. I don't know if this is a Python bug or an SSL bug. At first blush, I'd guess that Python is probably using OpenSSL incorrectly. Here's the Python traceback. Traceback (most recent call last): File "../Lib/httplib.py", line 895, in ? test() File "../Lib/httplib.py", line 884, in test status, reason, headers = hs.getreply() File "../Lib/httplib.py", line 734, in getreply response = self._conn.getresponse() File "../Lib/httplib.py", line 579, in getresponse response = self.response_class(self.sock) File "../Lib/httplib.py", line 99, in __init__ self.fp = sock.makefile('rb', 0) File "../Lib/httplib.py", line 614, in makefile buf = self.__ssl.read() socket.sslerror: (1, 'error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number') And the gdb stack trace. #0 0x401e96d1 in sk_pop_free () from /usr/local/ssl/lib/libcrypto.so.0.9.6 (gdb) bt #0 0x401e96d1 in sk_pop_free () from /usr/local/ssl/lib/libcrypto.so.0.9.6 #1 0x40191068 in __DTOR_END__ () from /usr/local/ssl/lib/libssl.so.0.9.6 #2 0xe853 in ?? () Cannot access memory at address 0x5614ec83. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-01-31 14:14 Message: Logged In: YES user_id=31392 The test using supermom was removed on the trunk. I also removed it on the 2.2 maintenance branch. I think we can close this bug now. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-30 16:43 Message: Logged In: YES user_id=670441 This actually does its tests by communicating with various web servers (python.org, sourceforge, theopalgroup.com, yahoo.com). This doesn't seem like a very reliable way to do these tests, but it certainly does seem like a 'real-world' test. Apparently yahoo.com/promotions/mom_com97/supermom.html used to give a garbled, non-standard status line, so it was used to give an error case to strict mode. Unsurprisingly this page has gone away and the new Not Found error page is standards compliant. You can either 1) get rid of the tests of the buggy server entirely (all code starting where it mentions yahoo) 2) someone can create a server which ALWAYS gives a garbled status line (maybe on python.org?) but this seems like it's not worth the effort, and there's still no guarantee that server won't go away in the future. 3) Create a mini-server in the test just to spit out a bad status line and make this test work. 4) get rid of these tests all together, as it seems unreliable to rely on external servers for them Option 1) is the least work and probably the best idea. If you want a patch for 1), 3), or 4) I can provide it, or someone else can do it if they want. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 14:47 Message: Logged In: YES user_id=31392 I don't see the coredump either; the C code is very different in 2.1, so it's probably a 2.1-specific bug. But the XXX strict mode problem in 2.2 is probably a bug. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-11 02:25 Message: Logged In: YES user_id=33168 Jeremy, can this bug be closed? www.python.org is down. I tried sf.net and there was no crash. But I did get this exception: XXX strict mode should have failed I'm not sure if that's a problem or not. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-03-19 15:26 Message: Logged In: YES user_id=11375 This looks like a duplicate of bug #531616, though I didn't see Python dump core. Try it with the current httplib in CVS; it should be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=527521&group_id=5470 From noreply@sourceforge.net Fri Jan 31 14:15:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 06:15:25 -0800 Subject: [Python-bugs-list] [ python-Bugs-555817 ] Flawed fcntl.ioctl implementation. Message-ID: Bugs item #555817, was opened at 2002-05-14 10:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Graham Horler (grahamh) >Assigned to: Anthony Baxter (anthonybaxter) Summary: Flawed fcntl.ioctl implementation. Initial Comment: I'm doing some USB user-space driver programming in Python 2.1.3 under Linux 2.4. When using a particular ioctl (HIDIOCGNAME), the return value as well as the (copy_to_user) binary data is significant. Here is the code from line 547 of hiddev.c (kernel 2.4.19-pre7): if (_IOC_NR(cmd) == _IOC_NR(HIDIOCGNAME(0))) { int len; if (!hid->name) return 0; len = strlen(hid->name) + 1; if (len > _IOC_SIZE(cmd)) len = _IOC_SIZE(cmd); return copy_to_user((char *) arg, hid->name, len) ? -EFAULT : len; } So here is the problem: fcntl.ioctl() will only give me one or the other value, but not both. I can work around this by initialising the input buffer to all chr(0), and then strip them off after. But there will be a time when an ioctl call *requires* both values. Until now I have appreciated the simple ioctl interface, but now it is shown to be an oversimplification. It may be that POSIX, or some standard somewhere says that ioctl should not be used to do this, but maybe Python should support it anyway. I suggest either: 1. A new function ioctl2(fd, op, arg) that returns a 2-tuple of (return_value, binary_buffer) and does not try to interpret the return value. 2. An optional 4th parameter whose presence (but not value) requests the 2-tuple mentioned in (1). Gotta love Python! ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-01-31 14:15 Message: Logged In: YES user_id=6656 Hmm, Martin's away and this should probably go in 2.3a2. Anthony, can you give it a once-over? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-28 18:17 Message: Logged In: YES user_id=6656 Argh, how does SF CVS know to slow down just as I start to work on my bugs? Anyway, I think this patch will do. Adds a test, docs, and beats up on ioctl's docstring. The only issue left that I know about is the error message that you get when none of the PyArg_ParseTuples pass -- but telling the full story would make the error message ridiculously long, so I don't much care. Tempted to change it to ioctl: ha ha, you stuffed up! read the docstring . Martin, can you review? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-02 16:55 Message: Logged In: YES user_id=6656 Assign to me in the hope that I'll stop forgetting about it (sigh). I'm about 70% of the way through what's needed I'd guess. Try to finish for 2.3a2... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-12-13 15:09 Message: Logged In: YES user_id=21627 The patch looks good, in principle, so please correct it, and provide documentation (do mention that you need to pass 1024 bytes to avoid copying). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-12-13 14:40 Message: Logged In: YES user_id=6656 I'd like to either move this forward or close it. Is/was there agreement that my patch would be OK if brushed up as described below, i.e. add tests, docs, provide better error messages? (actually, I note that my patch's use of Py_BEGIN_ALLOW_THREADS is amusingly broken... gotta love the C preprocessor). ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-06-12 11:38 Message: Logged In: YES user_id=543663 Still here... Thanks for the help people. Things have been a bit crazy ATM, but should be back to working with this again soon, so I'll let you know how it goes. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-16 13:15 Message: Logged In: YES user_id=29957 There's a very simple test_ioctl.py in patch #555883 (the ioctl2() sample implementation). It does a getpgrp(), then a TIOCGPGRP and checks it gets the same stuff. No, it won't work on Windows. I'm going to close off #555883 as Invalid. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 12:41 Message: Logged In: YES user_id=6656 Try the attached. (a) should have docs. This is getting hairy (if this then that, but if this and not that then the other...). (b) I've made no attempt to get this to hand out sane error messages (see above). (c) would be nice to have tests. how on earth do you test ioctl? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 12:03 Message: Logged In: YES user_id=6656 OK, that would seem to be easy enough to implement (well, the handling of writeable buffers, not all the optional hair). I like this: >>> buf = array.array('h', [0]*4) [19139 refs] >>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf) 0 [19139 refs] >>> buf array('h', [47, 137, 841, 615]) [19139 refs] I like this less: >>> import array, fcntl [19089 refs] >>> buf = array.array('h', [0]*3) [19093 refs] >>> fcntl.ioctl(0, termios.TIOCGWINSZ, buf) 0 [19095 refs] >>> del buf Debug memory block at address p=0x401c3cb8: 6 bytes originally requested The 4 pad bytes at p-4 are FORBIDDENBYTE, as expected. The 4 pad bytes at tail=0x401c3cbe are not all FORBIDDENBYTE (0xfb): at tail+0: 0x67 *** OUCH at tail+1: 0x02 *** OUCH at tail+2: 0xfb at tail+3: 0xfb The block was made by call #16015 to debug malloc/realloc. Data at p: 2f 00 89 00 49 03 Fatal Python error: bad trailing pad byte Aborted I'm not sure what we can possibly do about this? Copy into a fixed buffer like we do today, then copy out again after the ioctl? Probably the best option. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-16 11:43 Message: Logged In: YES user_id=21627 I'm in favour of a you-may-mutate-the-buffer flag. A transition strategy would be: - in 2.3, make the flag optional, with default 0 - in 2.4, warn if it is not specified - in 2.5, change the default All the time, if the buffer isn't mutable, specifying the flag should not be required. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-16 11:34 Message: Logged In: YES user_id=29957 Hm. The solaris /proc lib I did in python, I used 'struct' to dismantle C structures, but I did consider using byte arrays. So that's one data point. (ok, it's not ioctls, but it's similar sort of data). I'm loathe to go down the 'argument is mutable' optional flag, but I really would prefer to make this work rather than the ioctl2() approach, which really ain't that nice. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-16 10:21 Message: Logged In: YES user_id=6656 I'm not *trying* to be a party-pooper, but there's another problem: the point of passing a mutable array is so that fcntl.ioctl can return ioctl(2)'s return code rather than the string it returns now. So if someone does use arrays (or I guess Numeric.arrays?) for ioctls this would very likely cause breakage. I don't know how likely that is. Probably not very. But I know that if this change broke my code, I'd be a bit miffed. All this is a bit annoying, as mutating arrays is clearly the right solution -- where's that time machine? ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-15 23:50 Message: Logged In: YES user_id=543663 I just realised - using array objects and changing in-place oversomes the arbitrary limit of 1024 bytes. We could then achieve the full 16384 byte nirvana - hurrah! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 18:21 Message: Logged In: YES user_id=21627 I would not be concerned about the backwards compatibility, either: if anybody is passing arrays, there is a good chance that the ioctl does not modify the buffer, or that the caller would not worry about the (missing) modification - or else we had seen reports before. So documenting in Misc/NEWS and the documentation that mutable objects supporting the (write) buffer interface may now mutate seems sufficient. ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-15 17:32 Message: Logged In: YES user_id=543663 Thanks Michael, its all incredibly clear now (sorry Martin). I think using arrays sounds a great idea. IMVHO as to backward compatibility, AFAICT its not documented that arrays can be passed to ioctl() anyway (only says int and string no?), so it's only breaking undocumented behaviour. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2002-05-15 16:38 Message: Logged In: YES user_id=6656 grahamh: I think Martin understood you fine. Remember that arrays are mutable, whereas strings are not. So the idea would be that you'd write buf = array.array('c', '\000'*256) ret = fcntl.ioctl(fd, IOCTL_NUMBER, buf) then the first "ret" bytes of "buf" would be valid. However this possibly breaks backwards compatibility, as you can already pass arrays into the ioctl function and they are not modified. ---------------------------------------------------------------------- Comment By: Graham Horler (grahamh) Date: 2002-05-15 15:44 Message: Logged In: YES user_id=543663 Re Loewis: Not sure what you mean, perhaps an example of the problem from me would help: In C: char buf[256], strbuf[256]; int ret, fd; fd = open(...) ret = ioctl(fd, IOCTL_NUMBER, buf); strncpy(strbuf, buf, ret); This is impossible with the current fcntl module: buf = "X" * struct.calcsize("256s") buf = fcntl.ioctl(fd, IOCTL_NUMBER, buf) # The positive ioctl() return value is lost, and # hence I dont know how much of buf is significant Extract from asm/unistd.h: #define __syscall_return(type, res) \ do { \ if ((unsigned long)(res) >= (unsigned long)(-125)) { \ errno = -(res); \ res = -1; \ } \ return (type) (res); \ } while (0) So positive values are valid, but are being lost. Anthony's patch looks good (thanks, I have not had a chance to test it myself yet), and the above example would be: buf = "X" * struct.calcsize("256s") ret, buf = fcntl.ioctl2(fd, IOCTL_NUMBER, buf) strbuf = buf[:ret] # Result! Now, to test my understanding of your last comment about array objects Loewis, do you mean: - pass in a mutable list that gets changed in place to [ret, buf] - return (ret, buf) if called like this: ioctl(fd, IOC, [buf]) - or something else - please give example. Thanks people. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-05-15 13:04 Message: Logged In: YES user_id=21627 Thinking about the problem again, I think the right solution would be to support array objects as arguments to ioctl - those would then be passed into the system call. Am I correctly understanding the problem, that this would not require a new function? ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-14 13:06 Message: Logged In: YES user_id=29957 possible patch at http://sourceforge.net/tracker/index.php?func=detail&aid=555883&group_id=5470&atid=305470 I've only lightly tested it, not with any calls that return useful values in the return code (couldn't find any easily, didn't feel like figuring out userspace drivers right now :) Give it a whirl... ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-05-14 11:10 Message: Logged In: YES user_id=29957 Ouch. I think you're right - and I think that the ioctl2() implementation is probably the only solution. (I'm not so keen on the name, but I guess it kinda follows the 'standard' of other python functions, e.g. popen) I know changing the return of ioctl would be mega-ugly, unless there was a new, optional "return a tuple" argument. I doubt that's the appropriate fix. If the former approach is the appropriate one, it should be simple enough to add an ioctl2() to the C source. I can probably whip it up now... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=555817&group_id=5470 From noreply@sourceforge.net Fri Jan 31 14:13:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 06:13:17 -0800 Subject: [Python-bugs-list] [ python-Bugs-666219 ] AssertionErrors in httplib Message-ID: Bugs item #666219, was opened at 2003-01-11 08:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666219&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Jeremy Hylton (jhylton) Summary: AssertionErrors in httplib Initial Comment: I've recently noticed AssertionErrors being raised by httplib.LineAndFileWrapper.read(). It happens reliably when the server exits unexpectedly. Here's an example of an AssertionError in an xmlrpclib client when I kill the server it's talking to: Traceback (most recent call last): File "qa.py", line 22, in ? x = s.query(tmpl, st, en, radius, age) File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 985, in __call__ return self.__send(self.__name, args) File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1269, in __request verbose=self.__verbose File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1036, in request return self._parse_response(h.getfile(), sock) File "/Users/skip/local/lib/python2.3/xmlrpclib.py", line 1165, in _parse_response response = file.read(1024) File "/Users/skip/local/lib/python2.3/httplib.py", line 1150, in read assert not self._line_consumed and self._line_left AssertionError I don't see a problem with raising an exception in this situation. I just wonder if AssertionError is the best exception to raise (unless of course, the cause is a logic error in the httplib code). If an exception is being raised because the server went away, I think it would be better to raise IncompleteRead. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-01-31 08:13 Message: Logged In: YES user_id=44345 No, sorry, I haven't looked more deeply into the problem. I did investigate far enough to also see that the code was in the HTTP/0.9 weeds and am befuddled about why it would be there. It's using the vanilla xmlrpclib module at both ends. I'll try to spend a little time today. S ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-01-31 08:07 Message: Logged In: YES user_id=31392 Any more info Skip? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-01-14 15:18 Message: Logged In: YES user_id=31392 It's definitely the case that an AssertionError shouldn't be raised. It was my intention that the assert never fail. Do you know which part of the assert fails? Perhaps you could change the assert to print the values of _line_consumed and _line_left and run some more tests. I can't figure out how this goes wrong. Also, do you know when the server is sending an HTTP/0.9 response? I wonder if there's a bug somewhere else and the client is guessing the wrong protocol version for the response. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666219&group_id=5470 From noreply@sourceforge.net Fri Jan 31 14:19:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 06:19:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-591349 ] httplib throws a TypeError when the target host disconnects Message-ID: Bugs item #591349, was opened at 2002-08-06 00:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591349&group_id=5470 Category: Python Library Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Rob Green (rbgrn) Assigned to: Jeremy Hylton (jhylton) Summary: httplib throws a TypeError when the target host disconnects Initial Comment: This is the output that occurs about 1 in 500 hits to any particular URL. I've only seen it so far hitting servers running Apache 1.3.20, but I don't have enough data to limit it to that. Python 2.1.2 (#1, Mar 16 2002, 18:24:08) [GCC 2.95.3 [FreeBSD] 20010315 (release)] on freebsd4 h = httplib.HTTPConnection(host) response = h.getresponse() data = response.read() File "/usr/local/lib/python2.1/httplib.py", line 246, in read value = value + self._safe_read(chunk_left) File "/usr/local/lib/python2.1/httplib.py", line 314, in _safe_read chunk = self.fp.read(amt) TypeError: an integer is required ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-01-31 14:19 Message: Logged In: YES user_id=31392 Just getting back to this bug: What is the nc program? I don't have it on my RedHat 7.3 installation. ---------------------------------------------------------------------- Comment By: Rob Green (rbgrn) Date: 2002-09-26 04:40 Message: Logged In: YES user_id=590105 I have not tried the latest version, however I defined the test case which reproduces the problem. It takes under a minute to try, so please try it on your version as I do not currently have time to checkout and build it myself. Thank-you. Here's the test case again `nc -l -p 8888` on some terminal then in python have your test prog connect to the IP of that terminal port 8888 and GET / HTTP/1.0 or whatever then on the terminal hit Ctrl-C instead of handing back a response the test prog should throw the exception if affected. Thanks ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-09-03 22:20 Message: Logged In: YES user_id=31392 A bunch of questions. You seem to have narrowed this problem down a lot, but I'm not sure I understand the diagnosis. First off, have you tried the latest version of the code from CVS? It has changed in several ways, so it would be helpful if you could test with that version. I've been running a test driver for about an hour now without seeing any errors caused by httplib. The real problem I have is understanding what path through the code leaves chunked set to a true value and chunk_left set to something invalid. The begin() method of an HTTPResponse always sets chunked to 1 or 0. If it sets chunked to 1, it sets chunk_left to None. ---------------------------------------------------------------------- Comment By: Rob Green (rbgrn) Date: 2002-08-08 04:14 Message: Logged In: YES user_id=590105 Line 245 should be "if chunk_left is not _UNKNOWN:" And the next block up to line 259 should be indented. This causes an IncompleteRead exception to be thrown, which is IMO the correct one in this case. I attached a diff that patches the Python 2.1.2 httplib. ---------------------------------------------------------------------- Comment By: Rob Green (rbgrn) Date: 2002-08-08 03:51 Message: Logged In: YES user_id=590105 Ok I figured out what causes this. It's not a threading issue or anything like that, basically what happens is this: When httplib connects to a server and the hostname is good and the port is open and connects, but the server immediately disconnects without printing any text or anything, this exception is then thrown. I was able to reproduce it by running netcat -l -p locally and starting an HTTPConnection to that port, then punting netcat which causes python to throw the exception. ---------------------------------------------------------------------- Comment By: Rob Green (rbgrn) Date: 2002-08-07 06:16 Message: Logged In: YES user_id=590105 Ok I put together some test code that reproduced the bug in under an hour on my machine. Here it is... ---------------------------------------------------------------------- Comment By: Rob Green (rbgrn) Date: 2002-08-07 05:14 Message: Logged In: YES user_id=590105 I'd give you the URLs but I don't think it matters that much, I've seen this problem now hitting 4 different machines, all running linux/apache. It's not something very easy for me to reproduce because I only see the exception thrown once or maybe twice during the day where there are 20,000 hits from my daemon that day. I suppose that the way to reproduce it would be to have a list of urls, and to just have an app sit there and cycle through them doing a GET every 5 seconds or so, and eventually it should show up. I suppose to be more accurate the app would have to be threaded as well, maybe having a thread for each url that just opens an HTTPConnection every 5 seconds. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-08-06 12:42 Message: Logged In: YES user_id=31392 Can you provide any more information about what URLs cause problems? You could call set_debuglevel(1) to enable output of all HTTP trafffic. Or just a list of some of the URLs that failed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591349&group_id=5470 From noreply@sourceforge.net Fri Jan 31 15:25:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 07:25:31 -0800 Subject: [Python-bugs-list] [ python-Bugs-591349 ] httplib throws a TypeError when the target host disconnects Message-ID: Bugs item #591349, was opened at 2002-08-05 19:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591349&group_id=5470 Category: Python Library Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Rob Green (rbgrn) Assigned to: Jeremy Hylton (jhylton) Summary: httplib throws a TypeError when the target host disconnects Initial Comment: This is the output that occurs about 1 in 500 hits to any particular URL. I've only seen it so far hitting servers running Apache 1.3.20, but I don't have enough data to limit it to that. Python 2.1.2 (#1, Mar 16 2002, 18:24:08) [GCC 2.95.3 [FreeBSD] 20010315 (release)] on freebsd4 h = httplib.HTTPConnection(host) response = h.getresponse() data = response.read() File "/usr/local/lib/python2.1/httplib.py", line 246, in read value = value + self._safe_read(chunk_left) File "/usr/local/lib/python2.1/httplib.py", line 314, in _safe_read chunk = self.fp.read(amt) TypeError: an integer is required ---------------------------------------------------------------------- >Comment By: Rob Green (rbgrn) Date: 2003-01-31 09:25 Message: Logged In: YES user_id=590105 netcat the rpm is called netcat but the executable is nc you should be able to get an rpm for it off of rpmfind.net It's a very common program for diagnosing plain-text protocol network code. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-01-31 08:19 Message: Logged In: YES user_id=31392 Just getting back to this bug: What is the nc program? I don't have it on my RedHat 7.3 installation. ---------------------------------------------------------------------- Comment By: Rob Green (rbgrn) Date: 2002-09-25 23:40 Message: Logged In: YES user_id=590105 I have not tried the latest version, however I defined the test case which reproduces the problem. It takes under a minute to try, so please try it on your version as I do not currently have time to checkout and build it myself. Thank-you. Here's the test case again `nc -l -p 8888` on some terminal then in python have your test prog connect to the IP of that terminal port 8888 and GET / HTTP/1.0 or whatever then on the terminal hit Ctrl-C instead of handing back a response the test prog should throw the exception if affected. Thanks ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-09-03 17:20 Message: Logged In: YES user_id=31392 A bunch of questions. You seem to have narrowed this problem down a lot, but I'm not sure I understand the diagnosis. First off, have you tried the latest version of the code from CVS? It has changed in several ways, so it would be helpful if you could test with that version. I've been running a test driver for about an hour now without seeing any errors caused by httplib. The real problem I have is understanding what path through the code leaves chunked set to a true value and chunk_left set to something invalid. The begin() method of an HTTPResponse always sets chunked to 1 or 0. If it sets chunked to 1, it sets chunk_left to None. ---------------------------------------------------------------------- Comment By: Rob Green (rbgrn) Date: 2002-08-07 23:14 Message: Logged In: YES user_id=590105 Line 245 should be "if chunk_left is not _UNKNOWN:" And the next block up to line 259 should be indented. This causes an IncompleteRead exception to be thrown, which is IMO the correct one in this case. I attached a diff that patches the Python 2.1.2 httplib. ---------------------------------------------------------------------- Comment By: Rob Green (rbgrn) Date: 2002-08-07 22:51 Message: Logged In: YES user_id=590105 Ok I figured out what causes this. It's not a threading issue or anything like that, basically what happens is this: When httplib connects to a server and the hostname is good and the port is open and connects, but the server immediately disconnects without printing any text or anything, this exception is then thrown. I was able to reproduce it by running netcat -l -p locally and starting an HTTPConnection to that port, then punting netcat which causes python to throw the exception. ---------------------------------------------------------------------- Comment By: Rob Green (rbgrn) Date: 2002-08-07 01:16 Message: Logged In: YES user_id=590105 Ok I put together some test code that reproduced the bug in under an hour on my machine. Here it is... ---------------------------------------------------------------------- Comment By: Rob Green (rbgrn) Date: 2002-08-07 00:14 Message: Logged In: YES user_id=590105 I'd give you the URLs but I don't think it matters that much, I've seen this problem now hitting 4 different machines, all running linux/apache. It's not something very easy for me to reproduce because I only see the exception thrown once or maybe twice during the day where there are 20,000 hits from my daemon that day. I suppose that the way to reproduce it would be to have a list of urls, and to just have an app sit there and cycle through them doing a GET every 5 seconds or so, and eventually it should show up. I suppose to be more accurate the app would have to be threaded as well, maybe having a thread for each url that just opens an HTTPConnection every 5 seconds. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-08-06 07:42 Message: Logged In: YES user_id=31392 Can you provide any more information about what URLs cause problems? You could call set_debuglevel(1) to enable output of all HTTP trafffic. Or just a list of some of the URLs that failed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=591349&group_id=5470 From noreply@sourceforge.net Fri Jan 31 16:22:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 08:22:07 -0800 Subject: [Python-bugs-list] [ python-Bugs-677753 ] python.exe expected in extension builds Message-ID: Bugs item #677753, was opened at 2003-01-30 13:00 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=677753&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robin Dunn (robind) Assigned to: Jack Jansen (jackjansen) Summary: python.exe expected in extension builds Initial Comment: When building on OS X configure senses whether the build filesystem is case sensitive or not and if not builds "python.exe" instead of "python" to avoid conflicting with the "Python" dir. There are some things in doing the framework build that expect to have "python.exe" so i fyou ar building on a case-sensitive filesystem and only have "python" then they fail. Perhaps configure should make a python.exe --> python link. ---------------------------------------------------------------------- >Comment By: Robin Dunn (robind) Date: 2003-01-31 08:22 Message: Logged In: YES user_id=53955 Sorry, I meant to do that but must have been sidetracked... Here is the first one: ./python.exe /projects/Python-2.3a1/Mac/scripts/cachersrc.py -v /projects/_py/install/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/plat-mac /projects/_py/install/Library/Frameworks/Python.framework/Versions/2.3/Mac/Tools make[1]: ./python.exe: Command not found make[1]: *** [installmacsubtree] Error 127 make: *** [frameworkinstallmaclib] Error 2 ISTR that after making a link and running make again that there were a few more "python.exe"'s that floated by after this one too. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-01-31 01:04 Message: Logged In: YES user_id=45365 Robin, could you give an example of something that fails? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=677753&group_id=5470 From noreply@sourceforge.net Fri Jan 31 16:43:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 08:43:54 -0800 Subject: [Python-bugs-list] [ python-Bugs-678217 ] test_logging fails Message-ID: Bugs item #678217, was opened at 2003-01-31 16:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678217&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Nobody/Anonymous (nobody) Summary: test_logging fails Initial Comment: When I run the test suite, test_logging sometimes fails. It misses the following output and gets a bunch of exceptions llike the one I included at the end. I haven't counted, but I'd guess that there's one traceback for each missing line of output. test test_logging produced unexpected output: ********************************************************************** *** lines 489-514 of expected output missing: - ERR -> CRITICAL: Message 0 (via logrecv.tcp.ERR) - ERR -> ERROR: Message 1 (via logrecv.tcp.ERR) - INF -> CRITICAL: Message 2 (via logrecv.tcp.INF) - INF -> ERROR: Message 3 (via logrecv.tcp.INF) - INF -> WARN: Message 4 (via logrecv.tcp.INF) - INF -> INFO: Message 5 (via logrecv.tcp.INF) - INF.UNDEF -> CRITICAL: Message 6 (via logrecv.tcp.INF.UNDEF) - INF.UNDEF -> ERROR: Message 7 (via logrecv.tcp.INF.UNDEF) - INF.UNDEF -> WARN: Message 8 (via logrecv.tcp.INF.UNDEF) - INF.UNDEF -> INFO: Message 9 (via logrecv.tcp.INF.UNDEF) - INF.ERR -> CRITICAL: Message 10 (via logrecv.tcp.INF.ERR) - INF.ERR -> ERROR: Message 11 (via logrecv.tcp.INF.ERR) - INF.ERR.UNDEF -> CRITICAL: Message 12 (via logrecv.tcp.INF.ERR.UNDEF) - INF.ERR.UNDEF -> ERROR: Message 13 (via logrecv.tcp.INF.ERR.UNDEF) - DEB -> CRITICAL: Message 14 (via logrecv.tcp.DEB) - DEB -> ERROR: Message 15 (via logrecv.tcp.DEB) - DEB -> WARN: Message 16 (via logrecv.tcp.DEB) - DEB -> INFO: Message 17 (via logrecv.tcp.DEB) - DEB -> DEBUG: Message 18 (via logrecv.tcp.DEB) - UNDEF -> CRITICAL: Message 19 (via logrecv.tcp.UNDEF) - UNDEF -> ERROR: Message 20 (via logrecv.tcp.UNDEF) - UNDEF -> WARN: Message 21 (via logrecv.tcp.UNDEF) - UNDEF -> INFO: Message 22 (via logrecv.tcp.UNDEF) - INF.BADPARENT.UNDEF -> CRITICAL: Message 23 (via logrecv.tcp.INF.BADPARENT.UNDEF) - INF.BADPARENT -> CRITICAL: Message 24 (via logrecv.tcp.INF.BADPARENT) - INF -> INFO: Messages should bear numbers 0 through 24. (via logrecv.tcp.INF) ********************************************************************** Traceback (most recent call last): File "/home/jeremy/src/python/dist/src/Lib/logging/__init__.py", line 648, in emit self.stream.write("%s\n" % msg) ValueError: I/O operation on closed file Traceback (most recent call last): File "/home/jeremy/src/python/dist/src/Lib/logging/__init__.py", line 648, in emit self.stream.write("%s\n" % msg) ValueError: I/O operation on closed file ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678217&group_id=5470 From noreply@sourceforge.net Fri Jan 31 16:55:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 08:55:16 -0800 Subject: [Python-bugs-list] [ python-Bugs-676072 ] rfc822.Message() doesn't support __contains__() (+patch) Message-ID: Bugs item #676072, was opened at 2003-01-28 08:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676072&group_id=5470 Category: Python Library Group: Python 2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Michal Vitecek (fufsource) Assigned to: Raymond Hettinger (rhettinger) Summary: rfc822.Message() doesn't support __contains__() (+patch) Initial Comment: class rfc822.Message() should behave like a dictionary but it doesn't define method __contains__() so it's not possible to use form: 'header' in messageInstance attached is a simple patch that fixes this. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-31 11:55 Message: Logged In: YES user_id=80475 Hmm, Barry isn't crazy about it; the only rationale is consistency; the docs don't demand it; and the module is deprecated. I say we pass on this one and move on to other things. Marking as wont fix and closing. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-31 08:59 Message: Logged In: YES user_id=12800 I'm still not crazy about the specific behavior requested by this bug, i.e. that "header in msginst" should have meaning. But if everyone else wants this for rfc822.Message, I think Raymond's patch is probably best since it's more thorough. However, please add test cases and updates to the rfc822 documentation. ---------------------------------------------------------------------- Comment By: Michal Vitecek (fufsource) Date: 2003-01-31 04:15 Message: Logged In: YES user_id=698198 i don't know, but looking at the source from 2.2.2, there's a comment saying "Access as a dictionary (...)". in that case __contains__ should be implemented as well. from my personal point of view it's inconsistent in its behaviour since GvR said '.has_key()' would most probably be deprecated in his 2002's talk and 'in' should be used instead. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-30 23:47 Message: Logged In: YES user_id=80475 P.S. when I said "someone", I was talking about all of the dictionary interface except for __contains__ which was added by me many months ago based on the idea that where there is a has_key, there should be a __contains__. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-30 23:35 Message: Logged In: YES user_id=80475 Looking at the Py2.3 source, it looks like someone already implemented many of those dictionary semantics (including "header in msginst"). My thought was to complete this idea expressed in the comment, "Access as a dictionary", which was followed by definitions for len, __getitem__, __setitem__, __delitem__, setdefault, has_key, __contains__, keys, values, and items. So, it looked like it intended but did not succeed in implementing the entire dictionary interface. My patch was a simple way to fill in the blanks. OTOH, I have zero attachment to it and won't be disappointed if it is marked as Wont Fix and closed. It never pays to spend much brainpower on a deprecated module. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-30 22:41 Message: Logged In: YES user_id=12800 It's not entirely clear to me that Messages should have dictionary semantics, or that you should be able to say "header in msginst". I don't think I'd want those semantics for email.Message. Messages are more than just a collection of their headers. Why wouldn't __contains__ test for a subpart in a message tree, or for some text in the body of the message? Also, in email.Message, __getitem__ etc don't have dict semantics on purpose. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-01-30 18:40 Message: Logged In: YES user_id=80475 I've attached my own version of this patch for Py2.3. The same solution was used for shelve so that a single minimal intervention keeps the module fully synced with mapping interface. I know this module is superceded but it doesn't hurt to sync-up its interface for those who still use it. Barry, if it meets your approval please reassign back to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676072&group_id=5470 From noreply@sourceforge.net Fri Jan 31 17:22:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 09:22:08 -0800 Subject: [Python-bugs-list] [ python-Bugs-676990 ] memory leak in pyexpat.c::my_ElementDeclHandler() Message-ID: Bugs item #676990, was opened at 2003-01-29 14:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676990&group_id=5470 Category: XML Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neal Norwitz (nnorwitz) Summary: memory leak in pyexpat.c::my_ElementDeclHandler() Initial Comment: Fred, I'm assigning to you since you've seen this once already. :-) Not sure who would know best how to fix this problem. Perhaps Martin, but he's on vacation. As of now, 2003/1/29, there is a memory leak in xmlparse.c::doProlog() line 3979. The XML_Content is dynamically allocated, but never freed in the block. The lifetime of the variable content is not clear. It is passed to elementDeclHandler(). Does content need to be dynamic, or can it be a local (stack) variable? Does elementDeclHandler() take ownership of content? I can make the change in Python (which is where this problem was found from test_minidom). 20 bytes in 1 blocks are definitely lost in loss record 2 of 15 at 0x4015D480: malloc (vg_clientfuncs.c:100) doProlog (Modules/expat/xmlparse.c:3979) prologProcessor (Modules/expat/xmlparse.c:3185) prologInitProcessor (Modules/expat/xmlparse.c:3016) XML_ParseBuffer (Modules/expat/xmlparse.c:1439) XML_Parse (Modules/expat/xmlparse.c:1427) xmlparse_Parse (Modules/pyexpat.c:853) This problem was originally from this bug report in expat: http://sf.net/tracker/?func=detail&atid=110127&aid=676926&group_id=10127 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-31 12:22 Message: Logged In: YES user_id=3066 Oops, patch really attached now. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-30 10:38 Message: Logged In: YES user_id=3066 The attached patch frees the content model passed to the handler. This should fix the leak; please test using whatever tool you used to discover this. Thanks! ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-30 09:44 Message: Logged In: YES user_id=3066 Fixed summary. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-01-29 15:03 Message: Logged In: YES user_id=3066 As noted in the Expat tracker, this is not a memory leak in Expat, but in pyexpat. I've taken a quick look at the relevant code in pyexpat; it won't be hard to fix, but it will take longer than writing this response. I'll try to knock it out tonight. (For the record: this isn't due to any changes in Expat, it's just that the bug in pyexpat has only now been caught.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676990&group_id=5470 From noreply@sourceforge.net Fri Jan 31 17:44:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 09:44:43 -0800 Subject: [Python-bugs-list] [ python-Bugs-678250 ] test_mmap failling on AIX Message-ID: Bugs item #678250, was opened at 2003-01-31 12:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678250&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: test_mmap failling on AIX Initial Comment: test_mmap is failing on a flush while trying to do: Copy-on-write memory map data not written correctly The problem is that the mmap is opened with ACCESS_COPY. This translates to MAP_PRIVATE. On AIX, the msync man page says: "When the MS_SYNC and MAP_PRIVATE flags both are used, the msync subroutine returns an errno value of EINVAL." I'm not sure what the correct fix should be. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678250&group_id=5470 From noreply@sourceforge.net Fri Jan 31 17:53:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 09:53:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-669692 ] pdb user_call breakage Message-ID: Bugs item #669692, was opened at 2003-01-17 11:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669692&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: pdb user_call breakage Initial Comment: Reported on c.l.py: ----------- I'm running python 2.3a1 on a Win32 machine. pdb's behaviour seems to have been changed from 2.2*. "user_call" method is added, and it's called automatically for every function/method call when I set a breakpoint somewhere else and "continue". ------------ This is certainly my fauld, but I never use breakpoints in pdb, so right now I don't even know how to duplicate it, never mind fix it. It's probably shallow, though. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-01-31 17:53 Message: Logged In: YES user_id=6656 Fixed in revision 1.61 of Lib/pdb.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669692&group_id=5470 From noreply@sourceforge.net Fri Jan 31 17:55:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 09:55:09 -0800 Subject: [Python-bugs-list] [ python-Bugs-673797 ] setting socket timeout crashes SSL? Message-ID: Bugs item #673797, was opened at 2003-01-23 22:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=673797&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Craig Allen (cba037) Assigned to: Nobody/Anonymous (nobody) Summary: setting socket timeout crashes SSL? Initial Comment: First: bravo for compiling SSL support in the 2.3 binaries! I can connect fine to a secure web server using HTTPS. However, when I set a socket default timeout, I get errors: import socket socket.setdefaulttimeout(30.0) import urllib f = urllib.urlopen('https://members.tufts-health.com/memindex.html') print f.read() =================== Traceback (most recent call last): File "testssl.py", line 9, in ? f = urllib.urlopen('https://members.tufts-health.com/memindex.html') File "/usr/lib/python2.3/urllib.py", line 76, in urlopen return opener.open(url) File "/usr/lib/python2.3/urllib.py", line 181, in open return getattr(self, name)(url) File "/usr/lib/python2.3/urllib.py", line 375, in open_https h.endheaders() File "/usr/lib/python2.3/httplib.py", line 695, in endheaders self._send_output() File "/usr/lib/python2.3/httplib.py", line 581, in _send_output self.send(msg) File "/usr/lib/python2.3/httplib.py", line 548, in send self.connect() File "/usr/lib/python2.3/httplib.py", line 945, in connect ssl = socket.ssl(realsock, self.key_file, self.cert_file) socket.sslerror: (2, 'The operation did not complete (read)') =================== This is on Linux; similar behaviour on Win2K. ---------------------------------------------------------------------- Comment By: Geoff Talvola (gtalvola) Date: 2003-01-31 12:55 Message: Logged In: YES user_id=88162 This is fixed by patch 676472 so when that patch is checked in, this bug can be closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=673797&group_id=5470 From noreply@sourceforge.net Fri Jan 31 17:58:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 09:58:55 -0800 Subject: [Python-bugs-list] [ python-Bugs-669692 ] pdb user_call breakage Message-ID: Bugs item #669692, was opened at 2003-01-17 11:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669692&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Michael Hudson (mwh) Summary: pdb user_call breakage Initial Comment: Reported on c.l.py: ----------- I'm running python 2.3a1 on a Win32 machine. pdb's behaviour seems to have been changed from 2.2*. "user_call" method is added, and it's called automatically for every function/method call when I set a breakpoint somewhere else and "continue". ------------ This is certainly my fauld, but I never use breakpoints in pdb, so right now I don't even know how to duplicate it, never mind fix it. It's probably shallow, though. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-01-31 17:58 Message: Logged In: YES user_id=6656 and actually close the bug... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-31 17:53 Message: Logged In: YES user_id=6656 Fixed in revision 1.61 of Lib/pdb.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669692&group_id=5470 From noreply@sourceforge.net Fri Jan 31 18:01:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 10:01:33 -0800 Subject: [Python-bugs-list] [ python-Bugs-678259 ] locale.getpreferredencoding fails on AIX Message-ID: Bugs item #678259, was opened at 2003-01-31 13:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678259&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: locale.getpreferredencoding fails on AIX Initial Comment: The problem is setting LC_CTYPE to an empty string: >>> locale.setlocale(locale.LC_CTYPE, '') Traceback (most recent call last): File "", line 1, in ? File "/home/neal/python/dist/aix/Lib/locale.py", line 381, in setlocale return _setlocale(category, locale) locale.Error: locale setting not supported Putting a try/except around the setlocale call in getpreferredencoding allows the test to pass. I don't know if this is correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678259&group_id=5470 From noreply@sourceforge.net Fri Jan 31 18:06:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 10:06:24 -0800 Subject: [Python-bugs-list] [ python-Bugs-678264 ] test_resource fails when file size is limited Message-ID: Bugs item #678264, was opened at 2003-01-31 13:06 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678264&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: test_resource fails when file size is limited Initial Comment: test_resource does: print resource.RLIM_INFINITY == max I'm not sure of the benefit of this line. For machines which have limited file sizes, it causes the test to fail. Otherwise the test seems to work properly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678264&group_id=5470 From noreply@sourceforge.net Fri Jan 31 18:09:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 10:09:18 -0800 Subject: [Python-bugs-list] [ python-Bugs-672115 ] Assignment to __bases__ of direct object subclasses Message-ID: Bugs item #672115, was opened at 2003-01-21 22:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672115&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Michael Hudson (mwh) Summary: Assignment to __bases__ of direct object subclasses Initial Comment: I'm not entirely sure this is a bug, but I think it is surprising: Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class A(object): ... pass ... >>> class B(object): ... pass ... >>> B.__bases__ = (A,) Traceback (most recent call last): File "", line 1, in ? TypeError: __bases__ assignment: 'A' deallocator differs from 'object' It seems like you should be able to change the __bases__ of a new-style class (implemented in Python) which inherits directly from object to another new-style class. (Will the deallocator issue ever come into play if the only types involved are HEAPTYPES and object as the ultimate base?) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-01-31 18:09 Message: Logged In: YES user_id=6656 Are you interested in working up a patch for this? Hacking this kind of stuff requires motivation I'm not sure I can drum up in time for 2.3... ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2003-01-23 17:03 Message: Logged In: YES user_id=86307 Sorry about the parenthetical comment; I think what I was trying to say is basically what you have in your last paragraph. As for use cases, I don't have any myself (I ran into this with some test code for a metaclass which "overrides" __bases__). However, grepping through the standard library, I note that one place where assignment to __bases__ is used is in xmlrpclib.SlowParser. It appears to me that if SlowParser and xmllib.XMLParser (neither of which has a base class) were converted to new-style classes, the assignment to __bases__ would generate this exception. Of course, that shouldn't be too hard to work around if that turns out to be necessary. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-22 11:50 Message: Logged In: YES user_id=6656 I agree this is a bit surprising. When I was writing this code I went for the conservative-as-possible approach as I didn't want to introduce instabilities to Python. It certainly may be that I've overdone it. In this case I probably have; if the tp_dealloc of the class being adjusted is subtype_dealloc and the tp_dealloc that ultimately gets invoked is the same we're probably OK. But I'm not sure and it's been a while since I thought about this. It also happens that my motivating use-case for this isn't troubled by this restriction. I don't understand your last, parenthetical, comment. HEAPTYPES as such doesn't come into it, does it? You might be right that we don't need to worry about tp_dealloc if the ultimate solid_base doesn't change and all the tp_deallocs on the way there are subtype_dealloc... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672115&group_id=5470 From noreply@sourceforge.net Fri Jan 31 18:10:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 10:10:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-678265 ] test_coercion fails on AIX Message-ID: Bugs item #678265, was opened at 2003-01-31 13:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678265&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Tim Peters (tim_one) Summary: test_coercion fails on AIX Initial Comment: Tim, I assigned this to you to see if you had any insight/ideas about this problem. test_coercion fails on AIX. All the failures are due to the test expecting n+0j, but the output is n-0j. Here's an example: - / (2+0j) = (0.5+0j) ? ^ + / (2+0j) = (0.5-0j) ? ^ I have another compiler, so I'll probably try that. Especially since it's gcc. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678265&group_id=5470 From noreply@sourceforge.net Fri Jan 31 18:56:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 10:56:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-678294 ] test_coercion fails on AIX Message-ID: Bugs item #678294, was opened at 2003-01-31 13:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678294&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Tim Peters (tim_one) Summary: test_coercion fails on AIX Initial Comment: Tim, I assigned this to you to see if you had any insight/ideas about this problem. test_coercion fails on AIX. All the failures are due to the test expecting n+0j, but the output is n-0j. Here's an example: - / (2+0j) = (0.5+0j) ? ^ + / (2+0j) = (0.5-0j) ? ^ I have another compiler, so I'll probably try that. Especially since it's gcc. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678294&group_id=5470 From noreply@sourceforge.net Fri Jan 31 18:58:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 10:58:21 -0800 Subject: [Python-bugs-list] [ python-Bugs-678294 ] test_coercion fails on AIX Message-ID: Bugs item #678294, was opened at 2003-01-31 13:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678294&group_id=5470 Category: Python Interpreter Core Group: None >Status: Deleted >Resolution: Duplicate Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Tim Peters (tim_one) Summary: test_coercion fails on AIX Initial Comment: Tim, I assigned this to you to see if you had any insight/ideas about this problem. test_coercion fails on AIX. All the failures are due to the test expecting n+0j, but the output is n-0j. Here's an example: - / (2+0j) = (0.5+0j) ? ^ + / (2+0j) = (0.5-0j) ? ^ I have another compiler, so I'll probably try that. Especially since it's gcc. :-) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-31 13:58 Message: Logged In: YES user_id=33168 Not sure how this got duplicated, same as 678265. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678294&group_id=5470 From noreply@sourceforge.net Fri Jan 31 19:26:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 11:26:47 -0800 Subject: [Python-bugs-list] [ python-Bugs-678265 ] test_coercion fails on AIX Message-ID: Bugs item #678265, was opened at 2003-01-31 13:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678265&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Nobody/Anonymous (nobody) Summary: test_coercion fails on AIX Initial Comment: Tim, I assigned this to you to see if you had any insight/ideas about this problem. test_coercion fails on AIX. All the failures are due to the test expecting n+0j, but the output is n-0j. Here's an example: - / (2+0j) = (0.5+0j) ? ^ + / (2+0j) = (0.5-0j) ? ^ I have another compiler, so I'll probably try that. Especially since it's gcc. :-) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-31 14:26 Message: Logged In: YES user_id=33168 The test passes with gcc 3.2. The C compiler is in vac.C version 4.4.0.3 (lslpp -l vac.C). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678265&group_id=5470 From noreply@sourceforge.net Fri Jan 31 20:18:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 12:18:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-678352 ] list.append memory leak ? Message-ID: Bugs item #678352, was opened at 2003-01-31 15:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678352&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: thanos vassilakis (thanos) Assigned to: Nobody/Anonymous (nobody) Summary: list.append memory leak ? Initial Comment: # this SEEMS to leak l = xrange(10000) while 1: a=[] map(a.append, l) del a # this does not while 1: a=range(10000) del a ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678352&group_id=5470 From noreply@sourceforge.net Fri Jan 31 20:44:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 12:44:05 -0800 Subject: [Python-bugs-list] [ python-Bugs-678375 ] test_long fails Message-ID: Bugs item #678375, was opened at 2003-01-31 20:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678375&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Nobody/Anonymous (nobody) Summary: test_long fails Initial Comment: on linux kernel 2.2.17, libc2.2 this code demonstrates the problem: s='12345'*1000 float(s) Traceback (most recent call last): File "", line 1, in ? ValueError: invalid literal for float(): 1234512... caused by PyFloat_FromString in floatobject.c: Testing shows strtod only reads the first 721 digits of the string it gets (after any leading zeros). Python then thinks the remaining digits aren't valid because strtod did not process them, even though strtod returned inf as is proper. I guess this is a strtod problem, maybe it depends on the version of libc? PyFloat_FromString could deal with this case, but really only correctly if it reimpliments strtod, as there could be an exponent way on the end of the string. I don't know what the correct solution to this is, but surely something should at least be done about the failed test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678375&group_id=5470 From noreply@sourceforge.net Fri Jan 31 20:57:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 12:57:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-634116 ] pdb quit breakage Message-ID: Bugs item #634116, was opened at 2002-11-05 22:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634116&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: pdb quit breakage Initial Comment: Behold: >>> import pdb >>> pdb.run("pass") > (1)?() (Pdb) q >>> pdb.run("pass") Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/bdb.py", line 48, in trace_dispatch return self.dispatch_line(frame) File "/usr/local/lib/python2.3/bdb.py", line 61, in dispatch_line if self.quitting: raise BdbQuit bdb.BdbQuit >>> pdb.run("pass") > (1)?() (Pdb) q >>> IOW, quitting out of pdb causes some sticky state to remain behind which sabotages the next call to pdb.run(). This bug is new in Python 2.3. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-31 20:57 Message: Logged In: YES user_id=670441 This is very odd. I just downloaded the latest cvs and do not see the problem. Is it still there? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634116&group_id=5470 From noreply@sourceforge.net Fri Jan 31 21:00:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 13:00:59 -0800 Subject: [Python-bugs-list] [ python-Bugs-678352 ] list.append memory leak ? Message-ID: Bugs item #678352, was opened at 2003-01-31 15:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678352&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: thanos vassilakis (thanos) Assigned to: Nobody/Anonymous (nobody) Summary: list.append memory leak ? Initial Comment: # this SEEMS to leak l = xrange(10000) while 1: a=[] map(a.append, l) del a # this does not while 1: a=range(10000) del a ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-31 16:00 Message: Logged In: YES user_id=31435 Please identify the Python version and OS+compiler+C library in use. The process size remains steady for me under current CVS Python on Win2K w/ MSVC6. A true leak is possible but unlikely. More likely is that your platform C malloc()/free() decide not to return memory to the OS. If so, that's outside of Python's control ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678352&group_id=5470 From noreply@sourceforge.net Fri Jan 31 21:07:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 13:07:57 -0800 Subject: [Python-bugs-list] [ python-Bugs-634116 ] pdb quit breakage Message-ID: Bugs item #634116, was opened at 2002-11-05 17:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634116&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: pdb quit breakage Initial Comment: Behold: >>> import pdb >>> pdb.run("pass") > (1)?() (Pdb) q >>> pdb.run("pass") Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/bdb.py", line 48, in trace_dispatch return self.dispatch_line(frame) File "/usr/local/lib/python2.3/bdb.py", line 61, in dispatch_line if self.quitting: raise BdbQuit bdb.BdbQuit >>> pdb.run("pass") > (1)?() (Pdb) q >>> IOW, quitting out of pdb causes some sticky state to remain behind which sabotages the next call to pdb.run(). This bug is new in Python 2.3. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-31 16:07 Message: Logged In: YES user_id=6380 WFM too now. Maybe the latest checkin (by mwh) to pdb.py fixed it. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-31 15:57 Message: Logged In: YES user_id=670441 This is very odd. I just downloaded the latest cvs and do not see the problem. Is it still there? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=634116&group_id=5470 From noreply@sourceforge.net Fri Jan 31 21:08:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 13:08:30 -0800 Subject: [Python-bugs-list] [ python-Bugs-678265 ] test_coercion fails on AIX Message-ID: Bugs item #678265, was opened at 2003-01-31 13:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678265&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: test_coercion fails on AIX Initial Comment: Tim, I assigned this to you to see if you had any insight/ideas about this problem. test_coercion fails on AIX. All the failures are due to the test expecting n+0j, but the output is n-0j. Here's an example: - / (2+0j) = (0.5+0j) ? ^ + / (2+0j) = (0.5-0j) ? ^ I have another compiler, so I'll probably try that. Especially since it's gcc. :-) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-01-31 16:08 Message: Logged In: YES user_id=31435 You really need a platform wizard for something like this. If there are any compiler options with descriptions like "generate IEEE-754 compatible code" (or "stricter 754 xyz"), or "disable generation of fused multiply-add", they would be relevant. OTOH, Python promises nothing about how the sign bit of a floating zero behaves, so it would be OK by me if the test were changed not to produce complex results with zero imaginary members. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-31 14:26 Message: Logged In: YES user_id=33168 The test passes with gcc 3.2. The C compiler is in vac.C version 4.4.0.3 (lslpp -l vac.C). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678265&group_id=5470 From noreply@sourceforge.net Fri Jan 31 21:25:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 13:25:48 -0800 Subject: [Python-bugs-list] [ python-Bugs-676342 ] after using pdb readline does not work correctly Message-ID: Bugs item #676342, was opened at 2003-01-28 20:53 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676342&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Michael Stone (mbrierst) Assigned to: Nobody/Anonymous (nobody) Summary: after using pdb readline does not work correctly Initial Comment: After I use pdb in the interpreter my readline settings are messed up. It only knows about the pdb readline stuff forever afterward. In fact, this happens as soon as a Pdb object is instantiated, regardless of whether or not you use it. This is a result of some aspects of the Cmd object in Lib/cmd.py. Currently Cmd registers a new readline completer as soon as a Cmd object is instantiated. This is probably incorrect. I believe the correct place to register the new handler is in the preloop hook. That way the new readline completer is only used while the Cmd object is actually responsible for processing user input. Next, the old readline completer should probably be re-registered in the postloop hook. In order to do this, a new call must be added to the readline module to return the current completer so it can be saved and later restored. The files included patch readline.c (version 2.41.64) and cmd.py (version 1.26.16.2) to make the changes described above. After this patch readline works as expected in the interpreter. Let me know what you think of it. ---------------------------------------------------------------------- >Comment By: Michael Stone (mbrierst) Date: 2003-01-31 21:25 Message: Logged In: YES user_id=670441 I started using the latest cvs version today. I have attached a diff to the latest cvs as patchcmd2 if that's more convenient for you to apply. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-30 16:59 Message: Logged In: YES user_id=670441 That sounds good to me. Go ahead and check in patchcmd. Thanks for your suggestions, I will follow them in future patches. In this one, I was trying to follow the conventions I saw being used in the module, but they were outdated or incorrect (and I didn't always follow them correctly anyway!). Okay that's definitely enough commentary for a few line patch. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-30 10:22 Message: Logged In: YES user_id=6656 Thanks for the new patch, it looks OK. There are a couple of things that spring to mind for future patches: - the function should be METH_NOARGS (or you should check the args tuple) - there should be a blank line between the argspec line in the docstring and the description - you should use the PyDoc_STRVAR macro (but this was only used in the CVS trunk's version of readline). I made these changes and checked in revision 2.59 of Modules/readline.c. Wrt the cmd.py changes, I think I'll probably let that sleeping dog lie. I agree with you in general: cmd.py probably shouldn't be rebinding any keys, but 1) the interface is "specify the completion key to get completion", so backwards compatibility raises its head 2) as you say, most people do probably rebind tab anyway so I propose to check in your patchcmd, close the bug and wait for someone to submit a bug report about pdb messing up their bindings. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-29 18:19 Message: Logged In: YES user_id=670441 Actually, the readline library does have the functionality to get the current binding of the tab key, so it could be saved and restored. However, to do this in python some stuff would have to be added to the readline.c module, to create some python layer that deals with the way readline stores macros, functions, and keymaps. It's probably not worth the effort unless someone wants to do major changes to the readline module to add the full functionality of the underlying library to the python interface. Probably cmd.py shouldn't be rebinding the tab key to complete at all. If the user wants that, won't they have already done it somewhere else, like in their pythonrc or inputrc files? And if they don't it might be impolite to change their bindings. ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-01-29 15:27 Message: Logged In: YES user_id=670441 I attached a changed readline.c patch to hopefully get rid of any "sickness". (There was a not-checking-for-null problem too... ouch) I think it's good now. But note, there may not be a way to do this sort of thing perfectly. If you mess around enough with starting debuggers within debuggers (or in general anything that uses a Cmd object) it might be possible to end up with an unexpected completer function in the end. And it looks like under the current system there's no way to get back the completer key that was initially used. But this isn't SUCH a big deal since I think everyone uses tab, right? At any rate, the change is definitely an improvement for me. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-01-29 10:36 Message: Logged In: YES user_id=6656 I approve of this patch in principle. I hadn't done enough investigation to see that it was so easy to get the current completer function! OTOH: return Py_BuildValue("O", completer); is sick. Change that to Py_INCREF(completer); return completer; and if noone else howls, I'll check it in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=676342&group_id=5470 From noreply@sourceforge.net Fri Jan 31 22:47:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 14:47:40 -0800 Subject: [Python-bugs-list] [ python-Bugs-678352 ] list.append memory leak ? Message-ID: Bugs item #678352, was opened at 2003-01-31 15:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678352&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: thanos vassilakis (thanos) Assigned to: Nobody/Anonymous (nobody) Summary: list.append memory leak ? Initial Comment: # this SEEMS to leak l = xrange(10000) while 1: a=[] map(a.append, l) del a # this does not while 1: a=range(10000) del a ---------------------------------------------------------------------- >Comment By: thanos vassilakis (thanos) Date: 2003-01-31 17:47 Message: Logged In: YES user_id=91277 HP UX B.11.00 BSD 4.7 python 2.2 Its possible it is not a bug that is why I used the word SEEMS but why does the second code fragment behave? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-31 16:00 Message: Logged In: YES user_id=31435 Please identify the Python version and OS+compiler+C library in use. The process size remains steady for me under current CVS Python on Win2K w/ MSVC6. A true leak is possible but unlikely. More likely is that your platform C malloc()/free() decide not to return memory to the OS. If so, that's outside of Python's control ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678352&group_id=5470 From noreply@sourceforge.net Fri Jan 31 23:52:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 31 Jan 2003 15:52:37 -0800 Subject: [Python-bugs-list] [ python-Bugs-678464 ] Docs don't define sequence-ness very well Message-ID: Bugs item #678464, was opened at 2003-01-31 17:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678464&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Docs don't define sequence-ness very well Initial Comment: The notion of what a sequence is seems to be somewhat ill-defined. If I execute for k in None: pass a TypeError is raised with "iteration over non-sequence" as the message. I searched the source for that message and found three occurrences, one each in Objects/{abstract,classobject,typeobject}.c. In abstract.c a non-sequence is an object which fails the PySequence_Check(s) test. In typeobject.c:slot_tp_iter, a sequence is defined to have a __getitem__ method. In classobject.c a sequence must have either __iter__ or __getitem__ and if __iter__ is defined, it must return something which passes PyIter_Check(). So, if I want to do a sniff test for a sequence is it "close enough" to execute (hasattr(s, "__getitem__") or hasattr(s, "__iter__")) or should I execute iter(s) ? Since this seems to be a fairly nebulous concept it makes sense to me that it should be defined somewhere. I checked the ref manual (types.html) in the Sequences section but saw nothing mentioned. If this is already defined somewhere I'd be happy to be pointed in the right direction. I would just update types.html if I knew what the answer was... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678464&group_id=5470