[ python-Bugs-660083 ] GNU readline 4.2 prompt issue
Bugs item #660083, was opened at 2002-12-30 17:47 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660083&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: GNU readline 4.2 prompt issue Initial Comment: When Python is linked with GNU readline 4.2, using raw_input() without a prompt causes the most recent non-empty prompt to be used. GNU readline 4.1 and before don't have this behavior. I don't want it, but I don't know how to disable it (I am passing an empty string for the prompt to readline()). -- >Comment By: Michael Hudson (mwh) Date: 2005-04-07 09:55 Message: Logged In: YES user_id=6656 I can't reproduce this. (looking at old open readline bugs -- me?) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660083&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-971213 ] another threads+readline+signals nasty
Bugs item #971213, was opened at 2004-06-11 16:30 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971213&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: another threads+readline+signals nasty Initial Comment: python -c "import time, readline, thread; thread.start_new_thread(raw_input, ()); time.sleep(2)" Segfaults on ^C Fails on Linux, freebsd. On linux (FC - using kernel 2.6.1, glibc 2.3.3, gcc-3.3.3) (gdb) where #0 0x002627a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x008172b1 in ___newselect_nocancel () from /lib/tls/libc.so.6 #2 0x0011280b in time_sleep (self=0x0, args=0xb7fe17ac) at Modules/timemodule.c:815 on FreeBSD 5.2.1-RC, a different error. Fatal error 'longjmp()ing between thread contexts is undefined by POSIX 1003.1' at line 72 in file /usr/src/lib/libc_r/uthread/uthread_jmp.c (errno = 2) Abort (core dumped) -- >Comment By: Michael Hudson (mwh) Date: 2005-04-07 10:03 Message: Logged In: YES user_id=6656 I think this is fixed now, as in I can't reproduce it with CVS HEAD. Not sure why! I can think of a few fixes that might be responsible. It still messes the terminal up, though. -- Comment By: Michael Hudson (mwh) Date: 2004-08-07 22:41 Message: Logged In: YES user_id=6656 Bah, this still segfaults with CVS head. -- Comment By: Michael Hudson (mwh) Date: 2004-06-21 11:45 Message: Logged In: YES user_id=6656 Can you try the patch that's *now* in 960406? It seems to help for me (but I really would rather not think too hard about this!). -- Comment By: Michal Pasternak (mpasternak) Date: 2004-06-11 16:43 Message: Logged In: YES user_id=799039 readline used on FreeBSD was readline-4.3pl5; everything else: gcc 3.3.3, ncurses, libc were standard from 5.2.1. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 16:39 Message: Logged In: YES user_id=29957 The patch in #960406 doesn't help here. The FC test system also has readline-4.3, if it helps, as does the FreeBSD box. It apparently doesn't crash on OSX. -- Comment By: Michael Hudson (mwh) Date: 2004-06-11 16:38 Message: Logged In: YES user_id=6656 Hmm. Doesn't crash on OS X. Messes the terminal up good and proper, though. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971213&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1009263 ] non-ascii readline input crashes python
Bugs item #1009263, was opened at 2004-08-14 19:19 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1009263&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: non-ascii readline input crashes python Initial Comment: Start Python 2.3.4 on Linux command line: $ python Python 2.3.4 (#1, Jul 24 2004, 19:45:58) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> Enter the string "2×3" (2 times 3, the symbol between 2 and 3 is a multiplication sign, I think Unicode c397 or maybe 97c3 if I have it byte swapped) and hit return. Python reports a syntax error. Hit Ctrl-P to edit the line with readline. Use ctrl-D to delete the first character of the input line, and Python instantly crashes with a seg fault. -- >Comment By: Michael Hudson (mwh) Date: 2005-04-07 10:07 Message: Logged In: YES user_id=6656 Closing for want of response. -- Comment By: Michael Hudson (mwh) Date: 2004-09-07 17:02 Message: Logged In: YES user_id=6656 ping -- Comment By: Michael Hudson (mwh) Date: 2004-08-16 13:29 Message: Logged In: YES user_id=6656 You should check the $LANG or $LC_ALL env vars. Or just run 'locale' in the shell. What version of readline are you using? Both instinct, and looking at the backtrace, suggest a readline bug to me. -- Comment By: paul rubin (phr) Date: 2004-08-15 02:55 Message: Logged In: YES user_id=72053 Backtrace follows. I don't know how to tell my locale. My LOCALE shell variable is not set to anything--is there something else I need to check? Since the "2×3" displays properly in my terminal window, I think I'm likely using UTF-8. (gdb) r Starting program: /usr/local/bin/python [New Thread 1074951328 (LWP 6561)] Python 2.3.4 (#1, Jul 24 2004, 19:45:58) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 2×3 File "", line 1 2×3 ^ SyntaxError: invalid syntax >>> 2×3 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1074951328 (LWP 6561)] 0x401eb687 in _rl_get_char_len () from /usr/lib/libreadline.so.4 (gdb) bt #0 0x401eb687 in _rl_get_char_len () from /usr/lib/libreadline.so.4 #1 0x401eb701 in _rl_compare_chars () from /usr/lib/libreadline.so.4 #2 0x401e0030 in rl_redisplay () from /usr/lib/libreadline.so.4 #3 0x401de816 in rl_redisplay () from /usr/lib/libreadline.so.4 #4 0x401d2588 in readline_internal_char () from /usr/lib/libreadline.so.4 #5 0x401d2695 in readline_internal_char () from /usr/lib/libreadline.so.4 #6 0x401d26ce in readline_internal_char () from /usr/lib/libreadline.so.4 #7 0x401d219f in readline () from /usr/lib/libreadline.so.4 #8 0x40019074 in call_readline (sys_stdin=0x4212fcc0, sys_stdout=0x4212fe20, prompt=0x40177254 ">>> ") at /home/phr/python/Python-2.3.4/Modules/readline.c:679 #9 0x080e6110 in PyOS_Readline (sys_stdin=0x4212fcc0, sys_stdout=0x4212fe20, prompt=0x40177254 ">>> ") at Parser/myreadline.c:183 #10 0x08056c47 in tok_nextc (tok=0x817f428) at Parser/tokenizer.c:683 #11 0x08055d8f in tok_get (tok=0x817f428, p_start=0xbfffecc4, p_end=0xbfffecc8) at Parser/tokenizer.c:1014 #12 0x080559de in PyTokenizer_Get (tok=0x817f428, p_start=0xbfffecc4, p_end=0xbfffecc8) at Parser/tokenizer.c:1414 #13 0x0805543a in parsetok (tok=0x817f428, g=0x8126b88, start=256, err_ret=0xbfffed10, flags=0) at Parser/parsetok.c:125 #14 0x080cb0e2 in PyRun_InteractiveOneFlags (fp=0x4212fcc0, filename=0x80f004a "", flags=0xbfffedf8) at Python/pythonrun.c:738 #15 0x080caf3b in PyRun_InteractiveLoopFlags (fp=0x4212fcc0, filename=0x80f004a "", flags=0xbfffedf8) at Python/pythonrun.c:690 #16 0x080cc2ee in PyRun_AnyFileExFlags (fp=0x4212fcc0, filename=0x80f004a "", closeit=0, flags=0xbfffedf8) at Python/pythonrun.c:653 #17 0x08054d32 in Py_Main (argc=0, argv=0xbfffee74) at Modules/main.c:415 #18 0x080548ab in main (argc=1, argv=0xbfffee74) at Modules/python.c:23 #19 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6 -- Comment By: Hye-Shik Chang (perky) Date: 2004-08-14 22:10 Message: Logged In: YES user_id=55188 What locale do you use? I couldn't reproduce the problem on any of utf-8, iso8859-1, C, euc-kr locale. And, can you please attach a backtrace for the segfault point? -- You can respond by visiting:
[ python-Bugs-1103023 ] raw_input problem with readline and UTF8
Bugs item #1103023, was opened at 2005-01-15 18:10
Message generated for change (Comment added) made by mwh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1103023&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Casey Crabb (airog)
Assigned to: Nobody/Anonymous (nobody)
Summary: raw_input problem with readline and UTF8
Initial Comment:
Backspace doesn't remove all bytes of a multi-byte
UTF-8 character.
To reproduce the problem:
$ export LANG=en_US.UTF-8
$ python
Python 2.3.4 (#1, Jun 11 2004, 16:35:29)
[GCC 3.3.3 20040412 (Gentoo Linux 3.3.3-r3, ssp-3.3-7,
pie-8.5.3)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import readline
>>> raw_input() # ä, return
ä
'\xc3\xa4'
>>> raw_input() # ä, backspace, return
'\xc3'
>>>
A small C program does not have the same problem:
#include
#include
#include
#include
void pprint(const char *s);
int main(void) {
char *line;
for (;;) {
line = readline("> ");
if (!line)
break;
pprint(line);
free(line);
}
return 0;
}
void pprint(const char *s) {
while (*s) {
if (isprint(*s))
putchar(*s);
else
printf("\x%x", *s & 0xff);
s++;
}
putchar('\n');
}
--
>Comment By: Michael Hudson (mwh)
Date: 2005-04-07 10:07
Message:
Logged In: YES
user_id=6656
Is this still relavent?
--
Comment By: Matthew Mueller (donut)
Date: 2005-02-07 07:36
Message:
Logged In: YES
user_id=65253
Hi, it looks like this might be the same problem already
fixed in "[ 914291 ] Fix readline for utf-8 locales", but
your python version is from before the fix went in. Can you
try again with python 2.4, or 2.3.5 (when it is released, or
the release23-maint branch of cvs)?
Also, you could check if python's readline.so is linked to
an older version of libreadline.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1103023&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-811844 ] readline+no threads = core dump
Bugs item #811844, was opened at 2003-09-24 16:46
Message generated for change (Comment added) made by mwh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811844&group_id=5470
Category: Threads
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: TEd Drain (teddrain)
Assigned to: Nobody/Anonymous (nobody)
Summary: readline+no threads = core dump
Initial Comment:
Build 2.3 or 2.3.1 on linux with the following
configure command:
./configure --enable-shared --without-threads
Try running the rlcompleter example. If you hit TAB
with completions enabled, you'll get a core dump after
you hit return on that line. Works fine if I build
with threads enabled.
This is a major problem for me since we have to deliver
our software on machines that do not support pthreads
(hpux 10.2 for example).
~: uname -a
Linux 2.4.9-21 #1 Thu Jan 17 14:16:30 EST 2002
i686 unknown
~/builds-gcc2: python
Python 2.3.1 (#1, Sep 24 2003, 08:13:26)
[GCC 2.95.3 20010315 (release)] on linux2
Type "help", "copyright", "credits" or
"license" for
more information.
>>> import readline, rlcompleter
>>> readline.parse_and_bind("tab: complete")
>>> readline.par se_and_bind()
Fatal Python error: PyThreadState_Get: no current thread
Abort (core dumped)
--
>Comment By: Michael Hudson (mwh)
Date: 2005-04-07 10:12
Message:
Logged In: YES
user_id=6656
This seems to have been fixed, at some indeterminate time in the past.
--
Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-26 18:30
Message:
Logged In: YES
user_id=29957
Assuming the problem is just a shallow one, would the
following patch "fix" the problem?
It makes the crashes go away for me.
--
Comment By: Michael Hudson (mwh)
Date: 2003-09-24 17:17
Message:
Logged In: YES
user_id=6656
i see this too.
oops. hopefully easy to fix...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811844&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-846817 ] control-c is being sent to child thread rather than main
Bugs item #846817, was opened at 2003-11-21 19:46
Message generated for change (Comment added) made by mwh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846817&group_id=5470
Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: sheshi sankineni (sheshi)
Assigned to: Nobody/Anonymous (nobody)
Summary: control-c is being sent to child thread rather than main
Initial Comment:
Hi All,
We just migrated from Python-2.2.1 to Python-2.3.1 and
noticed a behavior change with respect to control-c +
threads and importing readline module. We have
developed a CLI (command line interface) to our
hardware using Python (communicating with CORBA).
I am providing you with the code (below) which
demonstrates the changed behavior in Python-2.3.1
with "import readline" & without "import readline" on
Linux
Redhat 7.2. The same program works fine on Python-
2.2.1 with or without importing readline and doing
control-c ALWAYS trapped by the main program.
Any help on this issue will be appreciated
thanks
-sheshi
cli.py
---
import os
import signal
import sys
import cliEngine
def handleKeyboardInterrupt(signalNumber, frame) :
print 'MAIN THREAD Control-C'
def handleSigUsr1(signalNumber, frame) :
pass
# The main function
if __name__ == '__main__':
try :
# Register a signal handler for ctrl-C, control-z
signal.signal(signal.SIGINT,
handleKeyboardInterrupt)
signal.signal(signal.SIGUSR1, handleSigUsr1)
signal.signal(signal.SIGTSTP, signal.SIG_IGN)
cliEngine.engine = cliEngine.CliEngine()
cliEngine.engine.setPid(os.getpid())
cliEngine.engine.start()
while cliEngine.engine.cliEngineRunning :
signal.pause()
print 'Exiting the main thread'
finally :
pass
cliEngine.py
-
import os
import signal
import sys
import threading
import readline
engine = None
class CliEngine(threading.Thread) :
# Static members of the class
cliEngineRunning = 0
mainThreadPid = 0
def __init__(self) :
threading.Thread.__init__(self)
self.cliEngineRunning = 1
engine = self
def setPid(self, mainPid) :
self.mainThreadPid = mainPid
def run(self) :
print 'calling CliEngine run'
self.cliEngineRunning = 1
self.runEngine()
def runEngine(self) :
while self.cliEngineRunning :
try :
line = raw_input('# ')
if line == "logout" :
self.cliEngineRunning = 0
except KeyboardInterrupt :
print 'CHILD THREAD Control-C
(KeyboardInterrupt)'
except EOFError :
# ctrl-d to logout from CLI
self.cliEngineRunning = 0
except :
print 'Unknown Exception'
self.cliEngineRunning = 0
print 'Returning from cliEngine.runEngine()'
If I remove "import readline" in the above file, control-c
is always trapped by the main thread (cli.py) as shown
by the output below
>>python cli.py
calling CliEngine run
# MAIN THREAD Control-C
# MAIN THREAD Control-C
# logout
Returning from cliEngine.runEngine()
Exiting the main thread
If in the above Python file (cliEngine.py), If I
include "import readline", control-c will be trapped by
the child thread (CliEngine) instead of the main thread,
as shown by the output below and the program
terminates with segmentation fault
>>python cli.py
calling CliEngine run
# CHILD THREAD Control-C (KeyboardInterrupt)
# CHILD THREAD Control-C (KeyboardInterrupt)
#
# logout
Returning from cliEngine.runEngine()
Segmentation fault
--
>Comment By: Michael Hudson (mwh)
Date: 2005-04-07 10:14
Message:
Logged In: YES
user_id=6656
Is this still an issue with Python 2.4?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=846817&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1054041 ] Python doesn't exit with proper resultcode on SIGINT
Bugs item #1054041, was opened at 2004-10-25 21:27 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1054041&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: James Y Knight (foom) Assigned to: Nobody/Anonymous (nobody) Summary: Python doesn't exit with proper resultcode on SIGINT Initial Comment: If you kill a python process with SIGINT (e.g. control-c), it catches the signal, and raises a KeyboardInterrupt. If the KeyboardInterrupt propagates to the top level, python exits. However, it exits with a result of 1, not a result of SIGINT. This means that if you run python in a shell script, the script will not properly exit on C-c. When exiting because of a KeyboardInterrupt, python ought to reraise the SIGINT, as follows, so that the exit code is correct for the caller: signal(SIGINT, SIG_DFL); kill(getpid(), SIGINT); See also http://www.cons.org/cracauer/sigint.html for a more detailed discussion on the topic. -- >Comment By: Michael Hudson (mwh) Date: 2005-04-07 10:26 Message: Logged In: YES user_id=6656 Feel like writing a patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1054041&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1168983 ] ftplib.py string index out of range
Bugs item #1168983, was opened at 2005-03-23 10:05
Message generated for change (Comment added) made by vmlinuxz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168983&group_id=5470
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: David Carroll (vmlinuxz)
Assigned to: Nobody/Anonymous (nobody)
Summary: ftplib.py string index out of range
Initial Comment:
The following code works great on all of the 2.3.x
releases I have used.
def
ftpFetch(localPath,remoteFileDate,ftpSite,ftpPass,ftpDir,ftpUser):
print "Fetching split_mgr report"
fileList=[]
processList=[]
ftp = FTP(ftpSite)
ftp.login(ftpUser,ftpPass)
ftp.dir('LIST '+ftpDir,fileList.append)
for x in range(len(fileList)):
if (string.find(fileList[x],remoteFileDate) != -1):
print fileList[x]
TMP=fileList[x]
output=localPath+str(TMP[45:])
print output
processList.append(output)
print processList
outfile = open(output,'w')
ftp.retrbinary('RETR '+ftpDir+TMP[45:],
open(output, 'wb').write)
ftp.quit()
print processList
return processList
However I get the following error under 2.4
Traceback (most recent call last):
File
"C:\Python24\lib\site-packages\PythonCard\widget.py",
line 417, in _dispatch
handler(background, aWxEvent)
File "C:\Documents and
Settings\PROTECTED\Desktop\ReadWaitReport\ReadWaitReport\readwaitreport.py",
line 61, in on_btnRun_command
mainRwclassLoop(self, mm+dd+yy, yesterday)
File "C:\Documents and
Settings\PROTECTED\Desktop\ReadWaitReport\ReadWaitReport\rwclass.py",
line 39, in mainRwclassLoop
processList =
ftpFetch(localPath,"split_mgr."+date[0:4],ftpSite,ftpPass,ftpDir,ftpUser)
File "C:\Documents and
Settings\PROTECTED\Desktop\ReadWaitReport\ReadWaitReport\rwclass.py",
line 173, in ftpFetch
ftp.dir('LIST '+ftpDir,fileList.append)
File "C:\Python24\lib\ftplib.py", line 464, in dir
self.retrlines(cmd, func)
File "C:\Python24\lib\ftplib.py", line 396, in retrlines
conn = self.transfercmd(cmd)
File "C:\Python24\lib\ftplib.py", line 345, in
transfercmd
return self.ntransfercmd(cmd, rest)[0]
File "C:\Python24\lib\ftplib.py", line 328, in
ntransfercmd
if resp[0] != '1':
IndexError: string index out of range
https://lists.dulug.duke.edu/pipermail/yum/2004-August/005067.html
discusses a similar problem under Linux in the YUM
script, I have reproduced this error under 2000, and XP.
I'm a fairly new programmer, and thus very new to
python so I hope this is enough information. I will
try and keep track of this and help out with more
information in any capacity I can.
Thank you for all your hard work and dedication.
David Carroll
--
>Comment By: David Carroll (vmlinuxz)
Date: 2005-04-07 09:51
Message:
Logged In: YES
user_id=684143
Thank you for leaving this open. I will try and get your
example today. I'm too uneducated to realize what I'm doing
wrong, so maybe you can use my ignorance for the common good
=).
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-04-05 04:31
Message:
Logged In: YES
user_id=80475
I fixed the IndexError. It should have been a protocol
error. See Lib/ftplib.py 1.74.
Leaving the bug open so the OP can make a more detailed post
so we can see what the root issue is about.
--
Comment By: Ilya Sandler (isandler)
Date: 2005-04-05 03:37
Message:
Logged In: YES
user_id=971153
It turns out that the code in plain text bug report is more
or less readable, so I can see what you were trying to do...
Seems like you are doing
ftp.dir("LIST "+ftpDir)
But ftplib docs:
http://www.python.org/doc/current/lib/ftp-objects.html
say that you need to specify the directory
ftp.dir(ftpDir)
so it seems that you are using ftp.dir() incorrectly
But, even then IndexError seems like a wrong kind of
exception for this kind of error...
So, I guess, my original request for a working code snippet
which would allow to reproduce the bug still stands..
--
Comment By: Ilya Sandler (isandler)
Date: 2005-04-05 02:12
Message:
Logged In: YES
user_id=971153
Could you submit a minimalistic piece of code which
illustrates the problem?
As well as any input data which are required to reproduce it?
(SourceForge garbled your original example)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168983&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/
[ python-Bugs-1175967 ] StringIO and cStringIO don't provide 'name' attribute
Bugs item #1175967, was opened at 2005-04-03 22:20 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175967&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Nobody/Anonymous (nobody) Summary: StringIO and cStringIO don't provide 'name' attribute Initial Comment: Documentation explicitly states that file-like objects should return a repr-style psuedoname. Patch is attached. -- >Comment By: Just van Rossum (jvr) Date: 2005-04-07 10:54 Message: Logged In: YES user_id=92689 The documentation also says "This is a read-only attribute and may not be present on all file-like objects.", so I'm inclined to close as "won't fix". I'm sure many in-the-wild file-like objects don't support it, either, so depending on its existence is bad style at best. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175967&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1178484 ] Erroneous line number error in Py2.4.1
Bugs item #1178484, was opened at 2005-04-07 15:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Timo Linna (tilinna) Assigned to: Nobody/Anonymous (nobody) Summary: Erroneous line number error in Py2.4.1 Initial Comment: For some reason Python 2.3.5 reports the error in the following program correctly: File "C:\Temp\problem.py", line 7 SyntaxError: unknown decode error ..whereas Python 2.4.1 reports an invalid line number: File "C:\Temp\problem.py", line 2 SyntaxError: unknown decode error - problem.py starts - # -*- coding: ascii -*- """ Foo bar """ # Ä is not allowed in ascii coding - problem.py ends - Without the encoding declaration both Python versions report the usual deprecation warning (just like they should be doing). My environment: Windows 2000 + SP3. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1178510 ] configure: refuses setgroups
Bugs item #1178510, was opened at 2005-04-07 14:53
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178510&group_id=5470
Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: zosh (zosh)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure: refuses setgroups
Initial Comment:
On Irix 6.5 with MIPS cc 7.30 configure refuses to recognize
the existence of "setgroups".
configure:14453: checking for setgroups
configure:14477: cc -c -g conftest.c >&5
cc-1020 cc: ERROR File = conftest.c, Line = 159
The identifier "setgroups" is undefined.
void* p = setgroups
...
1 error detected in the compilation of "conftest.c".
configure:14483: $? = 2
configure: failed program was:
| /* confdefs.h. */
...
| #include
| #ifdef HAVE_GRP_H
| #include
| #endif
|
| int
| main ()
| {
| void* p = setgroups
| ;
| return 0;
| }
When I compile a short test program that includes only unistd.h
with cc, it reports no errors.
So I had to manipulate pyconfig.h by hand to force the desired
behaviour. Is this a known issue? Please tell me if I have to
perform other test on my box to solve the issue.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178510&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1178484 ] Erroneous line number error in Py2.4.1
Bugs item #1178484, was opened at 2005-04-07 14:33 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&group_id=5470 Category: Parser/Compiler Group: Python 2.4 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Timo Linna (tilinna) Assigned to: Nobody/Anonymous (nobody) Summary: Erroneous line number error in Py2.4.1 Initial Comment: For some reason Python 2.3.5 reports the error in the following program correctly: File "C:\Temp\problem.py", line 7 SyntaxError: unknown decode error ..whereas Python 2.4.1 reports an invalid line number: File "C:\Temp\problem.py", line 2 SyntaxError: unknown decode error - problem.py starts - # -*- coding: ascii -*- """ Foo bar """ # Ä is not allowed in ascii coding - problem.py ends - Without the encoding declaration both Python versions report the usual deprecation warning (just like they should be doing). My environment: Windows 2000 + SP3. -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-04-07 16:28 Message: Logged In: YES user_id=89016 The reason for this is the new codec buffering code in 2.4: The codec might read and decode more data from the byte stream than is neccessary for decoding one line. I.e. when reading line n, the codec might decode bytes that belong to line n+1, n+2 etc. too. If there's a decoding error in this data, line n gets reported. I don't think there's a simple fix for this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178484&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1176893 ] Readline segfault
Bugs item #1176893, was opened at 2005-04-05 04:50
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1176893&group_id=5470
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
>Assigned to: Mark Hammond (mhammond)
Summary: Readline segfault
Initial Comment:
The latest change to the readline module has broken tab
completion:
./python
Python 2.5a0 (#1, Apr 5 2005, 01:14:33)
[GCC 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3,
pie-8.7.7.1)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import readline, rlcompleter
[25913 refs]
>>> readline.parse_and_bind("tab: complete")
[25913 refs]
>>> Segmentation fault
[Press tab after the parse_and_bind() call]
--
>Comment By: Tim Peters (tim_one)
Date: 2005-04-07 11:15
Message:
Logged In: YES
user_id=31435
Sorry, can't make time for this. Reassigned to Mark in case
he can.
--
Comment By: Michael Hudson (mwh)
Date: 2005-04-05 06:27
Message:
Logged In: YES
user_id=6656
Or maybe this one line patch is the answer (it certainly
fixes this case).
Tim, can you spare a minute to think about this? The patch
simply adds a check to PyEval_ReleaseThread that doesn't
call PyThread_release_lock if the GIL hasn't been allocated.
--
Comment By: Michael Hudson (mwh)
Date: 2005-04-05 06:18
Message:
Logged In: YES
user_id=6656
I'm going to go out on a limb and suggest this is a bug in
the PyGilState_ functions.
The problem burrows down to calling
PyThread_release_lock(interpreter_lock) when
interpreter_lock is NULL, i.e. PyEval_InitThreads hasn't
been called. (if you start a thread before running the
crashing code, it doesn't crash, because the GIL has been
allocated).
Not sure what the solution is, or who to bug (time to read
cvs log, I guess).
A silly workaround is to put PyEval_InitThreads in initreadline.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1176893&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1174606 ] Reading /dev/zero causes SystemError
Bugs item #1174606, was opened at 2005-03-31 22:48
Message generated for change (Comment added) made by jepler
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1174606&group_id=5470
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Adam Olsen (rhamphoryncus)
Assigned to: Nobody/Anonymous (nobody)
Summary: Reading /dev/zero causes SystemError
Initial Comment:
$ python -c 'open("/dev/zero").read()'
Traceback (most recent call last):
File "", line 1, in ?
SystemError: ../Objects/stringobject.c:3316: bad
argument to internal function
Compare with this two variants:
$ python -c 'open("/dev/zero").read(2**31-1)'
Traceback (most recent call last):
File "", line 1, in ?
MemoryError
$ python -c 'open("/dev/zero").read(2**31)'
Traceback (most recent call last):
File "", line 1, in ?
OverflowError: long int too large to convert to int
The unsized read should produce either MemoryError or
OverflowError instead of SystemError.
Tested with Python 2.2, 2.3, and 2.4.
--
Comment By: Jeff Epler (jepler)
Date: 2005-04-07 09:33
Message:
Logged In: YES
user_id=2772
To my surprise, the st_size field *is* undefined for
devices, according to
http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html
My Linux consistently gives 0 for device nodes, but I guess
Unix might not.
jafo, loweis: read() from /dev/zero is special cased in
linux. In 2.4.20-8, function read_zero_pagealined, a
comment says "for private mappings, just map in zero pages",
which will be very fast and not actually write any memory or
blocks of swap.
--
Comment By: Sean Reifschneider (jafo)
Date: 2005-04-06 02:17
Message:
Logged In: YES
user_id=81797
I'm quite sure that the 2GB is not getting filled when doing
this. After running the first command, and checking
/proc/meminfo, I see that only 46MB is shown as free, which
means that there was no more than this amount of RAM consumed.
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-04-06 02:06
Message:
Logged In: YES
user_id=21627
The surprising aspect is that the memory *is* being used.
Python allocates 2GB of memory, and then passes this to
read(2) (through stdio) to fill it with the contents of
/dev/zero. This should cause a write operation to the memory
pages, which in turn should cause them to consume actual
memory. For some reason, this doesn't happen.
--
Comment By: Sean Reifschneider (jafo)
Date: 2005-04-06 01:52
Message:
Logged In: YES
user_id=81797
Linux can do a very fast allocation if it has swap
available. It reserves space, but does not actually assign
the memory until you try to use it. In my case, I have 1GB
of RAM, around 700MB free, and another 2GB in swap. So, I
have plenty unless I use it. In C I can malloc 1GB and
unless I write every page in that block the system doesn't
really give the pages to the process.
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-04-06 01:40
Message:
Logged In: YES
user_id=21627
The problem is different. Instead, _PyString_Resize
complains that the new buffersize of the string is negative.
This in turn happens because the string manages to get
larger >2GB, which in turn happens because buffersize is
size_t, yet _PyString_Resize expects int.
I don't know how Linux manages to allocate such a large
string without thrashing.
There is a minor confusion with stat() as well:
new_buffersize tries to find out how much bytes are left to
the end of the file. In the case of /dev/zero, both fstat
and lseek are "lying" by returning 0. As lseek returns 0,
ftell is invoked and returns non-zero. Then, newbuffer does
not trust the values, and just adds BIGCHUNK.
--
Comment By: Sean Reifschneider (jafo)
Date: 2005-04-05 22:39
Message:
Logged In: YES
user_id=81797
I am able to reproduce this on a Fedora Core 3 Linux system:
>>> fp = open('/dev/zero', 'rb')
>>> d = fp.read()
Traceback (most recent call last):
File "", line 1, in ?
MemoryError
>>> print os.stat('/dev/zero').st_size
0
What about only trusting st_size if the file is a regular
file, not a directory or other type of special file?
Sean
--
Comment By: Armin Rigo (arigo)
Date: 2005-04-02 06:31
Message:
Logged In: YES
user_id=4771
os.stat() doesn't always give consistent results on dev files. On my machine
for some reason os.stat('/dev/null') appears to be random (and extremely
large). I suspect that on the OP's machine os.stat('/dev/zero') is not 0
either, but a random number that turns ou
[ python-Bugs-1178624 ] 2.4.1 breaks pyTTS
Bugs item #1178624, was opened at 2005-04-07 09:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178624&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dieter Deyke (deyke) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 breaks pyTTS Initial Comment: On my Windows XP PRO SP2 system, the combination of Python 2.4, pywin32-203.win32-py2.4, and pyTTS-3.0.win32-py2.4 did work. Updating to 2.4.1 broke pyTTS. Removing everythin, then installing 2.4.1, win32, and pyTTS resulted in the same failure. Removing everything again, and installing 2.4, win32, and pyTTS fixed it again. The problem is that with 2.4.1 pyTTS reported that "SAPI" was not supported. Looking deeper I saw that it got a syntax error reading a generated com interface file. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178624&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1178624 ] 2.4.1 breaks pyTTS
Bugs item #1178624, was opened at 2005-04-07 17:25 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178624&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dieter Deyke (deyke) Assigned to: Nobody/Anonymous (nobody) Summary: 2.4.1 breaks pyTTS Initial Comment: On my Windows XP PRO SP2 system, the combination of Python 2.4, pywin32-203.win32-py2.4, and pyTTS-3.0.win32-py2.4 did work. Updating to 2.4.1 broke pyTTS. Removing everythin, then installing 2.4.1, win32, and pyTTS resulted in the same failure. Removing everything again, and installing 2.4, win32, and pyTTS fixed it again. The problem is that with 2.4.1 pyTTS reported that "SAPI" was not supported. Looking deeper I saw that it got a syntax error reading a generated com interface file. -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-04-07 17:56 Message: Logged In: YES user_id=89016 Can you post the generated inferface file? Does this file contain long lines? Does it use a PEP 263 encoding directive? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178624&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-660083 ] GNU readline 4.2 prompt issue
Bugs item #660083, was opened at 2002-12-30 12:47 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660083&group_id=5470 Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: GNU readline 4.2 prompt issue Initial Comment: When Python is linked with GNU readline 4.2, using raw_input() without a prompt causes the most recent non-empty prompt to be used. GNU readline 4.1 and before don't have this behavior. I don't want it, but I don't know how to disable it (I am passing an empty string for the prompt to readline()). -- >Comment By: Guido van Rossum (gvanrossum) Date: 2005-04-07 12:46 Message: Logged In: YES user_id=6380 Me neither, but then I've got GNU readline 4.3 here, not 4.2, and I'm to lazy to try to reproduce it. Assuming that you actually tested with 4.2, just close it. -- Comment By: Michael Hudson (mwh) Date: 2005-04-07 04:55 Message: Logged In: YES user_id=6656 I can't reproduce this. (looking at old open readline bugs -- me?) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=660083&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1178624 ] 2.4.1 breaks pyTTS
Bugs item #1178624, was opened at 2005-04-07 09:25
Message generated for change (Comment added) made by deyke
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178624&group_id=5470
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dieter Deyke (deyke)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4.1 breaks pyTTS
Initial Comment:
On my Windows XP PRO SP2 system, the combination of
Python 2.4, pywin32-203.win32-py2.4, and
pyTTS-3.0.win32-py2.4 did work. Updating to 2.4.1 broke
pyTTS. Removing everythin, then installing 2.4.1,
win32, and pyTTS resulted in the same failure. Removing
everything again, and installing 2.4, win32, and pyTTS
fixed it again.
The problem is that with 2.4.1 pyTTS reported that
"SAPI" was not supported. Looking deeper I saw that it
got a syntax error reading a generated com interface file.
--
>Comment By: Dieter Deyke (deyke)
Date: 2005-04-07 10:49
Message:
Logged In: YES
user_id=132928
I attached the generated interface file. Loading this file
into python by itself does NOT generate an error, but going
into the pyTTS dir, starting python, and typing "import
sapi" shows:
C:\Python24\Lib\site-packages\pyTTS>python
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import sapi
Traceback (most recent call last):
File "", line 1, in ?
File "C:\Python24\lib\site-packages\pyTTS\sapi.py", line
10, in ?
sapi_mod =
gencache.EnsureModule('{C866CA3A-32F7-11D2-9602-00C04F8EE628}',
0
, 5, 0)
File
"C:\Python24\lib\site-packages\win32com\client\gencache.py",
line 393, in
EnsureModule
module = GetModuleForTypelib(typelibCLSID, lcid, major,
minor)
File
"C:\Python24\lib\site-packages\win32com\client\gencache.py",
line 258, in
GetModuleForTypelib
mod = _GetModule(modName)
File
"C:\Python24\lib\site-packages\win32com\client\gencache.py",
line 629, in
_GetModule
mod = __import__(mod_name)
File
"C:\Python24\lib\site-packages\win32com\gen_py\C866CA3A-32F7-11D2-9602-00
C04F8EE628x0x5x0.py", line 1192
"""Add"""
^
SyntaxError: invalid syntax
>>>
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-04-07 09:56
Message:
Logged In: YES
user_id=89016
Can you post the generated inferface file? Does this file
contain long lines? Does it use a PEP 263 encoding directive?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178624&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1178624 ] 2.4.1 breaks pyTTS
Bugs item #1178624, was opened at 2005-04-07 17:25
Message generated for change (Comment added) made by doerwalter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178624&group_id=5470
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dieter Deyke (deyke)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4.1 breaks pyTTS
Initial Comment:
On my Windows XP PRO SP2 system, the combination of
Python 2.4, pywin32-203.win32-py2.4, and
pyTTS-3.0.win32-py2.4 did work. Updating to 2.4.1 broke
pyTTS. Removing everythin, then installing 2.4.1,
win32, and pyTTS resulted in the same failure. Removing
everything again, and installing 2.4, win32, and pyTTS
fixed it again.
The problem is that with 2.4.1 pyTTS reported that
"SAPI" was not supported. Looking deeper I saw that it
got a syntax error reading a generated com interface file.
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-04-07 22:33
Message:
Logged In: YES
user_id=89016
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. :-( )
--
Comment By: Dieter Deyke (deyke)
Date: 2005-04-07 18:49
Message:
Logged In: YES
user_id=132928
I attached the generated interface file. Loading this file
into python by itself does NOT generate an error, but going
into the pyTTS dir, starting python, and typing "import
sapi" shows:
C:\Python24\Lib\site-packages\pyTTS>python
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import sapi
Traceback (most recent call last):
File "", line 1, in ?
File "C:\Python24\lib\site-packages\pyTTS\sapi.py", line
10, in ?
sapi_mod =
gencache.EnsureModule('{C866CA3A-32F7-11D2-9602-00C04F8EE628}',
0
, 5, 0)
File
"C:\Python24\lib\site-packages\win32com\client\gencache.py",
line 393, in
EnsureModule
module = GetModuleForTypelib(typelibCLSID, lcid, major,
minor)
File
"C:\Python24\lib\site-packages\win32com\client\gencache.py",
line 258, in
GetModuleForTypelib
mod = _GetModule(modName)
File
"C:\Python24\lib\site-packages\win32com\client\gencache.py",
line 629, in
_GetModule
mod = __import__(mod_name)
File
"C:\Python24\lib\site-packages\win32com\gen_py\C866CA3A-32F7-11D2-9602-00
C04F8EE628x0x5x0.py", line 1192
"""Add"""
^
SyntaxError: invalid syntax
>>>
--
Comment By: Walter Dörwald (doerwalter)
Date: 2005-04-07 17:56
Message:
Logged In: YES
user_id=89016
Can you post the generated inferface file? Does this file
contain long lines? Does it use a PEP 263 encoding directive?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178624&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1178863 ] Variable.__init__ uses self.set(), blocking specialization
Bugs item #1178863, was opened at 2005-04-07 23:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178863&group_id=5470 Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Emil (droun) Assigned to: Martin v. Löwis (loewis) Summary: Variable.__init__ uses self.set(), blocking specialization Initial Comment: in class Variable the constructor uses self.set() to set the value of the variable. This makes it hard and in some cases impossible to make a speciallization of Variable that performs some operation after changing the value. It would be preferable to use Tkinter.Variable.set(self, self._default) example: class ViewChanger(Tkinter.StringVar) : def __init__(self, views) : self.views = views Tkinter.StringVar.__init__(self) def set(self, newview) : self.views.activate(newview) Tkinter.StringVar.set(newview) get() and everything else will use the normal StringVar ipementation, but when the value is changed, a new view is activated. At creation here the self.views varaible will be accessed, method activate() will be called, and it might not even be fully initiallized yet. This is the normal case if you want to supply a variable to a widget, where a variable change may update the widget. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178863&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1178872 ] Variable.__init__ uses self.set(), blocking specialization
Bugs item #1178872, was opened at 2005-04-07 23:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178872&group_id=5470 Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Emil (droun) Assigned to: Martin v. Löwis (loewis) Summary: Variable.__init__ uses self.set(), blocking specialization Initial Comment: in class Variable the constructor uses self.set() to set the value of the variable. This makes it hard and in some cases impossible to make a speciallization of Variable that performs some operation after changing the value. It would be preferable to use Tkinter.Variable.set(self, self._default) example: class ViewChanger(Tkinter.StringVar) : def __init__(self, views) : self.views = views Tkinter.StringVar.__init__(self) def set(self, newview) : self.views.activate(newview) Tkinter.StringVar.set(newview) get() and everything else will use the normal StringVar ipementation, but when the value is changed, a new view is activated. At creation here the self.views varaible will be accessed, method activate() will be called, and it might not even be fully initiallized yet. This is the normal case if you want to supply a variable to a widget, where a variable change may update the widget. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178872&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1178510 ] configure: refuses setgroups
Bugs item #1178510, was opened at 2005-04-07 14:53
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178510&group_id=5470
Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: zosh (zosh)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure: refuses setgroups
Initial Comment:
On Irix 6.5 with MIPS cc 7.30 configure refuses to recognize
the existence of "setgroups".
configure:14453: checking for setgroups
configure:14477: cc -c -g conftest.c >&5
cc-1020 cc: ERROR File = conftest.c, Line = 159
The identifier "setgroups" is undefined.
void* p = setgroups
...
1 error detected in the compilation of "conftest.c".
configure:14483: $? = 2
configure: failed program was:
| /* confdefs.h. */
...
| #include
| #ifdef HAVE_GRP_H
| #include
| #endif
|
| int
| main ()
| {
| void* p = setgroups
| ;
| return 0;
| }
When I compile a short test program that includes only unistd.h
with cc, it reports no errors.
So I had to manipulate pyconfig.h by hand to force the desired
behaviour. Is this a known issue? Please tell me if I have to
perform other test on my box to solve the issue.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-04-08 00:50
Message:
Logged In: YES
user_id=21627
When you say "I compile a short test program that includes
only unistd.h" did you literally mean a program that only
includes unistd.h (i.e. has no main function)? If not, what
is the short program? In particular, make sure it includes
the line
void *p = setgroups;
Please locate the declaration of setgroups in unistd.h (or
whereever it is declared), and report whether this is in a
conditional compilation section, and if so, what precisely
the condition is.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1178510&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1176012 ] compiler module didn't get updated for "class foo():pass"
Bugs item #1176012, was opened at 2005-04-03 16:21 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1176012&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) >Assigned to: Brett Cannon (bcannon) Summary: compiler module didn't get updated for "class foo():pass" Initial Comment: Patch with fix and testcase is attached. -- Comment By: logistix (logistix) Date: 2005-04-03 17:01 Message: Logged In: YES user_id=699438 The parser module didn't get corrected either. Here is another patch with test case for that. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1176012&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1176012 ] compiler module didn't get updated for "class foo():pass"
Bugs item #1176012, was opened at 2005-04-03 16:21 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1176012&group_id=5470 Category: Python Library >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: logistix (logistix) Assigned to: Brett Cannon (bcannon) Summary: compiler module didn't get updated for "class foo():pass" Initial Comment: Patch with fix and testcase is attached. -- Comment By: logistix (logistix) Date: 2005-04-03 17:01 Message: Logged In: YES user_id=699438 The parser module didn't get corrected either. Here is another patch with test case for that. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1176012&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
