From noreply at sourceforge.net Sat Oct 1 04:57:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 30 Sep 2005 19:57:11 -0700 Subject: [ python-Bugs-1309724 ] __getnewargs__ is in pickle docs but not in code Message-ID: Bugs item #1309724, was opened at 2005-09-30 12:37 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1309724&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Myers Carpenter (myers_carpenter) >Assigned to: Neal Norwitz (nnorwitz) Summary: __getnewargs__ is in pickle docs but not in code Initial Comment: The pickle docs talk about __getnewargs__ for new style classes http://www.python.org/doc/2.3.5/lib/pickle-inst.html But after examing pickle.py I see no ref to __getnewargs__ in the code, nor could I get my example code to work. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-30 19:57 Message: Logged In: YES user_id=33168 The code is buried in the C implementation of Objects. In the doc you reference, this is the relative sentance: New-style types can provide a __getnewargs__() method that is used for protocol 2. Note that last phrase about requiring protocol 2. Your example works if you add a third parameter to pickle.dump() with the value of 2. Version 2 is not default. Hope this makes sense. ---------------------------------------------------------------------- Comment By: Myers Carpenter (myers_carpenter) Date: 2005-09-30 14:59 Message: Logged In: YES user_id=335935 Example code: import pickle class A(object): def __new__(klass, *args): print "__new__ %r" % (args,) return object.__new__(klass, *args) def __init__(self, *args): print "__init__" self.args = args def __getnewargs__(self): print "__getnewargs__" return (self.args,) print "object creation" a = A("a", "b",) print "pickle dump" pickle.dump(a, file("pickle.gnatest", "w")) del a print "pickle load" a = pickle.load(file("pickle.gnatest", "r")) print a Output: object creation __new__ ('a', 'b') __init__ pickle dump pickle load <__main__.A object at 0x4022096c> Expected: "__getnewargs__" never printed, __new__ not called after object load. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1309724&group_id=5470 From noreply at sourceforge.net Sat Oct 1 19:11:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 01 Oct 2005 10:11:51 -0700 Subject: [ python-Bugs-1239120 ] Win registry problem Message-ID: Bugs item #1239120, was opened at 2005-07-15 21:46 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239120&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Nobody/Anonymous (nobody) Summary: Win registry problem Initial Comment: Debbie Carraway in IT at NCSU gives this analysis of an apparent bug in the Python 2.4 installer for Windows. She discovered this in the context of using the installer for VPython, which looks for Python 2.4 in HKLM\Software\Python\PythonCore\2.4\InstallPath which used to work with Python 2.3. Here is her report: The problem is with the Python 2.4.1 installer. Python will put the InstallPath registry setting (which indicates where Python is installed) under HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE under some circumstances: (1) if you are not a member of the Administrators group (2) if you choose "Install for Just Me" rather than "Install for All Users", (3) if you automate the Python install using "msiexec.exe /i python-2.4.1.msi /q". The /q (quiet) switch causes different behavior than the defaults with a manual install ("msiexec.exe /i python-2.4.1.msi"). This is a mistake in the Python installer. The path to an installed application always belongs under HKLM, because the path to installed software is a machine-specific setting. If the path is in HKCU, the InstallPath setting can follow a user to a machine where Python is not installed. ---------------------------------------------------------------------- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-10-01 19:11 Message: Logged In: YES user_id=1188172 As far as I can see, newer installers (created with bdist_wininst) will look in both registry keys for Python versions. So I think a new VPython installer should solve this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239120&group_id=5470 From noreply at sourceforge.net Sun Oct 2 03:52:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 01 Oct 2005 18:52:14 -0700 Subject: [ python-Bugs-772896 ] unknown encoding -> MemoryError Message-ID: Bugs item #772896, was opened at 2003-07-17 03:27 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772896&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: George Yoshida (quiver) >Assigned to: Anthony Baxter (anthonybaxter) Summary: unknown encoding -> MemoryError Initial Comment: If you try to install a program and one of the files declares an unknown encoding(like 'UFT-8'), byte-compiling the file fails and get the message, "Sorry: MemoryError: ()" This message obscures the problem and makes it difficult to spot the problem. In fact, it took me a while to find out that the unknown encoding declaration caused the trouble. The error message needs to be more explicit. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-01 18:52 Message: Logged In: YES user_id=33168 I fixed this problem in 2.5. I am leaving it up to Anthony whether to backport this to 2.4 or not. Checked in as: Misc/NEWS: 1.1383, 1.1193.2.117 Python/pythonrun.c: 2.217, 2.211.2.3 Lib/test/bad_coding.py: 1.1 Lib/test/test_coding.py: 1.1 Parser/parsetok.c: 2.37 Parser/pgenmain.c: 2.32 Parser/tokenizer.c: 2.79 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772896&group_id=5470 From noreply at sourceforge.net Sun Oct 2 22:22:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Oct 2005 13:22:47 -0700 Subject: [ python-Bugs-1307798 ] subprocess.Popen locks on Cygwin Message-ID: Bugs item #1307798, was opened at 2005-09-29 03:05 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jacek Poplawski (jacek_poplawski) Assigned to: Jason Tishler (jlt63) Summary: subprocess.Popen locks on Cygwin Initial Comment: I have problem running application with subprocess.Popen, it happens only on Python from Cygwin or compiled on Cygwin. It works correctly on Linux, QNX, and Python from Windows installer, it also works on one version of Python 2.4.0 from Cygwin. When I run application with shell=True - everything is OK, but when I run it without it - Popen locks on data = os.read(errpipe_read, 1048576). Using options stdin, stdout, stderr doesn't help. I can't reproduce it with any simple application, application I am running is written in C++, multithreaded. $ python Python 2.4.2 (#1, Sep 29 2005, 10:56:12) [GCC 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import subprocess >>> subprocess.Popen("./application.exe") Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.4/subprocess.py", line 542, in __init__ errread, errwrite) File "/usr/local/lib/python2.4/subprocess.py", line 970, in _execute_child data = os.read(errpipe_read, 1048576) # Exceptions limited to 1 MB KeyboardInterrupt >>> subprocess.Popen("./application.exe",shell=True) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 13:22 Message: Logged In: YES user_id=33168 Jacek, are all the failures on cygwin? Can you report the version of cygwin on the failing boxes as well as the version of cygwin on the box that passed the test? ---------------------------------------------------------------------- Comment By: Jacek Poplawski (jacek_poplawski) Date: 2005-09-30 01:07 Message: Logged In: YES user_id=264913 Yes, I can run test_subprocess.py and all 38 tests are OK (in 15 seconds). Just like I wrote I can't reproduce that with any simple command, so maybe problem is that subprocess.Popen locks _if_ application does something specific - but what? PS. But I can reproduce that on few different computers with different Python installations so it is not just installation problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 22:33 Message: Logged In: YES user_id=33168 Jason, any comments? Is this cygwin specific or a general subprocess issue? ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2005-09-29 12:32 Message: Logged In: YES user_id=344921 Does the testsuite test_subprocess.py work correctly on this platform? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&group_id=5470 From noreply at sourceforge.net Mon Oct 3 02:37:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Oct 2005 17:37:37 -0700 Subject: [ python-Bugs-1219273 ] 'Expression' AST Node not documented Message-ID: Bugs item #1219273, was opened at 2005-06-12 11:27 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219273&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Martin Miller (mrmiller) >Assigned to: Neal Norwitz (nnorwitz) Summary: 'Expression' AST Node not documented Initial Comment: Python 2.4.1 documentation === The table at the end of section "19.3.1 AST Nodes" does not list Node type 'Expression' and its associated information. Also, the BNF for 'expression' shown in the file > expression ::= > or_test | lambda_form can't be correct because it doesn't cover cases of a simple literals (or identifiers) such as 42 and simple binary operator expressions such as 1+2. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 17:37 Message: Logged In: YES user_id=33168 Checked in as: * lib/asttable.tex 1.3 ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-06-29 12:26 Message: Logged In: YES user_id=174455 See patch #1227568 ---------------------------------------------------------------------- Comment By: Peter van Kampen (pterk) Date: 2005-06-29 12:24 Message: Logged In: YES user_id=174455 I have submitted a (very minimal) doc-patch that adds expression to the section 19.3.1. ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-18 13:34 Message: Logged In: YES user_id=1188172 To your second comment: the BNF for expression is correct since or_test can contain and_test which can contain not_test and so on until primary, atom, literal. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219273&group_id=5470 From noreply at sourceforge.net Mon Oct 3 02:44:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Oct 2005 17:44:53 -0700 Subject: [ python-Bugs-1308042 ] Datagram Socket Timeouts Message-ID: Bugs item #1308042, was opened at 2005-09-29 07:05 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1308042&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tom Vrankar (tvrankar) Assigned to: Nobody/Anonymous (nobody) Summary: Datagram Socket Timeouts Initial Comment: Python 2.4.1, MS Windows 2000 with service packs I'm trying to have a UDP client check for its server to start by repeatedly throwing messages at where it's expected to appear, and then checking for a response. I set a timeout on the recvfrom, expecting to block for the timeout and then proceeding to an exception handler, looping so until data is returned. Instead, the recvfrom throws an immediate exception "Connection reset by peer", and I loop rapidly without the load-softening effect of the timeout (in fact, it's the same behavior as if I didn't set the timeout at all). What UDP "connection" is it talking about? Seems wrong, but is it the implementation or is it me? If I start the server first, I get one "Invalid argument" exception in the client. In both cases, once the server is started, both processes are satisfied. Thanks. twv ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 17:44 Message: Logged In: YES user_id=33168 I added a note near the top of the socket module doc. """Some behavior may be platform dependent, since calls are made to the operating system socket APIs.""" Let me know if you think something more needs to be done. Checked in as: * Doc/lib/libsocket.tex 1.90, 1.88.2.2 ---------------------------------------------------------------------- Comment By: Tom Vrankar (tvrankar) Date: 2005-09-30 10:50 Message: Logged In: YES user_id=1353485 With Python around, I don't program much in C anymore, and for the same reason I usually assume platform independence (ensured by some clever Python programmer -- C or lib -- spackling over minor underlying differences) unless the Python docs explicitly tell me otherwise. nnorwitz's Linux results match my Solaris 8 results (and are what I intended). I submitted this report since the docs didn't provide any warnings about Python's UDP sockets behaving differently per platform. The behavior I saw would be wacky even on Windoze, but I don't know just how tolerant Windoze developers are of a poor sockets implementation :-). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 22:43 Message: Logged In: YES user_id=33168 This is a dupe of 1307357, but I'm closing that one since most of the comments are here. However, note this one comment from twv in the other report that says it also works on Solaris 8 and could well be Windoze specific. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 22:30 Message: Logged In: YES user_id=33168 Can you program the client in C and see if it behaves the same? Sockets are mostly just wrappers around the OS calls. It's possible this is the expected behaviour on Windows and python is just exposing that to you. I ran this on Linux and got this (which is what I think you want): neal at janus clean $ ./python PyBug/client.py & [1] 31484 neal at janus clean $ timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out timed out ./python PyBug/server.py timed out timed out timed out ('127.0.0.1', 40899) says CHECK ('127.0.0.1', 3000) says OK [10587 refs] [10585 refs] [1]+ Done ./python PyBug/client.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1308042&group_id=5470 From noreply at sourceforge.net Mon Oct 3 03:05:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Oct 2005 18:05:12 -0700 Subject: [ python-Bugs-887946 ] segfault if redirecting directory Message-ID: Bugs item #887946, was opened at 2004-01-30 16:42 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=887946&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Inyeol Lee (inyeol) >Assigned to: Neal Norwitz (nnorwitz) Summary: segfault if redirecting directory Initial Comment: If redirecting directory, python crashes. $ uname -a SunOS xxxxx 5.8 Generic_108528-18 sun4u sparc SUNW,Sun-Blade-1000 $ python Python 2.3.2 (#1, Oct 9 2003, 18:59:04) [GCC 2.95.3 20010315 (release)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> ^D $ mkdir foo $ ls -F foo/ $ python < foo Segmentation Fault -Inyeol Lee ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 18:05 Message: Logged In: YES user_id=33168 I fixed this problem and also added a warning when passing a directory on the command line. Before the fix, python would just silently exit which just bit me recently. (Same as mbp's comment.) Checked in as: * Misc/NEWS: 1.1384, 1.1193.2.118 * Modules/main.c: 1.85, 1.84.2.1 * Python/sysmodule.c: 2.130, 2.126.2.4 * Lib/test/test_cmd_line.py: 1.1, 1.1.2.2 ---------------------------------------------------------------------- Comment By: Martin Pool (mbp) Date: 2005-06-05 22:32 Message: Logged In: YES user_id=521 Here is another failure, which might have the same root cause: $ python /tmp $ echo $? 0 I'd expect this to give an error. ---------------------------------------------------------------------- Comment By: Martin Pool (mbp) Date: 2005-06-05 22:20 Message: Logged In: YES user_id=521 I doubt if libc checks whether the input is a directory; there are possible (though extremely obscure) cases where you might want to do that. I think you probably need something along the lines of fstat(0, &buf), then check the st_mode. Remember that fifos and chardevs ought to be allowed. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-11-22 04:32 Message: Logged In: YES user_id=1038590 Python's C main function assumes stdin, stdout and stderr are all valid FILE pointers. A little experimentation on a Linux box should establish what glibc is providing when the input pipe isn't a proper file (probably stdin == NULL given the symptoms, but that's just a guess) A sanity check on stdin should then be possible near the start of the main function. ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2004-11-22 04:24 Message: Logged In: YES user_id=1038590 Win XP SP 1 - C:\Python24>python < Lib "Access is Denied" ---------------------------------------------------------------------- Comment By: Inyeol Lee (inyeol) Date: 2004-11-04 11:10 Message: Logged In: YES user_id=595280 I did some more test among different versions; 2.4b1/Solaris - segfault 2.3.3/Linux - segfault 2.3.2/Solaris - segfault 2.1.1/Linux - OK 1.5.2/Linux - OK ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=887946&group_id=5470 From noreply at sourceforge.net Mon Oct 3 03:06:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Oct 2005 18:06:45 -0700 Subject: [ python-Bugs-814259 ] LDFLAGS ignored in Makefile Message-ID: Bugs item #814259, was opened at 2003-09-28 20:51 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814259&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Randy Davis (randydavis1) Assigned to: Neal Norwitz (nnorwitz) Summary: LDFLAGS ignored in Makefile Initial Comment: Under IRIX 6.3 gcc 3.2.2, building python results in the normal IRIX o32/n32 stupidity. However, attempting to correct it by specifying LDFLAGS of -n32 is ignored. Inspecting the Makefile produced by configure shows that the environment variable LDFLAGS is properly imported and is set as the environment variable is set (in this case; "LDFLAGS = -n32"). **HOWEVER**, it is NEVER used on any "ld" command line. I was able to fix it by changing the lines: LDSHARED= ld -shared -all BLDSHARED= ld -shared -all to: LDSHARED= ld -shared -all $(LDFLAGS) BLDSHARED= ld -shared -all $(LDFLAGS) While I do not profess that this is the best way to fix it, I do note that the LDFLAGS Makefile variable seems to be ignored unless this is done. Making this change got rid of the FATAL ld errors complaining about expecting o32 binaries but getting n32 versions. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 18:06 Message: Logged In: YES user_id=33168 Looking in Makefile.pre.in I see that LDFLAGS is used to link with. If you are still having problems, please re-open. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-01 23:30 Message: Logged In: YES user_id=33168 Looking in Makefile.pre.in I see that LDFLAGS is used to link with. If you are still having problems, please re-open. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814259&group_id=5470 From noreply at sourceforge.net Mon Oct 3 03:13:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Oct 2005 18:13:21 -0700 Subject: [ python-Bugs-898271 ] symtable module crashes w/ coding declaration Message-ID: Bugs item #898271, was opened at 2004-02-16 12:49 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=898271&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Peter ?strand (astrand) >Assigned to: Neal Norwitz (nnorwitz) Summary: symtable module crashes w/ coding declaration Initial Comment: The symtable module doesn't work with source code encodings, it seems. Sample code: #!/usr/bin/env python # -*- coding: iso-8859-1 -*- import sys import symtable filename = sys.argv[0] tab = symtable.symtable(open(filename).read(), filename, exec") print tab.get_type() When running this code, I get: Traceback (most recent call last): File "./bar.py", line 8, in ? print tab.get_type() File "/usr/local/lib/python2.3/symtable.py", line 71, in get_type assert self._table.type in (1, 2, 3), AssertionError: unexpected type: 0 If I remove the source code encoding declaration, things work fine. I've verified this problem with 2.3.2 and 2.3.3. 2.2.0 and 2.2.2 works fine. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 18:13 Message: Logged In: YES user_id=33168 This is still a problem w/2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=898271&group_id=5470 From noreply at sourceforge.net Mon Oct 3 03:19:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Oct 2005 18:19:09 -0700 Subject: [ python-Bugs-904474 ] File read of Chinese utf-16-le treats upper byte 1A as EOF Message-ID: Bugs item #904474, was opened at 2004-02-25 11:30 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=904474&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ron Rother (rrother) Assigned to: Nobody/Anonymous (nobody) Summary: File read of Chinese utf-16-le treats upper byte 1A as EOF Initial Comment: Any utf-16-le Chinese character with 1A as the most significant byte causes remainder of file to be ignored. code extract: (utf16_encoder, utf16_decoder, utf16_reader, utf16_writer) = codecs.lookup("utf-16-le") ifile = utf16_reader(open(sys.argv[1],"r")) t=ifile.read() When the Chinese character 1A 5C (尚) is encoundered, everthing from the 5C is discarded. These 3 lines: English="You have not selected any books!" Context=1,[MsgBox "You have not selected any books!"] Chinese(Simplified)="尚未选择任何书卷！" are input as: English="You have not selected any books!" Context=1,[MsgBox "You have not selected any books!"] Chinese(Simplified)=" ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 18:19 Message: Logged In: YES user_id=33168 MAL, this seems to come up from time to time. Perhaps we should update the doc for open()? If it's already documented, could we make it clearer? Then we should be able to close this bug. I think I saw another bug recently that was similar to this one. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-02-25 14:53 Message: Logged In: YES user_id=38388 I believe there is a misconception here: the open(..., "r") will cause the file to be opened in C lib's text mode. Since UTF-16 is binary data, this will lead to problems with line breaking and file handling in general. You should try: import codecs ifile = codecs.open(filename, 'rb', encoding='utf-16-le') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=904474&group_id=5470 From noreply at sourceforge.net Mon Oct 3 03:20:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Oct 2005 18:20:46 -0700 Subject: [ python-Bugs-906405 ] Build fails on XP w/mingw Message-ID: Bugs item #906405, was opened at 2004-02-28 03:08 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=906405&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Con (shrodingersdog) Assigned to: Nobody/Anonymous (nobody) >Summary: Build fails on XP w/mingw Initial Comment: When trying to build the source: Modules/posixmodule.c fails to build. I'm running on XP SP1 using mingw32-make ver 3.80 Is there any known issues on XP? ---------------------------------------------------------------------- Comment By: Con (shrodingersdog) Date: 2005-06-27 04:26 Message: Logged In: YES user_id=986333 Still, happens. In the end I just compiled the source using VC6, so it doesn't really matter for me anymore though. It might be that I just don't have the MinGW environment setup right... ---------------------------------------------------------------------- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-01 04:57 Message: Logged In: YES user_id=1188172 Is this still happening with 2.3.5 or 2.4.1? ---------------------------------------------------------------------- Comment By: Con (shrodingersdog) Date: 2004-05-01 03:52 Message: Logged In: YES user_id=986333 Sorry, crash is not the right word. I've attached the output from make. Let me know if that helps or if you need other info. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-04-24 01:08 Message: Logged In: YES user_id=21627 What exactly does "it crashes" mean? Do you get a blue screen? Is your hard disk making a crashing sound? ---------------------------------------------------------------------- Comment By: Con (shrodingersdog) Date: 2004-04-23 02:27 Message: Logged In: YES user_id=986333 When I run make it crashes when it gets to Modules/posixmodule.c. This is compiling with the Ming / (Cygwin?) compiler though. I have recently tried with MSVC 6 which builds without any problems. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-03-29 14:35 Message: Logged In: YES user_id=21627 In what way precisely does it fail? It builds fine for me with VC.NET 2003, which is the official build environment for Python on XP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=906405&group_id=5470 From noreply at sourceforge.net Mon Oct 3 03:26:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 02 Oct 2005 18:26:57 -0700 Subject: [ python-Bugs-914148 ] xml.sax segfault on error Message-ID: Bugs item #914148, was opened at 2004-03-11 06:14 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=914148&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Adam Sampson (adamsampson) >Assigned to: Neal Norwitz (nnorwitz) Summary: xml.sax segfault on error Initial Comment: While (mistakenly) using Mark Pilgrim's feedparser module to parse data from , Python segfaults when it should invoke an error handler for invalid XML. The attached code demonstrates the problem; it occurs with Python 2.2.3 and 2.3.3 on my system. I've tried to chop the example data down as far as possible, but reducing it any further doesn't exhibit the problem (it's currently just above 64k, which might be a coincidence). The gdb traceback I get from the example is as follows: #0 normal_updatePosition (enc=0x404a4fc0, ptr=0x40682000
, end=0x81e87e0 "a>\n\n
\n\n
\n8--------------->8--------------->8--------------->8------- This is happening, because the value of the self._filename variable is just the first character of the fn: '/'. The __init__ method of the FileInput class (/usr/lib/python2.3/fileinput.py) is the responsible one about this malfunction. In the __init__ function it's checking the type of the 'files' variable (in this case it is fn) for an iteration hack: ---------------8<---------------8<---------------8<---------------8<------- (...) def __init__(self, files=None, inplace=0, backup="", bufsize=0): if type(files) == type(''): files = (files,) (...) --------------->8--------------->8--------------->8--------------->8------- When the type of the 'files' variable is unicode, the value of the 'files' variable is incohorently becoming into this: files = [u'/', u'h', u'o', u'm', u'e', u'/', u'm', u'e', u'r', u'e' .... consequently, python is trying to execute os.rename('/', '/.bak') instead of os.rename('/home/meren/myfile', '/home/meren/myfile.bak'). After this function call os module decides to throw an error, normally.. [1], (...) if isinstance(files, basestring): files = (files,) (...) [2] (...) if type(files) == type(''): files = (files,) (...) Checking the type of the variable in the __init__ function of the class like [1] is solving the problem (now we are doing it like [2]).. Also, no backward compatibility problem appearing with this replacement. Here is a small patch to show replacement properly: ---------------8<---------------8<---------------8<---------------8<------- --- fileinput.orig.py 2005-10-24 19:55:53.019413368 +0300 +++ fileinput.py 2005-10-24 19:56:19.590373968 +0300 @@ -184,7 +184,7 @@ """ def __init__(self, files=None, inplace=0, backup="", bufsize=0): - if type(files) == type(''): + if isinstance(files, basestring): files = (files,) else: if files is None: --------------->8--------------->8--------------->8--------------->8------- and here is the result of the same operation after this patch: ---------------8<---------------8<---------------8<---------------8<------- (...) os.rename(self._filename, self._backupfilename) OSError: [Errno 16] Device or resource busy >>> reload(fileinput) >>> for line in fileinput.input(fn, inplace = 1): ... print line ... >>> --------------->8--------------->8--------------->8--------------->8------- Sorry for the long explanation, Thanks in advice.. Ciao. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1336582&group_id=5470 From noreply at sourceforge.net Mon Oct 24 19:47:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Oct 2005 10:47:21 -0700 Subject: [ python-Bugs-1336623 ] tarfile can't extract some tar archives.. Message-ID: Bugs item #1336623, was opened at 2005-10-24 17:47 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=1336623&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: A. Murat EREN (meren) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile can't extract some tar archives.. Initial Comment: Here is a small demo to reproduce the same problem: -----------------8<-----------------8<-----------------8<-----------------8<--- meren at pardus /home/meren $ wget ftp://ftp.sleepycat.com/releases/db.1.85.tar.gz (...) 100%[============>] 270,953 17.13K/s ETA 00:00 20:21:09 (15.25 KB/s) - `db.1.85.tar.gz' saved [270,953] meren at pardus /home/meren $ file db.1.85.tar.gz db.1.85.tar.gz: gzip compressed data, from Unix meren at pardus /home/meren $ python >>> tar = tarfile.open("db.1.85.tar.gz", "r:gz") >>> for tarinfo in tar: ... print tarinfo.name ... db.1.85 db.1.85/btree db.1.85/btree/Makefile.inc db.1.85/btree/bt_close.c db.1.85/btree/bt_conv.c db.1.85/btree/bt_debug.c db.1.85/btree/bt_delete.c db.1.85/btree/btree.h db.1.85/btree/bt_get.c db.1.85/btree/bt_open.c (...) >>> for tarinfo in tar: ... tar.extract(tarinfo) ... >>> Ctrl + D meren at pardus /home/meren $ ls db* db.1.85 db.1.85.tar.gz meren at pardus /home/meren $ file db.1.85 db.1.85: empty meren at pardus /home/meren $ cat db.1.85 meren at pardus /home/meren $ ----------------->8----------------->8----------------->8----------------->8--- Also this file is extracting with the same result too: ftp://ftp.linux.org.tr/pub/mirrors/gentoo/distfiles/ncompress-4.2.4.tar.gz This thing is very rarely happening, but it is happening. Also, I could extract these archives properly via the native 'tar' binary.. Thanks in advance, Ciao. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1336623&group_id=5470 From noreply at sourceforge.net Mon Oct 24 20:19:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 24 Oct 2005 11:19:32 -0700 Subject: [ python-Bugs-1336623 ] tarfile can't extract some tar archives.. Message-ID: Bugs item #1336623, was opened at 2005-10-24 17:47 Message generated for change (Comment added) made by meren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1336623&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: A. Murat EREN (meren) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile can't extract some tar archives.. Initial Comment: Here is a small demo to reproduce the same problem: -----------------8<-----------------8<-----------------8<-----------------8<--- meren at pardus /home/meren $ wget ftp://ftp.sleepycat.com/releases/db.1.85.tar.gz (...) 100%[============>] 270,953 17.13K/s ETA 00:00 20:21:09 (15.25 KB/s) - `db.1.85.tar.gz' saved [270,953] meren at pardus /home/meren $ file db.1.85.tar.gz db.1.85.tar.gz: gzip compressed data, from Unix meren at pardus /home/meren $ python >>> tar = tarfile.open("db.1.85.tar.gz", "r:gz") >>> for tarinfo in tar: ... print tarinfo.name ... db.1.85 db.1.85/btree db.1.85/btree/Makefile.inc db.1.85/btree/bt_close.c db.1.85/btree/bt_conv.c db.1.85/btree/bt_debug.c db.1.85/btree/bt_delete.c db.1.85/btree/btree.h db.1.85/btree/bt_get.c db.1.85/btree/bt_open.c (...) >>> for tarinfo in tar: ... tar.extract(tarinfo) ... >>> Ctrl + D meren at pardus /home/meren $ ls db* db.1.85 db.1.85.tar.gz meren at pardus /home/meren $ file db.1.85 db.1.85: empty meren at pardus /home/meren $ cat db.1.85 meren at pardus /home/meren $ ----------------->8----------------->8----------------->8----------------->8--- Also this file is extracting with the same result too: ftp://ftp.linux.org.tr/pub/mirrors/gentoo/distfiles/ncompress-4.2.4.tar.gz This thing is very rarely happening, but it is happening. Also, I could extract these archives properly via the native 'tar' binary.. Thanks in advance, Ciao. ---------------------------------------------------------------------- >Comment By: A. Murat EREN (meren) Date: 2005-10-24 18:19 Message: Logged In: YES user_id=718263 more examples: ftp://ftp.porcupine.org/pub/security/portmap_5beta.tar.gz ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6.tar.gz additionally, the same problem appearing when trying to extract these archives with the "ark" (yet another kde tool, just a simple front-end for the tar command. interesting, isn't it). Ciao. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1336623&group_id=5470 From noreply at sourceforge.net Tue Oct 25 14:38:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Oct 2005 05:38:20 -0700 Subject: [ python-Bugs-1337400 ] Python.h should include system headers properly [POSIX] Message-ID: Bugs item #1337400, was opened at 2005-10-25 14:38 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=1337400&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dimitri Papadopoulos (papadopo) Assigned to: Nobody/Anonymous (nobody) Summary: Python.h should include system headers properly [POSIX] Initial Comment: In Python 2.4.2, Python.h looks like this: #include [...] #include [...] #include #include #include #ifdef HAVE_UNISTD_H #include #endif On POSIX platforms should be included first! Indeed it includes headers such as on Solaris, on Irix, or on GNU systems, which define macros that specify the system interfaces to use, possibly depending on compiler options, which in turn may enable/disable/modify parts of other system headers such as or . By including , you ensure consistent systems interfaces are specified in all system headers included by Python sources. This may seem rather academic, but it actually breaks my Solaris builds: I need to compile Python using Sun's C compiler when building Python for performance and GNU's C++ compiler when building Python modules written in C++ for compatibility with C++ libraries used by these modules that can't be compiled with Sun's C++ compiler. So the same Python.h is used by Sun's C compiler (which it was created for in the first place) and GNU's C++ compiler. GNU's C++ compiler fails to compile some modules. Unfortunately I can't recall the exact modules and error messages right now, but including fixes the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337400&group_id=5470 From noreply at sourceforge.net Tue Oct 25 15:57:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Oct 2005 06:57:07 -0700 Subject: [ python-Bugs-1337400 ] Python.h should include system headers properly [POSIX] Message-ID: Bugs item #1337400, was opened at 2005-10-25 14:38 Message generated for change (Comment added) made by papadopo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337400&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dimitri Papadopoulos (papadopo) Assigned to: Nobody/Anonymous (nobody) Summary: Python.h should include system headers properly [POSIX] Initial Comment: In Python 2.4.2, Python.h looks like this: #include [...] #include [...] #include #include #include #ifdef HAVE_UNISTD_H #include #endif On POSIX platforms should be included first! Indeed it includes headers such as on Solaris, on Irix, or on GNU systems, which define macros that specify the system interfaces to use, possibly depending on compiler options, which in turn may enable/disable/modify parts of other system headers such as or . By including , you ensure consistent systems interfaces are specified in all system headers included by Python sources. This may seem rather academic, but it actually breaks my Solaris builds: I need to compile Python using Sun's C compiler when building Python for performance and GNU's C++ compiler when building Python modules written in C++ for compatibility with C++ libraries used by these modules that can't be compiled with Sun's C++ compiler. So the same Python.h is used by Sun's C compiler (which it was created for in the first place) and GNU's C++ compiler. GNU's C++ compiler fails to compile some modules. Unfortunately I can't recall the exact modules and error messages right now, but including fixes the problem. ---------------------------------------------------------------------- >Comment By: Dimitri Papadopoulos (papadopo) Date: 2005-10-25 15:57 Message: Logged In: YES user_id=52414 Oops... Instead of including fixes the problem. please read including first fixes the problem. Here is an example to reproduce the problem: $ cat > foo.cpp #include #include $ $ g++ -I/usr/local/python/include/python2.4 -c foo.cpp [...] /usr/local/gcc-4.0.2/lib/gcc/sparc-sun-solaris2.8/4.0.2/../../../../include/c++/4.0.2/cwchar:145: error: '::btowc' has not been declared [...] $ $ cat > foo.cpp #include #include #include $ $ g++ -I/usr/local/python/include/python2.4 -c foo.cpp [...] $ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337400&group_id=5470 From noreply at sourceforge.net Tue Oct 25 17:29:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Oct 2005 08:29:20 -0700 Subject: [ python-Bugs-874534 ] Errors testing python 2.3.3 Message-ID: Bugs item #874534, was opened at 2004-01-10 19:32 Message generated for change (Comment added) made by spektrum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=874534&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pierre (pierre42) Assigned to: Neal Norwitz (nnorwitz) Summary: Errors testing python 2.3.3 Initial Comment: # gmake test case $MAKEFLAGS in *-s*) LD_LIBRARY_PATH=/tmp/Python-2.3.3:/usr/local/lib:/usr/local/qt/lib:/usr/local/kde/lib:/usr/local/pwlib/lib:/usr/local/openh323/lib CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; *) LD_LIBRARY_PATH=/tmp/Python-2.3.3:/usr/local/lib:/usr/local/qt/lib:/usr/local/kde/lib:/usr/local/pwlib/lib:/usr/local/openh323/lib CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; esac running build running build_ext building 'dbm' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -fno-strict-aliasing -DHAVE_NDBM_H -I. -I/tmp/Python-2.3.3/./Include -I/usr/local/include -I/tmp/Python-2.3.3/Include -I/tmp/Python-2.3.3 -c /tmp/Python-2.3.3/Modules/dbmmodule.c -o build/temp.linux-i686-2.3/dbmmodule.o gcc -shared build/temp.linux-i686-2.3/dbmmodule.o -L/usr/local/lib -o build/lib.linux-i686-2.3/dbm.so *** WARNING: renaming "dbm" since importing it failed: build/lib.linux-i686-2.3/dbm.so: undefined symbol: dbm_firstkey running build_scripts find ./Lib -name '*.py[co]' -print | xargs rm -f LD_LIBRARY_PATH=/tmp/Python-2.3.3:/usr/local/lib:/usr/local/qt/lib:/usr/local/kde/lib:/usr/local/pwlib/lib:/usr/local/openh323/lib ./python -E -tt ./Lib/test/regrtest.py -l test_grammar [...] test_codecs test test_codecs failed -- Traceback (most recent call last): File "/tmp/Python-2.3.3/Lib/test/test_codecs.py", line 333, in test_nameprep raise test_support.TestFailed("Test 3.%d: %s" % (pos+1, str(e))) TestFailed: Test 3.5: u'\u0143 \u03b9' != u'\u0144 \u03b9' test_codeop [...] test_format /tmp/Python-2.3.3/Lib/test/test_format.py:19: FutureWarning: %u/%o/%x/%X of negative int will return a signed string in Python 2.4 and up result = formatstr % args test_fpformat [...] test_re test test_re produced unexpected output: ********************************************************************** *** lines 2-3 of actual output doesn't appear in expected output after line 1: + === Failed incorrectly ('(?u)\b.\b', u'\xc4', 0, 'found', u'\xc4') + === Failed incorrectly ('(?u)\w', u'\xc4', 0, 'found', u'\xc4') ********************************************************************** test_regex [...] test_unicode test test_unicode failed -- errors occurred in test.test_unicode.UnicodeTest test_unicode_file test_unicode_file skipped -- No Unicode filesystem semantics on this platform. test_unicodedata test test_unicodedata failed -- Traceback (most recent call last): File "/tmp/Python-2.3.3/Lib/test/test_unicodedata.py", line 62, in test_method_checksum self.assertEqual(result, self.expectedchecksum) File "/tmp/Python-2.3.3/Lib/unittest.py", line 302, in failUnlessEqual raise self.failureException, AssertionError: 'c269de8355871e3210ae8710b45c2ddb0675b9d5' != 'a37276dc2c158bef6dfd908ad34525c97180fad9' test_univnewlines [...] test_zlib 222 tests OK. 4 tests failed: test_codecs test_re test_unicode test_unicodedata 29 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_dbm test_email_codecs test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 2 skips unexpected on linux2: test_dbm test_locale gmake: *** [test] Error 1 ---------------------------------------------------------------------- Comment By: Matejcik (spektrum) Date: 2005-10-25 17:29 Message: Logged In: YES user_id=631694 i can confirm it happens in 2.3.3 and 2.3.5 compiler is gcc 3.3.3 or 4.0.2, happens with and without optimization i used the following configure options: --with-wctype-functions --with-fpectl --enable-shared --enable-unicode when using defaults, the tests pass ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 09:12 Message: Logged In: YES user_id=33168 Are you still having these problems? What compiler are you using? Have you tried building without optimization to see if the problems go away? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=874534&group_id=5470 From noreply at sourceforge.net Tue Oct 25 20:36:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Oct 2005 11:36:45 -0700 Subject: [ python-Bugs-1336623 ] tarfile can't extract some tar archives.. Message-ID: Bugs item #1336623, was opened at 2005-10-24 17:47 Message generated for change (Comment added) made by meren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1336623&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: A. Murat EREN (meren) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile can't extract some tar archives.. Initial Comment: Here is a small demo to reproduce the same problem: -----------------8<-----------------8<-----------------8<-----------------8<--- meren at pardus /home/meren $ wget ftp://ftp.sleepycat.com/releases/db.1.85.tar.gz (...) 100%[============>] 270,953 17.13K/s ETA 00:00 20:21:09 (15.25 KB/s) - `db.1.85.tar.gz' saved [270,953] meren at pardus /home/meren $ file db.1.85.tar.gz db.1.85.tar.gz: gzip compressed data, from Unix meren at pardus /home/meren $ python >>> tar = tarfile.open("db.1.85.tar.gz", "r:gz") >>> for tarinfo in tar: ... print tarinfo.name ... db.1.85 db.1.85/btree db.1.85/btree/Makefile.inc db.1.85/btree/bt_close.c db.1.85/btree/bt_conv.c db.1.85/btree/bt_debug.c db.1.85/btree/bt_delete.c db.1.85/btree/btree.h db.1.85/btree/bt_get.c db.1.85/btree/bt_open.c (...) >>> for tarinfo in tar: ... tar.extract(tarinfo) ... >>> Ctrl + D meren at pardus /home/meren $ ls db* db.1.85 db.1.85.tar.gz meren at pardus /home/meren $ file db.1.85 db.1.85: empty meren at pardus /home/meren $ cat db.1.85 meren at pardus /home/meren $ ----------------->8----------------->8----------------->8----------------->8--- Also this file is extracting with the same result too: ftp://ftp.linux.org.tr/pub/mirrors/gentoo/distfiles/ncompress-4.2.4.tar.gz This thing is very rarely happening, but it is happening. Also, I could extract these archives properly via the native 'tar' binary.. Thanks in advance, Ciao. ---------------------------------------------------------------------- >Comment By: A. Murat EREN (meren) Date: 2005-10-25 18:36 Message: Logged In: YES user_id=718263 I figured out that this is a very pesky problem. The problem is coming from the tar archives themselves. Simply, the "tarinfo.isdir()" check in the library returns false for the directories and they are extracting like a regular file.. How did they create these fool archives I don't know, and I couldn't reproduce similar buggy archives by myself. It would be nice to know. Because of the problem is not in the python library, it is very difficult to implement an efficent workaround to properly extract this kind of buggy tar archives. I'm going to attach a dirty workaround to show the idea (is anyone reading these reports?).. Ciao.. ---------------------------------------------------------------------- Comment By: A. Murat EREN (meren) Date: 2005-10-24 18:19 Message: Logged In: YES user_id=718263 more examples: ftp://ftp.porcupine.org/pub/security/portmap_5beta.tar.gz ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6.tar.gz additionally, the same problem appearing when trying to extract these archives with the "ark" (yet another kde tool, just a simple front-end for the tar command. interesting, isn't it). Ciao. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1336623&group_id=5470 From noreply at sourceforge.net Tue Oct 25 20:58:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Oct 2005 11:58:59 -0700 Subject: [ python-Bugs-1336623 ] tarfile can't extract some tar archives.. Message-ID: Bugs item #1336623, was opened at 2005-10-24 17:47 Message generated for change (Comment added) made by meren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1336623&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: A. Murat EREN (meren) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile can't extract some tar archives.. Initial Comment: Here is a small demo to reproduce the same problem: -----------------8<-----------------8<-----------------8<-----------------8<--- meren at pardus /home/meren $ wget ftp://ftp.sleepycat.com/releases/db.1.85.tar.gz (...) 100%[============>] 270,953 17.13K/s ETA 00:00 20:21:09 (15.25 KB/s) - `db.1.85.tar.gz' saved [270,953] meren at pardus /home/meren $ file db.1.85.tar.gz db.1.85.tar.gz: gzip compressed data, from Unix meren at pardus /home/meren $ python >>> tar = tarfile.open("db.1.85.tar.gz", "r:gz") >>> for tarinfo in tar: ... print tarinfo.name ... db.1.85 db.1.85/btree db.1.85/btree/Makefile.inc db.1.85/btree/bt_close.c db.1.85/btree/bt_conv.c db.1.85/btree/bt_debug.c db.1.85/btree/bt_delete.c db.1.85/btree/btree.h db.1.85/btree/bt_get.c db.1.85/btree/bt_open.c (...) >>> for tarinfo in tar: ... tar.extract(tarinfo) ... >>> Ctrl + D meren at pardus /home/meren $ ls db* db.1.85 db.1.85.tar.gz meren at pardus /home/meren $ file db.1.85 db.1.85: empty meren at pardus /home/meren $ cat db.1.85 meren at pardus /home/meren $ ----------------->8----------------->8----------------->8----------------->8--- Also this file is extracting with the same result too: ftp://ftp.linux.org.tr/pub/mirrors/gentoo/distfiles/ncompress-4.2.4.tar.gz This thing is very rarely happening, but it is happening. Also, I could extract these archives properly via the native 'tar' binary.. Thanks in advance, Ciao. ---------------------------------------------------------------------- >Comment By: A. Murat EREN (meren) Date: 2005-10-25 18:58 Message: Logged In: YES user_id=718263 no files attached.. sorry, here it is.. ---------------------------------------------------------------------- Comment By: A. Murat EREN (meren) Date: 2005-10-25 18:36 Message: Logged In: YES user_id=718263 I figured out that this is a very pesky problem. The problem is coming from the tar archives themselves. Simply, the "tarinfo.isdir()" check in the library returns false for the directories and they are extracting like a regular file.. How did they create these fool archives I don't know, and I couldn't reproduce similar buggy archives by myself. It would be nice to know. Because of the problem is not in the python library, it is very difficult to implement an efficent workaround to properly extract this kind of buggy tar archives. I'm going to attach a dirty workaround to show the idea (is anyone reading these reports?).. Ciao.. ---------------------------------------------------------------------- Comment By: A. Murat EREN (meren) Date: 2005-10-24 18:19 Message: Logged In: YES user_id=718263 more examples: ftp://ftp.porcupine.org/pub/security/portmap_5beta.tar.gz ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6.tar.gz additionally, the same problem appearing when trying to extract these archives with the "ark" (yet another kde tool, just a simple front-end for the tar command. interesting, isn't it). Ciao. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1336623&group_id=5470 From noreply at sourceforge.net Wed Oct 26 00:03:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Oct 2005 15:03:57 -0700 Subject: [ python-Bugs-1191458 ] [AST] Failing tests Message-ID: Bugs item #1191458, was opened at 2005-04-27 20:30 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Jeremy Hylton (jhylton) Summary: [AST] Failing tests Initial Comment: This tracker item is to be used to keep track of what tests are currently failing on the AST branch. This is somewhat important sinced there are so many failures it can be hard to detect if a change fixed what it was supposed to or actually managed to break more code. When posting follow-ups of fixed tests, please re-list the currently failing tests so as to make it simple to reference the current state of things. So, the current offenders are (from a straight ``regrtest.py`` run on my OS X box, which always has test__locale fail so I removed it):: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_peepholer test_scope test_socket test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings test_zipfile ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2005-10-25 15:03 Message: Logged In: YES user_id=357491 Yep, all tests pass, so that just leaves the test_trace tests that are currently commented out. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-10-23 21:51 Message: Logged In: YES user_id=35752 I believe the only remaining broken tests are the ones commented out in test_trace. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2005-10-07 11:46 Message: Logged In: YES user_id=31392 test_dis update: Fixed one of two failing tests. test_dis() was easy. test_bug_708901() is harder. The current AST only stores line numbers for statements. The test case is checking that the lnotab can assign a single statement multiple line numbers; in this case, the statement spans multiple lines and the disassembled code should reflect that. The fix is probably to add line numbers to expressions, which requires changing the AST definition and updating ast.c to assign line numbers. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2005-10-07 11:01 Message: Logged In: YES user_id=31392 Here's a quick status report on Linux + GCC 3.2.2 from today: 12 tests failed: test_dis test_doctest test_future test_genexps test_inspect test_new test_peepholer test_pwd test_scope test_subprocess test_symtable test_trace 7 skips unexpected on linux2: test_hotshot test_bsddb test_email test_parser test_transformer test_email_codecs test_compiler I'm going to trace into the details of why each of these tests is failing. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-07-10 21:15 Message: Logged In: YES user_id=357491 Scratch the "all open bugs" comment; didn't get to bug #1195576. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-07-10 21:13 Message: Logged In: YES user_id=357491 After applying all patches associated with all open bugs, the failing tests from ``./python.exe Lib/test/regrtest.py`` are: 14 tests failed: test_cookielib test_dis test_future test_genexps test_inspect test_new test_peepholer test_scope test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 04:40 Message: Logged In: YES user_id=1038590 Fixing #1186353 (lambda argument unpacking) fixes test_sort and test_itertools: 17 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_new test_ossaudiodev test_peepholer test_scope test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2005-05-28 01:33 Message: Logged In: YES user_id=1038590 Bumped bug priority to 9 so it stays on top of the SF tracker. Also, we can't merge the AST branch until this bug is closed, so it is fairly important to close out these issues :) Running "./python Lib/test/regrtest.py -uall" Suse Linux 9.1: 20 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_ossaudiodev test_peepholer test_scope test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings test_zipfile WIth the patch for 1186195 (genexp scoping) applied I get: 19 tests failed: test_compile test_cookielib test_dis test_doctest test_future test_genexps test_inspect test_itertools test_new test_ossaudiodev test_peepholer test_scope test_sort test_subprocess test_symtable test_syntax test_trace test_traceback test_warnings The remaining test_genexps failures are due to assignment statements not checking for genexps as illegal targets. Running test_zipfile in verbose mode indicated genexp problems, so it makes sense that fixing the scoping eliminated those failures. I'm going to look at lambdas next, since they seem to be the culprits with respect to a few different test failures. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191458&group_id=5470 From noreply at sourceforge.net Wed Oct 26 04:12:17 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Oct 2005 19:12:17 -0700 Subject: [ python-Bugs-1337987 ] IDLE, F5 – wrong external file content on error. Message-ID: Bugs item #1337987, was opened at 2005-10-26 04:12 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=1337987&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: MvGulik (tyrell_rr) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE, F5 ? wrong external file content on error. Initial Comment: IDLE, F5 ? wrong external file content on error. using: Python 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32 IDLE 1.0.5 , TK: 8.4 The basic problem is that when a external file is reloaded, by using F5, and that file contains a error. IDLE will tell about the error, and highlight the error, but its still using the old file content in its GUI window and not the newly reloaded file content. when: (IDLE GUI) - using F5 to reload and restart a external script. - new and changed script file containing a error. what: - display is showing previous script content. - error highlight is pointing at the wrong code. (bad!) how: first file: (create, load and execute) --- a = 1 print a --- change to: --- a = 1 print a : print a --- use F5 to auto reload and execute. Anything I'm doing wrong, or I can do locally to fix this?. just let me know. ps: upgrade to 2.4.x is not really a option in my case. (not yet at leased) Cheers M.v.Gulik ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337987&group_id=5470 From noreply at sourceforge.net Wed Oct 26 04:18:28 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Oct 2005 19:18:28 -0700 Subject: [ python-Bugs-1337990 ] doctest mishandles exceptions raised within generators Message-ID: Bugs item #1337990, was opened at 2005-10-26 11:48 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=1337990&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Wegener (twegener) Assigned to: Nobody/Anonymous (nobody) Summary: doctest mishandles exceptions raised within generators Initial Comment: If a generator raises an exception while iterating over it, doctest will only register the exception output, and will miss output that occurred during previous loop iterations. The following code clarifies and reproduces the problem: (also included as an attachment) """Reproduce bug with exceptions in a generator in doctest tests. This bug has been seen to occur in: Linux (RH9): Python 2.4.1 Python 2.3.5 Python 2.2.2 (using from __future__ import generators) Windows XP: Python 2.4.2 Python 2.3.5 """ def error_generator(): """Yield 0 to 2 and then try and raise an exception. >>> for j in error_generator(): ... print j 0 1 2 Traceback (most recent call last): Exception: Contrived exception for sake of example """ # Note: This is obviously a contrived example of generator use. for i in range(3): yield i if 1: raise Exception("Contrived exception for sake of example") raise StopIteration if __name__ == '__main__': # Run the doctest tests. import sys import doctest doctest.testmod(sys.modules['__main__']) print print 'What should have happened...' for j in error_generator(): print j ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337990&group_id=5470 From noreply at sourceforge.net Wed Oct 26 04:37:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Oct 2005 19:37:30 -0700 Subject: [ python-Bugs-1337987 ] IDLE, F5 – wrong external file content. (on error!) Message-ID: Bugs item #1337987, was opened at 2005-10-26 04:12 Message generated for change (Comment added) made by tyrell_rr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337987&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: MvGulik (tyrell_rr) Assigned to: Nobody/Anonymous (nobody) >Summary: IDLE, F5 ? wrong external file content. (on error!) Initial Comment: IDLE, F5 ? wrong external file content on error. using: Python 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32 IDLE 1.0.5 , TK: 8.4 The basic problem is that when a external file is reloaded, by using F5, and that file contains a error. IDLE will tell about the error, and highlight the error, but its still using the old file content in its GUI window and not the newly reloaded file content. when: (IDLE GUI) - using F5 to reload and restart a external script. - new and changed script file containing a error. what: - display is showing previous script content. - error highlight is pointing at the wrong code. (bad!) how: first file: (create, load and execute) --- a = 1 print a --- change to: --- a = 1 print a : print a --- use F5 to auto reload and execute. Anything I'm doing wrong, or I can do locally to fix this?. just let me know. ps: upgrade to 2.4.x is not really a option in my case. (not yet at leased) Cheers M.v.Gulik ---------------------------------------------------------------------- >Comment By: MvGulik (tyrell_rr) Date: 2005-10-26 04:37 Message: Logged In: YES user_id=779309 huu, little update. the error itself is not part of the real (code)problem. ( it is of course when its leading to misleading debug info ) but the display of the external file in just not updated after using F5. with or without a error being triggerd. M.v.Gulik ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337987&group_id=5470 From noreply at sourceforge.net Wed Oct 26 04:45:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 25 Oct 2005 19:45:00 -0700 Subject: [ python-Bugs-1337987 ] IDLE, F5 – wrong external file content. (on error!) Message-ID: Bugs item #1337987, was opened at 2005-10-25 21:12 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337987&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: MvGulik (tyrell_rr) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE, F5 ? wrong external file content. (on error!) Initial Comment: IDLE, F5 ? wrong external file content on error. using: Python 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32 IDLE 1.0.5 , TK: 8.4 The basic problem is that when a external file is reloaded, by using F5, and that file contains a error. IDLE will tell about the error, and highlight the error, but its still using the old file content in its GUI window and not the newly reloaded file content. when: (IDLE GUI) - using F5 to reload and restart a external script. - new and changed script file containing a error. what: - display is showing previous script content. - error highlight is pointing at the wrong code. (bad!) how: first file: (create, load and execute) --- a = 1 print a --- change to: --- a = 1 print a : print a --- use F5 to auto reload and execute. Anything I'm doing wrong, or I can do locally to fix this?. just let me know. ps: upgrade to 2.4.x is not really a option in my case. (not yet at leased) Cheers M.v.Gulik ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-25 21:45 Message: Logged In: YES user_id=80475 Save with Control-S before pressing F5. ---------------------------------------------------------------------- Comment By: MvGulik (tyrell_rr) Date: 2005-10-25 21:37 Message: Logged In: YES user_id=779309 huu, little update. the error itself is not part of the real (code)problem. ( it is of course when its leading to misleading debug info ) but the display of the external file in just not updated after using F5. with or without a error being triggerd. M.v.Gulik ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337987&group_id=5470 From noreply at sourceforge.net Wed Oct 26 11:37:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Oct 2005 02:37:53 -0700 Subject: [ python-Bugs-1338264 ] Memory keeping Message-ID: Bugs item #1338264, was opened at 2005-10-26 15:37 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=1338264&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: sin (sin_avatar) Assigned to: Nobody/Anonymous (nobody) Summary: Memory keeping Initial Comment: I execute this code on python 2.4.2 (authentic copy from console): Python 2.4.2 (#1, Oct 26 2005, 14:45:33) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> a = range(1,10000000) >>> del a before i type del - i run top and get (see console output below): 16300 sin 2 0 162M 161M poll 0:02 35.76% 9.28% python2.4 after del (console below): 16300 sin 2 0 162M 161M poll 0:03 7.18% 6.05% python2.4 I tried gc too ... but python didn't free memory. I checked this on windows - memory was freed, but interpreter with 0 defined variables "eat" about 75 Mb!. I think this is bug in interpereter core. some text from dmesg for you: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.8-RELEASE #0: Thu Apr 3 10:53:38 GMT 2003 root at freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/ GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (499.15-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x387f9ff real memory = 268369920 (262080K bytes) avail memory = 255901696 (249904K bytes) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338264&group_id=5470 From noreply at sourceforge.net Wed Oct 26 12:31:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Oct 2005 03:31:45 -0700 Subject: [ python-Bugs-1336623 ] tarfile can't extract some tar archives.. Message-ID: Bugs item #1336623, was opened at 2005-10-24 19:47 Message generated for change (Comment added) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1336623&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: A. Murat EREN (meren) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile can't extract some tar archives.. Initial Comment: Here is a small demo to reproduce the same problem: -----------------8<-----------------8<-----------------8<-----------------8<--- meren at pardus /home/meren $ wget ftp://ftp.sleepycat.com/releases/db.1.85.tar.gz (...) 100%[============>] 270,953 17.13K/s ETA 00:00 20:21:09 (15.25 KB/s) - `db.1.85.tar.gz' saved [270,953] meren at pardus /home/meren $ file db.1.85.tar.gz db.1.85.tar.gz: gzip compressed data, from Unix meren at pardus /home/meren $ python >>> tar = tarfile.open("db.1.85.tar.gz", "r:gz") >>> for tarinfo in tar: ... print tarinfo.name ... db.1.85 db.1.85/btree db.1.85/btree/Makefile.inc db.1.85/btree/bt_close.c db.1.85/btree/bt_conv.c db.1.85/btree/bt_debug.c db.1.85/btree/bt_delete.c db.1.85/btree/btree.h db.1.85/btree/bt_get.c db.1.85/btree/bt_open.c (...) >>> for tarinfo in tar: ... tar.extract(tarinfo) ... >>> Ctrl + D meren at pardus /home/meren $ ls db* db.1.85 db.1.85.tar.gz meren at pardus /home/meren $ file db.1.85 db.1.85: empty meren at pardus /home/meren $ cat db.1.85 meren at pardus /home/meren $ ----------------->8----------------->8----------------->8----------------->8--- Also this file is extracting with the same result too: ftp://ftp.linux.org.tr/pub/mirrors/gentoo/distfiles/ncompress-4.2.4.tar.gz This thing is very rarely happening, but it is happening. Also, I could extract these archives properly via the native 'tar' binary.. Thanks in advance, Ciao. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-10-26 12:31 Message: Logged In: YES user_id=642936 I submitted patch #1338314 which fixes this problem. tarfile.py is aware of these "buggy" archives, but the workaround did not work anymore. Thank you for your report, especially for the vast number of test archives. ---------------------------------------------------------------------- Comment By: A. Murat EREN (meren) Date: 2005-10-25 20:58 Message: Logged In: YES user_id=718263 no files attached.. sorry, here it is.. ---------------------------------------------------------------------- Comment By: A. Murat EREN (meren) Date: 2005-10-25 20:36 Message: Logged In: YES user_id=718263 I figured out that this is a very pesky problem. The problem is coming from the tar archives themselves. Simply, the "tarinfo.isdir()" check in the library returns false for the directories and they are extracting like a regular file.. How did they create these fool archives I don't know, and I couldn't reproduce similar buggy archives by myself. It would be nice to know. Because of the problem is not in the python library, it is very difficult to implement an efficent workaround to properly extract this kind of buggy tar archives. I'm going to attach a dirty workaround to show the idea (is anyone reading these reports?).. Ciao.. ---------------------------------------------------------------------- Comment By: A. Murat EREN (meren) Date: 2005-10-24 20:19 Message: Logged In: YES user_id=718263 more examples: ftp://ftp.porcupine.org/pub/security/portmap_5beta.tar.gz ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6.tar.gz additionally, the same problem appearing when trying to extract these archives with the "ark" (yet another kde tool, just a simple front-end for the tar command. interesting, isn't it). Ciao. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1336623&group_id=5470 From noreply at sourceforge.net Wed Oct 26 14:35:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Oct 2005 05:35:51 -0700 Subject: [ python-Bugs-1336623 ] tarfile can't extract some tar archives.. Message-ID: Bugs item #1336623, was opened at 2005-10-24 17:47 Message generated for change (Comment added) made by meren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1336623&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: A. Murat EREN (meren) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile can't extract some tar archives.. Initial Comment: Here is a small demo to reproduce the same problem: -----------------8<-----------------8<-----------------8<-----------------8<--- meren at pardus /home/meren $ wget ftp://ftp.sleepycat.com/releases/db.1.85.tar.gz (...) 100%[============>] 270,953 17.13K/s ETA 00:00 20:21:09 (15.25 KB/s) - `db.1.85.tar.gz' saved [270,953] meren at pardus /home/meren $ file db.1.85.tar.gz db.1.85.tar.gz: gzip compressed data, from Unix meren at pardus /home/meren $ python >>> tar = tarfile.open("db.1.85.tar.gz", "r:gz") >>> for tarinfo in tar: ... print tarinfo.name ... db.1.85 db.1.85/btree db.1.85/btree/Makefile.inc db.1.85/btree/bt_close.c db.1.85/btree/bt_conv.c db.1.85/btree/bt_debug.c db.1.85/btree/bt_delete.c db.1.85/btree/btree.h db.1.85/btree/bt_get.c db.1.85/btree/bt_open.c (...) >>> for tarinfo in tar: ... tar.extract(tarinfo) ... >>> Ctrl + D meren at pardus /home/meren $ ls db* db.1.85 db.1.85.tar.gz meren at pardus /home/meren $ file db.1.85 db.1.85: empty meren at pardus /home/meren $ cat db.1.85 meren at pardus /home/meren $ ----------------->8----------------->8----------------->8----------------->8--- Also this file is extracting with the same result too: ftp://ftp.linux.org.tr/pub/mirrors/gentoo/distfiles/ncompress-4.2.4.tar.gz This thing is very rarely happening, but it is happening. Also, I could extract these archives properly via the native 'tar' binary.. Thanks in advance, Ciao. ---------------------------------------------------------------------- >Comment By: A. Murat EREN (meren) Date: 2005-10-26 12:35 Message: Logged In: YES user_id=718263 thanks for the patch, it is just working. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-10-26 10:31 Message: Logged In: YES user_id=642936 I submitted patch #1338314 which fixes this problem. tarfile.py is aware of these "buggy" archives, but the workaround did not work anymore. Thank you for your report, especially for the vast number of test archives. ---------------------------------------------------------------------- Comment By: A. Murat EREN (meren) Date: 2005-10-25 18:58 Message: Logged In: YES user_id=718263 no files attached.. sorry, here it is.. ---------------------------------------------------------------------- Comment By: A. Murat EREN (meren) Date: 2005-10-25 18:36 Message: Logged In: YES user_id=718263 I figured out that this is a very pesky problem. The problem is coming from the tar archives themselves. Simply, the "tarinfo.isdir()" check in the library returns false for the directories and they are extracting like a regular file.. How did they create these fool archives I don't know, and I couldn't reproduce similar buggy archives by myself. It would be nice to know. Because of the problem is not in the python library, it is very difficult to implement an efficent workaround to properly extract this kind of buggy tar archives. I'm going to attach a dirty workaround to show the idea (is anyone reading these reports?).. Ciao.. ---------------------------------------------------------------------- Comment By: A. Murat EREN (meren) Date: 2005-10-24 18:19 Message: Logged In: YES user_id=718263 more examples: ftp://ftp.porcupine.org/pub/security/portmap_5beta.tar.gz ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6.tar.gz additionally, the same problem appearing when trying to extract these archives with the "ark" (yet another kde tool, just a simple front-end for the tar command. interesting, isn't it). Ciao. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1336623&group_id=5470 From noreply at sourceforge.net Wed Oct 26 20:14:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Oct 2005 11:14:25 -0700 Subject: [ python-Feature Requests-1110010 ] 'attrmap' function, attrmap(x)['attname'] == x.attname Message-ID: Feature Requests item #1110010, was opened at 2005-01-26 11:28 Message generated for change (Comment added) made by gregsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1110010&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: 'attrmap' function, attrmap(x)['attname'] == x.attname Initial Comment: One of the side effects of the new-style classes is that objects don't necessarily have __dict__ attached to them. It used to be possible to write things like def __str__(self): return "Node %(name)s, %(nlinks)d links, active: %(active)s" % self.__dict__ ... but this doesn't work if the class doesn't have a __dict__. Even if does, I'm not sure it will always get members from base classes. There is a 'vars' function; you could put 'vars(self)' in the above instead of self.__dict__, but it still doesn't work if the class doesn't have a __dict__. I can see different solutions for this: (1) change the 'string %' operator so that it allows %(.name)s, leading to a getattr() on the right-side argument rather than a getitem. return "Node %(.name)s, %(.nlinks)d links, active: %(.active)s" % self (2) Make a builtin like vars, but which works when the object doesn't have a __dict__ I.e. attrmap(x) would return a mapping which is bound to x, and reading attrmap(x)['attname'] is the same as getattr(x,'attname'). Thus return "Node %(name)s, %(nlinks)d links, active: %(active)s" % attrmap(self) This attrmap() function can be implemented in pure python, of course. I originally thought (1) made a lot of sense, but (2) seems to work just as well and doesn't require changing much. Also, (1) allows cases like "%(name)s %(.name2)s", which are not very useful, but are very likely to be created by accident; whereas in (2) you are deciding on the right of the '%' whether you are naming attributes or providing mapping keys. I'm not sure it's a good idea change 'vars' to have this behaviour, since vars(x).keys() currently works in a predictable way when vars(x) works; whereas attrmap(x).keys() may not be complete, or possible, even when attrmap(x) is useful. I.e. when x has a __getattr__ defined. On the other hand, vars(x) doesn't currently do much at all, so maybe it's possible to enhance it like this without breaking anything. The motivation for this came from the "%(name)s" issue, but the attrmap() function would be useful in other places e.g. processdata( infile, outfile, **attrmap(options)) ... where options might be obtained from optparse, e.g. Or, an attrmap can be used with the new Templates: string.Template('Node $name').substitute( attrmap(node)) Both of these examples will work with vars(), but only when the object actually has __dict__. This is why I'm thinking it may make sense to enhance vars: some code may be broken by the change; but other code, broken by new-style classes, may be unbroken by this change. The proxy could be writable, so that attrmap(x)['a'] = y is the same as x.a = y .. which could have more uses. A possible useful (possibly weird) variation: attrmap accepts 1 or more parameters, and the resulting proxy is bound to all of them. when attrmap(x,y,z)['a'] is done, the proxy will try x.a, y.a, z.a until one of them doesn't raise AttributeError. So it's equivalent to merging dictionaries. This would be useful in the %(name)s or Template cases, where you want information from several objects. ---------------------------------------------------------------------- >Comment By: Gregory Smith (gregsmith) Date: 2005-10-26 14:14 Message: Logged In: YES user_id=292741 To josiahcarlson: Yes, I can add __getitem__ to any class. But I don't see why I should make a whole bunch of classes act like dictionaries, only so that I can pass them to single API (like string.Template) which requires a dictionary. A class should have a dictionary behaviour if it makes sense for that class; if I have to add it specifically, and only, to make it work well in one particular situation, that's a kluge. If I have to add dict behaviour to a whole bunch of classes to make them all work in that one situation, that's a serious kluge. And entirely unintuitive, to borrow a phrase. When you encounter this situation, IMO, it's clear that a little 'pipe-fitting' like this is the best solution. Furthermore, and to underline the above, what if I have a class which already has a __getitem__ interface for it's own purposes? Chances are this behaves in a way which makes it useless for harvesting general attributes from the object; the object always has a getattr interface, however. Since ALL objects have a getattr interface, and there's a fair number of APIs that require objects with a read-only, string-keyed dict interface, why not have this universal pipe-fitting to tie them together, so as not to have to modify the objects and/or interfaces. To rhettinger: First off, what do you mean by 'use case'? I gave three examples of the use of the function, with %attrmap(x), string.Template(...).substitute(attrmap(x)); attrmap(options). I can expand these to more detail if you like. I didn't give use examples for the 'write' case; I haven't encountered a use for that. Yes, you have to think a bit before you see what it's for. That's arguably true for super(), slice() and operator.attrgetter() as well. Once you've run into the situation where it's useful, it becomes pretty clear what it's for. Given the general problem it solves, it's hard to imagine a neater and more intuitive solution IMO. Here's a 2-line sales pitch, which was implied, but not given, in the original post: def __str__(self): return "MyObj(name=%(name)s, n=%(n)d, links = %(links)d )" % attrmap(self) vs. the harder-to-maintain return "MyObj( name=%s, n=%d, links = %d )" % (self.name, self.n, self.links) ...this requires the programmer to maintain the same list of symbols twice, a burden which is very common in languages inferior to Python. And obviously it's very simple (the base functionality is 5 lines). Like attrgetter, It becomes more useful when it's always available in the standard lib, and a little faster if it happens to be in C. to loewis: fair enough, maybe it doesn't qualify for a builtin. But it might make more sense to do it as operator.attrmap rather than UserDict.AttrMap; it seems to fit into the same category as attrgettr and itemgetter. I wasn't aware of those two when I originally posted. And am I the only one who thinks the first example I gave (with __str__ using "..."%self.__dict__) is a pretty neat trick? And who has noticed it's been broken with new-style classes? That by itself, IMO, calls for a fix, and replacing self.__dict__ with attrmap(self) is a pretty simple fix. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-27 00:18 Message: Logged In: YES user_id=80475 -1 While potentially useful, the function is entirely unintuitive (it has to be studied a bit before being able to see what it is for). Also, the OP is short on use cases (none were presented). IMO, this belongs as a cookbook recipe. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-06-26 13:47 Message: Logged In: YES user_id=341410 An implementation of the base attrmap functionality (as suggested by Reinhold in his post in python-dev)... class attrmap: def __init__(self, obj): self.obj = obj def __getitem__(self, key): return getattr(self.obj, key) To Gregory Smith: If you merely add the __getitem__ method with a 'self' as the first argument of getattr, you don't even need attrmap. As an aside, when I want dictionary-like behavior from my classes, I use a dictionary or something that implements a subset of the mapping protocol. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-11 19:51 Message: Logged In: YES user_id=21627 I think I would rather not to see this as a builtin, e.g. putting it into UserDict.AttrMap instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1110010&group_id=5470 From noreply at sourceforge.net Thu Oct 27 01:08:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Oct 2005 16:08:07 -0700 Subject: [ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs Message-ID: Bugs item #1338995, was opened at 2005-10-26 16:08 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=1338995&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 From noreply at sourceforge.net Thu Oct 27 01:30:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Oct 2005 16:30:42 -0700 Subject: [ python-Bugs-1339007 ] shelve.Shelf.__del__ throws exceptions Message-ID: Bugs item #1339007, was opened at 2005-10-26 16:30 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=1339007&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Geoffrey T. Dairiki (dairiki) Assigned to: Nobody/Anonymous (nobody) Summary: shelve.Shelf.__del__ throws exceptions Initial Comment: Python calls an object's __del__ method, even if the objects __init__ method was unsuccessful (i.e. __init__ terminated via exception.) Because of this, if there is an error while attempting to open a Shelf, the destructor is still called, even though the Shelf is not fully constructed. The code in shelve.Shelf does not check for this possibility, and therefor triggers an AttributeError. Here is an example script which should reproduce the error. ===Begin test.py====l import shelve try: shelf = shelve.open('non-existant-file', flag='r') except: pass ===End test.py===== For me, the above script produces the message: Exception exceptions.AttributeError: "DbfilenameShelf instance has no attribute 'writeback'" in ignored I can reproduce this using either Python 2.4.1 or 2.3.5. I took a quick look at the current CVS version of shelve.py, and it appears to suffer the same problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339007&group_id=5470 From noreply at sourceforge.net Thu Oct 27 02:21:39 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Oct 2005 17:21:39 -0700 Subject: [ python-Bugs-1339045 ] Threading misbehavior with lambdas Message-ID: Bugs item #1339045, was opened at 2005-10-27 02:21 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=1339045&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Maciek Fijalkowski (fijal) Assigned to: Nobody/Anonymous (nobody) Summary: Threading misbehavior with lambdas Initial Comment: suppose i write: def f(x): print x() for i in range(3): f ( lambda : i ) I got 0,1,2 But when I write for i in range(3): thread . start_new_thread ( f , ( lambda : i ) ) I got 2,2,2 Probably I don't get well design principles, but isn't it against thread consistency? (as long as threads does not interact with each other, interlace doesn't matter). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339045&group_id=5470 From noreply at sourceforge.net Thu Oct 27 08:16:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 26 Oct 2005 23:16:43 -0700 Subject: [ python-Feature Requests-1110010 ] 'attrmap' function, attrmap(x)['attname'] == x.attname Message-ID: Feature Requests item #1110010, was opened at 2005-01-26 08:28 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1110010&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Smith (gregsmith) Assigned to: Nobody/Anonymous (nobody) Summary: 'attrmap' function, attrmap(x)['attname'] == x.attname Initial Comment: One of the side effects of the new-style classes is that objects don't necessarily have __dict__ attached to them. It used to be possible to write things like def __str__(self): return "Node %(name)s, %(nlinks)d links, active: %(active)s" % self.__dict__ ... but this doesn't work if the class doesn't have a __dict__. Even if does, I'm not sure it will always get members from base classes. There is a 'vars' function; you could put 'vars(self)' in the above instead of self.__dict__, but it still doesn't work if the class doesn't have a __dict__. I can see different solutions for this: (1) change the 'string %' operator so that it allows %(.name)s, leading to a getattr() on the right-side argument rather than a getitem. return "Node %(.name)s, %(.nlinks)d links, active: %(.active)s" % self (2) Make a builtin like vars, but which works when the object doesn't have a __dict__ I.e. attrmap(x) would return a mapping which is bound to x, and reading attrmap(x)['attname'] is the same as getattr(x,'attname'). Thus return "Node %(name)s, %(nlinks)d links, active: %(active)s" % attrmap(self) This attrmap() function can be implemented in pure python, of course. I originally thought (1) made a lot of sense, but (2) seems to work just as well and doesn't require changing much. Also, (1) allows cases like "%(name)s %(.name2)s", which are not very useful, but are very likely to be created by accident; whereas in (2) you are deciding on the right of the '%' whether you are naming attributes or providing mapping keys. I'm not sure it's a good idea change 'vars' to have this behaviour, since vars(x).keys() currently works in a predictable way when vars(x) works; whereas attrmap(x).keys() may not be complete, or possible, even when attrmap(x) is useful. I.e. when x has a __getattr__ defined. On the other hand, vars(x) doesn't currently do much at all, so maybe it's possible to enhance it like this without breaking anything. The motivation for this came from the "%(name)s" issue, but the attrmap() function would be useful in other places e.g. processdata( infile, outfile, **attrmap(options)) ... where options might be obtained from optparse, e.g. Or, an attrmap can be used with the new Templates: string.Template('Node $name').substitute( attrmap(node)) Both of these examples will work with vars(), but only when the object actually has __dict__. This is why I'm thinking it may make sense to enhance vars: some code may be broken by the change; but other code, broken by new-style classes, may be unbroken by this change. The proxy could be writable, so that attrmap(x)['a'] = y is the same as x.a = y .. which could have more uses. A possible useful (possibly weird) variation: attrmap accepts 1 or more parameters, and the resulting proxy is bound to all of them. when attrmap(x,y,z)['a'] is done, the proxy will try x.a, y.a, z.a until one of them doesn't raise AttributeError. So it's equivalent to merging dictionaries. This would be useful in the %(name)s or Template cases, where you want information from several objects. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-10-26 23:16 Message: Logged In: YES user_id=341410 gregsmith: class attrmap: def __getitem__(self, key): return getattr(self, key) Use that as a mixin with any class you want to offer attribute mapping support to. As in... class foo(..., attrmap): ... Now your class has attribute mapping support. Amazing! As for the neatness of __dict__, I have used it before, but when I need to rely on using __dict__, I make sure my object has one (generally by not creating or using __slots__). ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2005-10-26 11:14 Message: Logged In: YES user_id=292741 To josiahcarlson: Yes, I can add __getitem__ to any class. But I don't see why I should make a whole bunch of classes act like dictionaries, only so that I can pass them to single API (like string.Template) which requires a dictionary. A class should have a dictionary behaviour if it makes sense for that class; if I have to add it specifically, and only, to make it work well in one particular situation, that's a kluge. If I have to add dict behaviour to a whole bunch of classes to make them all work in that one situation, that's a serious kluge. And entirely unintuitive, to borrow a phrase. When you encounter this situation, IMO, it's clear that a little 'pipe-fitting' like this is the best solution. Furthermore, and to underline the above, what if I have a class which already has a __getitem__ interface for it's own purposes? Chances are this behaves in a way which makes it useless for harvesting general attributes from the object; the object always has a getattr interface, however. Since ALL objects have a getattr interface, and there's a fair number of APIs that require objects with a read-only, string-keyed dict interface, why not have this universal pipe-fitting to tie them together, so as not to have to modify the objects and/or interfaces. To rhettinger: First off, what do you mean by 'use case'? I gave three examples of the use of the function, with %attrmap(x), string.Template(...).substitute(attrmap(x)); attrmap(options). I can expand these to more detail if you like. I didn't give use examples for the 'write' case; I haven't encountered a use for that. Yes, you have to think a bit before you see what it's for. That's arguably true for super(), slice() and operator.attrgetter() as well. Once you've run into the situation where it's useful, it becomes pretty clear what it's for. Given the general problem it solves, it's hard to imagine a neater and more intuitive solution IMO. Here's a 2-line sales pitch, which was implied, but not given, in the original post: def __str__(self): return "MyObj(name=%(name)s, n=%(n)d, links = %(links)d )" % attrmap(self) vs. the harder-to-maintain return "MyObj( name=%s, n=%d, links = %d )" % (self.name, self.n, self.links) ...this requires the programmer to maintain the same list of symbols twice, a burden which is very common in languages inferior to Python. And obviously it's very simple (the base functionality is 5 lines). Like attrgetter, It becomes more useful when it's always available in the standard lib, and a little faster if it happens to be in C. to loewis: fair enough, maybe it doesn't qualify for a builtin. But it might make more sense to do it as operator.attrmap rather than UserDict.AttrMap; it seems to fit into the same category as attrgettr and itemgetter. I wasn't aware of those two when I originally posted. And am I the only one who thinks the first example I gave (with __str__ using "..."%self.__dict__) is a pretty neat trick? And who has noticed it's been broken with new-style classes? That by itself, IMO, calls for a fix, and replacing self.__dict__ with attrmap(self) is a pretty simple fix. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-26 21:18 Message: Logged In: YES user_id=80475 -1 While potentially useful, the function is entirely unintuitive (it has to be studied a bit before being able to see what it is for). Also, the OP is short on use cases (none were presented). IMO, this belongs as a cookbook recipe. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-06-26 10:47 Message: Logged In: YES user_id=341410 An implementation of the base attrmap functionality (as suggested by Reinhold in his post in python-dev)... class attrmap: def __init__(self, obj): self.obj = obj def __getitem__(self, key): return getattr(self.obj, key) To Gregory Smith: If you merely add the __getitem__ method with a 'self' as the first argument of getattr, you don't even need attrmap. As an aside, when I want dictionary-like behavior from my classes, I use a dictionary or something that implements a subset of the mapping protocol. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-02-11 16:51 Message: Logged In: YES user_id=21627 I think I would rather not to see this as a builtin, e.g. putting it into UserDict.AttrMap instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1110010&group_id=5470 From noreply at sourceforge.net Thu Oct 27 15:36:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Oct 2005 06:36:03 -0700 Subject: [ python-Bugs-1339045 ] Threading misbehavior with lambdas Message-ID: Bugs item #1339045, was opened at 2005-10-27 02:21 Message generated for change (Settings changed) made by fijal You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339045&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.4 >Status: Deleted Resolution: None Priority: 5 Submitted By: Maciek Fijalkowski (fijal) Assigned to: Nobody/Anonymous (nobody) Summary: Threading misbehavior with lambdas Initial Comment: suppose i write: def f(x): print x() for i in range(3): f ( lambda : i ) I got 0,1,2 But when I write for i in range(3): thread . start_new_thread ( f , ( lambda : i ) ) I got 2,2,2 Probably I don't get well design principles, but isn't it against thread consistency? (as long as threads does not interact with each other, interlace doesn't matter). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339045&group_id=5470 From noreply at sourceforge.net Thu Oct 27 17:36:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Oct 2005 08:36:49 -0700 Subject: [ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs Message-ID: Bugs item #1338995, was opened at 2005-10-27 03:08 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-27 19:36 Message: Logged In: YES user_id=4799 Yes, _safequote() call seems like a bug. A leftover after I've merged a half dozens of patches into this one. Should be removed. But there should certainly be no '&'. You certainly dont want to start lynx/links/elinks in the background, do you?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 From noreply at sourceforge.net Thu Oct 27 19:35:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Oct 2005 10:35:53 -0700 Subject: [ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs Message-ID: Bugs item #1338995, was opened at 2005-10-26 16:08 Message generated for change (Comment added) made by gregcouch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). ---------------------------------------------------------------------- >Comment By: Greg Couch (gregcouch) Date: 2005-10-27 10:35 Message: Logged In: YES user_id=131838 And I don't want starting up firefox to hang my python GUI either. So, if you look at the code more closely, lynx/links/elinks subclass from GenericBrowser not UnixBrowser, so adding the & to UnixBrowser is the correct thing to do. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-27 08:36 Message: Logged In: YES user_id=4799 Yes, _safequote() call seems like a bug. A leftover after I've merged a half dozens of patches into this one. Should be removed. But there should certainly be no '&'. You certainly dont want to start lynx/links/elinks in the background, do you?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 From noreply at sourceforge.net Thu Oct 27 20:33:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Oct 2005 11:33:51 -0700 Subject: [ python-Feature Requests-1309676 ] Add os.path.relpath Message-ID: Feature Requests item #1309676, was opened at 2005-09-30 20:38 Message generated for change (Comment added) made by rbarran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1309676&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: Add os.path.relpath Initial Comment: Add a method to os.path which calculates the "difference" of two paths. See this python-dev thread for details and sample implementations: http://mail.python.org/pipermail/python-dev/2005-September/056391.html ---------------------------------------------------------------------- Comment By: Richard Barran (rbarran) Date: 2005-10-27 20:33 Message: Logged In: YES user_id=1207189 Hi, Submitted a patch #1339796 to add this function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1309676&group_id=5470 From noreply at sourceforge.net Thu Oct 27 20:37:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Oct 2005 11:37:57 -0700 Subject: [ python-Bugs-1339806 ] CVS webbrowser.py (1.40) bugs Message-ID: Bugs item #1339806, was opened at 2005-10-27 11:37 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=1339806&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339806&group_id=5470 From noreply at sourceforge.net Thu Oct 27 20:43:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Oct 2005 11:43:29 -0700 Subject: [ python-Bugs-1339806 ] CVS webbrowser.py (1.40) bugs Message-ID: Bugs item #1339806, was opened at 2005-10-27 11:37 Message generated for change (Settings changed) made by gregcouch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339806&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Deleted >Resolution: Duplicate Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339806&group_id=5470 From noreply at sourceforge.net Thu Oct 27 21:29:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Oct 2005 12:29:35 -0700 Subject: [ python-Bugs-1338264 ] Memory keeping Message-ID: Bugs item #1338264, was opened at 2005-10-26 02:37 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338264&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: sin (sin_avatar) Assigned to: Nobody/Anonymous (nobody) Summary: Memory keeping Initial Comment: I execute this code on python 2.4.2 (authentic copy from console): Python 2.4.2 (#1, Oct 26 2005, 14:45:33) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> a = range(1,10000000) >>> del a before i type del - i run top and get (see console output below): 16300 sin 2 0 162M 161M poll 0:02 35.76% 9.28% python2.4 after del (console below): 16300 sin 2 0 162M 161M poll 0:03 7.18% 6.05% python2.4 I tried gc too ... but python didn't free memory. I checked this on windows - memory was freed, but interpreter with 0 defined variables "eat" about 75 Mb!. I think this is bug in interpereter core. some text from dmesg for you: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.8-RELEASE #0: Thu Apr 3 10:53:38 GMT 2003 root at freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/ GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (499.15-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x387f9ff real memory = 268369920 (262080K bytes) avail memory = 255901696 (249904K bytes) ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-10-27 12:29 Message: Logged In: YES user_id=341410 >From what I understand, whether or not the Python runtime "frees" memory (which can be freed) is generally dependant on platform malloc() and free(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338264&group_id=5470 From noreply at sourceforge.net Thu Oct 27 21:32:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Oct 2005 12:32:48 -0700 Subject: [ python-Bugs-1339045 ] Threading misbehavior with lambdas Message-ID: Bugs item #1339045, was opened at 2005-10-26 17:21 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339045&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: Python 2.4 Status: Deleted Resolution: None Priority: 5 Submitted By: Maciek Fijalkowski (fijal) Assigned to: Nobody/Anonymous (nobody) Summary: Threading misbehavior with lambdas Initial Comment: suppose i write: def f(x): print x() for i in range(3): f ( lambda : i ) I got 0,1,2 But when I write for i in range(3): thread . start_new_thread ( f , ( lambda : i ) ) I got 2,2,2 Probably I don't get well design principles, but isn't it against thread consistency? (as long as threads does not interact with each other, interlace doesn't matter). ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-10-27 12:32 Message: Logged In: YES user_id=341410 This is a bug in your understanding of lambdas, not in how threads work. More specifically, lambdas do late binding. By the time the threads have actually started executing and call the lambda, the name 'i' is bound to the value 2. If you need early binding, then you should bind early: for i in xrange(3): thread.start_new_thread(f, (lambda i=i:i)) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339045&group_id=5470 From noreply at sourceforge.net Thu Oct 27 21:38:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Oct 2005 12:38:23 -0700 Subject: [ python-Bugs-1313051 ] mac_roman codec missing "apple" codepoint Message-ID: Bugs item #1313051, was opened at 2005-10-04 09:37 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1313051&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Tony Nelson (tony_nelson) Assigned to: Nobody/Anonymous (nobody) Summary: mac_roman codec missing "apple" codepoint Initial Comment: The mac_roman codec is missing a single codepoint for the trademarked Apple logo (0xF0 <=> 0xF8FF per Apple docs), which prevents round-tripping of mac_roman text through Unicode. Adding the codepoint as a private encoding (per Apple) has no trademark implications, only the character itself, in a font, would have such issues. I'm using Python 2.3, but AFAICT it is an issue in later Python versions as well. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-10-27 12:38 Message: Logged In: YES user_id=341410 tony_nelson: Raising an exception during execution need not crash a user program, that's why Guido added try/except clauses into the language. You would be well advised to learn about and use them, as you will no doubt run into other exception-causing situations in the future. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-21 07:27 Message: Logged In: YES user_id=38388 This should be resolved with the new codec in CVS. ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2005-10-04 19:16 Message: Logged In: YES user_id=1356214 >Tony: Python is not damaging your data - the codec will >raise an exception in case that particular character is >converted to Unicode. Right, crashing the unsuspecting user's program and destroying the data utterly. Anyway, it doesn't damage /my/ data because I add the missing codepoint to the codec: # Fix missing Apple logo in mac_roman. import encodings.mac_roman if not encodings.mac_roman.decoding_map[0xF0]: encodings.mac_roman.decoding_map[0xF0] = 0xF8FF encodings.mac_roman.encoding_map[0xF8FF] = 0xF0 It just damages data for all the other users of the codec. >Please recreate the codec using gencodec.py (which you can >find the Tools/ directory) and add it as attachement to this >bug report. Thanks. Umm, I take it you want me to download a mapping file first. Here is a new mac_roman.py. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2005-10-04 14:48 Message: Logged In: YES user_id=38388 Tony, comment like yours are not very helpful. Python's codecs rely on facts defined by standards bodies, e.g. the Unicode consortium, ISO, etc.. If you don't present proof of your claim then there's nothing much we can do about your particular problem. Fortunately, proof isn't hard to find in this case: http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/ROMAN.TXT Looks like Apple added the mapping sometime after the codec was created. Walter: it is common for companies to add their logos as private Unicode characters. This happens a lot in the Asian world. Of course, interop isn't great, but at least you don't lose information by converting to Unicode. Tony: Python is not damaging your data - the codec will raise an exception in case that particular character is converted to Unicode. Please recreate the codec using gencodec.py (which you can find the Tools/ directory) and add it as attachement to this bug report. Thanks. ---------------------------------------------------------------------- Comment By: Tony Nelson (tony_nelson) Date: 2005-10-04 13:41 Message: Logged In: YES user_id=1356214 It isn't Python's job to tell people what characters they are allowed to use. Apple defined the codepoint and its mapping to Unicode. Python is not the Unicode Police, and should not damage the data it was given just to prove a point. Damaging the user's data isn't very "batteries included". ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2005-10-04 11:07 Message: Logged In: YES user_id=89016 The codepoint 0xF8FF is in the Private Use Area, so this is not an official Unicode character, and for other uses 0xF8FF might mean something completely different. So I think this mapping shouldn't be added to mac_roman. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1313051&group_id=5470 From noreply at sourceforge.net Thu Oct 27 21:38:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Oct 2005 12:38:53 -0700 Subject: [ python-Bugs-1338264 ] Memory keeping Message-ID: Bugs item #1338264, was opened at 2005-10-26 05:37 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338264&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: sin (sin_avatar) Assigned to: Nobody/Anonymous (nobody) Summary: Memory keeping Initial Comment: I execute this code on python 2.4.2 (authentic copy from console): Python 2.4.2 (#1, Oct 26 2005, 14:45:33) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> a = range(1,10000000) >>> del a before i type del - i run top and get (see console output below): 16300 sin 2 0 162M 161M poll 0:02 35.76% 9.28% python2.4 after del (console below): 16300 sin 2 0 162M 161M poll 0:03 7.18% 6.05% python2.4 I tried gc too ... but python didn't free memory. I checked this on windows - memory was freed, but interpreter with 0 defined variables "eat" about 75 Mb!. I think this is bug in interpereter core. some text from dmesg for you: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.8-RELEASE #0: Thu Apr 3 10:53:38 GMT 2003 root at freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/ GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (499.15-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x387f9ff real memory = 268369920 (262080K bytes) avail memory = 255901696 (249904K bytes) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-10-27 15:38 Message: Logged In: YES user_id=31435 Space for integer objects in particular lives in an immortal free list of unbounded size, so it's certain in the current implementation that doing range(10000000) will hang on to space for 10 million integers forever. If you don't want that, don't do that ;-) Iterating over xrange(10000000) instead will consume very little RAM. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-10-27 15:29 Message: Logged In: YES user_id=341410 >From what I understand, whether or not the Python runtime "frees" memory (which can be freed) is generally dependant on platform malloc() and free(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338264&group_id=5470 From noreply at sourceforge.net Thu Oct 27 21:41:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Oct 2005 12:41:32 -0700 Subject: [ python-Bugs-1339883 ] TAB SETTINGS DONT WORK (win) Message-ID: Bugs item #1339883, was opened at 2005-10-27 12:41 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=1339883&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: reson5 (reson5) Assigned to: Nobody/Anonymous (nobody) Summary: TAB SETTINGS DONT WORK (win) Initial Comment: Hi! I have downloaded newer version of Python and unfortunately the TAB settings in IDLE have no effect on the spaces inserted - ALWAYS 4 spaces. Previous release had the same problem. Win 2k, Python 2.4.2. Regards, Reson ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339883&group_id=5470 From noreply at sourceforge.net Fri Oct 28 07:19:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Oct 2005 22:19:23 -0700 Subject: [ python-Bugs-1193099 ] Embedded python thread crashes Message-ID: Bugs item #1193099, was opened at 2005-04-30 12:03 Message generated for change (Comment added) made by ugodiggi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193099&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: 3rd Party Status: Open Resolution: None Priority: 5 Submitted By: ugodiggi (ugodiggi) Assigned to: Nobody/Anonymous (nobody) Summary: Embedded python thread crashes Initial Comment: The following code crashes about 1/3 of the times. My platform is Python 2.4.1 on WXP (I tried the release version from the msi and the debug version built by me). I can reproduce the same behavior on another wxp system, under python 2.4. The crash happens (in the python thread) while the main thread is in Py_Finalize. I traced the crash to _Py_ForgetReference(op) in object.c at line 1847, where I have op->_ob_prev == NULL. The open file seems to be the issue, since if I remove all the references to the file I cannot get the program to crash. Cheers and ciao Ugo ////////////////////////// TestPyThreads.cpp ////////////////////////// #include // Sleep #include "Python.h" int main() { PyEval_InitThreads(); Py_Initialize(); PyGILState_STATE main_restore_state = PyGILState_UNLOCKED; PyGILState_Release(main_restore_state); // start the thread { PyGILState_STATE state = PyGILState_Ensure(); int trash = PyRun_SimpleString( "import thread\n" "import time\n" "def foo():\n" " f = open('pippo.out', 'w', 0)\n" " i = 0;\n" " while 1:\n" " f.write('%d\n'%i)\n" " time.sleep(0.01)\n" " i += 1\n" "t = thread.start_new_thread(foo, ())\n" ); PyGILState_Release(state); } // wait 300 ms Sleep(300); PyGILState_Ensure(); Py_Finalize(); return 0; } ---------------------------------------------------------------------- >Comment By: ugodiggi (ugodiggi) Date: 2005-10-27 22:19 Message: Logged In: YES user_id=1269908 I'm sorry I've been so late in answering. I don't have the time to investigate on the short term, and I'm very unfamiliar with python internals. I did do a fair amount of testing when I originally posted the item, including running with the 2.4.0 and 2.4.1 downloaded from python.org and 2.4.1 built by me in release and debug mode. I also tried on a different windows machine, running XP and 2.4.?. All were showing the same problem. I've followed the google thread and I don't think it's the same problem. My best guess is that this is caused by a leaked open file handle, that does not get closed correctly in the Py_Finalize call, but I'm not quite sure on how to follow this in the debugger. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-10 20:52 Message: Logged In: YES user_id=33168 Perhaps this is caused by different runtime DLLs. Here's what I googled for: site:mail.python.org windows python runtime dll crash See http://python.org/sf/1003535 Can you try to research more and see if you can come up with anything? (I don't run windows, so I can't test anything.) Do you get this problem with the version built from python.org or only with the version you built? ---------------------------------------------------------------------- Comment By: ugodiggi (ugodiggi) Date: 2005-10-06 00:29 Message: Logged In: YES user_id=1269908 Something changed on the computer I'm testing on, and the crash happens way less often (say 1/10 of the times in debug mode, and very rarely in Release mode). The compiler is MSVC7.1 on WXP, using Python 241 This is the stack of the main thread 7ffe0304() ntdll.dll!77f5b5d4() kernel32.dll!77e7a683() msvcr71d.dll!_close_lk(int fh=0x00000003) Line 115 + 0x4a C msvcr71d.dll!_close(int fh=0x00000003) Line 60 + 0x9 C msvcr71d.dll!_fclose_lk(_iobuf * str=0x1027c898) Line 127 + 0xc C msvcr71d.dll!fclose(_iobuf * stream=0x1027c898) Line 58 + 0x9 C > python24_d.dll!file_dealloc(PyFileObject * f=0x00919ec8) Line 308 + 0xd C python24_d.dll!_Py_Dealloc(_object * op=0x00919ec8) Line 1870 + 0x7 C python24_d.dll!frame_dealloc(_frame * f=0x00972960) Line 394 + 0x67 C python24_d.dll!_Py_Dealloc(_object * op=0x00972960) Line 1870 + 0x7 C python24_d.dll!PyThreadState_Clear(_ts * tstate=0x00892c88) Line 200 + 0x6c C python24_d.dll!PyInterpreterState_Clear(_is * interp=0x00894f48) Line 93 + 0x9 C python24_d.dll!Py_Finalize() Line 401 + 0x9 C TestPyThreads.exe!main() Line 33 + 0x8 C++ TestPyThreads.exe!mainCRTStartup() Line 259 + 0x19 C kernel32.dll!77e8141a() and this is the stack of the other thread (_threadstart) (the crash is here, where "if (frame->f_exc_type != NULL) " gets called with frame == NULL) > python24_d.dll!reset_exc_info(_ts * tstate=0x00892c88) Line 2861 + 0x3 C python24_d.dll!PyEval_EvalFrame(_frame * f=0x00972960) Line 2490 + 0x9 C python24_d.dll!PyEval_EvalCodeEx(PyCodeObject * co=0x00943ad0, _object * globals=0x008e3230, _object * locals=0x00000000, _object * * args=0x008c104c, int argcount=0x00000000, _object * * kws=0x00000000, int kwcount=0x00000000, _object * * defs=0x00000000, int defcount=0x00000000, _object * closure=0x00000000) Line 2730 + 0x9 C python24_d.dll!function_call(_object * func=0x009431f0, _object * arg=0x008c1038, _object * kw=0x00000000) Line 553 + 0x40 C python24_d.dll!PyObject_Call(_object * func=0x009431f0, _object * arg=0x008c1038, _object * kw=0x00000000) Line 1751 + 0xf C python24_d.dll!PyEval_CallObjectWithKeywords(_object * func=0x009431f0, _object * arg=0x008c1038, _object * kw=0x00000000) Line 3419 + 0x11 C python24_d.dll!t_bootstrap(void * boot_raw=0x008c8148) Line 433 + 0x1a C python24_d.dll!bootstrap(void * call=0x0012f694) Line 166 + 0x7 C msvcr71d.dll!_threadstart(void * ptd=0x009101a0) Line 196 + 0xd C kernel32.dll!77e7d28e() as you can see, the crash is also happening at a different place than what I had observed before, but I cannot find the stack that I had in that case. ---------------------------------------------------------------------- Comment By: ugodiggi (ugodiggi) Date: 2005-10-05 11:39 Message: Logged In: YES user_id=1269908 I would guess that the problem is going to be windows specific? I tested similar problem on both the debug and release build, and I did try to get some comment on comp.lang.python i.e. http://mail.python.org/pipermail/python-list/2005- April/278404.html my comment on the debugging was: > The crash happens while the main thread is in Py_Finalize. > I traced the crash to _Py_ForgetReference(op) in object.c at line 1847, > where I have op->_ob_prev == NULL. I did not look at the python code long enough to follow it. I will try to reproduce tonight and send out the stack - for whatever reason I'm not finding it any longer. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-03 22:37 Message: Logged In: YES user_id=33168 I can't reproduce on gentoo linux (amd64) with a debug build. I played with different values for sleep. BTW, it would be better if you attached the code as a file, since formatting is lost. Can you try to debug this problem? Can you attach info from the debugger? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193099&group_id=5470 From noreply at sourceforge.net Fri Oct 28 08:01:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Oct 2005 23:01:27 -0700 Subject: [ python-Bugs-1336623 ] tarfile can't extract some tar archives.. Message-ID: Bugs item #1336623, was opened at 2005-10-24 10:47 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1336623&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: A. Murat EREN (meren) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile can't extract some tar archives.. Initial Comment: Here is a small demo to reproduce the same problem: -----------------8<-----------------8<-----------------8<-----------------8<--- meren at pardus /home/meren $ wget ftp://ftp.sleepycat.com/releases/db.1.85.tar.gz (...) 100%[============>] 270,953 17.13K/s ETA 00:00 20:21:09 (15.25 KB/s) - `db.1.85.tar.gz' saved [270,953] meren at pardus /home/meren $ file db.1.85.tar.gz db.1.85.tar.gz: gzip compressed data, from Unix meren at pardus /home/meren $ python >>> tar = tarfile.open("db.1.85.tar.gz", "r:gz") >>> for tarinfo in tar: ... print tarinfo.name ... db.1.85 db.1.85/btree db.1.85/btree/Makefile.inc db.1.85/btree/bt_close.c db.1.85/btree/bt_conv.c db.1.85/btree/bt_debug.c db.1.85/btree/bt_delete.c db.1.85/btree/btree.h db.1.85/btree/bt_get.c db.1.85/btree/bt_open.c (...) >>> for tarinfo in tar: ... tar.extract(tarinfo) ... >>> Ctrl + D meren at pardus /home/meren $ ls db* db.1.85 db.1.85.tar.gz meren at pardus /home/meren $ file db.1.85 db.1.85: empty meren at pardus /home/meren $ cat db.1.85 meren at pardus /home/meren $ ----------------->8----------------->8----------------->8----------------->8--- Also this file is extracting with the same result too: ftp://ftp.linux.org.tr/pub/mirrors/gentoo/distfiles/ncompress-4.2.4.tar.gz This thing is very rarely happening, but it is happening. Also, I could extract these archives properly via the native 'tar' binary.. Thanks in advance, Ciao. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-27 23:01 Message: Logged In: YES user_id=33168 Committed revision 41340. Committed revision 41341. ---------------------------------------------------------------------- Comment By: A. Murat EREN (meren) Date: 2005-10-26 05:35 Message: Logged In: YES user_id=718263 thanks for the patch, it is just working. ---------------------------------------------------------------------- Comment By: Lars Gust?bel (gustaebel) Date: 2005-10-26 03:31 Message: Logged In: YES user_id=642936 I submitted patch #1338314 which fixes this problem. tarfile.py is aware of these "buggy" archives, but the workaround did not work anymore. Thank you for your report, especially for the vast number of test archives. ---------------------------------------------------------------------- Comment By: A. Murat EREN (meren) Date: 2005-10-25 11:58 Message: Logged In: YES user_id=718263 no files attached.. sorry, here it is.. ---------------------------------------------------------------------- Comment By: A. Murat EREN (meren) Date: 2005-10-25 11:36 Message: Logged In: YES user_id=718263 I figured out that this is a very pesky problem. The problem is coming from the tar archives themselves. Simply, the "tarinfo.isdir()" check in the library returns false for the directories and they are extracting like a regular file.. How did they create these fool archives I don't know, and I couldn't reproduce similar buggy archives by myself. It would be nice to know. Because of the problem is not in the python library, it is very difficult to implement an efficent workaround to properly extract this kind of buggy tar archives. I'm going to attach a dirty workaround to show the idea (is anyone reading these reports?).. Ciao.. ---------------------------------------------------------------------- Comment By: A. Murat EREN (meren) Date: 2005-10-24 11:19 Message: Logged In: YES user_id=718263 more examples: ftp://ftp.porcupine.org/pub/security/portmap_5beta.tar.gz ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6.tar.gz additionally, the same problem appearing when trying to extract these archives with the "ark" (yet another kde tool, just a simple front-end for the tar command. interesting, isn't it). Ciao. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1336623&group_id=5470 From noreply at sourceforge.net Fri Oct 28 08:48:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 27 Oct 2005 23:48:14 -0700 Subject: [ python-Bugs-1340337 ] time.strptime() with bad % code throws bad exception Message-ID: Bugs item #1340337, was opened at 2005-10-27 23:48 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=1340337&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Steve R. Hastings (steveha) Assigned to: Nobody/Anonymous (nobody) Summary: time.strptime() with bad % code throws bad exception Initial Comment: I am using Python 2.4.2, the latest version currently available for the system I am using, which is Ubuntu 5.10 for x86. I was calling the time.strptime() function, and I had accidentally typed an extra % symbol in the time format string. If you do this you get a baffling message in the traceback. The deepest frame of the traceback looks like this: File "/usr/lib/python2.4/_strptime.py", line 256, in pattern processed_format = "%s%s%s" % (processed_format, KeyError: '-' This means that I accidentally put "%-" in my format string. What happens if I accidentally put "% " in my format string? This: File "/usr/lib/python2.4/_strptime.py", line 256, in pattern processed_format = "%s%s%s" % (processed_format, KeyError: '\' It turns out that spaces in the format string are replaced by r'\s*' by the time the exception happens. It really freaked me out to see Python complaining about a backslash, when I hadn't put a backslash into my format string. I propose that this library call should be re-written to catch the exception, and then throw a more sensible exception, including a statement like: "unknown % code in format string". In a perfect world this would be done in such a way that the last frame appearing in the traceback would be for the call to time.strptime(), and not show any lines from the guts of time.strptime() about regular expression compiling. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1340337&group_id=5470 From noreply at sourceforge.net Fri Oct 28 11:46:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Oct 2005 02:46:06 -0700 Subject: [ python-Bugs-1337987 ] IDLE, F5 – wrong external file content. (on error!) Message-ID: Bugs item #1337987, was opened at 2005-10-26 04:12 Message generated for change (Comment added) made by tyrell_rr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337987&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: MvGulik (tyrell_rr) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE, F5 ? wrong external file content. (on error!) Initial Comment: IDLE, F5 ? wrong external file content on error. using: Python 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32 IDLE 1.0.5 , TK: 8.4 The basic problem is that when a external file is reloaded, by using F5, and that file contains a error. IDLE will tell about the error, and highlight the error, but its still using the old file content in its GUI window and not the newly reloaded file content. when: (IDLE GUI) - using F5 to reload and restart a external script. - new and changed script file containing a error. what: - display is showing previous script content. - error highlight is pointing at the wrong code. (bad!) how: first file: (create, load and execute) --- a = 1 print a --- change to: --- a = 1 print a : print a --- use F5 to auto reload and execute. Anything I'm doing wrong, or I can do locally to fix this?. just let me know. ps: upgrade to 2.4.x is not really a option in my case. (not yet at leased) Cheers M.v.Gulik ---------------------------------------------------------------------- >Comment By: MvGulik (tyrell_rr) Date: 2005-10-28 11:46 Message: Logged In: YES user_id=779309 > Save with Control-S before pressing F5. Don't think that a good idee. This will save the initially loaded old file content inside IDLE over the new file content (external edited -> not using IDLE for editing) Effectingly undoing all the changes done with the external editor. M.v.Gulik. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-26 04:45 Message: Logged In: YES user_id=80475 Save with Control-S before pressing F5. ---------------------------------------------------------------------- Comment By: MvGulik (tyrell_rr) Date: 2005-10-26 04:37 Message: Logged In: YES user_id=779309 huu, little update. the error itself is not part of the real (code)problem. ( it is of course when its leading to misleading debug info ) but the display of the external file in just not updated after using F5. with or without a error being triggerd. M.v.Gulik ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1337987&group_id=5470 From noreply at sourceforge.net Fri Oct 28 13:56:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Oct 2005 04:56:35 -0700 Subject: [ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs Message-ID: Bugs item #1338995, was opened at 2005-10-27 03:08 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-28 15:56 Message: Logged In: YES user_id=4799 No, I still think it is a bad idea to put a generic Unix browser to background by default. If you want to do it - do it explicitly. Start a browser in a background yourself, and use remote actions from the module to open new windows/tabs. Or register another browser, with different .open() and/or ._remote(). And, BTW, Elinks is a subclass of UnixBrowser, not GenericBrowser. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-27 21:35 Message: Logged In: YES user_id=131838 And I don't want starting up firefox to hang my python GUI either. So, if you look at the code more closely, lynx/links/elinks subclass from GenericBrowser not UnixBrowser, so adding the & to UnixBrowser is the correct thing to do. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-27 19:36 Message: Logged In: YES user_id=4799 Yes, _safequote() call seems like a bug. A leftover after I've merged a half dozens of patches into this one. Should be removed. But there should certainly be no '&'. You certainly dont want to start lynx/links/elinks in the background, do you?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 From noreply at sourceforge.net Fri Oct 28 14:21:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Oct 2005 05:21:40 -0700 Subject: [ python-Bugs-1289136 ] distutils extension library path bug on cygwin Message-ID: Bugs item #1289136, was opened at 2005-09-12 14:04 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289136&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Whitley (jwhitley) Assigned to: Nobody/Anonymous (nobody) Summary: distutils extension library path bug on cygwin Initial Comment: A while back I reported a problem on the Cygwin mailing list where all python extension packages would fail "python setup.py install" at the link step due to a mangled lib dir (-L) option. distutils was producing a link line with "-L.", instead of the desired "-L/usr/lib/python2.4/config". I've finally rooted out the cause of this problem. The relevant code is the if-block starting at line 188 of: /usr/lib/python2.4/distutils/command/build_ext.py I've reproduced that block here for clarity of discussion (indentation truncated for redability) if sys.platform[:6] == 'cygwin' or sys.platform[:6] == 'atheos': if string.find(sys.executable, sys.exec_prefix) != -1: # building third party extensions self.library_dirs.append(os.path.join(sys.prefix, "lib", "python" + get_python_version(), "config")) else: # building python standard extensions self.library_dirs.append('.') The test "string.find(...) != -1" attempts to test whether "/usr" appears in the full executable name. This incorrectly fails in the case that /bin is in the user's path before /usr/bin. (i.e. string.find("/bin/python","/usr") == -1) Note that a vagary of Cygwin is that /usr/bin is a Cygwin mount to /bin. The user-side workaround is to ensure that /usr/bin appears in your path before /bin. It looks like a new and improved Cygwin special case test is needed to fix this problem; I'm not sure offhand what the best case would be. Perhaps an outright test as follows would work: sys.executable.startswith(sys.exec_prefix) or sys.executable.startswith(os.sep+"bin") ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2005-10-28 04:21 Message: Logged In: YES user_id=86216 Unfortunately, I don't think readlink will help. I was thinking of comparing inodes, but AFAICT inodes under Cygwin are not guaranteed to be unique for all platforms and filesystems. So, maybe John's check is the only reliable option? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-23 18:47 Message: Logged In: YES user_id=33168 What does os.readlink(sys.executable) return? Maybe that will help you find the true canonical name? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2005-09-16 04:04 Message: Logged In: YES user_id=86216 John, Thanks for the excellent analysis! All, Unfortunately, I'm not sure what is the best way to solve this problem. Does anyone have any suggestions? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289136&group_id=5470 From noreply at sourceforge.net Fri Oct 28 14:28:35 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Oct 2005 05:28:35 -0700 Subject: [ python-Bugs-1298709 ] _socket module not build under cygwin Message-ID: Bugs item #1298709, was opened at 2005-09-22 04:59 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298709&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Jason Tishler (jlt63) Summary: _socket module not build under cygwin Initial Comment: Hello, Bulding Python-2.4.2c1 under cygwin gives the following: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fno-strict-aliasing -I. -I/home/mtebeka/src/Python-2.4.2c1/./Include -I/home/mtebeka/src/Python-2.4.2c1/Include -I/home/mtebeka/src/Python-2.4.2c1 -c /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c -o build/temp.cygwin-1.5.18-i686-2.4/socketmodule.o /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c: In function `socket_inet_ntop': /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: `INET_ADDRSTRLEN' undeclared (first use in this function) /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: (Each undeclared identifier is reported only once /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: error: for each function it appears in.) /home/mtebeka/src/Python-2.4.2c1/Modules/socketmodule.c:3351: warning: unused variable `ip' ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2005-10-28 04:28 Message: Logged In: YES user_id=86216 No news is good news, so I'm closing this bug report. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2005-09-23 03:18 Message: Logged In: YES user_id=86216 This is a known Cygwin issues which will be fixed in 1.5.19: http://cygwin.com/ml/cygwin/2005-07/msg01257.html I recommend that Cygwin users temporarily patch their netinet/in.h instead of changing the Python source code. And yes, I still maintain Cygwin Python. :,) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 20:56 Message: Logged In: YES user_id=33168 Patch is also #1275079. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-22 20:31 Message: Logged In: YES user_id=33168 Jason, are you still working on Cygwin issues? ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2005-09-22 05:22 Message: Logged In: YES user_id=358087 The problem can be sloved by adding the following lines in socketmodule.c beginning. /* FIXME: We should include ws2tcpip.h, however this causes compilation problems */ #if defined(__CYGWIN__) #define INET_ADDRSTRLEN 16 #define INET6_ADDRSTRLEN 46 #endif /* __CYGWIN__ */ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1298709&group_id=5470 From noreply at sourceforge.net Fri Oct 28 19:29:37 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Oct 2005 10:29:37 -0700 Subject: [ python-Bugs-1289136 ] distutils extension library path bug on cygwin Message-ID: Bugs item #1289136, was opened at 2005-09-12 15:04 Message generated for change (Comment added) made by jwhitley You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289136&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Whitley (jwhitley) Assigned to: Nobody/Anonymous (nobody) Summary: distutils extension library path bug on cygwin Initial Comment: A while back I reported a problem on the Cygwin mailing list where all python extension packages would fail "python setup.py install" at the link step due to a mangled lib dir (-L) option. distutils was producing a link line with "-L.", instead of the desired "-L/usr/lib/python2.4/config". I've finally rooted out the cause of this problem. The relevant code is the if-block starting at line 188 of: /usr/lib/python2.4/distutils/command/build_ext.py I've reproduced that block here for clarity of discussion (indentation truncated for redability) if sys.platform[:6] == 'cygwin' or sys.platform[:6] == 'atheos': if string.find(sys.executable, sys.exec_prefix) != -1: # building third party extensions self.library_dirs.append(os.path.join(sys.prefix, "lib", "python" + get_python_version(), "config")) else: # building python standard extensions self.library_dirs.append('.') The test "string.find(...) != -1" attempts to test whether "/usr" appears in the full executable name. This incorrectly fails in the case that /bin is in the user's path before /usr/bin. (i.e. string.find("/bin/python","/usr") == -1) Note that a vagary of Cygwin is that /usr/bin is a Cygwin mount to /bin. The user-side workaround is to ensure that /usr/bin appears in your path before /bin. It looks like a new and improved Cygwin special case test is needed to fix this problem; I'm not sure offhand what the best case would be. Perhaps an outright test as follows would work: sys.executable.startswith(sys.exec_prefix) or sys.executable.startswith(os.sep+"bin") ---------------------------------------------------------------------- >Comment By: John Whitley (jwhitley) Date: 2005-10-28 10:29 Message: Logged In: YES user_id=649097 Jason is correct that readlink won't help. On Cygwin installations, /bin and /usr/bin are not symlinks, they're aliases in Cygwin's default mount system. (C:\cygwin on / (root) and C:\cygwin\bin on /usr/bin) The Python 2.4.1 docs says: "readlink(path) Return a string representing the path to which the symbolic link points." For good measure, I confirmed that readlink doesn't give the desired results. The bigger problem that I see is that this code is using hard-coded automagic path detection to figure out something that it should be told explicitly. That is, "are we in the special case of building python's own libraries/extensions." (versus trying to install an extension to an existing python installation.) To illustrate the problem, both my proposal and the original code are broken for trying to build python in /usr/local. (e.g. build under /usr/local/src -- thinks it's an install not a build due to "/usr" prefix...) ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2005-10-28 05:21 Message: Logged In: YES user_id=86216 Unfortunately, I don't think readlink will help. I was thinking of comparing inodes, but AFAICT inodes under Cygwin are not guaranteed to be unique for all platforms and filesystems. So, maybe John's check is the only reliable option? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-23 19:47 Message: Logged In: YES user_id=33168 What does os.readlink(sys.executable) return? Maybe that will help you find the true canonical name? ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2005-09-16 05:04 Message: Logged In: YES user_id=86216 John, Thanks for the excellent analysis! All, Unfortunately, I'm not sure what is the best way to solve this problem. Does anyone have any suggestions? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1289136&group_id=5470 From noreply at sourceforge.net Fri Oct 28 20:49:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Oct 2005 11:49:23 -0700 Subject: [ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs Message-ID: Bugs item #1338995, was opened at 2005-10-26 16:08 Message generated for change (Comment added) made by gregcouch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). ---------------------------------------------------------------------- >Comment By: Greg Couch (gregcouch) Date: 2005-10-28 11:49 Message: Logged In: YES user_id=131838 So you really want to change existing practice and break all Python GUI programs that invoke webbrowser.open? And the Elinks example proves my point. What is the point of it being a UnixBrowser, in the terminal window, if you can't send remote commands to it (because the Python GUI application is blocked until the browser exits)? Tty-based browsers are nice for completeness, but are really a last resort for a Python application, and imply that no windowing system is available (i.e, remotely logged in and not forwarding X connections, so not running GUI applications either). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-28 04:56 Message: Logged In: YES user_id=4799 No, I still think it is a bad idea to put a generic Unix browser to background by default. If you want to do it - do it explicitly. Start a browser in a background yourself, and use remote actions from the module to open new windows/tabs. Or register another browser, with different .open() and/or ._remote(). And, BTW, Elinks is a subclass of UnixBrowser, not GenericBrowser. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-27 10:35 Message: Logged In: YES user_id=131838 And I don't want starting up firefox to hang my python GUI either. So, if you look at the code more closely, lynx/links/elinks subclass from GenericBrowser not UnixBrowser, so adding the & to UnixBrowser is the correct thing to do. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-27 08:36 Message: Logged In: YES user_id=4799 Yes, _safequote() call seems like a bug. A leftover after I've merged a half dozens of patches into this one. Should be removed. But there should certainly be no '&'. You certainly dont want to start lynx/links/elinks in the background, do you?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 From noreply at sourceforge.net Fri Oct 28 22:26:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Oct 2005 13:26:49 -0700 Subject: [ python-Bugs-1341031 ] mmap does not accept length as 0 Message-ID: Bugs item #1341031, was opened at 2005-10-28 15:26 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=1341031&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: liturgist (liturgist) Assigned to: Nobody/Anonymous (nobody) Summary: mmap does not accept length as 0 Initial Comment: Creating an mmap object does not accept a length parameter of zero on Linux FC4 and Cygwin. However, it does on Windows XP. $ ls -al t.dat -rw-r--r-- 1 pwatson mkgroup-l-d 64 Oct 28 10:13 t.dat $ python Python 2.4.1 (#1, May 27 2005, 18:02:40) [GCC 3.3.3 (cygwin special)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import mmap >>> fp = open('t.dat', 'rb') >>> b = mmap.mmap(fp.fileno(), 0, access=mmap.ACCESS_READ) Traceback (most recent call last): File "", line 1, in ? EnvironmentError: [Errno 22] Invalid argument >>> b = mmap.mmap(fp.fileno(), 64, access=mmap.ACCESS_READ) >>> b.size() 64 ===== $ ls -al .profile -rwxrwxr-x 1 pwatson pwatson 1920 Jul 22 06:57 .profile $ python Python 2.4.1 (#1, Jul 19 2005, 14:16:43) [GCC 4.0.0 20050519 (Red Hat 4.0.0-8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import mmap >>> fp = open('.profile', 'rb') >>> b = mmap.mmap(fp.fileno(), 0, access=mmap.ACCESS_READ) Traceback (most recent call last): File "", line 1, in ? EnvironmentError: [Errno 22] Invalid argument >>> b = mmap.mmap(fp.fileno(), 1920, access=mmap.ACCESS_READ) >>> b.size() 1920 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1341031&group_id=5470 From noreply at sourceforge.net Fri Oct 28 23:09:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Oct 2005 14:09:57 -0700 Subject: [ python-Bugs-1341031 ] mmap does not accept length as 0 Message-ID: Bugs item #1341031, was opened at 2005-10-28 15:26 Message generated for change (Comment added) made by liturgist You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1341031&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library >Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: liturgist (liturgist) Assigned to: Nobody/Anonymous (nobody) Summary: mmap does not accept length as 0 Initial Comment: Creating an mmap object does not accept a length parameter of zero on Linux FC4 and Cygwin. However, it does on Windows XP. $ ls -al t.dat -rw-r--r-- 1 pwatson mkgroup-l-d 64 Oct 28 10:13 t.dat $ python Python 2.4.1 (#1, May 27 2005, 18:02:40) [GCC 3.3.3 (cygwin special)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import mmap >>> fp = open('t.dat', 'rb') >>> b = mmap.mmap(fp.fileno(), 0, access=mmap.ACCESS_READ) Traceback (most recent call last): File "", line 1, in ? EnvironmentError: [Errno 22] Invalid argument >>> b = mmap.mmap(fp.fileno(), 64, access=mmap.ACCESS_READ) >>> b.size() 64 ===== $ ls -al .profile -rwxrwxr-x 1 pwatson pwatson 1920 Jul 22 06:57 .profile $ python Python 2.4.1 (#1, Jul 19 2005, 14:16:43) [GCC 4.0.0 20050519 (Red Hat 4.0.0-8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import mmap >>> fp = open('.profile', 'rb') >>> b = mmap.mmap(fp.fileno(), 0, access=mmap.ACCESS_READ) Traceback (most recent call last): File "", line 1, in ? EnvironmentError: [Errno 22] Invalid argument >>> b = mmap.mmap(fp.fileno(), 1920, access=mmap.ACCESS_READ) >>> b.size() 1920 ---------------------------------------------------------------------- >Comment By: liturgist (liturgist) Date: 2005-10-28 16:09 Message: Logged In: YES user_id=197677 It would be helpful to creating cross-platform code for all platforms to have the same requirements. If this is marked as Not-A-Bug, then how about changing it to a documentation bug so that and example could be provided? fp = open(fn, 'rb') b = mmap.mmap(fp.fileno(), os.stat(fp.name).st_size, access=mmap.ACCESS_READ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1341031&group_id=5470 From noreply at sourceforge.net Sat Oct 29 01:12:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Oct 2005 16:12:56 -0700 Subject: [ python-Bugs-1341031 ] mmap does not accept length as 0 Message-ID: Bugs item #1341031, was opened at 2005-10-28 15:26 Message generated for change (Settings changed) made by liturgist You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1341031&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: liturgist (liturgist) Assigned to: Nobody/Anonymous (nobody) Summary: mmap does not accept length as 0 Initial Comment: Creating an mmap object does not accept a length parameter of zero on Linux FC4 and Cygwin. However, it does on Windows XP. $ ls -al t.dat -rw-r--r-- 1 pwatson mkgroup-l-d 64 Oct 28 10:13 t.dat $ python Python 2.4.1 (#1, May 27 2005, 18:02:40) [GCC 3.3.3 (cygwin special)] on cygwin Type "help", "copyright", "credits" or "license" for more information. >>> import mmap >>> fp = open('t.dat', 'rb') >>> b = mmap.mmap(fp.fileno(), 0, access=mmap.ACCESS_READ) Traceback (most recent call last): File "", line 1, in ? EnvironmentError: [Errno 22] Invalid argument >>> b = mmap.mmap(fp.fileno(), 64, access=mmap.ACCESS_READ) >>> b.size() 64 ===== $ ls -al .profile -rwxrwxr-x 1 pwatson pwatson 1920 Jul 22 06:57 .profile $ python Python 2.4.1 (#1, Jul 19 2005, 14:16:43) [GCC 4.0.0 20050519 (Red Hat 4.0.0-8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import mmap >>> fp = open('.profile', 'rb') >>> b = mmap.mmap(fp.fileno(), 0, access=mmap.ACCESS_READ) Traceback (most recent call last): File "", line 1, in ? EnvironmentError: [Errno 22] Invalid argument >>> b = mmap.mmap(fp.fileno(), 1920, access=mmap.ACCESS_READ) >>> b.size() 1920 ---------------------------------------------------------------------- Comment By: liturgist (liturgist) Date: 2005-10-28 16:09 Message: Logged In: YES user_id=197677 It would be helpful to creating cross-platform code for all platforms to have the same requirements. If this is marked as Not-A-Bug, then how about changing it to a documentation bug so that and example could be provided? fp = open(fn, 'rb') b = mmap.mmap(fp.fileno(), os.stat(fp.name).st_size, access=mmap.ACCESS_READ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1341031&group_id=5470 From noreply at sourceforge.net Sat Oct 29 06:10:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 28 Oct 2005 21:10:45 -0700 Subject: [ python-Bugs-1340337 ] time.strptime() with bad % code throws bad exception Message-ID: Bugs item #1340337, was opened at 2005-10-27 23:48 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1340337&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Steve R. Hastings (steveha) >Assigned to: Brett Cannon (bcannon) Summary: time.strptime() with bad % code throws bad exception Initial Comment: I am using Python 2.4.2, the latest version currently available for the system I am using, which is Ubuntu 5.10 for x86. I was calling the time.strptime() function, and I had accidentally typed an extra % symbol in the time format string. If you do this you get a baffling message in the traceback. The deepest frame of the traceback looks like this: File "/usr/lib/python2.4/_strptime.py", line 256, in pattern processed_format = "%s%s%s" % (processed_format, KeyError: '-' This means that I accidentally put "%-" in my format string. What happens if I accidentally put "% " in my format string? This: File "/usr/lib/python2.4/_strptime.py", line 256, in pattern processed_format = "%s%s%s" % (processed_format, KeyError: '\' It turns out that spaces in the format string are replaced by r'\s*' by the time the exception happens. It really freaked me out to see Python complaining about a backslash, when I hadn't put a backslash into my format string. I propose that this library call should be re-written to catch the exception, and then throw a more sensible exception, including a statement like: "unknown % code in format string". In a perfect world this would be done in such a way that the last frame appearing in the traceback would be for the call to time.strptime(), and not show any lines from the guts of time.strptime() about regular expression compiling. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1340337&group_id=5470 From noreply at sourceforge.net Sat Oct 29 10:01:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 29 Oct 2005 01:01:56 -0700 Subject: [ python-Bugs-1324799 ] Curses module doesn't install on Solaris 2.8 Message-ID: Bugs item #1324799, was opened at 2005-10-12 12:21 Message generated for change (Comment added) made by narzola You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1324799&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Koenig (arkoenig) Assigned to: Nobody/Anonymous (nobody) Summary: Curses module doesn't install on Solaris 2.8 Initial Comment: During installation, the following happens: building '_curses' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC - fno-strict-aliasing -I. -I/tmp/build-gnu20746/Python- 2.4.2/./Include -I/usr/gnu/include -I/usr/local/include - I/tmp/build-gnu20746/Python-2.4.2/Include -I/tmp/build- gnu20746/Python-2.4.2 -c /tmp/build-gnu20746/Python- 2.4.2/Modules/_cursesmodule.c -o build/temp.solaris-2.8- sun4u-2.4/_cursesmodule.o /tmp/build-gnu20746/Python- 2.4.2/Modules/_cursesmodule.c: In function 'PyCursesWindow_GetStr': /tmp/build-gnu20746/Python- 2.4.2/Modules/_cursesmodule.c:822: warning: implicit declaration of function 'mvwgetnstr' gcc -shared build/temp.solaris-2.8-sun4u- 2.4/_cursesmodule.o -L/usr/gnu/lib -L/usr/local/lib -lcurses - ltermcap -o build/lib.solaris-2.8-sun4u-2.4/_curses.so *** WARNING: renaming "_curses" since importing it failed: ld.so.1: ./python: fatal: relocation error: file build/lib.solaris-2.8-sun4u-2.4/_curses.so: symbol mvwgetnstr: referenced symbol not found building '_curses_panel' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC - fno-strict-aliasing -I. -I/tmp/build-gnu20746/Python- 2.4.2/./Include -I/usr/gnu/include -I/usr/local/include - I/tmp/build-gnu20746/Python-2.4.2/Include -I/tmp/build- gnu20746/Python-2.4.2 -c /tmp/build-gnu20746/Python- 2.4.2/Modules/_curses_panel.c -o build/temp.solaris-2.8- sun4u-2.4/_curses_panel.o gcc -shared build/temp.solaris-2.8-sun4u- 2.4/_curses_panel.o -L/usr/gnu/lib -L/usr/local/lib -lpanel - lcurses -ltermcap -o build/lib.solaris-2.8-sun4u- 2.4/_curses_panel.so *** WARNING: renaming "_curses_panel" since importing it failed: No module named _curses ---------------------------------------------------------------------- Comment By: Nelson Arzola (narzola) Date: 2005-10-29 08:01 Message: Logged In: YES user_id=39023 I would like to add that this problem also exists under Solaris 2.10. For some reason, mvwgetnstr is not defined under Solaris 10. When I use nm to get the symbols out of /usr/lib/libcurses.so.1, I do not find it. When I replace the two references in /dsk/data0/build/Python-2.4.2/Modules/_cursesmodule.c from mvwgetnstr to mvwgetnwstr, I was able to compile the module and pass the appropriate tests. Since I don't use curses, I really don't have a good way to test this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1324799&group_id=5470 From noreply at sourceforge.net Sat Oct 29 23:29:33 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 29 Oct 2005 14:29:33 -0700 Subject: [ python-Bugs-1341934 ] "\n" is incorrectly represented Message-ID: Bugs item #1341934, was opened at 2005-10-30 01:29 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=1341934&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Pavel (psut) Assigned to: Nobody/Anonymous (nobody) Summary: "\n" is incorrectly represented Initial Comment: here: http://python.org/doc/2.4.2/lib/dom-objects.html
is inserted incorretly. ================ newl specifies the string emitted at the end of each line and defaults to
n. ================ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1341934&group_id=5470 From noreply at sourceforge.net Sun Oct 30 04:06:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 29 Oct 2005 20:06:09 -0700 Subject: [ python-Bugs-1341934 ] "\n" is incorrectly represented Message-ID: Bugs item #1341934, was opened at 2005-10-30 06:29 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1341934&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.4 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Pavel (psut) Assigned to: Nobody/Anonymous (nobody) Summary: "\n" is incorrectly represented Initial Comment: here: http://python.org/doc/2.4.2/lib/dom-objects.html
is inserted incorretly. ================ newl specifies the string emitted at the end of each line and defaults to
n. ================ ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2005-10-30 12:06 Message: Logged In: YES user_id=55188 Committed in 41354. Thank you! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1341934&group_id=5470 From noreply at sourceforge.net Sun Oct 30 22:49:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Oct 2005 13:49:23 -0800 Subject: [ python-Bugs-1342811 ] Tkinter.Menu.delete doesn't delete command of entry Message-ID: Bugs item #1342811, was opened at 2005-10-30 22:49 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=1342811&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Sverker Nilsson (svenil) Assigned to: Martin v. L?wis (loewis) Summary: Tkinter.Menu.delete doesn't delete command of entry Initial Comment: Tkinter.Menu.delete does not delete the commands defined for the entries it deletes. Those objects will be retained until the menu itself is deleted. For example, after code like this: button = Menubutton(root, text='Window') menu = Menu(button) button['menu'] = menu def command(): print 'command button pressed' menu.add_command(command=command) menu.delete(END) del command the command function will still be referenced and kept in memory - until the menu object itself is destroyed. This may not always be a serious problem, but in my case the menu was a 'Window' menu and the command was a method on a window top level widget, so retaining a pointer to it after deleting the menu entry kept a reference to that entire window, with any associated data. I have figured out a possible fix that is in the attached file test_menuleak.py that contains some test functions. I also changed the comment - for as far as I can see, the second optional index is actually INCLUDED in the range of entries deleted. Version info Python 2.3.3 (#2, Mar 11 2004, 19:45:43) [GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2 I think it applies to all versions: I tested with the latest 2.4.2 as well. Sverker Nilsson ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1342811&group_id=5470 From noreply at sourceforge.net Mon Oct 31 07:15:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Oct 2005 22:15:12 -0800 Subject: [ python-Bugs-1338264 ] Memory keeping Message-ID: Bugs item #1338264, was opened at 2005-10-26 15:37 Message generated for change (Comment added) made by sin_avatar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338264&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: sin (sin_avatar) Assigned to: Nobody/Anonymous (nobody) Summary: Memory keeping Initial Comment: I execute this code on python 2.4.2 (authentic copy from console): Python 2.4.2 (#1, Oct 26 2005, 14:45:33) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> a = range(1,10000000) >>> del a before i type del - i run top and get (see console output below): 16300 sin 2 0 162M 161M poll 0:02 35.76% 9.28% python2.4 after del (console below): 16300 sin 2 0 162M 161M poll 0:03 7.18% 6.05% python2.4 I tried gc too ... but python didn't free memory. I checked this on windows - memory was freed, but interpreter with 0 defined variables "eat" about 75 Mb!. I think this is bug in interpereter core. some text from dmesg for you: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.8-RELEASE #0: Thu Apr 3 10:53:38 GMT 2003 root at freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/ GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (499.15-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x387f9ff real memory = 268369920 (262080K bytes) avail memory = 255901696 (249904K bytes) ---------------------------------------------------------------------- >Comment By: sin (sin_avatar) Date: 2005-10-31 11:15 Message: Logged In: YES user_id=1368129 Certainly, i 'am not a C guru, but i uderstood - if interpreter keep more than 100Mb, and not keep useful information - it's suxx. Fore example if i use my script as a part Zope portal - it would be awful. Certainly my script was just example - but if i use mult-thread server wrote on python and create list in each thread - i would take memory from system and i cannot give it back. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-10-28 01:38 Message: Logged In: YES user_id=31435 Space for integer objects in particular lives in an immortal free list of unbounded size, so it's certain in the current implementation that doing range(10000000) will hang on to space for 10 million integers forever. If you don't want that, don't do that ;-) Iterating over xrange(10000000) instead will consume very little RAM. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-10-28 01:29 Message: Logged In: YES user_id=341410 >From what I understand, whether or not the Python runtime "frees" memory (which can be freed) is generally dependant on platform malloc() and free(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338264&group_id=5470 From noreply at sourceforge.net Mon Oct 31 07:56:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 30 Oct 2005 22:56:07 -0800 Subject: [ python-Bugs-1338264 ] Memory keeping Message-ID: Bugs item #1338264, was opened at 2005-10-26 02:37 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338264&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: sin (sin_avatar) Assigned to: Nobody/Anonymous (nobody) Summary: Memory keeping Initial Comment: I execute this code on python 2.4.2 (authentic copy from console): Python 2.4.2 (#1, Oct 26 2005, 14:45:33) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> a = range(1,10000000) >>> del a before i type del - i run top and get (see console output below): 16300 sin 2 0 162M 161M poll 0:02 35.76% 9.28% python2.4 after del (console below): 16300 sin 2 0 162M 161M poll 0:03 7.18% 6.05% python2.4 I tried gc too ... but python didn't free memory. I checked this on windows - memory was freed, but interpreter with 0 defined variables "eat" about 75 Mb!. I think this is bug in interpereter core. some text from dmesg for you: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.8-RELEASE #0: Thu Apr 3 10:53:38 GMT 2003 root at freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/ GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (499.15-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x387f9ff real memory = 268369920 (262080K bytes) avail memory = 255901696 (249904K bytes) ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-10-30 22:56 Message: Logged In: YES user_id=341410 Suggested close because and/or: a) not a bug (integer freelists) b) platform specific malloc/free behavior on the list->ob_item member (some platforms will drop to 121M allocated memory after the deletion) c) OP didn't listen when it was suggested they use xrange() instead of range() ---------------------------------------------------------------------- Comment By: sin (sin_avatar) Date: 2005-10-30 22:15 Message: Logged In: YES user_id=1368129 Certainly, i 'am not a C guru, but i uderstood - if interpreter keep more than 100Mb, and not keep useful information - it's suxx. Fore example if i use my script as a part Zope portal - it would be awful. Certainly my script was just example - but if i use mult-thread server wrote on python and create list in each thread - i would take memory from system and i cannot give it back. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-10-27 12:38 Message: Logged In: YES user_id=31435 Space for integer objects in particular lives in an immortal free list of unbounded size, so it's certain in the current implementation that doing range(10000000) will hang on to space for 10 million integers forever. If you don't want that, don't do that ;-) Iterating over xrange(10000000) instead will consume very little RAM. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-10-27 12:29 Message: Logged In: YES user_id=341410 >From what I understand, whether or not the Python runtime "frees" memory (which can be freed) is generally dependant on platform malloc() and free(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338264&group_id=5470 From noreply at sourceforge.net Mon Oct 31 10:06:05 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Oct 2005 01:06:05 -0800 Subject: [ python-Bugs-1338264 ] Memory keeping Message-ID: Bugs item #1338264, was opened at 2005-10-26 15:37 Message generated for change (Comment added) made by sin_avatar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338264&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: sin (sin_avatar) Assigned to: Nobody/Anonymous (nobody) Summary: Memory keeping Initial Comment: I execute this code on python 2.4.2 (authentic copy from console): Python 2.4.2 (#1, Oct 26 2005, 14:45:33) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> a = range(1,10000000) >>> del a before i type del - i run top and get (see console output below): 16300 sin 2 0 162M 161M poll 0:02 35.76% 9.28% python2.4 after del (console below): 16300 sin 2 0 162M 161M poll 0:03 7.18% 6.05% python2.4 I tried gc too ... but python didn't free memory. I checked this on windows - memory was freed, but interpreter with 0 defined variables "eat" about 75 Mb!. I think this is bug in interpereter core. some text from dmesg for you: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.8-RELEASE #0: Thu Apr 3 10:53:38 GMT 2003 root at freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/ GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (499.15-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x387f9ff real memory = 268369920 (262080K bytes) avail memory = 255901696 (249904K bytes) ---------------------------------------------------------------------- >Comment By: sin (sin_avatar) Date: 2005-10-31 14:06 Message: Logged In: YES user_id=1368129 One more time. >>> a = [1 for i in xrange(10000000)] >>> del a This code clear - and this not raise "memory keeping"(!) >>> a = [i for i in xrange(10000000)] >>> del a But this code take about 163 Mb on my freeBSD. I can't udestood why you don't care about this? P.S. somebody explain me phrase "a) not a bug (integer freelists)" ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-10-31 11:56 Message: Logged In: YES user_id=341410 Suggested close because and/or: a) not a bug (integer freelists) b) platform specific malloc/free behavior on the list->ob_item member (some platforms will drop to 121M allocated memory after the deletion) c) OP didn't listen when it was suggested they use xrange() instead of range() ---------------------------------------------------------------------- Comment By: sin (sin_avatar) Date: 2005-10-31 11:15 Message: Logged In: YES user_id=1368129 Certainly, i 'am not a C guru, but i uderstood - if interpreter keep more than 100Mb, and not keep useful information - it's suxx. Fore example if i use my script as a part Zope portal - it would be awful. Certainly my script was just example - but if i use mult-thread server wrote on python and create list in each thread - i would take memory from system and i cannot give it back. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-10-28 01:38 Message: Logged In: YES user_id=31435 Space for integer objects in particular lives in an immortal free list of unbounded size, so it's certain in the current implementation that doing range(10000000) will hang on to space for 10 million integers forever. If you don't want that, don't do that ;-) Iterating over xrange(10000000) instead will consume very little RAM. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-10-28 01:29 Message: Logged In: YES user_id=341410 >From what I understand, whether or not the Python runtime "frees" memory (which can be freed) is generally dependant on platform malloc() and free(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338264&group_id=5470 From noreply at sourceforge.net Mon Oct 31 12:31:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Oct 2005 03:31:00 -0800 Subject: [ python-Bugs-1343671 ] Broken docs for os.removedirs Message-ID: Bugs item #1343671, was opened at 2005-10-31 12:30 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=1343671&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David K?gedal (d_kagedal) Assigned to: Nobody/Anonymous (nobody) Summary: Broken docs for os.removedirs Initial Comment: The documentation for the os.removedirs function is seriously broken. This is from the library reference: "removedirs(path) Removes directories recursively. Works like rmdir() except that, if the leaf directory is successfully removed, directories corresponding to rightmost path segments will be pruned way until either the whole path is consumed or an error is raised (which is ignored, because it generally means that a parent directory is not empty). Throws an error exception if the leaf directory could not be successfully removed. New in version 1.5.2." The first sentence is the only part that makes any sense. This shorter version contains as much information and less misinformation" "removedirs(path) Removes a directory and everything in it recursively. If a file couldn't be removed, the removal is aborted and you might get an exception if you're lucky." The doc string you get when you type "help(os.removedirs)" is different from the one in the library reference, but equally broken. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1343671&group_id=5470 From noreply at sourceforge.net Mon Oct 31 14:11:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Oct 2005 05:11:51 -0800 Subject: [ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs Message-ID: Bugs item #1338995, was opened at 2005-10-27 03:08 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-31 16:11 Message: Logged In: YES user_id=4799 Yes, I want. Current practice of running a browser in the background by default is deadly broken. The old code of webbrowser.py is full of dirty hacks. Look at Netscape._remote(). It tries to start a browser to send a remote command; if that fails it tries to start the browser in the background, waits an arbitrary number of seconds (why this? why not less? why not more?) and without testing if the browser in the background was started it retries sending the remote command. You can never know if the browser was started and if the command was sent becuase .open() does not return a result code. At the global level the bug is that webbrowser.py doesn't tri all browsers in the tryorder - it only concentrates on the first it found in PATH. What if the brwoser cannot be started (damaged disk image; wrong DISAPLY; wrong xhost/xauth permissions)? My patched webbrowser.py is much safer. It runs all browsers in the tryorder until it finds one that can be started. One doesn't need to wait a random number of seconds, too little for slow systems, too many for fast. .open() returns a success/fail status (on systems where it is possible to obtain one). The framework still alows you to shoot yourself in the foot, but you must do it explicitly. Either run os.system("shotgun-browser &") yourself or register your own ShotgunBrowser. Thus the new framework is safe by default but still flexible. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-28 22:49 Message: Logged In: YES user_id=131838 So you really want to change existing practice and break all Python GUI programs that invoke webbrowser.open? And the Elinks example proves my point. What is the point of it being a UnixBrowser, in the terminal window, if you can't send remote commands to it (because the Python GUI application is blocked until the browser exits)? Tty-based browsers are nice for completeness, but are really a last resort for a Python application, and imply that no windowing system is available (i.e, remotely logged in and not forwarding X connections, so not running GUI applications either). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-28 15:56 Message: Logged In: YES user_id=4799 No, I still think it is a bad idea to put a generic Unix browser to background by default. If you want to do it - do it explicitly. Start a browser in a background yourself, and use remote actions from the module to open new windows/tabs. Or register another browser, with different .open() and/or ._remote(). And, BTW, Elinks is a subclass of UnixBrowser, not GenericBrowser. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-27 21:35 Message: Logged In: YES user_id=131838 And I don't want starting up firefox to hang my python GUI either. So, if you look at the code more closely, lynx/links/elinks subclass from GenericBrowser not UnixBrowser, so adding the & to UnixBrowser is the correct thing to do. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-27 19:36 Message: Logged In: YES user_id=4799 Yes, _safequote() call seems like a bug. A leftover after I've merged a half dozens of patches into this one. Should be removed. But there should certainly be no '&'. You certainly dont want to start lynx/links/elinks in the background, do you?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 From noreply at sourceforge.net Mon Oct 31 18:16:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Oct 2005 09:16:25 -0800 Subject: [ python-Bugs-417833 ] pydoc HTTP reload failure Message-ID: Bugs item #417833, was opened at 2001-04-21 09:10 Message generated for change (Comment added) made by rturpin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Garth T Kidd (gtk) Assigned to: Ka-Ping Yee (ping) Summary: pydoc HTTP reload failure Initial Comment: pydoc, when run as a web server, can't cope with reloads of modules which use 'from Package import Module' syntax for imports. To reproduce: * extract the attached DemonstratePydocBug tarchive into your Python 2.1 directory * python -c Lib\pydoc.py -p 8192 * visit http://localhost:8192/DemonstratePydocBug.html The rest of the instructions are there. Demonstrated on Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32. Funnily enough, there's no problem with trying the following under Python interactively: Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import DemonstratePydocBug.ReloadFails >>> import DemonstratePydocBug.ReloadFails >>> import DemonstratePydocBug.ReloadFails >>> import DemonstratePydocBug.ReloadFails Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> from DemonstratePydocBug import ReloadFails >>> from DemonstratePydocBug import ReloadFails >>> from DemonstratePydocBug import ReloadFails >>> from DemonstratePydocBug import ReloadFails I'm dropping additional debugging code into pydoc.py to see if I can figure out what's going on. ---------------------------------------------------------------------- Comment By: Russell Turpin (rturpin) Date: 2005-10-31 11:16 Message: Logged In: YES user_id=670280 There's a similar bug in Python 2.4. It causes the __import__ function to throw an AttributeError exception during safeimport(). I've patched our local copy of pydoc to fix this. The patch is to the safeimport() function. The patched lines are: # This keeps __import__ from throwing an exception on reloads. # del sys.modules[path] # This is sole original line module = sys.modules[path] # Added this line try: # Added this line reload(module) # Added this line except: # Added this line module = None # Added this line return module # Added this line This replaces the line: del sys.modules[path] ---------------------------------------------------------------------- Comment By: Eddie Parker (eparker) Date: 2004-08-31 16:41 Message: Logged In: YES user_id=991512 This is still current, as of 08/31/2004. Rather annoying, too. :( ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-16 18:43 Message: Logged In: YES user_id=357491 Just as an update, this still seeems to be an issue in Python 2.3b1 w/ version 1.82 of pydoc ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 11:15 Message: Logged In: YES user_id=59803 Using pydoc in the interpreter doesn't tickle any of these bugs, so hopefully I can narrow my focus down to the difference in handling between serve() and help(). Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import pydoc >>> pydoc.help Welcome to Python 2.1! This is the online help utility. [...] help> modules Please wait a moment while I gather a list of all available modules... [list of modules] Enter any module name to get more help. Or, type "modules spam" to search for modules whose descriptions contain the word "spam". help> DemonstratePydocBug.ReloadFails Help on module DemonstratePydocBug.ReloadFails in DemonstratePydocBug: NAME DemonstratePydocBug.ReloadFails FILE c:\python21\lib\demonstratepydocbug\reloadfails.py [...] help> DemonstratePydocBug.TryThis Help on module DemonstratePydocBug.TryThis in DemonstratePydocBug: NAME DemonstratePydocBug.TryThis [...] ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 10:09 Message: Logged In: YES user_id=59803 Yet another demonstration case: DemonstratePydocBug/TryThis.py: import DemonstratePydocBug.Target Target = DemonstratePydocBug.Target This gives us a local Target variable, same as 'from DemonstratePydocBug import Target'. Pydoc barfs on this on the very first load. The traceback I hacked into pydoc claims: Traceback (most recent call last): File "C:\Python21\Lib\pydoc.py", line 223, in safeimport module = __import__(path) File "c:\python21\lib\DemonstratePydocBug\TryThis.py", line 9, in ? Target = DemonstratePydocBug.Target AttributeError: 'DemonstratePydocBug' module has no attribute 'Target' In the interpreter, everything's fine with both techniques for getting Target: C:\Python21\thirdparty\MoinMoin>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> from DemonstratePydocBug import Target >>> Target <module 'DemonstratePydocBug.Target' from 'c:\python21 \lib\DemonstratePydocBug\Target.pyc'> >>> C:\Python21\thirdparty\MoinMoin>python Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import DemonstratePydocBug.Target >>> Target = DemonstratePydocBug.Target >>> Target <module 'DemonstratePydocBug.Target' from 'c:\python21 \lib\DemonstratePydocBug\Target.pyc'> >>> ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 09:58 Message: Logged In: YES user_id=59803 WHOA. Belay that. I screwed up trying to run too many tests in a row without shutting down the interpreter. Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import pydoc >>> import DemonstratePydocBug >>> pydoc.help(DemonstratePydocBug.Target) Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'DemonstratePydocBug' module has no attribute 'Target' Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. >>> import pydoc >>> import DemonstratePydocBug >>> DemonstratePydocBug.Target Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'DemonstratePydocBug' module has no attribute 'Target' >>> import DemonstratePydocBug.Target >>> DemonstratePydocBug.Target <module 'DemonstratePydocBug.Target' from 'c:\python21 \lib\DemonstratePydocBug\Target.pyc'> >>> pydoc.help(DemonstratePydocBug.Target) Help on module DemonstratePydocBug.Target: NAME DemonstratePydocBug.Target FILE c:\python21\lib\demonstratepydocbug\target.py DESCRIPTION Target: module to help demonstrate the pydoc reload bug. See the docstring in __init__.py for full details. Reloading the description of this module in pydoc should work, but that's hardly unusual because it doesn't import *anything*. Try ReloadWorks and ReloadFails, instead. DATA __file__ = r'c:\python21 \lib\DemonstratePydocBug\Target.pyc' __name__ = 'DemonstratePydocBug.Target' >>> pydoc.help(DemonstratePydocBug.Target) Help on module DemonstratePydocBug.Target: NAME DemonstratePydocBug.Target ... ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 09:55 Message: Logged In: YES user_id=59803 >>> import pydoc >>> import DemonstratePydocBug >>> pydoc.help(DemonstratePydocBug.Target) ... we get good stuff... >>> print DemonstratePydocBug.ReloadFails2 <module 'DemonstratePydocBug.ReloadFails2' from 'DemonstratePydocBug\ReloadFails2.py'> >>> pydoc.help(DemonstratePydocBug.ReloadFails2) ... we get good stuff... ---------------------------------------------------------------------- Comment By: Garth T Kidd (gtk) Date: 2001-04-21 09:43 Message: Logged In: YES user_id=59803 I've found another demonstration case. Noting that from package import module gives you a variable called 'module', whilst import package.module gives you a variable called 'package', I thought I'd try out another import syntax which wouldn't break code that was trying out the first option: import package.module as module This also works under the Python 2.1 interpreter but breaks pydoc 1.38. I've attached an updated demonstration tarchive. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=417833&group_id=5470 From noreply at sourceforge.net Mon Oct 31 20:11:47 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Oct 2005 11:11:47 -0800 Subject: [ python-Bugs-1338264 ] Memory keeping Message-ID: Bugs item #1338264, was opened at 2005-10-26 02:37 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338264&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: sin (sin_avatar) Assigned to: Nobody/Anonymous (nobody) Summary: Memory keeping Initial Comment: I execute this code on python 2.4.2 (authentic copy from console): Python 2.4.2 (#1, Oct 26 2005, 14:45:33) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> a = range(1,10000000) >>> del a before i type del - i run top and get (see console output below): 16300 sin 2 0 162M 161M poll 0:02 35.76% 9.28% python2.4 after del (console below): 16300 sin 2 0 162M 161M poll 0:03 7.18% 6.05% python2.4 I tried gc too ... but python didn't free memory. I checked this on windows - memory was freed, but interpreter with 0 defined variables "eat" about 75 Mb!. I think this is bug in interpereter core. some text from dmesg for you: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.8-RELEASE #0: Thu Apr 3 10:53:38 GMT 2003 root at freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/ GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (499.15-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x387f9ff real memory = 268369920 (262080K bytes) avail memory = 255901696 (249904K bytes) ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-10-31 11:11 Message: Logged In: YES user_id=341410 Integers are immutable. That is, each integer with a different value will be a different integer object (some integers with the same value will also be different objects). In CPython, id(obj) is the memory location of that object. >>> a = 9876 >>> id(a) 9121340 >>> a += 1 >>> id(a) 8738760 It is assumed by the CPython runtime, based on significant experience by CPython programmers, that if you are using a large number of integers now, that you are probably going to use a large number of integers in the future. When an integer object is allocated, the object hangs around for as long as it is needed, and when it is no longer needed, it is placed on a list of allocated integer objects which can be re-used, but which are never freed (the integer freelist). This allows Python to allocate blocks of integers at a time when necessary (which speeds up allocations), re-use unused integer objects (which removes additional allocations in the majority of cases), and removes the free() call (on many platforms, free() doesn't work). Integer freelists are not going away, and the behavior you are experiencing is a result of integer freelists (though the 163M rather than 123M memory used is a result of FreeBSD's memory manager not being perfect). As Tim Peters suggested, if you need to iterate through 10 million unique integers, do so via xrange, but don't save them all. If you can't think about how to do such a thing in your application, you can ask users on the comp.lang.python newsgroup, or via the python-list at python.org mailing list, but remember to include the code you are using now and a description of what you want it to do. ---------------------------------------------------------------------- Comment By: sin (sin_avatar) Date: 2005-10-31 01:06 Message: Logged In: YES user_id=1368129 One more time. >>> a = [1 for i in xrange(10000000)] >>> del a This code clear - and this not raise "memory keeping"(!) >>> a = [i for i in xrange(10000000)] >>> del a But this code take about 163 Mb on my freeBSD. I can't udestood why you don't care about this? P.S. somebody explain me phrase "a) not a bug (integer freelists)" ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-10-30 22:56 Message: Logged In: YES user_id=341410 Suggested close because and/or: a) not a bug (integer freelists) b) platform specific malloc/free behavior on the list->ob_item member (some platforms will drop to 121M allocated memory after the deletion) c) OP didn't listen when it was suggested they use xrange() instead of range() ---------------------------------------------------------------------- Comment By: sin (sin_avatar) Date: 2005-10-30 22:15 Message: Logged In: YES user_id=1368129 Certainly, i 'am not a C guru, but i uderstood - if interpreter keep more than 100Mb, and not keep useful information - it's suxx. Fore example if i use my script as a part Zope portal - it would be awful. Certainly my script was just example - but if i use mult-thread server wrote on python and create list in each thread - i would take memory from system and i cannot give it back. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-10-27 12:38 Message: Logged In: YES user_id=31435 Space for integer objects in particular lives in an immortal free list of unbounded size, so it's certain in the current implementation that doing range(10000000) will hang on to space for 10 million integers forever. If you don't want that, don't do that ;-) Iterating over xrange(10000000) instead will consume very little RAM. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-10-27 12:29 Message: Logged In: YES user_id=341410 >From what I understand, whether or not the Python runtime "frees" memory (which can be freed) is generally dependant on platform malloc() and free(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338264&group_id=5470 From noreply at sourceforge.net Mon Oct 31 21:00:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Oct 2005 12:00:50 -0800 Subject: [ python-Bugs-1338264 ] Memory keeping Message-ID: Bugs item #1338264, was opened at 2005-10-26 05:37 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338264&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: sin (sin_avatar) Assigned to: Nobody/Anonymous (nobody) Summary: Memory keeping Initial Comment: I execute this code on python 2.4.2 (authentic copy from console): Python 2.4.2 (#1, Oct 26 2005, 14:45:33) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> a = range(1,10000000) >>> del a before i type del - i run top and get (see console output below): 16300 sin 2 0 162M 161M poll 0:02 35.76% 9.28% python2.4 after del (console below): 16300 sin 2 0 162M 161M poll 0:03 7.18% 6.05% python2.4 I tried gc too ... but python didn't free memory. I checked this on windows - memory was freed, but interpreter with 0 defined variables "eat" about 75 Mb!. I think this is bug in interpereter core. some text from dmesg for you: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.8-RELEASE #0: Thu Apr 3 10:53:38 GMT 2003 root at freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/ GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (499.15-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x387f9ff real memory = 268369920 (262080K bytes) avail memory = 255901696 (249904K bytes) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2005-10-31 15:00 Message: Logged In: YES user_id=31435 sin_avatar, it's the number of integer objects _simultaneously alive_ that matters, not the total number of integer objects ever created. Creating a list (or any other in-memory container) containing millions of integers can be a bad idea on many counts. I'm closing this as WontFix, as there are no plans to replace the integer freelist. I think it would be good if an upper bound were placed on its size (as most other internal freelists have), but that's trickier than it sounds and there are no plans to do that either. > I can't udestood why you don't care about this? It's a tradeoff: it's much easier to avoid in real life than it is to change the implementation in a way that would actually help (the int freelist is an important speed optimization for most integer-heavy apps). Changing your coding practices to live with this is your only realistic hope for relief. BTW, the idea that you might really need to create a list with 10 million integers in each thread of a threaded server is too bizarre to argue about ;-) ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-10-31 14:11 Message: Logged In: YES user_id=341410 Integers are immutable. That is, each integer with a different value will be a different integer object (some integers with the same value will also be different objects). In CPython, id(obj) is the memory location of that object. >>> a = 9876 >>> id(a) 9121340 >>> a += 1 >>> id(a) 8738760 It is assumed by the CPython runtime, based on significant experience by CPython programmers, that if you are using a large number of integers now, that you are probably going to use a large number of integers in the future. When an integer object is allocated, the object hangs around for as long as it is needed, and when it is no longer needed, it is placed on a list of allocated integer objects which can be re-used, but which are never freed (the integer freelist). This allows Python to allocate blocks of integers at a time when necessary (which speeds up allocations), re-use unused integer objects (which removes additional allocations in the majority of cases), and removes the free() call (on many platforms, free() doesn't work). Integer freelists are not going away, and the behavior you are experiencing is a result of integer freelists (though the 163M rather than 123M memory used is a result of FreeBSD's memory manager not being perfect). As Tim Peters suggested, if you need to iterate through 10 million unique integers, do so via xrange, but don't save them all. If you can't think about how to do such a thing in your application, you can ask users on the comp.lang.python newsgroup, or via the python-list at python.org mailing list, but remember to include the code you are using now and a description of what you want it to do. ---------------------------------------------------------------------- Comment By: sin (sin_avatar) Date: 2005-10-31 04:06 Message: Logged In: YES user_id=1368129 One more time. >>> a = [1 for i in xrange(10000000)] >>> del a This code clear - and this not raise "memory keeping"(!) >>> a = [i for i in xrange(10000000)] >>> del a But this code take about 163 Mb on my freeBSD. I can't udestood why you don't care about this? P.S. somebody explain me phrase "a) not a bug (integer freelists)" ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-10-31 01:56 Message: Logged In: YES user_id=341410 Suggested close because and/or: a) not a bug (integer freelists) b) platform specific malloc/free behavior on the list->ob_item member (some platforms will drop to 121M allocated memory after the deletion) c) OP didn't listen when it was suggested they use xrange() instead of range() ---------------------------------------------------------------------- Comment By: sin (sin_avatar) Date: 2005-10-31 01:15 Message: Logged In: YES user_id=1368129 Certainly, i 'am not a C guru, but i uderstood - if interpreter keep more than 100Mb, and not keep useful information - it's suxx. Fore example if i use my script as a part Zope portal - it would be awful. Certainly my script was just example - but if i use mult-thread server wrote on python and create list in each thread - i would take memory from system and i cannot give it back. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-10-27 15:38 Message: Logged In: YES user_id=31435 Space for integer objects in particular lives in an immortal free list of unbounded size, so it's certain in the current implementation that doing range(10000000) will hang on to space for 10 million integers forever. If you don't want that, don't do that ;-) Iterating over xrange(10000000) instead will consume very little RAM. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-10-27 15:29 Message: Logged In: YES user_id=341410 >From what I understand, whether or not the Python runtime "frees" memory (which can be freed) is generally dependant on platform malloc() and free(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338264&group_id=5470 From noreply at sourceforge.net Mon Oct 31 23:01:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Oct 2005 14:01:20 -0800 Subject: [ python-Bugs-1338995 ] CVS webbrowser.py (1.40) bugs Message-ID: Bugs item #1338995, was opened at 2005-10-26 16:08 Message generated for change (Comment added) made by gregcouch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Couch (gregcouch) Assigned to: Nobody/Anonymous (nobody) Summary: CVS webbrowser.py (1.40) bugs Initial Comment: There are two calls to _safequote that are only made on darwin, aka, Mac OS X. That function is missing. And the UnixBrowser is missing an & in the "simpler command" and thus causes python to hang until the browser is exited (if it wasn't running already). ---------------------------------------------------------------------- >Comment By: Greg Couch (gregcouch) Date: 2005-10-31 14:01 Message: Logged In: YES user_id=131838 Breaking applications that use webbrowser does not help application writers. It would be much more useful to me, as an application writer, if the webbrowser module gave an error saying it couldn't contact a web browser, rather than the new behavior of hanging my application. You have yet to address this common use case. Running the webbrowser in the background is a contract that the webbrowser module can't break and still be called the webbrowser module. I agree that the 2.4.2 version is a practical hack that should be fixed, but the CVS webbrower almost fixes it while breaking existing applications. Since adding an & is so bad (the web browser is already confirmed to exist and to be executable), the CVS webbrower could be changed to use the subprocess module instead of os.system, and the original webbrowser contract could be preserved. The wrong display or wrong xhost/xauth permissions are not a problem because the python GUI application that calls webbrowser would have failed to start up in the first place if those problems existed. Starting the web browser in the background only needs to confirm that the web browser actually started up. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-31 05:11 Message: Logged In: YES user_id=4799 Yes, I want. Current practice of running a browser in the background by default is deadly broken. The old code of webbrowser.py is full of dirty hacks. Look at Netscape._remote(). It tries to start a browser to send a remote command; if that fails it tries to start the browser in the background, waits an arbitrary number of seconds (why this? why not less? why not more?) and without testing if the browser in the background was started it retries sending the remote command. You can never know if the browser was started and if the command was sent becuase .open() does not return a result code. At the global level the bug is that webbrowser.py doesn't tri all browsers in the tryorder - it only concentrates on the first it found in PATH. What if the brwoser cannot be started (damaged disk image; wrong DISAPLY; wrong xhost/xauth permissions)? My patched webbrowser.py is much safer. It runs all browsers in the tryorder until it finds one that can be started. One doesn't need to wait a random number of seconds, too little for slow systems, too many for fast. .open() returns a success/fail status (on systems where it is possible to obtain one). The framework still alows you to shoot yourself in the foot, but you must do it explicitly. Either run os.system("shotgun-browser &") yourself or register your own ShotgunBrowser. Thus the new framework is safe by default but still flexible. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-28 11:49 Message: Logged In: YES user_id=131838 So you really want to change existing practice and break all Python GUI programs that invoke webbrowser.open? And the Elinks example proves my point. What is the point of it being a UnixBrowser, in the terminal window, if you can't send remote commands to it (because the Python GUI application is blocked until the browser exits)? Tty-based browsers are nice for completeness, but are really a last resort for a Python application, and imply that no windowing system is available (i.e, remotely logged in and not forwarding X connections, so not running GUI applications either). ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-28 04:56 Message: Logged In: YES user_id=4799 No, I still think it is a bad idea to put a generic Unix browser to background by default. If you want to do it - do it explicitly. Start a browser in a background yourself, and use remote actions from the module to open new windows/tabs. Or register another browser, with different .open() and/or ._remote(). And, BTW, Elinks is a subclass of UnixBrowser, not GenericBrowser. ---------------------------------------------------------------------- Comment By: Greg Couch (gregcouch) Date: 2005-10-27 10:35 Message: Logged In: YES user_id=131838 And I don't want starting up firefox to hang my python GUI either. So, if you look at the code more closely, lynx/links/elinks subclass from GenericBrowser not UnixBrowser, so adding the & to UnixBrowser is the correct thing to do. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2005-10-27 08:36 Message: Logged In: YES user_id=4799 Yes, _safequote() call seems like a bug. A leftover after I've merged a half dozens of patches into this one. Should be removed. But there should certainly be no '&'. You certainly dont want to start lynx/links/elinks in the background, do you?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1338995&group_id=5470