From noreply at sourceforge.net Thu Apr 1 00:15:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 1 00:15:29 2004 Subject: [ python-Bugs-927248 ] Python segfaults when freeing Message-ID: Bugs item #927248, was opened at 2004-04-01 13:07 Message generated for change (Settings changed) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=927248&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) >Summary: Python segfaults when freeing Initial Comment: An example to produce this behavior: >>> f = lambda: None >>> for i in range(1000000): ... f = f.__call__ ... >>> f = None Segmentation fault ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=927248&group_id=5470 From noreply at sourceforge.net Thu Apr 1 00:21:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 1 00:21:52 2004 Subject: [ python-Bugs-927248 ] Python segfaults when freeing "deep" objects Message-ID: Bugs item #927248, was opened at 2004-04-01 13:07 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=927248&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) >Summary: Python segfaults when freeing "deep" objects Initial Comment: An example to produce this behavior: >>> f = lambda: None >>> for i in range(1000000): ... f = f.__call__ ... >>> f = None Segmentation fault ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-04-01 14:21 Message: Logged In: YES user_id=55188 Oh. my patch doesn't fix another scenario that using recursive by two or more types of slots. So I remove. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=927248&group_id=5470 From noreply at sourceforge.net Thu Apr 1 00:47:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 1 00:48:03 2004 Subject: [ python-Bugs-926075 ] re.sub on u'' gives NON-unicode '' Message-ID: Bugs item #926075, was opened at 2004-03-31 00:27 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926075&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Fredrik Lundh (effbot) Summary: re.sub on u'' gives NON-unicode '' Initial Comment: >>> import re >>> re.sub(u'.', u'', u'') '' This holds for any RE that doesn't match the empty string. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-04-01 14:47 Message: Logged In: YES user_id=55188 Here's a fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926075&group_id=5470 From noreply at sourceforge.net Thu Apr 1 02:54:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 1 02:54:33 2004 Subject: [ python-Bugs-850964 ] optparse: OptionParser.__init__'s "prog" argument ignored Message-ID: Bugs item #850964, was opened at 2003-11-28 18:48 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850964&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Paul Mueller (yuurei) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: optparse: OptionParser.__init__'s "prog" argument ignored Initial Comment: optparse uses sys.argv[0] for the program name even if you supply the prog argument to OptionParser.__init__ ie, if you have p = OptionParser(prog='NEW_NAME'), p.print_usage, p.print_help, p.error, etc. don't use NEW_NAME as %prog. This is with Python 2.3.2 ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-04-01 02:54 Message: Logged In: YES user_id=3066 Unfortunately, the patch breaks some of the existing tests for optparse. I've committed a fix that doesn't require changing the existing tests and that adds new tests so this doesn't break in the future. Fixed for Python 2.3.4 and 2.4: Lib/optparse.py 1.8, 1.5.8.2 Lib/test/test_optparse.py 1.3, 1.2.8.2 ---------------------------------------------------------------------- Comment By: Paul Mueller (yuurei) Date: 2003-12-01 12:33 Message: Logged In: YES user_id=908814 The patch works perfectly. Thank you. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-12-01 01:06 Message: Logged In: YES user_id=671362 I've submitted a patch. See : http://www.python.org/sf/851902 Please apply the patch and check if "prog" argument works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850964&group_id=5470 From noreply at sourceforge.net Thu Apr 1 03:16:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 1 03:16:41 2004 Subject: [ python-Bugs-819178 ] optparse "append" action should always make the empty list. Message-ID: Bugs item #819178, was opened at 2003-10-07 06:47 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=819178&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Greg Ward (gward) Summary: optparse "append" action should always make the empty list. Initial Comment: I was torn between "Bug" and "RFE" on this one. Anyway, with options whose action is "append", optparse.OptionParser will set the option to None if it's never called. Instead, I think it should set the option to the empty list, so code can iterate over the list regardless of whether the option was ever given. It keeps users from having to guard their iteration with "if options.foo:" Such a change would be slightly backwards-incompatible; users who use "if option.foo is None:" form instead of just "if not options.foo:" would run into trouble, as well as those users who used an "else" statement in their loops. The latter seemed like a big problem, until I realized that those users' code *already* guards against the empty case, and thus shouldn't run into difficulties. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2004-04-01 03:16 Message: Logged In: YES user_id=3066 I'd agree that supplying [] as the default is the right thing to do, but the compatibility issue pretty much kills it. This should probably become a documentation issue; a hint to use default=[] would go a long way, and works with the existing code. ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-10-07 06:48 Message: Logged In: YES user_id=99508 So, I *thought* I could change this to an RFE after submitting it, but apparently not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=819178&group_id=5470 From noreply at sourceforge.net Thu Apr 1 09:36:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 1 12:03:01 2004 Subject: [ python-Feature Requests-927543 ] "with self:" statement Message-ID: Feature Requests item #927543, was opened at 2004-04-01 16:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=927543&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Dunne (tomdunne) Assigned to: Nobody/Anonymous (nobody) Summary: "with self:" statement Initial Comment: please forgive if this is documented somewhere; I looked and searched and could not find any up to date PEPs or comments about the status of this idea. I managed to find a thread from 2002 that talked about this in great detail: http://mail.python.org/pipermail/python-list/2002-July/112888.html but there was no conclusion... I know it's not a new idea and it shows up often... but here goes: How about a "with self:" statement, but more in the style of (forgive) VB then Pascal, ie referenced items in the self instance are preceded with a dot. present syntax: with self: ??returnvalue = self.x + self.y * self.width proposed syntax: with self: ??returnvalue = .x + .y * .width If no preceding dot is used, you run into an ambiguity when assigning values. How do you know if the variable is to be assigned in self or to an object in a higher scope... the preceding dot avoids that problem since it explicitly tags self items. (using nested "with" statements will lead to the same problem when assigning values. Assignment will have to be to the innermost "with object". Reading values should work ok though. ) I understand that I could just simply use "s." instead of "self." or assign all needed values in one preceding line: ??x,y,width = self.x, self.y, self.width This is a question that shows up every so often, the points made in the thread are good: http://mail.python.org/pipermail/python-list/2002-July/113831.html has this been recently discussed? is there a patch or PEP? (I might be able to provide a patch...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=927543&group_id=5470 From noreply at sourceforge.net Thu Apr 1 15:12:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 1 15:12:57 2004 Subject: [ python-Bugs-921077 ] embedding in multi-threaded & multi sub-interpreter environ Message-ID: Bugs item #921077, was opened at 2004-03-22 09:39 Message generated for change (Comment added) made by atulkshirsagar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=921077&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Atul (atulkshirsagar) Assigned to: Nobody/Anonymous (nobody) Summary: embedding in multi-threaded & multi sub-interpreter environ Initial Comment: I am embedding python in my C++ application. I am using Python *2.3.2* with a C++ extention DLL in multi- threaded environment. I am using SWIG-1.3.19 to generate C++ to Python interface. Now to explain it in details, 1. Python initialization [Py_Initialize()] and finalization [Py_Finalize()] is done in the *main* thread. 2. For each new thread I create a separate sub- interpreter [Py_NewInterpreter()]. 3. Using PyRun_String("import myModule"...) before execution of python script, extention module is imported. 4. Each thread executes *multiple* python script using PyEval_EvalCode() using the class objects in my extention DLL. 5. Each sub-interpreter is destroyed [Py_EndInterpreter ()] at the end of that particular thread. I am observing that; As explained above when multiple threads are running. And as one of these threads finishes, in other running threads I start getting "TypeError: 'NoneType' object is not callable" error on the methods called on class objects in extention module. The same code *works fine* with Python 2.2.2. I have found these links more or less talking about the same problem migrating from 2.2 to 2.3. http://mail.python.org/pipermail/python-dev/2003- September/038237.html http://mail.python.org/pipermail/python-list/2004- February/206851.html http://mail.python.org/pipermail/python-list/2004- January/204040.html I *guess* what is happening is global variables are zapped to "NoneType" when one thread finishes and other thread trying to access them through the Python script (step 4.) this error is generated. But it *works* sometimes when(*guess*) the running thread is at step 3. and by importing the module the global variables are re-initialized for "Type" information. I tried using reload(myModule) to solve the problem but that is generating big memory leak every time it is called. Is this a know issue with 2.3 (interpreter?) ? Or is there a change for 2.3 in the way embedding should be done in a multi-threaded and multi-sub-interpreter environment ? ---------------------------------------------------------------------- >Comment By: Atul (atulkshirsagar) Date: 2004-04-01 14:12 Message: Logged In: YES user_id=1003784 Hello Martin, I am attaching the sample program which demonstrates the issue; 1. I compiled it on Windows 2000 with VC++ compiler. 2. There is a "Extension Module" [flpythonmodulesu(d).dll] which is used by "Main" program ========================================= Extension Module (extModule.dsp project) generates : (*u.* - release, *ud.* - debug) 1. dll _flpythonmodulesud.dll 2. python script flpythonmodulesud.py ------------------------------------------------------ 1. Module has class FlPythonString and class Record defined 2. Using interface file include\flpythonmodulesud.i, SWIG- 1.3.19 generates include\flpythonmodulesud_wrap.cxx =========================================== ========================================= Main sample program (multiSub.dsp project) generates : 1. executable multiSub.exe ------------------------------------------------------ 1. Links in the extension DLL 2. Initializes and De-initializes python in main thread 3. Main thread creates 2 separate threads: (a) Each thread creating a new sub-interpreter (b) importing extension module (c) Calling following EXPRESSION using PyEval_EvalCode(), Thread 1: myVar = FlPythonStringPtr(STRObject) myRecord = myVar.NewRecord() Thread=str(myVar.Get()) record=str(myRecord.GetValue()) print 'Inside EXPRESSION ' + Thread + ':' + record;myVar.DeleteRecord(myRecord) Thread 2: myVar = FlPythonStringPtr(STRObject) for recordNum in range(1, 11): myRecord = myVar.NewRecord() Thread=str(myVar.Get()) record=str(myRecord.GetValue()) print 'Inside EXPRESSION ' + Thread + ':' + record;myVar.DeleteRecord(myRecord) (d) Destroying sub-interpreter. Comments in the code explain details about each step. =========================================== ========================================== Console Output messages explanations (Attaching a sample console output for the issue [consoleop.txt]) ----------------------------------------------------- -Thread *ID*:IMPORT Module Called:*ITERATION* -Inside EXPRESSION *Thread*:*Record::GetValue() [hardcoded to 1000]* -Thread *ID*:EXPRESSION Done:*ITERATION* -Thread *ID*:ENDINTERPRETER Called -Thread *ID*:EXPRESSION Failed!:*ITERATION* Check the error message demonstrating the issue: ----------------------------------------------- "Thread 2:EXPRESSION Failed!:3 Traceback (most recent call last): File "EXPRESSION", line 4, in ? File "E:\VssLocal\Isis\python23_issue\multiSub\Debug\flpython modulesud.py", line 69, in Get def Get(*args): return apply (_flpythonmodulesud.FlPythonString_Get,args) File "E:\VssLocal\Isis\python23_issue\multiSub\Debug\flpython modulesud.py", line 51, in __init__ _swig_setattr(self, Record, 'this', this) TypeError: 'NoneType' object is not callable" ========================================== Martin, Thanks for taking a look at the issue which has proved to be a major hurdle for our release and made us switch back to Python 2.2.2. Python 2.2.2 in itself has some issues for us; so if this can get fixed we would desperately be seeking a patch on Python 2.3. Let me know if you need any more inputs from my side. Thanks again, Atul ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-03-29 16:28 Message: Logged In: YES user_id=21627 Can you provide an example that demonstrates the supposed bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=921077&group_id=5470 From noreply at sourceforge.net Thu Apr 1 15:16:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 1 15:16:50 2004 Subject: [ python-Bugs-474836 ] Tix not included in windows distribution Message-ID: Bugs item #474836, was opened at 2001-10-25 13:22 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Thomas Heller (theller) Summary: Tix not included in windows distribution Initial Comment: Although there is a Tix.py available, there is no Tix support in the precomiled Python-distribution for windows. So import Tix works fine, but root = Tix.Tk() results in TclError: package not found. It is possible to circumvent this problem by installing a regular Tcl/Tk distribution (e.g. in c:\programme\tcl) and installing Tix in the regular Tcl-path (i.e. tcl\lib). Mathias ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-04-01 22:16 Message: Logged In: YES user_id=11105 I've built according to your instructions (slightly adjusted), then copied tix8184.dll to the DLLs directory (of a Python 2.3.3, installed with the windows installer), and the tix8.1 directory into the tcl directory (sibling of tcl8.4, tk8.4 and so on). Demo\tixwidgets.py complains: Traceback (most recent call last): File "c:\sf\python\dist23\src\Demo\tix\tixwidgets.py", line 1002, in ? root = Tix.Tk() File "C:\Python23\lib\lib-tk\Tix.py", line 210, in __init__ self.tk.eval('package require Tix') _tkinter.TclError: couldn't load library "tix8184.dll": this library or a dependent library could not be found in library path Any advise? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-03-31 22:03 Message: Logged In: YES user_id=21627 The instructions from 2003-04-26/2003-06-15 should still be valid. For 2.4, the story will be different, as Tix does not currently build with VC7. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-03-31 21:43 Message: Logged In: YES user_id=11105 I'm willing to do some work to include tix in Python 2.3.4, if someone can update the instructions. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-02-24 18:16 Message: Logged In: YES user_id=764593 Note that the problem is still there in 2.3.3; if it can't be fixed, could the documentation at least mention that Tix requires 3rd-party libraries on Windows? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 15:15 Message: Logged In: YES user_id=21627 Reassigning to Thomas, who is doing Windows releases these days. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-03 15:13 Message: Logged In: YES user_id=31435 Unassigned (doesn't look like I'll ever get time for this). ---------------------------------------------------------------------- Comment By: Aaron Optimizer Digulla (digulla) Date: 2003-10-03 13:10 Message: Logged In: YES user_id=606 loewis, when will your package show up in the official Python distribution? It's still not there in 2.3.2 :-( ---------------------------------------------------------------------- Comment By: Aaron Optimizer Digulla (digulla) Date: 2003-07-28 15:22 Message: Logged In: YES user_id=606 The Tix8184.dll is still missing in Python 2.3c2. The included Tix8183.dll (which is in the directory tcl\tix8.1\ along with a couple of other dlls -> can't be found by Python) is linked against Tcl/Tk 8.3. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-06-15 14:40 Message: Logged In: YES user_id=21627 I found that the instructions need slight modification: In step 2, use tk...\mkd.bat for mkdir. Apart from that, these instructions work fine for me, now. I have made a binary release of tix8.1 for Python 2.3 at http://www.dcl.hpi.uni-potsdam.de/home/loewis/tix8.1.zip The tix8184.dll goes to DLLs, the tix8.1 subdirectory goes to tcl. It differs from the standard tix8.1 subdirectory only in fixing the path to the DLLs directory. To test whether this works, execute Demo/tix/tixwidgets.py. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-04-26 12:22 Message: Logged In: YES user_id=21627 I still think Python should include Tix. Here are some instructions on how to make Tix 8.1.4 work: 1. Unpack as a sibling of tcl8.4.1 and tk8.4.1 2. Edit win\common.mk, to set the following variables TCL_VER=8.4 INSTALLDIR= MKDIR=mkdir 3. Edit win\makefile.vc, to set the following variables TOOLS32= TOOLS32_rc= 4. Edit win\tk\pkgindex.tcl, to replace lappend dirs ../../Dlls with lappend dirs [file join [file dirname [info nameofexe]] Dlls] 5. nmake -f makefile.vc 6. nmake -f makefile.vc install 7. Copy INSTALLDIR\bin\tix8184.dll to \DLLs 8. Optionally copy tix8184.lib somewhere 9. copy INSTALLDIR\lib\tix8.1 into \tcl With these instructions, invoking t.tk.eval("package require Tix") succeeds. For some reason, Tix won't still find any of the commands; I'll investigate this later. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-12-11 10:14 Message: Logged In: YES user_id=33229 My you're courageous - going with a version of Tcl that doesn't even pass its own tests :-) Been there, seen it, done it .... 8.1.4 will be out this week, which compiles with 8.4 but I don't expect it to "support" 8.4 for a while yet (they added more problems in 8.4.1). 8.3.5 is definitely "supported". Check back with me before 2.3 goes into beta and I'll do another minor release if necessary. Maybe Tk will test clean then. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-20 02:36 Message: Logged In: YES user_id=31435 Parents shouldn't disagree in front of their children . Not all the Tcl or Tk tests (their tests, not ours) passed when I built 8.4.1, but I couldn't (and can't) make time to dig into that, and all the Python stuff I tried worked fine. So I don't fear 8.4, and am inclined to accept Martin's assurance that 8.4 is best for Python. We intend to put out the first 2.3 Python alpha by the end of the year, and my bet is it won't be a minute before that. If Tix 8.1.4 is at RC3 now, I'd *guess* you'll have a final release out well before then. Yes? No? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-19 23:12 Message: Logged In: YES user_id=21627 I think the recommendation cannot apply to Python; I'm very much in favour of releasing Python 2.3 with Tk 8.4.x. So the question then is whether Python 2.3 should include Tix 8.1.4 or no Tix at all, and at what time Tix 8.1.4 can be expected. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-19 20:10 Message: Logged In: YES user_id=33229 Look on http://tix.sourceforge.net/download.shtml for Tix 8.1.4 RC3. It works with Tk 8.4.1 and passes the test suite, but there are still issues with Tk 8.4 and it has not been widely tested with yet with 8.4.1, so we still recommend 8.3.5. (Tcl major releases often aren't stable until patch .3 or so.) If you have any problems let me know directly by email and I'll try and help. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-18 17:35 Message: Logged In: YES user_id=31435 Does Tix 8.1.3 play with Tcl/Tk 8.4.1? The 2.3. Windows distro is set up to include the latter now. The win\common.mak file from Tix 8.1.3 doesn't have a section for Tcl/Tk 8.4, though. There appear to be several reasons Tix won't compile on my box anyway without fiddling the Tix makefiles (e.g., my VC doesn't live in \DevStudio), so before spending more time on that I'd like to know whether it's doomed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 15:52 Message: Logged In: YES user_id=6380 I support this. Tim, I know you're not a big Tk user (to say the least). I'll offer to help in person. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 08:30 Message: Logged In: YES user_id=33229 I would really like to see Tix in 2.3 and will be glad to help. AFAIK there are no major issues with tix-8.1.3 and Python 2.x and it should be a simple drop in of a cannonically compiled Tix. If there are any issues that need dealing with at Tix's end, I'll be glad to put out a new minor release of Tix to address them. On Python's end I've suggested a fix for http://python.org/sf/564729 FYI, please also see my comments for bug 632323. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 06:34 Message: Logged In: YES user_id=33229 I would really like to see Tix in 2.3 and will be glad to help. AFAIK there are no major issues with tix-8.1.3 and Python 2.x and it should be a simple drop in of a cannonically compiled Tix. If there are any issues that need dealing with at Tix's end, I'll be glad to put out a new minor release of Tix to address them. On Python's end I've suggested a fix for http://python.org/sf/564729 FYI, please also see my comments for bug 632323. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-23 04:34 Message: Logged In: YES user_id=6380 Yes, for 2.3. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-10 02:48 Message: Logged In: YES user_id=31435 Guido, do you want me to spend time on this? ---------------------------------------------------------------------- Comment By: Mathias Palm (monos) Date: 2002-03-07 14:38 Message: Logged In: YES user_id=361926 Thanks. Mathias ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-02-25 13:57 Message: Logged In: YES user_id=21627 The zip file is slightly too large for SF, so it is now at http://www.informatik.hu- berlin.de/~loewis/python/tix813win.zip ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-02-25 13:56 Message: Logged In: YES user_id=21627 Building Tix from sources is non-trivial, and I could not find any recent Windows binary distribution (based on Tix 8.1). So I'll attach a build of Tix 8.1.3 for Tcl/Tk 8.3, as a drop-in into the Python binary distribution. Compared to the original distribution, only tix8.1 \pkgIndex.tcl required tweaking, to tell it that tix8183.dll can be found in the DLLs subdirectory. Also, unless TIX_LIBRARY is set, the Tix tcl files *must* live in tcl\tix8.1, since tix8183.dll will look in TCL_LIBRARY\..\tix (among other locations). If a major Tcl release happens before Python 2.3 is released (and it is then still desirable to distribute Python with Tix), these binaries need to be regenerated. Would these instructions (unpack zip file into distribution tree) be precise enough to allow incorporation into the windows installer? ---------------------------------------------------------------------- Comment By: Mathias Palm (monos) Date: 2001-10-29 12:53 Message: Logged In: YES user_id=361926 As mentioned in the mail above (by me, Mathias), Tix is a package belonging to Tcl/Tk (to be found on sourceforge: tix.sourceforge.net, or via the Python home page - tkinter link). Everything needed can be found there, just read about it (and dont forget about the winking, eyes might be getting dry) Mathias ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-25 20:26 Message: Logged In: YES user_id=31435 I don't know anything about Tix, so if somebody wants this in the Windows installer, they're going to have to explain exactly (by which I mean exactly <0.5 wink>) what's needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470 From noreply at sourceforge.net Thu Apr 1 16:13:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 1 16:14:04 2004 Subject: [ python-Bugs-833405 ] urllib.urlencode doesn't work for output from cgi.parse_qs Message-ID: Bugs item #833405, was opened at 2003-10-30 15:39 Message generated for change (Comment added) made by mike_j_brown You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833405&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Myers Carpenter (myers_carpenter) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlencode doesn't work for output from cgi.parse_qs Initial Comment: >>> urllib.urlencode(cgi.parse_qsl('ext=.jpg&outquality=56')) 'ext=.jpg&outquality=56' >>> urllib.urlencode(cgi.parse_qs('ext=.jpg&outquality=56')) 'ext=%5B%27.jpg%27%5D&outquality=%5B%2756%27%5D' "%5B%27" = "['" ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-04-01 14:13 Message: Logged In: YES user_id=371366 I am only guessing, here, but if you had an object that you wanted to embed a representation of in a URL or in HTML form data, it would be prudent to call str() on the object and let its __str__ method give you a string representation, and then you'd percent-encode that. This makes sense for user- defined classes, where you can define __str__, but not for built-in types like an ordinary list, so they give you the doseq flag for those situations. ---------------------------------------------------------------------- Comment By: Myers Carpenter (myers_carpenter) Date: 2004-03-31 09:56 Message: Logged In: YES user_id=335935 Can you name one web app that you know will take args in the form of "ext=[27.jpg]"? Why not do some type inspection to see what types you are dealing with? What is the use of encoding a list in a url using python syntax? ---------------------------------------------------------------------- Comment By: Mike Brown (mike_j_brown) Date: 2004-03-30 23:01 Message: Logged In: YES user_id=371366 As per the urlencode() API documentation, you are passing in sequences, so you need to set the doseq flag. >>> urllib.urlencode(cgi.parse_qs ('ext=.jpg&outquality=56'),doseq=1) 'ext=.jpg&outquality=56' I recommend that this bug report be closed as Invalid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833405&group_id=5470 From noreply at sourceforge.net Thu Apr 1 19:26:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 1 19:26:35 2004 Subject: [ python-Bugs-856103 ] reload() fails with modules from zips Message-ID: Bugs item #856103, was opened at 2003-12-08 02:48 Message generated for change (Comment added) made by filitov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: reload() fails with modules from zips Initial Comment: If you call reload() with a module that was imported from a zip, it fails with a "no such module" error. Although zips are typically read-only, it is possible that a zip could be modified during a run, and a reload be necessary. If this is considered unnecessary, then I think a more informative "can't reload from zip" error would be better than a 'no such module" one. """ >set PYTHONPATH=path/to/spambayes.zip >python >>> from spambayes import Options >>> Options >>> reload(Options) Traceback (most recent call last): File "", line 1, in ? ImportError: No module named Options """ This is with Python 2.3.2 and WinXP. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-01 18:26 Message: Logged In: YES user_id=642545 Here's a patch that fixes the problem so that modules from zip files can be reloaded. The problem was the PyImport_ReloadModulefunction not passing a loader around. Perhaps this is naive, and the PyImport_ReloadModule was purposefully not using a loader, but, again, it works for me. cvs diff -u dist\src\Python\import.c (in directory C:\cvs\python\) Index: dist/src/Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.230 diff -u -r2.230 import.c --- dist/src/Python/import.c 1 Apr 2004 02:45:22 -0000 2.230 +++ dist/src/Python/import.c 2 Apr 2004 00:18:46 -0000 @@ -2217,7 +2217,7 @@ PyImport_ReloadModule(PyObject *m) { PyObject *modules = PyImport_GetModuleDict(); - PyObject *path = NULL; + PyObject *path, *loader = NULL; char *name, *subname; char buf[MAXPATHLEN+1]; struct filedescr *fdp; @@ -2259,11 +2259,12 @@ PyErr_Clear(); } buf[0] = '\0'; - fdp = find_module(name, subname, path, buf, MAXPATHLEN+1, &fp, NULL); + fdp = find_module(name, subname, path, buf, MAXPATHLEN+1, &fp, &loader); Py_XDECREF(path); if (fdp == NULL) return NULL; - m = load_module(name, fp, buf, fdp->type, NULL); + m = load_module(name, fp, buf, fdp->type, loader); + Py_XDECREF(loader); if (fp) fclose(fp); return m; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&group_id=5470 From noreply at sourceforge.net Thu Apr 1 22:37:10 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Apr 1 22:37:36 2004 Subject: [ python-Bugs-856103 ] reload() fails with modules from zips Message-ID: Bugs item #856103, was opened at 2003-12-08 02:48 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&group_id=5470 Category: Python Interpreter Core >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) >Assigned to: Just van Rossum (jvr) Summary: reload() fails with modules from zips Initial Comment: If you call reload() with a module that was imported from a zip, it fails with a "no such module" error. Although zips are typically read-only, it is possible that a zip could be modified during a run, and a reload be necessary. If this is considered unnecessary, then I think a more informative "can't reload from zip" error would be better than a 'no such module" one. """ >set PYTHONPATH=path/to/spambayes.zip >python >>> from spambayes import Options >>> Options >>> reload(Options) Traceback (most recent call last): File "", line 1, in ? ImportError: No module named Options """ This is with Python 2.3.2 and WinXP. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2004-04-01 21:37 Message: Logged In: YES user_id=44345 attached is the patch to protect it from the vagaries of cut-n- paste. I also added a simple testReload test to the test_zipimport.py file. I can't get zip imports to work. Perhaps Just can test this out. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-01 18:26 Message: Logged In: YES user_id=642545 Here's a patch that fixes the problem so that modules from zip files can be reloaded. The problem was the PyImport_ReloadModulefunction not passing a loader around. Perhaps this is naive, and the PyImport_ReloadModule was purposefully not using a loader, but, again, it works for me. cvs diff -u dist\src\Python\import.c (in directory C:\cvs\python\) Index: dist/src/Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.230 diff -u -r2.230 import.c --- dist/src/Python/import.c 1 Apr 2004 02:45:22 -0000 2.230 +++ dist/src/Python/import.c 2 Apr 2004 00:18:46 -0000 @@ -2217,7 +2217,7 @@ PyImport_ReloadModule(PyObject *m) { PyObject *modules = PyImport_GetModuleDict(); - PyObject *path = NULL; + PyObject *path, *loader = NULL; char *name, *subname; char buf[MAXPATHLEN+1]; struct filedescr *fdp; @@ -2259,11 +2259,12 @@ PyErr_Clear(); } buf[0] = '\0'; - fdp = find_module(name, subname, path, buf, MAXPATHLEN+1, &fp, NULL); + fdp = find_module(name, subname, path, buf, MAXPATHLEN+1, &fp, &loader); Py_XDECREF(path); if (fdp == NULL) return NULL; - m = load_module(name, fp, buf, fdp->type, NULL); + m = load_module(name, fp, buf, fdp->type, loader); + Py_XDECREF(loader); if (fp) fclose(fp); return m; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&group_id=5470 From noreply at sourceforge.net Fri Apr 2 02:00:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 2 02:01:09 2004 Subject: [ python-Bugs-856103 ] reload() fails with modules from zips Message-ID: Bugs item #856103, was opened at 2003-12-08 09:48 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Just van Rossum (jvr) Summary: reload() fails with modules from zips Initial Comment: If you call reload() with a module that was imported from a zip, it fails with a "no such module" error. Although zips are typically read-only, it is possible that a zip could be modified during a run, and a reload be necessary. If this is considered unnecessary, then I think a more informative "can't reload from zip" error would be better than a 'no such module" one. """ >set PYTHONPATH=path/to/spambayes.zip >python >>> from spambayes import Options >>> Options >>> reload(Options) Traceback (most recent call last): File "", line 1, in ? ImportError: No module named Options """ This is with Python 2.3.2 and WinXP. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2004-04-02 09:00 Message: Logged In: YES user_id=92689 The import.c patch looks fine (although I didn't test it yet). Skip, what doesn't work for you? "I can't get zip imports to work" is quite broad... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-04-02 05:37 Message: Logged In: YES user_id=44345 attached is the patch to protect it from the vagaries of cut-n- paste. I also added a simple testReload test to the test_zipimport.py file. I can't get zip imports to work. Perhaps Just can test this out. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-02 02:26 Message: Logged In: YES user_id=642545 Here's a patch that fixes the problem so that modules from zip files can be reloaded. The problem was the PyImport_ReloadModulefunction not passing a loader around. Perhaps this is naive, and the PyImport_ReloadModule was purposefully not using a loader, but, again, it works for me. cvs diff -u dist\src\Python\import.c (in directory C:\cvs\python\) Index: dist/src/Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.230 diff -u -r2.230 import.c --- dist/src/Python/import.c 1 Apr 2004 02:45:22 -0000 2.230 +++ dist/src/Python/import.c 2 Apr 2004 00:18:46 -0000 @@ -2217,7 +2217,7 @@ PyImport_ReloadModule(PyObject *m) { PyObject *modules = PyImport_GetModuleDict(); - PyObject *path = NULL; + PyObject *path, *loader = NULL; char *name, *subname; char buf[MAXPATHLEN+1]; struct filedescr *fdp; @@ -2259,11 +2259,12 @@ PyErr_Clear(); } buf[0] = '\0'; - fdp = find_module(name, subname, path, buf, MAXPATHLEN+1, &fp, NULL); + fdp = find_module(name, subname, path, buf, MAXPATHLEN+1, &fp, &loader); Py_XDECREF(path); if (fdp == NULL) return NULL; - m = load_module(name, fp, buf, fdp->type, NULL); + m = load_module(name, fp, buf, fdp->type, loader); + Py_XDECREF(loader); if (fp) fclose(fp); return m; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&group_id=5470 From noreply at sourceforge.net Fri Apr 2 03:34:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 2 03:34:47 2004 Subject: [ python-Bugs-887242 ] "-framework Python" for building modules is bad Message-ID: Bugs item #887242, was opened at 2004-01-29 15:40 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=887242&group_id=5470 Category: Macintosh Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: "-framework Python" for building modules is bad Initial Comment: We should use the -bundle_loader method for linking modules for both the framework and non-framework verisons of Python. All of these "version mismatch" errors would pretty much be avoided if this were the case, since a 10.2 and 10.3 MacPython 2.3 should be binary compatible. There are other reasons to use -bundle_loader, such as using the same suite of modules for both Stackless and regular Python. Besides, -bundle_loader is for building -bundles :) It's a simple change to the configure script, and it would be great if this could happen before OS X 10.4. ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2004-04-02 03:34 Message: Logged In: YES user_id=139309 minimal patch for Python 2.4 CVS configure.in (and configure) attached. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-01-29 18:21 Message: Logged In: YES user_id=139309 -undefined dynamic_lookup has a localized effect, it still uses two level namespaces and doesn't force the whole process to go flat. Apple uses this flag for Perl in 10.3 (maybe other things, like Apache), so presumably they designed it with situations like ours in mind. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2004-01-29 18:11 Message: Logged In: YES user_id=45365 Ok, I only tried -bundle_loader Python.framework, and when that didn't work I stopped trying. But I have some misgivings about the -undefined dynamic_lookup: doesn't this open up the whole flat namespace/undefined suppress can of worms that we had under 10.1? What we *really* want is to a way to tell the linker "at runtime, the host program must already have loaded a Python.framework, any Python.framework, and that is what we want to link against". ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-01-29 18:05 Message: Logged In: YES user_id=139309 That's not true. -bundle_loader does not generate a mach header load command, it is merely so that ld can make sure that all of your symbols are defined at link time (it will work for an embedded Python, try it). You do need -undefined dynamic_lookup though, because -bundle_loader doesn't respect indirect symbols. I'm not sure it's possible to make Python.framework get "imported" into the executable so that it's possible to -bundle_loader without -undefined dynamic_lookup (-prebind maybe, but I doubt it). ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2004-01-29 17:53 Message: Logged In: YES user_id=45365 There's a reason why I use -framework in stead of -bundle_loader: you can only specify an application as bundle_loader, not Python.framework itself. This means you have to specify the Python executable, which makes it impossible to load extension modules (including all the standard extension modules) into an application embedding Python. I don't think this is acceptable. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2004-01-29 17:24 Message: Logged In: YES user_id=139309 err, this is a 10.3+ only request, and requires use of -undefined dynamic_lookup as well ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=887242&group_id=5470 From noreply at sourceforge.net Fri Apr 2 07:23:01 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 2 07:23:10 2004 Subject: [ python-Bugs-856103 ] reload() fails with modules from zips Message-ID: Bugs item #856103, was opened at 2003-12-08 02:48 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) >Assigned to: Skip Montanaro (montanaro) Summary: reload() fails with modules from zips Initial Comment: If you call reload() with a module that was imported from a zip, it fails with a "no such module" error. Although zips are typically read-only, it is possible that a zip could be modified during a run, and a reload be necessary. If this is considered unnecessary, then I think a more informative "can't reload from zip" error would be better than a 'no such module" one. """ >set PYTHONPATH=path/to/spambayes.zip >python >>> from spambayes import Options >>> Options >>> reload(Options) Traceback (most recent call last): File "", line 1, in ? ImportError: No module named Options """ This is with Python 2.3.2 and WinXP. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2004-04-02 06:23 Message: Logged In: YES user_id=44345 > what doesn't work for you? Sorry. Pilot error. I was adding foozip.zip to sys.path then trying from foozip import somemodule instead of just import somemodule (Obvious, not a feature I use a lot...) Seems to be working for me now. I'll try a couple more tests then check it in. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-04-02 01:00 Message: Logged In: YES user_id=92689 The import.c patch looks fine (although I didn't test it yet). Skip, what doesn't work for you? "I can't get zip imports to work" is quite broad... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-04-01 21:37 Message: Logged In: YES user_id=44345 attached is the patch to protect it from the vagaries of cut-n- paste. I also added a simple testReload test to the test_zipimport.py file. I can't get zip imports to work. Perhaps Just can test this out. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-01 18:26 Message: Logged In: YES user_id=642545 Here's a patch that fixes the problem so that modules from zip files can be reloaded. The problem was the PyImport_ReloadModulefunction not passing a loader around. Perhaps this is naive, and the PyImport_ReloadModule was purposefully not using a loader, but, again, it works for me. cvs diff -u dist\src\Python\import.c (in directory C:\cvs\python\) Index: dist/src/Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.230 diff -u -r2.230 import.c --- dist/src/Python/import.c 1 Apr 2004 02:45:22 -0000 2.230 +++ dist/src/Python/import.c 2 Apr 2004 00:18:46 -0000 @@ -2217,7 +2217,7 @@ PyImport_ReloadModule(PyObject *m) { PyObject *modules = PyImport_GetModuleDict(); - PyObject *path = NULL; + PyObject *path, *loader = NULL; char *name, *subname; char buf[MAXPATHLEN+1]; struct filedescr *fdp; @@ -2259,11 +2259,12 @@ PyErr_Clear(); } buf[0] = '\0'; - fdp = find_module(name, subname, path, buf, MAXPATHLEN+1, &fp, NULL); + fdp = find_module(name, subname, path, buf, MAXPATHLEN+1, &fp, &loader); Py_XDECREF(path); if (fdp == NULL) return NULL; - m = load_module(name, fp, buf, fdp->type, NULL); + m = load_module(name, fp, buf, fdp->type, loader); + Py_XDECREF(loader); if (fp) fclose(fp); return m; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&group_id=5470 From noreply at sourceforge.net Fri Apr 2 09:55:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 2 09:55:50 2004 Subject: [ python-Bugs-928297 ] platform.libc_ver() fails on Cygwin Message-ID: Bugs item #928297, was opened at 2004-04-02 23:55 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=928297&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: platform.libc_ver() fails on Cygwin Initial Comment: >>> import platform >>> platform.libc_ver() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/platform.py", line 134, in libc_ver f = open(executable,'rb') IOError: [Errno 2] No such file or directory: '/usr/bin/python' The problem is that on Cygwin sys.executable returns /path/to/python, but since Cygwin is running on Windows, sys.executable is a symbolic link to /path/to/python.exe. >>> import os, sys >>> os.path.exists(sys.executable) True >>> os.path.isfile(sys.executable) True >>> file(sys.executable) Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 2] No such file or directory: '/usr/bin/python' >>> os.path.islink(sys.executable) True >>> os.path.realpath(sys.executable) '/usr/bin/python2.3.exe' >>> file(sys.executable + '.exe') Following is the info about the machine I tested: >>> from platform import * >>> platform() 'CYGWIN_NT-5.0-1.5.7-0.109-3-2-i686-32bit' >>> python_compiler() 'GCC 3.3.1 (cygming special)' >>> python_build() (1, 'Dec 30 2003 08:29:25') >>> python_version() '2.3.3' >>> uname() ('CYGWIN_NT-5.0', 'my_user_name', '1.5.7 (0.109/3/2)', '2004-01-30 19:32', 'i686', '') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=928297&group_id=5470 From noreply at sourceforge.net Fri Apr 2 09:56:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 2 09:56:42 2004 Subject: [ python-Bugs-928297 ] platform.libc_ver() fails on Cygwin Message-ID: Bugs item #928297, was opened at 2004-04-02 23:55 Message generated for change (Settings changed) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=928297&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) >Assigned to: M.-A. Lemburg (lemburg) Summary: platform.libc_ver() fails on Cygwin Initial Comment: >>> import platform >>> platform.libc_ver() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/platform.py", line 134, in libc_ver f = open(executable,'rb') IOError: [Errno 2] No such file or directory: '/usr/bin/python' The problem is that on Cygwin sys.executable returns /path/to/python, but since Cygwin is running on Windows, sys.executable is a symbolic link to /path/to/python.exe. >>> import os, sys >>> os.path.exists(sys.executable) True >>> os.path.isfile(sys.executable) True >>> file(sys.executable) Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 2] No such file or directory: '/usr/bin/python' >>> os.path.islink(sys.executable) True >>> os.path.realpath(sys.executable) '/usr/bin/python2.3.exe' >>> file(sys.executable + '.exe') Following is the info about the machine I tested: >>> from platform import * >>> platform() 'CYGWIN_NT-5.0-1.5.7-0.109-3-2-i686-32bit' >>> python_compiler() 'GCC 3.3.1 (cygming special)' >>> python_build() (1, 'Dec 30 2003 08:29:25') >>> python_version() '2.3.3' >>> uname() ('CYGWIN_NT-5.0', 'my_user_name', '1.5.7 (0.109/3/2)', '2004-01-30 19:32', 'i686', '') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=928297&group_id=5470 From noreply at sourceforge.net Fri Apr 2 10:38:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 2 10:40:22 2004 Subject: [ python-Bugs-856103 ] reload() fails with modules from zips Message-ID: Bugs item #856103, was opened at 2003-12-08 02:48 Message generated for change (Comment added) made by filitov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Skip Montanaro (montanaro) Summary: reload() fails with modules from zips Initial Comment: If you call reload() with a module that was imported from a zip, it fails with a "no such module" error. Although zips are typically read-only, it is possible that a zip could be modified during a run, and a reload be necessary. If this is considered unnecessary, then I think a more informative "can't reload from zip" error would be better than a 'no such module" one. """ >set PYTHONPATH=path/to/spambayes.zip >python >>> from spambayes import Options >>> Options >>> reload(Options) Traceback (most recent call last): File "", line 1, in ? ImportError: No module named Options """ This is with Python 2.3.2 and WinXP. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-02 09:38 Message: Logged In: YES user_id=642545 Actually, it doesn't seem to be working fully. I've been playing with Skip's test patch and it looks like the code it reloads uses...the same buffer size as it did with the original read? You can play with replacing 'return __name__' with different strings and it will change the error you get. E.g. with 'return __name__+"modified"', it parses fine, but get_foo() is not found (which is added after get_name()). E.g. with 'return "new"', it does not parse fine, it returns 'NameError: name 'de' is not defined'. My guess is that it got part way through reading "def get_foo(): return 1" and hit the end of a buffer. Or something. At this point, its beyond my C/Python code skills to track it down. Hopefully its just some minor error in re-loading the code from the new zip file you guys can easily find. I can't see where to upload a patch file, so you can get what I'm currently playing with at: http://sh5.beachead.com:8080/~stephen/patch.txt Note the import.c patch is the same, the new patch just adds stuff to Skip's testReload function to try loading code from a new zip file. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-04-02 06:23 Message: Logged In: YES user_id=44345 > what doesn't work for you? Sorry. Pilot error. I was adding foozip.zip to sys.path then trying from foozip import somemodule instead of just import somemodule (Obvious, not a feature I use a lot...) Seems to be working for me now. I'll try a couple more tests then check it in. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-04-02 01:00 Message: Logged In: YES user_id=92689 The import.c patch looks fine (although I didn't test it yet). Skip, what doesn't work for you? "I can't get zip imports to work" is quite broad... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-04-01 21:37 Message: Logged In: YES user_id=44345 attached is the patch to protect it from the vagaries of cut-n- paste. I also added a simple testReload test to the test_zipimport.py file. I can't get zip imports to work. Perhaps Just can test this out. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-01 18:26 Message: Logged In: YES user_id=642545 Here's a patch that fixes the problem so that modules from zip files can be reloaded. The problem was the PyImport_ReloadModulefunction not passing a loader around. Perhaps this is naive, and the PyImport_ReloadModule was purposefully not using a loader, but, again, it works for me. cvs diff -u dist\src\Python\import.c (in directory C:\cvs\python\) Index: dist/src/Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.230 diff -u -r2.230 import.c --- dist/src/Python/import.c 1 Apr 2004 02:45:22 -0000 2.230 +++ dist/src/Python/import.c 2 Apr 2004 00:18:46 -0000 @@ -2217,7 +2217,7 @@ PyImport_ReloadModule(PyObject *m) { PyObject *modules = PyImport_GetModuleDict(); - PyObject *path = NULL; + PyObject *path, *loader = NULL; char *name, *subname; char buf[MAXPATHLEN+1]; struct filedescr *fdp; @@ -2259,11 +2259,12 @@ PyErr_Clear(); } buf[0] = '\0'; - fdp = find_module(name, subname, path, buf, MAXPATHLEN+1, &fp, NULL); + fdp = find_module(name, subname, path, buf, MAXPATHLEN+1, &fp, &loader); Py_XDECREF(path); if (fdp == NULL) return NULL; - m = load_module(name, fp, buf, fdp->type, NULL); + m = load_module(name, fp, buf, fdp->type, loader); + Py_XDECREF(loader); if (fp) fclose(fp); return m; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&group_id=5470 From noreply at sourceforge.net Fri Apr 2 10:59:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 2 11:00:02 2004 Subject: [ python-Bugs-928297 ] platform.libc_ver() fails on Cygwin Message-ID: Bugs item #928297, was opened at 2004-04-02 16:55 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=928297&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: M.-A. Lemburg (lemburg) Summary: platform.libc_ver() fails on Cygwin Initial Comment: >>> import platform >>> platform.libc_ver() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/platform.py", line 134, in libc_ver f = open(executable,'rb') IOError: [Errno 2] No such file or directory: '/usr/bin/python' The problem is that on Cygwin sys.executable returns /path/to/python, but since Cygwin is running on Windows, sys.executable is a symbolic link to /path/to/python.exe. >>> import os, sys >>> os.path.exists(sys.executable) True >>> os.path.isfile(sys.executable) True >>> file(sys.executable) Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 2] No such file or directory: '/usr/bin/python' >>> os.path.islink(sys.executable) True >>> os.path.realpath(sys.executable) '/usr/bin/python2.3.exe' >>> file(sys.executable + '.exe') Following is the info about the machine I tested: >>> from platform import * >>> platform() 'CYGWIN_NT-5.0-1.5.7-0.109-3-2-i686-32bit' >>> python_compiler() 'GCC 3.3.1 (cygming special)' >>> python_build() (1, 'Dec 30 2003 08:29:25') >>> python_version() '2.3.3' >>> uname() ('CYGWIN_NT-5.0', 'my_user_name', '1.5.7 (0.109/3/2)', '2004-01-30 19:32', 'i686', '') ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-04-02 17:59 Message: Logged In: YES user_id=38388 Patches are welcome :-) I don't have cygwin installed, so there's nothing much I can do about this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=928297&group_id=5470 From noreply at sourceforge.net Fri Apr 2 11:03:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 2 11:04:05 2004 Subject: [ python-Bugs-765228 ] Subclassing from Modules Message-ID: Bugs item #765228, was opened at 2003-07-03 12:32 Message generated for change (Settings changed) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765228&group_id=5470 Category: Python Interpreter Core >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Nobody/Anonymous (nobody) Summary: Subclassing from Modules Initial Comment: In Python 2.2.3 there's a problem with accidental subclassing from a Python module, e.g. import MyStuff class A(MyStuff): pass this gives no error until you try to instantiate the class: o = A() TypeError: 'module' object is not callable In Python 2.3 the error is generated at module startup time: class A(MyStuff): pass TypeError: function takes at most 2 arguments (3 given) Since it is rather common that you create modules which have the same name as their most important class, I would find it more appropriate to raise a TypeError with a message "can't subclass a module instance" in both versions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765228&group_id=5470 From noreply at sourceforge.net Fri Apr 2 11:35:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 2 11:37:20 2004 Subject: [ python-Bugs-856103 ] reload() fails with modules from zips Message-ID: Bugs item #856103, was opened at 2003-12-08 02:48 Message generated for change (Comment added) made by filitov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Skip Montanaro (montanaro) Summary: reload() fails with modules from zips Initial Comment: If you call reload() with a module that was imported from a zip, it fails with a "no such module" error. Although zips are typically read-only, it is possible that a zip could be modified during a run, and a reload be necessary. If this is considered unnecessary, then I think a more informative "can't reload from zip" error would be better than a 'no such module" one. """ >set PYTHONPATH=path/to/spambayes.zip >python >>> from spambayes import Options >>> Options >>> reload(Options) Traceback (most recent call last): File "", line 1, in ? ImportError: No module named Options """ This is with Python 2.3.2 and WinXP. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-02 10:35 Message: Logged In: YES user_id=642545 So, upon some more investigation, it looks like the problem is that the toc_entry from the old zip file is being used, which has the old file size, not the new file size. It looks like in zipimport.c, line 126, where the zip_directory_cache is used to cache all of the toc_entry's for a zip file, a check on the zip file modification should be made, just as the modification check is done vs. .py files, I would imagine. This would require storing another a tuple in zip_directory_cache of (modification_time, list of toc_entry's). Let me know if you want me to take a shot at implementing this. Otherwise I'd prefer deferring to you guys, as I assume you can do it with much less time and much higher quality than I could. Thanks. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-02 09:38 Message: Logged In: YES user_id=642545 Actually, it doesn't seem to be working fully. I've been playing with Skip's test patch and it looks like the code it reloads uses...the same buffer size as it did with the original read? You can play with replacing 'return __name__' with different strings and it will change the error you get. E.g. with 'return __name__+"modified"', it parses fine, but get_foo() is not found (which is added after get_name()). E.g. with 'return "new"', it does not parse fine, it returns 'NameError: name 'de' is not defined'. My guess is that it got part way through reading "def get_foo(): return 1" and hit the end of a buffer. Or something. At this point, its beyond my C/Python code skills to track it down. Hopefully its just some minor error in re-loading the code from the new zip file you guys can easily find. I can't see where to upload a patch file, so you can get what I'm currently playing with at: http://sh5.beachead.com:8080/~stephen/patch.txt Note the import.c patch is the same, the new patch just adds stuff to Skip's testReload function to try loading code from a new zip file. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-04-02 06:23 Message: Logged In: YES user_id=44345 > what doesn't work for you? Sorry. Pilot error. I was adding foozip.zip to sys.path then trying from foozip import somemodule instead of just import somemodule (Obvious, not a feature I use a lot...) Seems to be working for me now. I'll try a couple more tests then check it in. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-04-02 01:00 Message: Logged In: YES user_id=92689 The import.c patch looks fine (although I didn't test it yet). Skip, what doesn't work for you? "I can't get zip imports to work" is quite broad... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-04-01 21:37 Message: Logged In: YES user_id=44345 attached is the patch to protect it from the vagaries of cut-n- paste. I also added a simple testReload test to the test_zipimport.py file. I can't get zip imports to work. Perhaps Just can test this out. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-01 18:26 Message: Logged In: YES user_id=642545 Here's a patch that fixes the problem so that modules from zip files can be reloaded. The problem was the PyImport_ReloadModulefunction not passing a loader around. Perhaps this is naive, and the PyImport_ReloadModule was purposefully not using a loader, but, again, it works for me. cvs diff -u dist\src\Python\import.c (in directory C:\cvs\python\) Index: dist/src/Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.230 diff -u -r2.230 import.c --- dist/src/Python/import.c 1 Apr 2004 02:45:22 -0000 2.230 +++ dist/src/Python/import.c 2 Apr 2004 00:18:46 -0000 @@ -2217,7 +2217,7 @@ PyImport_ReloadModule(PyObject *m) { PyObject *modules = PyImport_GetModuleDict(); - PyObject *path = NULL; + PyObject *path, *loader = NULL; char *name, *subname; char buf[MAXPATHLEN+1]; struct filedescr *fdp; @@ -2259,11 +2259,12 @@ PyErr_Clear(); } buf[0] = '\0'; - fdp = find_module(name, subname, path, buf, MAXPATHLEN+1, &fp, NULL); + fdp = find_module(name, subname, path, buf, MAXPATHLEN+1, &fp, &loader); Py_XDECREF(path); if (fdp == NULL) return NULL; - m = load_module(name, fp, buf, fdp->type, NULL); + m = load_module(name, fp, buf, fdp->type, loader); + Py_XDECREF(loader); if (fp) fclose(fp); return m; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&group_id=5470 From noreply at sourceforge.net Fri Apr 2 11:48:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 2 11:49:02 2004 Subject: [ python-Bugs-474836 ] Tix not included in windows distribution Message-ID: Bugs item #474836, was opened at 2001-10-25 13:22 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Thomas Heller (theller) Summary: Tix not included in windows distribution Initial Comment: Although there is a Tix.py available, there is no Tix support in the precomiled Python-distribution for windows. So import Tix works fine, but root = Tix.Tk() results in TclError: package not found. It is possible to circumvent this problem by installing a regular Tcl/Tk distribution (e.g. in c:\programme\tcl) and installing Tix in the regular Tcl-path (i.e. tcl\lib). Mathias ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2004-04-02 18:48 Message: Logged In: YES user_id=11105 Problem seems to be that tix8184.dll is not found, and neither of the entries in tcl\tix8.1\pkgIndex.tcl seem to work. Adding a line lappend dirs /python23/DLLs helps when the whole stuff is installed in c:\Python23, but this cannot be the solution. OTOH, I don't know anything of tcl, so I cannot proceed. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-04-01 22:16 Message: Logged In: YES user_id=11105 I've built according to your instructions (slightly adjusted), then copied tix8184.dll to the DLLs directory (of a Python 2.3.3, installed with the windows installer), and the tix8.1 directory into the tcl directory (sibling of tcl8.4, tk8.4 and so on). Demo\tixwidgets.py complains: Traceback (most recent call last): File "c:\sf\python\dist23\src\Demo\tix\tixwidgets.py", line 1002, in ? root = Tix.Tk() File "C:\Python23\lib\lib-tk\Tix.py", line 210, in __init__ self.tk.eval('package require Tix') _tkinter.TclError: couldn't load library "tix8184.dll": this library or a dependent library could not be found in library path Any advise? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-03-31 22:03 Message: Logged In: YES user_id=21627 The instructions from 2003-04-26/2003-06-15 should still be valid. For 2.4, the story will be different, as Tix does not currently build with VC7. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2004-03-31 21:43 Message: Logged In: YES user_id=11105 I'm willing to do some work to include tix in Python 2.3.4, if someone can update the instructions. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-02-24 18:16 Message: Logged In: YES user_id=764593 Note that the problem is still there in 2.3.3; if it can't be fixed, could the documentation at least mention that Tix requires 3rd-party libraries on Windows? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 15:15 Message: Logged In: YES user_id=21627 Reassigning to Thomas, who is doing Windows releases these days. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-03 15:13 Message: Logged In: YES user_id=31435 Unassigned (doesn't look like I'll ever get time for this). ---------------------------------------------------------------------- Comment By: Aaron Optimizer Digulla (digulla) Date: 2003-10-03 13:10 Message: Logged In: YES user_id=606 loewis, when will your package show up in the official Python distribution? It's still not there in 2.3.2 :-( ---------------------------------------------------------------------- Comment By: Aaron Optimizer Digulla (digulla) Date: 2003-07-28 15:22 Message: Logged In: YES user_id=606 The Tix8184.dll is still missing in Python 2.3c2. The included Tix8183.dll (which is in the directory tcl\tix8.1\ along with a couple of other dlls -> can't be found by Python) is linked against Tcl/Tk 8.3. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-06-15 14:40 Message: Logged In: YES user_id=21627 I found that the instructions need slight modification: In step 2, use tk...\mkd.bat for mkdir. Apart from that, these instructions work fine for me, now. I have made a binary release of tix8.1 for Python 2.3 at http://www.dcl.hpi.uni-potsdam.de/home/loewis/tix8.1.zip The tix8184.dll goes to DLLs, the tix8.1 subdirectory goes to tcl. It differs from the standard tix8.1 subdirectory only in fixing the path to the DLLs directory. To test whether this works, execute Demo/tix/tixwidgets.py. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-04-26 12:22 Message: Logged In: YES user_id=21627 I still think Python should include Tix. Here are some instructions on how to make Tix 8.1.4 work: 1. Unpack as a sibling of tcl8.4.1 and tk8.4.1 2. Edit win\common.mk, to set the following variables TCL_VER=8.4 INSTALLDIR= MKDIR=mkdir 3. Edit win\makefile.vc, to set the following variables TOOLS32= TOOLS32_rc= 4. Edit win\tk\pkgindex.tcl, to replace lappend dirs ../../Dlls with lappend dirs [file join [file dirname [info nameofexe]] Dlls] 5. nmake -f makefile.vc 6. nmake -f makefile.vc install 7. Copy INSTALLDIR\bin\tix8184.dll to \DLLs 8. Optionally copy tix8184.lib somewhere 9. copy INSTALLDIR\lib\tix8.1 into \tcl With these instructions, invoking t.tk.eval("package require Tix") succeeds. For some reason, Tix won't still find any of the commands; I'll investigate this later. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-12-11 10:14 Message: Logged In: YES user_id=33229 My you're courageous - going with a version of Tcl that doesn't even pass its own tests :-) Been there, seen it, done it .... 8.1.4 will be out this week, which compiles with 8.4 but I don't expect it to "support" 8.4 for a while yet (they added more problems in 8.4.1). 8.3.5 is definitely "supported". Check back with me before 2.3 goes into beta and I'll do another minor release if necessary. Maybe Tk will test clean then. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-20 02:36 Message: Logged In: YES user_id=31435 Parents shouldn't disagree in front of their children . Not all the Tcl or Tk tests (their tests, not ours) passed when I built 8.4.1, but I couldn't (and can't) make time to dig into that, and all the Python stuff I tried worked fine. So I don't fear 8.4, and am inclined to accept Martin's assurance that 8.4 is best for Python. We intend to put out the first 2.3 Python alpha by the end of the year, and my bet is it won't be a minute before that. If Tix 8.1.4 is at RC3 now, I'd *guess* you'll have a final release out well before then. Yes? No? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-19 23:12 Message: Logged In: YES user_id=21627 I think the recommendation cannot apply to Python; I'm very much in favour of releasing Python 2.3 with Tk 8.4.x. So the question then is whether Python 2.3 should include Tix 8.1.4 or no Tix at all, and at what time Tix 8.1.4 can be expected. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-19 20:10 Message: Logged In: YES user_id=33229 Look on http://tix.sourceforge.net/download.shtml for Tix 8.1.4 RC3. It works with Tk 8.4.1 and passes the test suite, but there are still issues with Tk 8.4 and it has not been widely tested with yet with 8.4.1, so we still recommend 8.3.5. (Tcl major releases often aren't stable until patch .3 or so.) If you have any problems let me know directly by email and I'll try and help. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-18 17:35 Message: Logged In: YES user_id=31435 Does Tix 8.1.3 play with Tcl/Tk 8.4.1? The 2.3. Windows distro is set up to include the latter now. The win\common.mak file from Tix 8.1.3 doesn't have a section for Tcl/Tk 8.4, though. There appear to be several reasons Tix won't compile on my box anyway without fiddling the Tix makefiles (e.g., my VC doesn't live in \DevStudio), so before spending more time on that I'd like to know whether it's doomed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 15:52 Message: Logged In: YES user_id=6380 I support this. Tim, I know you're not a big Tk user (to say the least). I'll offer to help in person. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 08:30 Message: Logged In: YES user_id=33229 I would really like to see Tix in 2.3 and will be glad to help. AFAIK there are no major issues with tix-8.1.3 and Python 2.x and it should be a simple drop in of a cannonically compiled Tix. If there are any issues that need dealing with at Tix's end, I'll be glad to put out a new minor release of Tix to address them. On Python's end I've suggested a fix for http://python.org/sf/564729 FYI, please also see my comments for bug 632323. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 06:34 Message: Logged In: YES user_id=33229 I would really like to see Tix in 2.3 and will be glad to help. AFAIK there are no major issues with tix-8.1.3 and Python 2.x and it should be a simple drop in of a cannonically compiled Tix. If there are any issues that need dealing with at Tix's end, I'll be glad to put out a new minor release of Tix to address them. On Python's end I've suggested a fix for http://python.org/sf/564729 FYI, please also see my comments for bug 632323. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-23 04:34 Message: Logged In: YES user_id=6380 Yes, for 2.3. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-10 02:48 Message: Logged In: YES user_id=31435 Guido, do you want me to spend time on this? ---------------------------------------------------------------------- Comment By: Mathias Palm (monos) Date: 2002-03-07 14:38 Message: Logged In: YES user_id=361926 Thanks. Mathias ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-02-25 13:57 Message: Logged In: YES user_id=21627 The zip file is slightly too large for SF, so it is now at http://www.informatik.hu- berlin.de/~loewis/python/tix813win.zip ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-02-25 13:56 Message: Logged In: YES user_id=21627 Building Tix from sources is non-trivial, and I could not find any recent Windows binary distribution (based on Tix 8.1). So I'll attach a build of Tix 8.1.3 for Tcl/Tk 8.3, as a drop-in into the Python binary distribution. Compared to the original distribution, only tix8.1 \pkgIndex.tcl required tweaking, to tell it that tix8183.dll can be found in the DLLs subdirectory. Also, unless TIX_LIBRARY is set, the Tix tcl files *must* live in tcl\tix8.1, since tix8183.dll will look in TCL_LIBRARY\..\tix (among other locations). If a major Tcl release happens before Python 2.3 is released (and it is then still desirable to distribute Python with Tix), these binaries need to be regenerated. Would these instructions (unpack zip file into distribution tree) be precise enough to allow incorporation into the windows installer? ---------------------------------------------------------------------- Comment By: Mathias Palm (monos) Date: 2001-10-29 12:53 Message: Logged In: YES user_id=361926 As mentioned in the mail above (by me, Mathias), Tix is a package belonging to Tcl/Tk (to be found on sourceforge: tix.sourceforge.net, or via the Python home page - tkinter link). Everything needed can be found there, just read about it (and dont forget about the winking, eyes might be getting dry) Mathias ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-25 20:26 Message: Logged In: YES user_id=31435 I don't know anything about Tix, so if somebody wants this in the Windows installer, they're going to have to explain exactly (by which I mean exactly <0.5 wink>) what's needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470 From noreply at sourceforge.net Fri Apr 2 11:53:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 2 11:54:37 2004 Subject: [ python-Bugs-856103 ] reload() fails with modules from zips Message-ID: Bugs item #856103, was opened at 2003-12-08 09:48 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Skip Montanaro (montanaro) Summary: reload() fails with modules from zips Initial Comment: If you call reload() with a module that was imported from a zip, it fails with a "no such module" error. Although zips are typically read-only, it is possible that a zip could be modified during a run, and a reload be necessary. If this is considered unnecessary, then I think a more informative "can't reload from zip" error would be better than a 'no such module" one. """ >set PYTHONPATH=path/to/spambayes.zip >python >>> from spambayes import Options >>> Options >>> reload(Options) Traceback (most recent call last): File "", line 1, in ? ImportError: No module named Options """ This is with Python 2.3.2 and WinXP. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2004-04-02 18:53 Message: Logged In: YES user_id=92689 Hm, I forgot about the caching of directory info. I don't think properly supporting reloading from zip files is worth the effort. It would be nice if it failed nicer, though. The reload patch is still cool, though, since it should fix reloading with PEP 302-style importers in general (yet zipimport may still choose not to support it). A reload test in test_importhooks.py would be a great addition. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-02 18:35 Message: Logged In: YES user_id=642545 So, upon some more investigation, it looks like the problem is that the toc_entry from the old zip file is being used, which has the old file size, not the new file size. It looks like in zipimport.c, line 126, where the zip_directory_cache is used to cache all of the toc_entry's for a zip file, a check on the zip file modification should be made, just as the modification check is done vs. .py files, I would imagine. This would require storing another a tuple in zip_directory_cache of (modification_time, list of toc_entry's). Let me know if you want me to take a shot at implementing this. Otherwise I'd prefer deferring to you guys, as I assume you can do it with much less time and much higher quality than I could. Thanks. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-02 17:38 Message: Logged In: YES user_id=642545 Actually, it doesn't seem to be working fully. I've been playing with Skip's test patch and it looks like the code it reloads uses...the same buffer size as it did with the original read? You can play with replacing 'return __name__' with different strings and it will change the error you get. E.g. with 'return __name__+"modified"', it parses fine, but get_foo() is not found (which is added after get_name()). E.g. with 'return "new"', it does not parse fine, it returns 'NameError: name 'de' is not defined'. My guess is that it got part way through reading "def get_foo(): return 1" and hit the end of a buffer. Or something. At this point, its beyond my C/Python code skills to track it down. Hopefully its just some minor error in re-loading the code from the new zip file you guys can easily find. I can't see where to upload a patch file, so you can get what I'm currently playing with at: http://sh5.beachead.com:8080/~stephen/patch.txt Note the import.c patch is the same, the new patch just adds stuff to Skip's testReload function to try loading code from a new zip file. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-04-02 14:23 Message: Logged In: YES user_id=44345 > what doesn't work for you? Sorry. Pilot error. I was adding foozip.zip to sys.path then trying from foozip import somemodule instead of just import somemodule (Obvious, not a feature I use a lot...) Seems to be working for me now. I'll try a couple more tests then check it in. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-04-02 09:00 Message: Logged In: YES user_id=92689 The import.c patch looks fine (although I didn't test it yet). Skip, what doesn't work for you? "I can't get zip imports to work" is quite broad... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-04-02 05:37 Message: Logged In: YES user_id=44345 attached is the patch to protect it from the vagaries of cut-n- paste. I also added a simple testReload test to the test_zipimport.py file. I can't get zip imports to work. Perhaps Just can test this out. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-02 02:26 Message: Logged In: YES user_id=642545 Here's a patch that fixes the problem so that modules from zip files can be reloaded. The problem was the PyImport_ReloadModulefunction not passing a loader around. Perhaps this is naive, and the PyImport_ReloadModule was purposefully not using a loader, but, again, it works for me. cvs diff -u dist\src\Python\import.c (in directory C:\cvs\python\) Index: dist/src/Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.230 diff -u -r2.230 import.c --- dist/src/Python/import.c 1 Apr 2004 02:45:22 -0000 2.230 +++ dist/src/Python/import.c 2 Apr 2004 00:18:46 -0000 @@ -2217,7 +2217,7 @@ PyImport_ReloadModule(PyObject *m) { PyObject *modules = PyImport_GetModuleDict(); - PyObject *path = NULL; + PyObject *path, *loader = NULL; char *name, *subname; char buf[MAXPATHLEN+1]; struct filedescr *fdp; @@ -2259,11 +2259,12 @@ PyErr_Clear(); } buf[0] = '\0'; - fdp = find_module(name, subname, path, buf, MAXPATHLEN+1, &fp, NULL); + fdp = find_module(name, subname, path, buf, MAXPATHLEN+1, &fp, &loader); Py_XDECREF(path); if (fdp == NULL) return NULL; - m = load_module(name, fp, buf, fdp->type, NULL); + m = load_module(name, fp, buf, fdp->type, loader); + Py_XDECREF(loader); if (fp) fclose(fp); return m; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&group_id=5470 From noreply at sourceforge.net Fri Apr 2 11:01:08 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 2 12:03:00 2004 Subject: [ python-Bugs-880951 ] "ez" format code for ParseTuple() Message-ID: Bugs item #880951, was opened at 2004-01-21 00:03 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=880951&group_id=5470 Category: Unicode Group: Feature Request Status: Open Resolution: None >Priority: 3 Submitted By: Jon Willeke (willeke) Assigned to: M.-A. Lemburg (lemburg) Summary: "ez" format code for ParseTuple() Initial Comment: I'm using Python 2.3.3 on SuSE Linux 8.2. It would be nice to have an "ez" format code that is to "es" as "z" is to "s". Whereas the "s" and "z" codes depend on the default encoding, "es" lets you specify the encoding, which is useful for interfacing with GTK+ and GNOME libraries, which have largely standardized on UTF-8. I think it is possible to simulate the desired behavior with "O&", but it would be simpler with "ez". ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-04-02 18:01 Message: Logged In: YES user_id=38388 No answers... lowering the priority. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-03-25 18:41 Message: Logged In: YES user_id=38388 Can you elaborate on the use case ? I'm asking because I don't find the 'z' code particulary useful myself because there are more elegant ways to deal with optional arguments. ---------------------------------------------------------------------- Comment By: Jon Willeke (willeke) Date: 2004-01-22 00:29 Message: Logged In: YES user_id=185468 I'm attaching a patch that adds support for the "ez" and "ez#" format codes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=880951&group_id=5470 From noreply at sourceforge.net Fri Apr 2 11:00:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 2 12:03:27 2004 Subject: [ python-Bugs-928332 ] Python interpreter stalled on _PyPclose.WaitForSingleObject Message-ID: Bugs item #928332, was opened at 2004-04-02 16:00 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=928332&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Popov (evgeni_popov) Assigned to: Thomas Heller (theller) Summary: Python interpreter stalled on _PyPclose.WaitForSingleObject Initial Comment: Windows only: You can easily block the whole interpreter by starting a lengthy/blocking external process with os.popenX: import os, time, threading def showtime(): while 1: print '.' time.sleep(1) th1 = threading.Thread(None, showtime, None) th1.start() fo = os.popen('cscript waitforever.vbs', 'rt') res = fo.close() print 'ok' waitforever.vbs has a single line: WScript.Sleep (2000000000) You will never reach print 'ok', which is the expected behaviour because fo.close() is waiting for the process to stop, something which will never happen. The problem is that the 'showtime' thread is also blocked ! Indeed, when looking with the debugger, we can see that the main thread is blocked in the _PyPclose.WaitForSingleObject call, but the GIL has not been released before entering this wait, so any other Python thread are blocked too. So I think that the GIL should be released before the WaitForSingleObject call. Also, something different from INFINITE as the second parameter may be appropriate (defined by the user, for eg, would be great)... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=928332&group_id=5470 From noreply at sourceforge.net Fri Apr 2 12:33:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 2 12:33:13 2004 Subject: [ python-Bugs-928332 ] Python interpreter stalled on _PyPclose.WaitForSingleObject Message-ID: Bugs item #928332, was opened at 2004-04-02 18:00 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=928332&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Popov (evgeni_popov) >Assigned to: Nobody/Anonymous (nobody) Summary: Python interpreter stalled on _PyPclose.WaitForSingleObject Initial Comment: Windows only: You can easily block the whole interpreter by starting a lengthy/blocking external process with os.popenX: import os, time, threading def showtime(): while 1: print '.' time.sleep(1) th1 = threading.Thread(None, showtime, None) th1.start() fo = os.popen('cscript waitforever.vbs', 'rt') res = fo.close() print 'ok' waitforever.vbs has a single line: WScript.Sleep (2000000000) You will never reach print 'ok', which is the expected behaviour because fo.close() is waiting for the process to stop, something which will never happen. The problem is that the 'showtime' thread is also blocked ! Indeed, when looking with the debugger, we can see that the main thread is blocked in the _PyPclose.WaitForSingleObject call, but the GIL has not been released before entering this wait, so any other Python thread are blocked too. So I think that the GIL should be released before the WaitForSingleObject call. Also, something different from INFINITE as the second parameter may be appropriate (defined by the user, for eg, would be great)... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=928332&group_id=5470 From noreply at sourceforge.net Fri Apr 2 15:49:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 2 15:49:59 2004 Subject: [ python-Bugs-884085 ] OSATerminology is broken Message-ID: Bugs item #884085, was opened at 2004-01-25 12:32 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=884085&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: OSATerminology is broken Initial Comment: the terminologyID is actually not supposed to come from the current dialect. Since Apple doesn't really support non- English dialects anymore anyway (as far as I can tell), I'm just going to keep it as zero. Here's a patch (that just comments that stuff out, so it can be further tested). ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2004-04-02 22:49 Message: Logged In: YES user_id=45365 This whole bit of code is a silly misunderstanding. I'll rip it out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=884085&group_id=5470 From noreply at sourceforge.net Fri Apr 2 18:26:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 2 18:27:36 2004 Subject: [ python-Bugs-856103 ] reload() fails with modules from zips Message-ID: Bugs item #856103, was opened at 2003-12-08 02:48 Message generated for change (Comment added) made by filitov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Skip Montanaro (montanaro) Summary: reload() fails with modules from zips Initial Comment: If you call reload() with a module that was imported from a zip, it fails with a "no such module" error. Although zips are typically read-only, it is possible that a zip could be modified during a run, and a reload be necessary. If this is considered unnecessary, then I think a more informative "can't reload from zip" error would be better than a 'no such module" one. """ >set PYTHONPATH=path/to/spambayes.zip >python >>> from spambayes import Options >>> Options >>> reload(Options) Traceback (most recent call last): File "", line 1, in ? ImportError: No module named Options """ This is with Python 2.3.2 and WinXP. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-02 17:26 Message: Logged In: YES user_id=642545 Okay, so you talked me in to it. Besides the previous PyImport_ReloadModule patch, I modified zipimport.c to add another cache (zip_directory_cache of toc_entry's and zip_mtime_cache of modification times). On creation of a new ZipImporter or call to get_module_code, check_archive_mtime is called, which gets the new mtime and compares to the cached one. If they are different, it calls the old read_directory. read_directory was modified to, instead of creating a brand new path: [toc_entry] dictionary, clear and re-populate the same 'files' dictionary. This is so that if multiple ZipImporters are sharing an archive, and hence already sharing the same 'files' entry in zip_directory_cache, if one of them detects a new zip file and has the toc_entry's reloaded, the other ZipImporters will see the change to (as they all share the same dictionary). This was pretty much the same functionality before (sharing dictionaries), just that now read_directory clears/updates an exisitng one instead creating its own brand new one. Also, I had to add a sleep(1) call in testReload to ensure the modification time stamp would change. Again, either I don't have permissions to upload files, or I just can't figure it out, so the patch is at: http://sh5.beachead.com:8080/~stephen/patch.txt This is my first foray into Python coding, so double checking all of the reference counting inc/dec stuff would be a really good idea. I also took about 20 minutes to look at adding a reload test to test_importhooks.py, as suggested, but couldn't get it to work. I couldn't tell if it was because I was writing a flawed test (which is what I am suspecting) or if the PyImport_ReloadModule patch was not working. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-04-02 10:53 Message: Logged In: YES user_id=92689 Hm, I forgot about the caching of directory info. I don't think properly supporting reloading from zip files is worth the effort. It would be nice if it failed nicer, though. The reload patch is still cool, though, since it should fix reloading with PEP 302-style importers in general (yet zipimport may still choose not to support it). A reload test in test_importhooks.py would be a great addition. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-02 10:35 Message: Logged In: YES user_id=642545 So, upon some more investigation, it looks like the problem is that the toc_entry from the old zip file is being used, which has the old file size, not the new file size. It looks like in zipimport.c, line 126, where the zip_directory_cache is used to cache all of the toc_entry's for a zip file, a check on the zip file modification should be made, just as the modification check is done vs. .py files, I would imagine. This would require storing another a tuple in zip_directory_cache of (modification_time, list of toc_entry's). Let me know if you want me to take a shot at implementing this. Otherwise I'd prefer deferring to you guys, as I assume you can do it with much less time and much higher quality than I could. Thanks. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-02 09:38 Message: Logged In: YES user_id=642545 Actually, it doesn't seem to be working fully. I've been playing with Skip's test patch and it looks like the code it reloads uses...the same buffer size as it did with the original read? You can play with replacing 'return __name__' with different strings and it will change the error you get. E.g. with 'return __name__+"modified"', it parses fine, but get_foo() is not found (which is added after get_name()). E.g. with 'return "new"', it does not parse fine, it returns 'NameError: name 'de' is not defined'. My guess is that it got part way through reading "def get_foo(): return 1" and hit the end of a buffer. Or something. At this point, its beyond my C/Python code skills to track it down. Hopefully its just some minor error in re-loading the code from the new zip file you guys can easily find. I can't see where to upload a patch file, so you can get what I'm currently playing with at: http://sh5.beachead.com:8080/~stephen/patch.txt Note the import.c patch is the same, the new patch just adds stuff to Skip's testReload function to try loading code from a new zip file. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-04-02 06:23 Message: Logged In: YES user_id=44345 > what doesn't work for you? Sorry. Pilot error. I was adding foozip.zip to sys.path then trying from foozip import somemodule instead of just import somemodule (Obvious, not a feature I use a lot...) Seems to be working for me now. I'll try a couple more tests then check it in. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2004-04-02 01:00 Message: Logged In: YES user_id=92689 The import.c patch looks fine (although I didn't test it yet). Skip, what doesn't work for you? "I can't get zip imports to work" is quite broad... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-04-01 21:37 Message: Logged In: YES user_id=44345 attached is the patch to protect it from the vagaries of cut-n- paste. I also added a simple testReload test to the test_zipimport.py file. I can't get zip imports to work. Perhaps Just can test this out. ---------------------------------------------------------------------- Comment By: Stephen Haberman (filitov) Date: 2004-04-01 18:26 Message: Logged In: YES user_id=642545 Here's a patch that fixes the problem so that modules from zip files can be reloaded. The problem was the PyImport_ReloadModulefunction not passing a loader around. Perhaps this is naive, and the PyImport_ReloadModule was purposefully not using a loader, but, again, it works for me. cvs diff -u dist\src\Python\import.c (in directory C:\cvs\python\) Index: dist/src/Python/import.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/import.c,v retrieving revision 2.230 diff -u -r2.230 import.c --- dist/src/Python/import.c 1 Apr 2004 02:45:22 -0000 2.230 +++ dist/src/Python/import.c 2 Apr 2004 00:18:46 -0000 @@ -2217,7 +2217,7 @@ PyImport_ReloadModule(PyObject *m) { PyObject *modules = PyImport_GetModuleDict(); - PyObject *path = NULL; + PyObject *path, *loader = NULL; char *name, *subname; char buf[MAXPATHLEN+1]; struct filedescr *fdp; @@ -2259,11 +2259,12 @@ PyErr_Clear(); } buf[0] = '\0'; - fdp = find_module(name, subname, path, buf, MAXPATHLEN+1, &fp, NULL); + fdp = find_module(name, subname, path, buf, MAXPATHLEN+1, &fp, &loader); Py_XDECREF(path); if (fdp == NULL) return NULL; - m = load_module(name, fp, buf, fdp->type, NULL); + m = load_module(name, fp, buf, fdp->type, loader); + Py_XDECREF(loader); if (fp) fclose(fp); return m; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=856103&group_id=5470 From noreply at sourceforge.net Fri Apr 2 23:20:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Apr 2 23:21:12 2004 Subject: [ python-Bugs-928297 ] platform.libc_ver() fails on Cygwin Message-ID: Bugs item #928297, was opened at 2004-04-02 23:55 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=928297&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: M.-A. Lemburg (lemburg) Summary: platform.libc_ver() fails on Cygwin Initial Comment: >>> import platform >>> platform.libc_ver() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/platform.py", line 134, in libc_ver f = open(executable,'rb') IOError: [Errno 2] No such file or directory: '/usr/bin/python' The problem is that on Cygwin sys.executable returns /path/to/python, but since Cygwin is running on Windows, sys.executable is a symbolic link to /path/to/python.exe. >>> import os, sys >>> os.path.exists(sys.executable) True >>> os.path.isfile(sys.executable) True >>> file(sys.executable) Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 2] No such file or directory: '/usr/bin/python' >>> os.path.islink(sys.executable) True >>> os.path.realpath(sys.executable) '/usr/bin/python2.3.exe' >>> file(sys.executable + '.exe') Following is the info about the machine I tested: >>> from platform import * >>> platform() 'CYGWIN_NT-5.0-1.5.7-0.109-3-2-i686-32bit' >>> python_compiler() 'GCC 3.3.1 (cygming special)' >>> python_build() (1, 'Dec 30 2003 08:29:25') >>> python_version() '2.3.3' >>> uname() ('CYGWIN_NT-5.0', 'my_user_name', '1.5.7 (0.109/3/2)', '2004-01-30 19:32', 'i686', '') ---------------------------------------------------------------------- >Comment By: George Yoshida (quiver) Date: 2004-04-03 13:20 Message: Logged In: YES user_id=671362 First, I need to correct my previous post. 'symbolic' was unrelated. Python on Cygwin does't like exe files that doesn't end with '.exe'. I think changing fileobject.c to support I/O exe files on Cygwin whether it ends with '.exe' or not is the way to go. Is there anyone who can do that? It's beyoond my skill level. $ ls -l /usr/bin/python* lrwxrwxrwx 1 abel Users 24 Jan 1 01:34 /usr/bin/python - > python2.3.exe lrwxrwxrwx 1 abel Users 24 Jan 1 01:34 /usr/bin/python.exe -> python2.3.exe -rwxrwxrwx 1 abel Users 4608 Dec 30 22:32 /usr/bin/python2.3.exe >>> file('/usr/bin/python') Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 2] No such file or directory: '/usr/bin/python' >>> file('/usr/bin/python.exe') >>> file('/usr/bin/python2.3') Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 2] No such file or directory: '/usr/bin/python2.3' >>> file('/usr/bin/python2.3.exe') ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-04-03 00:59 Message: Logged In: YES user_id=38388 Patches are welcome :-) I don't have cygwin installed, so there's nothing much I can do about this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=928297&group_id=5470 From noreply at sourceforge.net Sat Apr 3 02:14:09 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 3 02:15:33 2004 Subject: [ python-Bugs-928751 ] Typo in 7.2.1: socket.connect_ex Message-ID: Bugs item #928751, was opened at 2004-04-02 23:14 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=928751&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: PieOnCar (pieoncar) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in 7.2.1: socket.connect_ex Initial Comment: The last line in connect_ex says "... is no longer be available..." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=928751&group_id=5470 From noreply at sourceforge.net Sat Apr 3 11:00:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 3 11:01:03 2004 Subject: [ python-Bugs-928881 ] Default encoding harmful Message-ID: Bugs item #928881, was opened at 2004-04-03 18:00 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=928881&group_id=5470 Category: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Toni Goeller (tgoeller) Assigned to: M.-A. Lemburg (lemburg) Summary: Default encoding harmful Initial Comment: Although I am a newbie to Python and seem to be the only one in the world who is unhappy about it (at least I didn't find open bugs against it): Setting the default encoding to 'ascii' and the error handling to 'strict' is the worst choice to make. The following rules to ease the creation of stable programs are violated: Rule 1: str() should *NEVER* raise exceptions. It is meant to give you a readable representation of your data. Period. It is ok to return "You fool! Why do you have non-ascii characters in your Unicode string when ascii is your default encoding?", but it is *NOT* ok to return an exception! Rule 2: Avoid data driven exceptions, if they can be avoided. In most cases, it is absolutely not what the programmer wants to get an exception for half of the possible byte values (and this is the less tested half in English-speaking countries). The default should enable the less experienced programmer to write acceptably stable programs, non-default settings should enable the expert to fine-tune program behaviour. This gets worse for Python's choice to make it extremely hard to set the default encoding after the sitecustomize.py file was run (if it is run at all). No other programming language I know is as hard to use in this respect as Python. I know this is a defined feature, not a bug, but it is a bad and dangerous design decision nonetheless. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=928881&group_id=5470 From noreply at sourceforge.net Sat Apr 3 11:53:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 3 11:53:49 2004 Subject: [ python-Bugs-928881 ] Default encoding harmful Message-ID: Bugs item #928881, was opened at 2004-04-04 01:00 Message generated for change (Comment added) made by perky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=928881&group_id=5470 Category: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Toni Goeller (tgoeller) Assigned to: M.-A. Lemburg (lemburg) Summary: Default encoding harmful Initial Comment: Although I am a newbie to Python and seem to be the only one in the world who is unhappy about it (at least I didn't find open bugs against it): Setting the default encoding to 'ascii' and the error handling to 'strict' is the worst choice to make. The following rules to ease the creation of stable programs are violated: Rule 1: str() should *NEVER* raise exceptions. It is meant to give you a readable representation of your data. Period. It is ok to return "You fool! Why do you have non-ascii characters in your Unicode string when ascii is your default encoding?", but it is *NOT* ok to return an exception! Rule 2: Avoid data driven exceptions, if they can be avoided. In most cases, it is absolutely not what the programmer wants to get an exception for half of the possible byte values (and this is the less tested half in English-speaking countries). The default should enable the less experienced programmer to write acceptably stable programs, non-default settings should enable the expert to fine-tune program behaviour. This gets worse for Python's choice to make it extremely hard to set the default encoding after the sitecustomize.py file was run (if it is run at all). No other programming language I know is as hard to use in this respect as Python. I know this is a defined feature, not a bug, but it is a bad and dangerous design decision nonetheless. ---------------------------------------------------------------------- >Comment By: Hye-Shik Chang (perky) Date: 2004-04-04 01:53 Message: Logged In: YES user_id=55188 > str() should *NEVER* raise exceptions. It is meant to > give you a readable representation of your data. If you want just string representations, use repr(). str() have never guaranteed not raising exceptions. > It is ok to return "You fool! Why do you have non-ascii > characters in your Unicode string when ascii is your > default encoding?", but it is *NOT* ok to return an > exception! What remains when except exceptions? > This gets worse for Python's choice to make it > extremely hard to set the default encoding after the > sitecustomize.py file was run (if it is run at all). I agree that sitecustomize.py and "if 0:" blocks that controls encodings stuff are somewhat newbie-unfriendly. Can't you say any good idea to improve this situation? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=928881&group_id=5470 From noreply at sourceforge.net Sat Apr 3 12:13:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 3 12:13:20 2004 Subject: [ python-Bugs-928881 ] Default encoding harmful Message-ID: Bugs item #928881, was opened at 2004-04-03 18:00 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=928881&group_id=5470 Category: Unicode Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Toni Goeller (tgoeller) Assigned to: M.-A. Lemburg (lemburg) Summary: Default encoding harmful Initial Comment: Although I am a newbie to Python and seem to be the only one in the world who is unhappy about it (at least I didn't find open bugs against it): Setting the default encoding to 'ascii' and the error handling to 'strict' is the worst choice to make. The following rules to ease the creation of stable programs are violated: Rule 1: str() should *NEVER* raise exceptions. It is meant to give you a readable representation of your data. Period. It is ok to return "You fool! Why do you have non-ascii characters in your Unicode string when ascii is your default encoding?", but it is *NOT* ok to return an exception! Rule 2: Avoid data driven exceptions, if they can be avoided. In most cases, it is absolutely not what the programmer wants to get an exception for half of the possible byte values (and this is the less tested half in English-speaking countries). The default should enable the less experienced programmer to write acceptably stable programs, non-default settings should enable the expert to fine-tune program behaviour. This gets worse for Python's choice to make it extremely hard to set the default encoding after the sitecustomize.py file was run (if it is run at all). No other programming language I know is as hard to use in this respect as Python. I know this is a defined feature, not a bug, but it is a bad and dangerous design decision nonetheless. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2004-04-03 19:13 Message: Logged In: YES user_id=38388 There is a simple solutions to both of your problems: always use Unicode for text data and use proper encodings when doing text data I/O. The intention of the strict Python defaults is to teach programmers to right correct programs rather than get away with bad design. Closing this as won't fix. ---------------------------------------------------------------------- Comment By: Hye-Shik Chang (perky) Date: 2004-04-03 18:53 Message: Logged In: YES user_id=55188 > str() should *NEVER* raise exceptions. It is meant to > give you a readable representation of your data. If you want just string representations, use repr(). str() have never guaranteed not raising exceptions. > It is ok to return "You fool! Why do you have non-ascii > characters in your Unicode string when ascii is your > default encoding?", but it is *NOT* ok to return an > exception! What remains when except exceptions? > This gets worse for Python's choice to make it > extremely hard to set the default encoding after the > sitecustomize.py file was run (if it is run at all). I agree that sitecustomize.py and "if 0:" blocks that controls encodings stuff are somewhat newbie-unfriendly. Can't you say any good idea to improve this situation? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=928881&group_id=5470 From noreply at sourceforge.net Sat Apr 3 13:04:36 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 3 13:04:42 2004 Subject: [ python-Bugs-736428 ] allow HTMLParser error recovery Message-ID: Bugs item #736428, was opened at 2003-05-12 12:37 Message generated for change (Comment added) made by kingswood You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736428&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Steven Rosenthal (smroid) Assigned to: Nobody/Anonymous (nobody) Summary: allow HTMLParser error recovery Initial Comment: I'm using 2.3a2. HTMLParser correctly raises a "malformed start tag" error on: because my application is imprecise by nature (web scraping), I want to be able to continue after such errors. I can override the error() method to not raise an exception. To make this work, I also needed to alter HTMLParser.py, near line 316, to read as: self.updatepos(i, j) self.error("malformed start tag") return j # ADDED THIS LINE raise AssertionError("we should not get here!") My enhancement request is for every place where self.error() is called, to ensure that the "override error() to not raise an exception" continuation strategy works as well as can be hoped. Thanks, Steve ---------------------------------------------------------------------- Comment By: Frank Vorstenbosch (kingswood) Date: 2004-04-03 19:04 Message: Logged In: YES user_id=555155 This problem is actually more widespread than previously indicated. Not only do all calls to self.error where that function returns need to cope with that, and recover (the HTMLParser defines that every character in the input will be visited exactly once), but other modules are also affected. In particular, feeding HTML (from spam) with a tag into HTMLParser causes markupbase._scan_name to emit an error that now needs to recover. The patch in #917188 may be better than the one suggested here as it deals with all places where self.error() can return. More is needed to fix the problem completely. In markupbase.py, at least this is necessary --- markupbase.py.orig Sat Apr 03 17:43:48 2004 +++ markupbase.py Sat Apr 03 18:02:48 2004 @@ -377,6 +377,8 @@ else: self.updatepos(declstartpos, i) self.error("expected name token") + return None,rawdata.find(">",i) # To be overridden -- handlers for unknown objects def unknown_decl(self, data): ---------------------------------------------------------------------- Comment By: Frank Vorstenbosch (kingswood) Date: 2004-03-16 09:53 Message: Logged In: YES user_id=555155 Fixed by my patch against 2.3.3. The patch adds recovery to ensure progress and tries to not miss any data in the input. The error() method is now commented as being overridable, just def error(): pass to ignore any parsing errors. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736428&group_id=5470 From noreply at sourceforge.net Sat Apr 3 13:16:11 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 3 13:16:18 2004 Subject: [ python-Bugs-928751 ] Typo in 7.2.1: socket.connect_ex Message-ID: Bugs item #928751, was opened at 2004-04-03 02:14 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=928751&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: PieOnCar (pieoncar) >Assigned to: Neal Norwitz (nnorwitz) Summary: Typo in 7.2.1: socket.connect_ex Initial Comment: The last line in connect_ex says "... is no longer be available..." ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2004-04-03 13:16 Message: Logged In: YES user_id=33168 Thanks! Fixed for bind too. Checked in as: * libsocket.tex 1.81 and 1.76.6.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=928751&group_id=5470 From noreply at sourceforge.net Sat Apr 3 14:28:23 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Apr 3 14:28:37 2004 Subject: [ python-Bugs-914148 ] xml.sax segfault on error Message-ID: Bugs item #914148, was opened at 2004-03-11 15:14 Message generated for change (Comment added) made by jojoworks You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=914148&group_id=5470 Category: XML Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Adam Sampson (adamsampson) Assigned to: Nobody/Anonymous (nobody) 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
\n