[ python-Bugs-1087975 ] example code not working
Bugs item #1087975, was opened at 2004-12-19 17:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1087975group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: perica (zivkovicperica) Assigned to: Nobody/Anonymous (nobody) Summary: example code not working Initial Comment: in chapter 9.11 Generator Expressions in Python Tutorial this example is not working: sum(i*i for i in range(10)) # sum of squares 285 I'm using Python 2.3.4 (GCC 3.4.2) on FreeBSD 5.3 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1087975group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1086603 ] segfault in readline
Bugs item #1086603, was opened at 2004-12-16 18:02 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1086603group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: DSM (dsm001) Assigned to: Nobody/Anonymous (nobody) Summary: segfault in readline Initial Comment: It's possible to produce segfaults using two functions from the readline module by giving them negative values (GNU readline 4.3-10), at least in some circumstances. Python 2.5a0 (#10, Dec 15 2004, 19:53:33) [GCC 3.3.3 (Debian 20040401)] on linux2 Type help, copyright, credits or license for more information. import readline [25290 refs] readline.remove_history_item(-1) Segmentation fault readline.replace_history_item(-1,'abc') Segmentation fault gdb reveals it happens because the (external) remove_history and replace_history_entry don't return NULL in these cases. I'm not sure whether we're responsible for checking the sanity of inputs or the GNU code should be returning NULL and isn't, but at least sometimes it doesn't. -- Comment By: Michael Hudson (mwh) Date: 2004-12-19 16:41 Message: Logged In: YES user_id=6656 Do you want to fix it then? :) I can't imagine it's that hard, but it would be easier for someone who can test that their fix helps... -- Comment By: George Yoshida (quiver) Date: 2004-12-18 10:45 Message: Logged In: YES user_id=671362 FYI, I can reproduce this with : - Python 2.4 readline 4.3 under SuSE 9.1 - Python 2.5(snapshot as of 2004-12-17) readline 4.3 under SuSE 9.1 - Python 2.4 readline 4.3.5(?) under Cygwin -- Comment By: Michael Hudson (mwh) Date: 2004-12-17 14:18 Message: Logged In: YES user_id=6656 Hmm. I can't reproduce this (also with readline 4.3). Odd. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1086603group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-818315 ] Shared object modules in Windows have no __file__.
Bugs item #818315, was opened at 2003-10-05 23:44 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=818315group_id=5470 Category: Windows Group: None Status: Closed Resolution: Invalid Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: Shared object modules in Windows have no __file__. Initial Comment: The subject basically says it. Whether it's math.so, operator.so, anything -- in *nix it has an __file__, in Windows it doesn't. -- Comment By: Martin v. Löwis (loewis) Date: 2004-12-19 19:07 Message: Logged In: YES user_id=21627 It's as alanmcintyre says: math is not a shared object in Windows. Closing this as invalid. -- Comment By: Alan McIntyre (ESRG) (alanmcintyre) Date: 2004-11-06 21:19 Message: Logged In: YES user_id=1115903 In the case of the math module, I would assume that it doesn't have a __file__ attribute on Windows because it's a builtin and is rolled up into python2x.dll in the Windows distribution. This seems to match up with the 2.3 codumentation: The __file__ attribute is not present for C modules that are statically linked into the interpreter; for extension modules loaded dynamically from a shared library, it is the pathname of the shared library file. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=818315group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-793078 ] Easier-to-create alternative Python installer for Windows
Bugs item #793078, was opened at 2003-08-22 12:20 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=793078group_id=5470 Category: Installation Group: Feature Request Status: Closed Resolution: Fixed Priority: 5 Submitted By: David Fraser (davidfraser) Assigned to: Nobody/Anonymous (nobody) Summary: Easier-to-create alternative Python installer for Windows Initial Comment: It is unfortunate that the standard Python installer requires proprietrary products (Wise) to build on Windows. It makes it difficult to recreate a Python installer for those who want a custom installer. While I appreciate the nice installer donated by Wise (http://starship.python.net/crew/mhammond/wise/wise.html) it would be great if there was a simpler solution. The ultimate solution would be to use the distutils setup to create an installer. It doesn't have to look as nice as the Wise one, as long as it can be created using all Open-source tools. -- Comment By: Martin v. Löwis (loewis) Date: 2004-12-19 19:09 Message: Logged In: YES user_id=21627 This bug is fixed in 2.4, which only requires Python (+pythonwin) to build the installer. -- Comment By: Thomas Heller (theller) Date: 2003-08-25 09:42 Message: Logged In: YES user_id=11105 There *is* already a src\PCBuild\python.iss file, comments about what needs to be done are at the top of the file. -- Comment By: Skip Montanaro (montanaro) Date: 2003-08-23 05:35 Message: Logged In: YES user_id=44345 I'm sure if you contributed an InnoSetup installer file it would be accepted. ;-) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=793078group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1087975 ] example code not working
Bugs item #1087975, was opened at 2004-12-19 11:35 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1087975group_id=5470 Category: Documentation Group: Python 2.3 Status: Closed Resolution: Invalid Priority: 5 Submitted By: perica (zivkovicperica) Assigned to: Nobody/Anonymous (nobody) Summary: example code not working Initial Comment: in chapter 9.11 Generator Expressions in Python Tutorial this example is not working: sum(i*i for i in range(10)) # sum of squares 285 I'm using Python 2.3.4 (GCC 3.4.2) on FreeBSD 5.3 -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 13:27 Message: Logged In: YES user_id=80475 It looks like you have a Python 2.4 tutorial in-hand but are working with an old version of python, 2.3.4 which did not have generator expressions. Here is a link to the tutorial that matches the version on your system (note it does not have a section 9.11): http://www.python.org/doc/2.3.4/tut/tut.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1087975group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1088039 ] CGIHTTPServer: directories/scripts with spaces in their name
Bugs item #1088039, was opened at 2004-12-19 11:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1088039group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: LT (sweetleon) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer: directories/scripts with spaces in their name Initial Comment: It looks like we're not properly quoting the path the script, and when the script or its directory has a space in its name - quite common on Windoze - it doesn't work. Here's the output: host - - [19/Dec/2004 11:07:01] command: C:\Python24\python.exe -u c:\Documents a nd Settings\User\My Documents\project\cgi-bin\webpage.py host - - [19/Dec/2004 11:07:01] C:\Python24\python.exe: can't open file 'c:\Docum ents': [Errno 2] No such file or directory ibm - - [19/Dec/2004 11:07:02] CGI script exit status 0x2 ibm - - [19/Dec/2004 11:07:02] code 404, message File not found -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1088039group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-843590 ] 'macintosh' encoding alias for 'mac_roman'
Feature Requests item #843590, was opened at 2003-11-17 10:29
Message generated for change (Comment added) made by yenzenz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=355470aid=843590group_id=5470
Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stuart Bishop (zenzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'macintosh' encoding alias for 'mac_roman'
Initial Comment:
OS X's Mail.app can generate Subject lines like:
Subject: =?MACINTOSH?B?vLu7vMGqo6KwpKalu7w=?=
(Which decodes to
'\xbc\xbb\xbb\xbc\xc1\xaa\xa3\xa2\xb0\xa4\xa6\xa5\xbb\xb
c')
This appears to be what Python calls the mac_roman
encoding. I suggest adding 'macintosh' as an alias to
'mac_roman' to encodings/aliases.py to allow the email
package to decode these headers.
--
Comment By: Jens Klein (yenzenz)
Date: 2004-12-19 21:09
Message:
Logged In: YES
user_id=474612
seems its a bit more difficult:
encoding 'macintosh is registered by iana[1] (nice formatted in [2]) and is
covered by RFC1345[3].
Name: macintosh [RFC1345,KXS2]
MIBenum: 2027
Source: The Unicode Standard ver1.0, ISBN 0-201-56788-1, Oct 1991
Alias: mac
Alias: csMacintosh
[1]http://www.iana.org/assignments/character-sets
[2]http://www.cs.tut.fi/~jkorpela/chars/sorted.html
[3]http://www.faqs.org/rfcs/rfc1345.html
so far the hard facts from specification view. in all these specs are
mac_roman etc. not mentioned. So what?
I found at [4] with the popular program 'recode' a hint of the alias. the
aothor
there uses the iana registered macintosh as an alias for mac_roman:
DEFENCODING(( MacRoman, /* JDK 1.1 */
/* This is the best table for MACINTOSH. The ones */
/* in glibc and FreeBSD-iconv are bad quality. */
MACINTOSH, /* IANA */
MAC,/* IANA */
csMacintosh,/* IANA */
),
mac_roman,
{ mac_roman_mbtowc }, { mac_roman_wctomb, NULL })
[4]http://recode.progiciels-bpi.ca/showfile.html?name=fusion/recode-3.6/
libiconv/encodings.def
Because of that (I trust recode somehow) i would propose to add macintosh
as an alias for mac_roman.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2004-12-19 00:01
Message:
Logged In: YES
user_id=38388
I have no problem adding aliases to the encodings package,
but please provide some reference that this actually is a
valid alias for the mac_roman encoding. There are quite a
few other mac_* encodings to choose from as well, so the
coice is not obvious to me.
--
Comment By: Jens Klein (yenzenz)
Date: 2004-12-18 23:49
Message:
Logged In: YES
user_id=474612
+1 from me
Archetypes (a Zope framework) runs also in a problem because of the
missing alias.
more infos:
https://sourceforge.net/tracker/index.php?
func=detailaid=1068001group_id=75272atid=543430
--
Comment By: Stuart Bishop (zenzen)
Date: 2003-11-17 11:47
Message:
Logged In: YES
user_id=46639
The test was just a sequence of random high-bit characters:
ºªªº¡£¢?§¶ªº
(lets see if the web interface lets that through).
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2003-11-17 11:12
Message:
Logged In: YES
user_id=38388
Are you sure ? The decoded string you give does not look
like anything readable...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=355470aid=843590group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1081824 ] Rewrite of docs for compiler.visitor
Bugs item #1081824, was opened at 2004-12-08 21:06 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1081824group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Jeremy Hylton (jhylton) Summary: Rewrite of docs for compiler.visitor Initial Comment: I was recently prompted to look at the docs for compiler.visitor (Lib Ref 19.4 Using Visitors to Walk ASTs). With all due respect it is not up to the standards of most of the docs. I have attempted a rewrite which is in the attachment. I suggest also that the entry for walk() on the main compiler doc page (19.1) should be updated to refer to 19.4 for details. HTH Kent -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1081824group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1079011 ] Incorrect error message (somewhat)
Bugs item #1079011, was opened at 2004-12-04 14:44 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1079011group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect error message (somewhat) Initial Comment: Comparing complex numbers with cmp yields: cmp(1+3j, 1+3j) 0 cmp(1+3j, 3+4j) Traceback (most recent call last): File stdin, line 1, in ? TypeError: cannot compare complex numbers using , =, , = Well, I didn't use , =, or =. It's not a major bug, but it doesn't look too nice... would it be possible to return NotImplemented? Or would that be semantically incorrect? -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 15:47 Message: Logged In: YES user_id=80475 Rewrote the error message. See Objects/complexobject.c 2.73 and 2.72.2.1 -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-10 12:31 Message: Logged In: YES user_id=80475 That is incorrect be == and != are implemented. The message is slightly weird but still helpful. Any rewording I can think of makes the message more obtuse, so I recommend leaving it alone and closing this bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1079011group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1086642 ] Compile of _socket fails on 2.4
Bugs item #1086642, was opened at 2004-12-16 14:21 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1086642group_id=5470 Category: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 6 Submitted By: A. Stocker (akosprime) Assigned to: Nobody/Anonymous (nobody) Summary: Compile of _socket fails on 2.4 Initial Comment: I'm attempting to install Python 2.4 on an SGI Origin 2400 running Irix 6.5.22. I'm using gcc (3.3) to compile, and I've tried using three different make programs (make, smake, and gmake[3.80]) but get the same error during compilation during the building of _socket. There was not a problem building 2.2.1 on this machine before, we never built 2.3 so I do not know if the same problem existed. Here is the relevant entry from the make: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -shared -fno-strict-aliasing -I. -I/usr/local/src/Python-2.4/./Include -I/us r/local/include -I/usr/local/src/Python-2.4/Include -I/usr/local/src/Python-2.4 -c /usr/local/src/Python-2.4/Modules/socke tmodule.c -o build/temp.irix64-6.5-2.4/socketmodule.o In file included from /usr/local/src/Python-2.4/Modules/socketmodule.c:280: /usr/local/src/Python-2.4/Modules/addrinfo.h:145:1: warning: _SS_ALIGNSIZE redefined In file included from /usr/local/src/Python-2.4/Modules/socketmodule.h:8, from /usr/local/src/Python-2.4/Modules/socketmodule.c:223: /usr/include/sys/socket.h:246:1: warning: this is the location of the previous definition /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `makeipaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:853: warning: implicit declaration of function `getnameinfo' /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: `NI_NUMERICHOST' undeclared (first use in this function) /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: (Each undeclared identifier is reported only once /usr/local/src/Python-2.4/Modules/socketmodule.c:854: error: for each function it appears in.) /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyname_ex': /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: implicit declaration of function `gethostbyname_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2785: warning: assignment makes pointer from integer without a cast /usr/local/src/Python-2.4/Modules/socketmodule.c: In function `socket_gethostbyaddr': /usr/local/src/Python-2.4/Modules/socketmodule.c:2880: warning: implicit declaration of function `gethostbyaddr_r' /usr/local/src/Python-2.4/Modules/socketmodule.c:2881: warning: assignment makes pointer from integer without a cast building '_ssl' extension -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1086642group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1084766 ] sys.stdin segfaults on invalid stdin
Bugs item #1084766, was opened at 2004-12-13 18:41 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1084766group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Mihai Ibanescu (misa) Assigned to: Nobody/Anonymous (nobody) Summary: sys.stdin segfaults on invalid stdin Initial Comment: Bug reported as: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=140715 If stdin is invalid (e.g., redirected from a directory by mistake), python interpreter segfaults on any attempt to access it. In a case where one actually tries to read sys.stdin, I would expect something like Traceback (most recent call last): File string, line 1, in ? IOError: [Errno 21] Is a directory -- Comment By: Jeff Epler (jepler) Date: 2004-12-18 22:25 Message: Logged In: YES user_id=2772 Duplicated here on a stale CVS version of 2.4. Here's some information from gdb: Starting program: /usr/src/cvs/python/dist/src/python -S -c '' / [Thread debugging using libthread_db enabled] [New Thread -151074304 (LWP 6154)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -151074304 (LWP 6154)] 0x08074f90 in PyDict_SetItem (op=0xf6fae79c, key=0xf6fb6f20, value=0x0) at Objects/dictobject.c:549 549 Py_INCREF(value); (gdb) where #0 0x08074f90 in PyDict_SetItem (op=0xf6fae79c, key=0xf6fb6f20, value=0x0) at Objects/dictobject.c:549 #1 0x08075e13 in PyDict_SetItemString (v=0xf6fae79c, key=0x8109d60 stdin, item=0x0) at Objects/dictobject.c:1988 #2 0x080d6988 in _PySys_Init () at Python/sysmodule.c:961 #3 0x080d3e17 in Py_InitializeEx (install_sigs=1) at Python/pythonrun.c:190 #4 0x080d5815 in Py_Initialize () at Python/pythonrun.c:283 #5 0x08055159 in Py_Main (argc=4, argv=0xfefac1b4) at Modules/main.c:418 #6 0x08054e0f in main (argc=4, argv=0xfefac1b4) at Modules/python.c:23 The problem seems to be that PyFile_FromFile() returns NULL without tripping the PyErr_Occurred() test on my line 946 of sysmodule.c, because the call to fill_file_fields() returns NULL too. It looks like fill_file_fields is supposed to return NULL with an error set, but when dircheck() is called that early, PyExc_IOError is NULL, so no error is set. Maybe _PyExc_Init() must be moved earlier in startup. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1084766group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1088077 ] [PATCH] tty needs a way to restore the terminal mode.
Bugs item #1088077, was opened at 2004-12-19 15:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1088077group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] tty needs a way to restore the terminal mode. Initial Comment: tty provides a nice, simple interface for setting the terminal to raw or cbreak modes. However, it doesn't provide a way to put the terminal back in the mode it was in before that change. Every responsible application should leave the terminal in the mode it found it in - unless the application is called sttty, of course. tty needs a setsane function. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1088077group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1088077 ] [PATCH] tty needs a way to restore the terminal mode.
Bugs item #1088077, was opened at 2004-12-19 15:24 Message generated for change (Comment added) made by mwm You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1088077group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mike Meyer (mwm) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] tty needs a way to restore the terminal mode. Initial Comment: tty provides a nice, simple interface for setting the terminal to raw or cbreak modes. However, it doesn't provide a way to put the terminal back in the mode it was in before that change. Every responsible application should leave the terminal in the mode it found it in - unless the application is called sttty, of course. tty needs a setsane function. -- Comment By: Mike Meyer (mwm) Date: 2004-12-19 15:28 Message: Logged In: YES user_id=93910 The patch to add the setsane method is in patch #1088078. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1088077group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1085300 ] Mac Library Modules 1.1.1 Bad Info
Bugs item #1085300, was opened at 2004-12-14 13:43 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1085300group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Walrus (unclewalrus) Assigned to: Brett Cannon (bcannon) Summary: Mac Library Modules 1.1.1 Bad Info Initial Comment: Document states that OS X's TextEdit only saves RTF files. This is incorrect; you can make a plaintext file by choosing 'Make Plain Text' from the Format menu. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 16:35 Message: Logged In: YES user_id=80475 Brett, can you verify this and, if true, add an appropriate note to the docs. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1085300group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1076819 ] test_shelve failures
Bugs item #1076819, was opened at 2004-12-01 10:22 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1076819group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Michal #268;iha#345; (nijel) Assigned to: Nobody/Anonymous (nobody) Summary: test_shelve failures Initial Comment: == FAIL: test_read (__main__.TestAsciiFileShelve) -- Traceback (most recent call last): File /usr/src/packages/BUILD/Python-2.4/Lib/test/mapping_tests.py, line 59, in test_read self.assert_(d.has_key(k)) AssertionError == FAIL: test_read (__main__.TestBinaryFileShelve) -- Traceback (most recent call last): File /usr/src/packages/BUILD/Python-2.4/Lib/test/mapping_tests.py, line 59, in test_read self.assert_(d.has_key(k)) AssertionError == FAIL: test_read (__main__.TestProto2FileShelve) -- Traceback (most recent call last): File /usr/src/packages/BUILD/Python-2.4/Lib/test/mapping_tests.py, line 59, in test_read self.assert_(d.has_key(k)) AssertionError -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 16:38 Message: Logged In: YES user_id=80475 Works for me on WinME and WinXP. -- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2004-12-12 03:53 Message: Logged In: YES user_id=250749 Test works for me on FreeBSD 4.8. Make sure that you can use anydbm - more details on what db module is actually invoked by anydbm might help shed some more light on the matter (use the file utility on a database created with anydbm.open()). -- Comment By: Michal #268;iha#345; (nijel) Date: 2004-12-01 10:26 Message: Logged In: YES user_id=192186 System information: i386 kernel 2.6.8 glibc 2.3.3 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1076819group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1074333 ] input from numeric pad always dropped when numlock off
Bugs item #1074333, was opened at 2004-11-27 16:37 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1074333group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Rick Graves (netvigator) Assigned to: Kurt B. Kaiser (kbk) Summary: input from numeric pad always dropped when numlock off Initial Comment: The behaviour of the direction keys on the numpad is inconsistent when numlock is turned off. Home/End/PgUp/PgDn and the arrow keys work fine in some applications (gedit), but do not work in Python's idle. By not work, I mean: input is silently dropped. How reproducible: Always Steps to Reproduce: 1. Turn off numlock. 3. Open gedit, type in garbage, use direction keys on numpad to move around. 4. Open idle, type in garbage, attempt to use direction keys on numpad to move around. It fails. Actual Results: Intense frustration for people who have been using the numeric keypad as direction keys for decades! Expected Results: When numlock is off, the direction keys on the numpad should function in the same manner as the dedicated direction keys. I am reporting this for Python 2.3, but I had exactly the same problem in Python 2.2. This problem has also been reported to RedHat, see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136600. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 16:44 Message: Logged In: YES user_id=80475 Kurt, as far as I can tell, there is nothing in Tkinter that gives us any control over this. If you concur, please mark this as 3rd party and/or platform specific and close it. -- Comment By: Rick Graves (netvigator) Date: 2004-11-27 16:50 Message: Logged In: YES user_id=1167414 In RedHat bugzilla, this problem was reported for fedora under x86_64. I have been having the problem on i386 using CentOS-3, which is similar to RHEL 3. So the problem seems to apply across Linux architectures, but not across platforms. It may be a RedHat problem across architectures. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1074333group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1072182 ] bad arg type to isspace in struct module
Bugs item #1072182, was opened at 2004-11-23 18:35
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1072182group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg McFarlane (gregm)
Assigned to: Raymond Hettinger (rhettinger)
Summary: bad arg type to isspace in struct module
Initial Comment:
For characters greater than 0x7f, the calls to
isspace() in Modules/structmodule.c can return random
values. For example, on Solaris I got this (incorrect)
output:
import struct
struct.calcsize('10d\xfed')
88
After changing the three occurrences of
isspace((int)c) to isspace((unsigned char)c), this
was the (correct) output:
import struct
struct.calcsize('10d\xfed')
Traceback (most recent call last):
File stdin, line 1, in ?
struct.error: bad char in struct format
Reason: the '\xfe' is taken as a signed char. The code
(int)c converts this to a signed int (-2). The system
isspace macro uses this as an index into the __ctype
array. The array is only defined for the values 0 to
255 and so -2 is out-of-bounds. The value returned by
isspace depends on what happens to be at that location
in memory.
NOTE: There may be other occurrences of this bug in
other parts of the python code. Please check.
--
Comment By: Erik Demaine (edemaine)
Date: 2004-11-23 23:52
Message:
Logged In: YES
user_id=265183
Looking at other instances of isspace and friends, I think
this is the point of calling Py_CHARMASK, which is used to
Convert a possibly signed character to a nonnegative int
(depending on whether 'char' is signed or unsigned).
In other words, I believe the three instances of
isspace((int)c) in Modules/structmodule.c should be changed
to isspace(Py_CHARMASK(c)).
`grep isspace */*.c | grep -v CHARMASK` suggests some other
potential bugs:
- Modules/posixmodule.c:466 (os2_formatmsg): isspace(*lastc)
- Modules/socketmodule.c:504 (set_error): isspace(*lastc)
`egrep
'isalnum|isalpha|isascii|isblank|iscntrl|isdigit|isgraph|islower|isprint|isprint|ispunct|isupper|isxdigit'
*/*.c | grep -v Py_CHARMASK` suggest the following further bugs:
- Modules/_hotshot.c:1431 (get_version_string):
isdigit((int)*rev) [unlikely to cause trouble, but wrong in
the same way...]
- Modules/_tkinter.c:639 (Tkapp_New): isupper((int)argv0[0])
- Modules/pyexpat.c:1800 (get_version_string):
isdigit((int)*rev) [again unlikely a problem]
- Modules/stropmodule.c:760 (strop_atoi): isalnum((int)end[-1])
ye
- Parser/grammar.c:183 (translabel):
isalpha((int)(lb-lb_str[1]))
- Parser/tokenizer.c:232 (get_coding_spec): isalnum((int)t[0])
- Parser/atof.c:16 (atof): (c = *s++) != '\0' isdigit(c)
[same problem appears three times in the same function]
- Python/compile.c:1721,1727 (parsestr): int quote = *s; ...
isalpha(quote)
- Python/dynload_aix.c:147 (aix_loaderror): isdigit(*message[i])
- Python/getargs.c:141 (vgetargs1): int c = *format++ (and
later, isalpha(c))
- Python/getargcs.c:258 (vgetargs1): isalpha((int)(*format))
- Python/getargs.c:336 (converttuple): int c = *format++
(and later, isalpha(c))
- Python/getargs.c:1222 (vgetargskeyword): i = *format++
(and later, isalpha(i))
That's all that I could find.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1072182group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1069409 ] C:\Python24\Lib\compileall.py returns False
Bugs item #1069409, was opened at 2004-11-19 09:01 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1069409group_id=5470 Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: PieterB (pieterb) Assigned to: Kurt B. Kaiser (kbk) Summary: C:\Python24\Lib\compileall.py returns False Initial Comment: I tried running compileall.py from IDLE with Python 2.4c1 (WinXP, SP1). I get the following 'error': Listing C:\WINDOWS\System32\python24.zip ... Can't list C:\WINDOWS\System32\python24.zip Listing C:\Python24 ... Listing C:\Python24\DLLs ... Listing C:\Python24\lib ... Listing C:\Python24\lib\plat-win ... Can't list C:\Python24\lib\plat-win Listing C:\Python24\lib\lib-tk ... Compiling C:\Python24\lib\lib-tk\Canvas.py ... Compiling C:\Python24\lib\lib-tk\Dialog.py ... Compiling C:\Python24\lib\lib-tk\FileDialog.py ... Compiling C:\Python24\lib\lib-tk\ScrolledText.py ... Compiling C:\Python24\lib\lib-tk\Tix.py ... Compiling C:\Python24\lib\lib-tk\Tkdnd.py ... Compiling C:\Python24\lib\lib-tk\turtle.py ... Traceback (most recent call last): File C:\Python24\Lib\compileall.py, line 157, in -toplevel- sys.exit(exit_status) SystemExit: False Shouldn't an integer value (e.g. 0) be returned by sys.exit? It's nice that you can see where the script has ended, but I think it's good to be more elaborate that everything went OK. I think some users might think it's strange to get a Traceback when everything is ok. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 17:27 Message: Logged In: YES user_id=80475 I think this is just a fact of life when using IDLE to run scripts designed for command-line use. The script is question is fine and represents good coding style. The only question is whether IDLE should handle system exits differently. Kurt, please pronounce and close. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1069409group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1072853 ] thisid not intialized in pindent.py script
Bugs item #1072853, was opened at 2004-11-24 18:13 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1072853group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Niraj Bajpai (nbajpai) Assigned to: Nobody/Anonymous (nobody) Summary: thisid not intialized in pindent.py script Initial Comment: Hi there, I am using python version 2.3.4. For some cases when using pindent.py with -c and -e option as follows, the variable thisid does not gets initialized before it hits line #310 ( current, firstkw, lastkw, topid = indent, thiskw, thiskw, thisid), this is traced all the way back to line #268 (for my case it fell in this else clause ... didn't try to look the exact scenario causing this) ... adding thisid = '' help fix the code for my scenario. If this fix is good for all scenario, please roll this over to main line code. Regards, Niraj -- Comment By: Tim Peters (tim_one) Date: 2004-12-19 17:32 Message: Logged In: YES user_id=31435 ann says that because rev 1.10 mechanically converted the whole file from tab indents to 4-space indents. I've never looked at this code, and never even used it. I care about reindent.py, but not pindent.py (it's Guido's baby, BTW). Unassigned myself. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 17:12 Message: Logged In: YES user_id=80475 Tim, cvs ann says this is your code. -- Comment By: Niraj Bajpai (nbajpai) Date: 2004-11-24 21:50 Message: Logged In: YES user_id=1165734 I am running on solaris-8 and command I used is as follows: pindent.py -c -e file_name This is for some special cases (I do not know, haven't digged into) and does not happen for all the mis-formatted files. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1072853group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1074333 ] input from numeric pad always dropped when numlock off
Bugs item #1074333, was opened at 2004-11-27 16:37 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1074333group_id=5470 Category: IDLE Group: Python 2.3 Status: Closed Resolution: Rejected Priority: 3 Submitted By: Rick Graves (netvigator) Assigned to: Kurt B. Kaiser (kbk) Summary: input from numeric pad always dropped when numlock off Initial Comment: The behaviour of the direction keys on the numpad is inconsistent when numlock is turned off. Home/End/PgUp/PgDn and the arrow keys work fine in some applications (gedit), but do not work in Python's idle. By not work, I mean: input is silently dropped. How reproducible: Always Steps to Reproduce: 1. Turn off numlock. 3. Open gedit, type in garbage, use direction keys on numpad to move around. 4. Open idle, type in garbage, attempt to use direction keys on numpad to move around. It fails. Actual Results: Intense frustration for people who have been using the numeric keypad as direction keys for decades! Expected Results: When numlock is off, the direction keys on the numpad should function in the same manner as the dedicated direction keys. I am reporting this for Python 2.3, but I had exactly the same problem in Python 2.2. This problem has also been reported to RedHat, see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136600. -- Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-19 18:13 Message: Logged In: YES user_id=149084 Yes, if OP wants to pursue it, he should take it up with the Tk people: http://tcl.sourceforge.net/ -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 16:44 Message: Logged In: YES user_id=80475 Kurt, as far as I can tell, there is nothing in Tkinter that gives us any control over this. If you concur, please mark this as 3rd party and/or platform specific and close it. -- Comment By: Rick Graves (netvigator) Date: 2004-11-27 16:50 Message: Logged In: YES user_id=1167414 In RedHat bugzilla, this problem was reported for fedora under x86_64. I have been having the problem on i386 using CentOS-3, which is similar to RHEL 3. So the problem seems to apply across Linux architectures, but not across platforms. It may be a RedHat problem across architectures. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1074333group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1074011 ] write failure ignored in Py_Finalize()
Bugs item #1074011, was opened at 2004-11-26 23:02
Message generated for change (Comment added) made by wom-work
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1074011group_id=5470
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: write failure ignored in Py_Finalize()
Initial Comment:
[forwarded from http://bugs.debian.org/283108]
Write errors on stdout may be ignored, and hence may
result in loss of valuable user data.
Here's a quick demo:
$ ./close-bug
foo
$ ./close-bug /dev/full echo unreported write failure
unreported write failure
$ cat close-bug
#!/usr/bin/python
import sys
def main ():
try:
print 'foo'
sys.stdout.close ()
except IOError, e:
sys.stderr.write ('write failed: %s\n' % e)
sys.exit (1)
if __name__ == '__main__':
main ()
This particular failure comes from the following
unchecked fflush
of stdout in pythonrun.c:
static void
call_ll_exitfuncs(void)
{
while (nexitfuncs 0)
(*exitfuncs[--nexitfuncs])();
fflush(stdout);
fflush(stderr);
}
Flushing the stream manually, python does raise an
exception.
Please note that simply adding a test for fflush
failure is
not sufficient. If you change the above to do this:
if (fflush(stdout) != 0)
{
...handle error...
}
It will appear to solve the problem.
But here is a counterexample:
import sys
def main ():
try:
print x * 4095
print
sys.stdout.close ()
except IOError, e:
sys.stderr.write ('write failed: %s\n' % e)
sys.exit (1)
if __name__ == '__main__':
main ()
If you run the above with stdout redirected to /dev/full,
it will silently succeed (exit 0) in spite of a write
failure.
That's what happens on my debian unstable system.
Instead of just checking the fflush return value,
it should also check ferror:
if (fflush(stdout) != 0 || ferror(stdout))
{
...handle error...
}
--
Comment By: Ben Hutchings (wom-work)
Date: 2004-12-19 23:38
Message:
Logged In: YES
user_id=203860
Tim, these bugs are quite difficult to trigger, but they can
hide any kind of file error and lose arbitrarily large
amounts of data.
Here, the following program will run indefinitely:
full = open('/dev/full', 'w')
while 1:
print full, 'x' * 1023
print full
It seems to be essential that both the character that fills
the file buffer (here it is 1024 bytes long) and the next
are generated implicitly by print - otherwise the write
error will be detected.
--
Comment By: Tim Peters (tim_one)
Date: 2004-12-19 22:24
Message:
Logged In: YES
user_id=31435
Sorry, don't care enough to spend time on it (not a bug I've
had, not one I expect to have, don't care if it never
changes). Suggest not using /dev/full as an output device
wink.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-19 21:47
Message:
Logged In: YES
user_id=80475
Tim, what do you think?
--
Comment By: Ben Hutchings (wom-work)
Date: 2004-12-07 00:33
Message:
Logged In: YES
user_id=203860
OK, I can reproduce the remaining problem if I substitute
1023 for 4095. The culprit seems to be the unchecked fputs()
in PyFile_WriteString, which is used for the spaces and
newlines generated by the print statement but not for the
objects. I think that's a separate bug.
--
Comment By: Jim Meyering (meyering)
Date: 2004-12-06 23:27
Message:
Logged In: YES
user_id=41497
Even with python-2.4 (built fresh from CVS this morning),
I can still reproduce the problem on a Linux-2.6.9/ext3 system:
/p/p/python-2.4/bin/python write-4096 /dev/full echo fail
fail
The size that provokes the failure depends on the I/O block size
of your system, so you might need something as big as 131072
on some other type of system.
--
Comment By: Ben Hutchings (wom-work)
Date: 2004-12-06 23:11
Message:
Logged In: YES
user_id=203860
The second sample script works for me (in that it raises the
expected exception) with or without my patch. If the error
status of the file has been set by some other operation
without Python noticing it then surely that's a bug in the
code that calls that other operation.
--
Comment By: Jim Meyering (meyering)
Date: 2004-12-02 09:20
Message:
Logged In: YES
user_id=41497
Hi,
I
[ python-Bugs-1088119 ] Comments regarding 'macintosh' behaviour wrong for MacOS X
Bugs item #1088119, was opened at 2004-12-20 00:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1088119group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: James Matthew Farrow (jmfarrow) Assigned to: Nobody/Anonymous (nobody) Summary: Comments regarding 'macintosh' behaviour wrong for MacOS X Initial Comment: Comments in the documentation regarding the behaviour on the Macintosh appear to be referring to the behaviour under MacOS 9 and the behaviour under MacOS X is different. For example, the documentation (for at least 2.3.4 and 2.4) for os.path.expanduser states On the Macintosh, this always returns path unchanged. Under MacOS X (the example below is for 10.3.7) this is not true: [ezri:~] jmfarrow% uname -a Darwin ezri.internal 7.7.0 Darwin Kernel Version 7.7.0: Sun Nov 7 16:06:51 PST 2004; root:xnu/xnu-517.9.5.obj~1/RELEASE_PPC Power Macintosh powerpc [ezri:~] jmfarrow% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type help, copyright, credits or license for more information. import os os.path.expanduser(~jmfarrow) '/Users/jmfarrow' -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1088119group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1069409 ] C:\Python24\Lib\compileall.py returns False
Bugs item #1069409, was opened at 2004-11-19 09:01 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1069409group_id=5470 Category: IDLE Group: Python 2.4 Status: Closed Resolution: Rejected Priority: 5 Submitted By: PieterB (pieterb) Assigned to: Kurt B. Kaiser (kbk) Summary: C:\Python24\Lib\compileall.py returns False Initial Comment: I tried running compileall.py from IDLE with Python 2.4c1 (WinXP, SP1). I get the following 'error': Listing C:\WINDOWS\System32\python24.zip ... Can't list C:\WINDOWS\System32\python24.zip Listing C:\Python24 ... Listing C:\Python24\DLLs ... Listing C:\Python24\lib ... Listing C:\Python24\lib\plat-win ... Can't list C:\Python24\lib\plat-win Listing C:\Python24\lib\lib-tk ... Compiling C:\Python24\lib\lib-tk\Canvas.py ... Compiling C:\Python24\lib\lib-tk\Dialog.py ... Compiling C:\Python24\lib\lib-tk\FileDialog.py ... Compiling C:\Python24\lib\lib-tk\ScrolledText.py ... Compiling C:\Python24\lib\lib-tk\Tix.py ... Compiling C:\Python24\lib\lib-tk\Tkdnd.py ... Compiling C:\Python24\lib\lib-tk\turtle.py ... Traceback (most recent call last): File C:\Python24\Lib\compileall.py, line 157, in -toplevel- sys.exit(exit_status) SystemExit: False Shouldn't an integer value (e.g. 0) be returned by sys.exit? It's nice that you can see where the script has ended, but I think it's good to be more elaborate that everything went OK. I think some users might think it's strange to get a Traceback when everything is ok. -- Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-19 19:20 Message: Logged In: YES user_id=149084 From compileall.py:155 : if __name__ == '__main__': exit_status = not main() sys.exit(exit_status) IDLE traps the sys.exit() because quitting IDLE is usually not what the user wants to do when it's encountered in the user's program. compileall.py is exiting with a False status, equivalent to the conventional UNIX success return of zero. You could take it up with the compileall.py maintainer, but to me it's no biggie. In any case, IDLE is working as designed. You can actually run this by $ idle -r compileall.py It will end up in the IDLE shell when finished, just close the shell :-) Works on Windows, too, but the pathnames are more complicated because IDLE isn't currently installed correctly. -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 17:27 Message: Logged In: YES user_id=80475 I think this is just a fact of life when using IDLE to run scripts designed for command-line use. The script is question is fine and represents good coding style. The only question is whether IDLE should handle system exits differently. Kurt, please pronounce and close. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1069409group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1080387 ] IDLE Themes and Keys Config not Robust
Bugs item #1080387, was opened at 2004-12-06 21:54 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1080387group_id=5470 Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: projecktzero (projecktzero) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE Themes and Keys Config not Robust Initial Comment: After uninstalling Python 2.3.4 on my Windows 2000 workstation, I installed Python 2.4. Unfortunately, IDLE refused to start up. I would just see some hard drive activity, then nothing. Getting some help from the tutor list(Danny Yoo), I was told to try... import idlelib.PyShell idlelib.PyShell.main() from the Python command prompt. IDLE fired up, but it complained about my color theme(which I had created in Python 2.3.4). Unfortunately, I do not have the errors/warnings. I deleted the color theme from IDLE, and now IDLE fires up without issue. The color theme must have been left over from Python 2.3.4. -- Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-19 20:33 Message: Logged In: YES user_id=149084 This bug was caused by adding the colorization of built-in keywords. The current design of the themes and keybindings in the configuration system saves the entire modified config file instead of just the changes. When IDLE tried to load your config-highlight.cfg it got out of sync and died miserably. An initial fix would be to fix the config system to load the default bindings (as intended) when there was a problem with the user binding. But to fully fix the problem and make the config system robust, it appears to be necessary to redesign it to save only the changes, as it does for config-main.cfg and config-extensions.cfg. That way any new color items would be loaded from the default config-highlight.def. That's a bit of work. Maybe someone will step up. I've attached a patch to config-highlight.def which should take care of the problem. On Windows it's easiest, no doubt, to just type in the four missing lines. Or just delete config-highlights.cfg and recreate it, whichever is less work. -- Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-07 16:44 Message: Logged In: YES user_id=149084 Thanks for the report. I'll try to reproduce the problem myself. What is supposed to happen is if IDLE has a problem retreiving the theme, it's supposed to load the default theme from config-highlight.def and if that fails it's supposed to use a fallback theme written into the code itself. Clearly all this complexity isn't working too well, and the error messages aren't particularly helpful. -- Comment By: projecktzero (projecktzero) Date: 2004-12-07 09:35 Message: Logged In: YES user_id=1173237 I was able to reproduce the problem. I'm attaching the warning messages in a text file. -- Comment By: projecktzero (projecktzero) Date: 2004-12-07 08:08 Message: Logged In: YES user_id=1173237 From IDLE, I removed Deleted the Custom Theme. I will attempt to reproduce the issue and report on what warnings and/or errors appear from the Python command line. I'll uninstall 2.4. Reinstall 2.3.4. Add a theme to IDLE. Uninstall 2.3.4. Install 2.4 and see if I can capture the warnings/errors. -- Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-07 00:13 Message: Logged In: YES user_id=149084 The (un)installer doesn't know about the user's .idlerc file. There should not be any incompatiblility between 2.3.4 and 2.4 regarding the color themes. It's too bad you didn't save the error messages. Could you describe exactly what you mean by I deleted the color theme? . What files or parts of files were removed? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1080387group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1088206 ] zlib decompressobj documentation typo
Bugs item #1088206, was opened at 2004-12-20 04:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1088206group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Scott David Daniels (scott_daniels) Assigned to: Nobody/Anonymous (nobody) Summary: zlib decompressobj documentation typo Initial Comment: In both Python 2.3.4 and 2.4 Python Library Reference 7.15 zlib -- Compression compatible with gzip The documentation that describes zlib.decompressobj, the method description for the decompress message looks like: decompress( string) [max_length] Decompress string, returning a ... when it should be: decompress( string [, max_length]) Decompress string, returning a ... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1088206group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1088119 ] Comments regarding 'macintosh' behaviour wrong for MacOS X
Bugs item #1088119, was opened at 2004-12-19 19:01 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1088119group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: James Matthew Farrow (jmfarrow) Assigned to: Brett Cannon (bcannon) Summary: Comments regarding 'macintosh' behaviour wrong for MacOS X Initial Comment: Comments in the documentation regarding the behaviour on the Macintosh appear to be referring to the behaviour under MacOS 9 and the behaviour under MacOS X is different. For example, the documentation (for at least 2.3.4 and 2.4) for os.path.expanduser states On the Macintosh, this always returns path unchanged. Under MacOS X (the example below is for 10.3.7) this is not true: [ezri:~] jmfarrow% uname -a Darwin ezri.internal 7.7.0 Darwin Kernel Version 7.7.0: Sun Nov 7 16:06:51 PST 2004; root:xnu/xnu-517.9.5.obj~1/RELEASE_PPC Power Macintosh powerpc [ezri:~] jmfarrow% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type help, copyright, credits or license for more information. import os os.path.expanduser(~jmfarrow) '/Users/jmfarrow' -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1088119group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1074333 ] input from numeric pad always dropped when numlock off
Bugs item #1074333, was opened at 2004-11-27 16:37 Message generated for change (Comment added) made by netvigator You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1074333group_id=5470 Category: IDLE Group: Python 2.3 Status: Closed Resolution: Rejected Priority: 3 Submitted By: Rick Graves (netvigator) Assigned to: Kurt B. Kaiser (kbk) Summary: input from numeric pad always dropped when numlock off Initial Comment: The behaviour of the direction keys on the numpad is inconsistent when numlock is turned off. Home/End/PgUp/PgDn and the arrow keys work fine in some applications (gedit), but do not work in Python's idle. By not work, I mean: input is silently dropped. How reproducible: Always Steps to Reproduce: 1. Turn off numlock. 3. Open gedit, type in garbage, use direction keys on numpad to move around. 4. Open idle, type in garbage, attempt to use direction keys on numpad to move around. It fails. Actual Results: Intense frustration for people who have been using the numeric keypad as direction keys for decades! Expected Results: When numlock is off, the direction keys on the numpad should function in the same manner as the dedicated direction keys. I am reporting this for Python 2.3, but I had exactly the same problem in Python 2.2. This problem has also been reported to RedHat, see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136600. -- Comment By: Rick Graves (netvigator) Date: 2004-12-20 01:14 Message: Logged In: YES user_id=1167414 Yes, if OP wants to pursue it, he should take it up with the Tk people: http://tcl.sourceforge.net/ 1) Who is OP? 2) Is this ball in my court or someone else's? Thanks, netvigator aka Rick Graves -- Comment By: Kurt B. Kaiser (kbk) Date: 2004-12-19 18:13 Message: Logged In: YES user_id=149084 Yes, if OP wants to pursue it, he should take it up with the Tk people: http://tcl.sourceforge.net/ -- Comment By: Raymond Hettinger (rhettinger) Date: 2004-12-19 16:44 Message: Logged In: YES user_id=80475 Kurt, as far as I can tell, there is nothing in Tkinter that gives us any control over this. If you concur, please mark this as 3rd party and/or platform specific and close it. -- Comment By: Rick Graves (netvigator) Date: 2004-11-27 16:50 Message: Logged In: YES user_id=1167414 In RedHat bugzilla, this problem was reported for fedora under x86_64. I have been having the problem on i386 using CentOS-3, which is similar to RHEL 3. So the problem seems to apply across Linux architectures, but not across platforms. It may be a RedHat problem across architectures. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1074333group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
