[ python-Bugs-1249965 ] IDLE does not start. 2.4.1
Bugs item #1249965, was opened at 2005-08-01 23:53 Message generated for change (Comment added) made by codepyro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249965&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: IDLE Group: Python 2.4 >Status: Closed Resolution: None >Priority: 1 Submitted By: codepyro (codepyro) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE does not start. 2.4.1 Initial Comment: Installed Python 2.4.1 on Windows XP SP 2 I shutoff my Sygate Firewall and Stopped the Windows Firewall/ICS service. I also shut off all Anti-Virus services. I ran IDLE, it fails to start. No errors or anything. It does not show up in task manager either. IDLE in 2.3.4 worked.(uninstalled before installing 2.4.1) -- >Comment By: codepyro (codepyro) Date: 2005-08-02 03:08 Message: Logged In: YES user_id=1120033 Had to delete all the paths in registry and sys environment. This fixed the problem. IDLE with 2.4.1 works now. -- Comment By: codepyro (codepyro) Date: 2005-08-02 00:18 Message: Logged In: YES user_id=1120033 Someone Suggested (PYthon installed on D) d:\Python24\pythonw.exe "d:\Python24\Lib\idlelib\idle.pyw" -n -s I ran that..Start -> Run It didnt work 2.3.5 Works. 2.4.0 Doesnt work.(Same prob) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249965&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1249873 ] numarray in debian python 2.4.1
Bugs item #1249873, was opened at 2005-08-01 23:38 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249873&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: LovePanda (lovepanda) Assigned to: Nobody/Anonymous (nobody) Summary: numarray in debian python 2.4.1 Initial Comment: Hi there, I ran across this error when running a few lines of code in debian python, but this runs perfectly in windows python. Basically I created a dummy matrix called "gamma" (using kroneckerproduct in numarray) and printed out its mean. Here is the code: gamma = kroneckerproduct(ones((N, 1)),identity(T)) print gamma.mean() and Here is the error message: Traceback (most recent call last): File "vul_prov.py", line 149, in ? VLs = mv_prov(hhc, idyrisk, provid, 1) File "/home/meng/China/Extent/Data/Urban2002/Empirics/tmp/vulnerability.py", line 605, in mv_prov print gamma.mean() File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 1137, in mean return self.sum()/(self.nelements()*1.0) File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 1133, in sum return ufunc.add.reduce(ufunc.add.areduce(self, type=type).flat, type=type) IndexError: too many indices. Thank you for helping on this! Oh, btw, the version for python in both platforms is 2.4.1 Xiangyi -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-02 11:11 Message: Logged In: YES user_id=1188172 Duplicate of #1249903. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249873&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1249867 ] numarray in debian python 2.4.1
Bugs item #1249867, was opened at 2005-08-01 23:26 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249867&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: LovePanda (lovepanda) Assigned to: Nobody/Anonymous (nobody) Summary: numarray in debian python 2.4.1 Initial Comment: Hi there, I ran across this error when running a few lines of code in debian python, but this runs perfectly in windows python. Basically I created a dummy matrix called "gamma" (using kroneckerproduct in numarray) and printed out its mean. Here is the code: gamma = kroneckerproduct(ones((N, 1)),identity(T)) print gamma.mean() and Here is the error message: Traceback (most recent call last): File "vul_prov.py", line 149, in ? VLs = mv_prov(hhc, idyrisk, provid, 1) File "/home/meng/China/Extent/Data/Urban2002/Empirics/tmp/vulnerability.py", line 605, in mv_prov print gamma.mean() File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 1137, in mean return self.sum()/(self.nelements()*1.0) File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 1133, in sum return ufunc.add.reduce(ufunc.add.areduce(self, type=type).flat, type=type) IndexError: too many indices. Thank you for helping on this! Oh, btw, the version for python in both platforms is 2.4.1 Xiangyi -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-02 11:11 Message: Logged In: YES user_id=1188172 Duplicate of #1249903. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249867&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1249903 ] numarray in debian python 2.4.1
Bugs item #1249903, was opened at 2005-08-02 01:05 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249903&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: LovePanda (lovepanda) Assigned to: Nobody/Anonymous (nobody) Summary: numarray in debian python 2.4.1 Initial Comment: Hi there, I ran across this error when running a few lines of code in debian python, but this runs perfectly in windows python. Basically I created a dummy matrix called "gamma" (using kroneckerproduct in numarray) and printed out its mean. Here is the code: gamma = kroneckerproduct(ones((N, 1)),identity(T)) print gamma.mean() and Here is the error message: Traceback (most recent call last): File "vul_prov.py", line 149, in ? VLs = mv_prov(hhc, idyrisk, provid, 1) File "/home/meng/China/Extent/Data/Urban2002/Empirics/tmp/vulnerability.py", line 605, in mv_prov print gamma.mean() File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 1137, in mean return self.sum()/(self.nelements()*1.0) File "/usr/lib/python2.4/site-packages/numarray/numarraycore.py", line 1133, in sum return ufunc.add.reduce(ufunc.add.areduce(self, type=type).flat, type=type) IndexError: too many indices. Thank you for helping on this! Oh, btw, the version for python in both platforms is 2.4.1 Xiangyi -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-02 11:13 Message: Logged In: YES user_id=1188172 What values do N and T have? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249903&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1249615 ] isinstance() fails depending on how modules imported
Bugs item #1249615, was opened at 2005-08-01 16:54 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249615&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hugh Gibson (hgibson50) Assigned to: Nobody/Anonymous (nobody) Summary: isinstance() fails depending on how modules imported Initial Comment: I have found an inconsistency with instance type checking dependent on how modules are imported. Using Windows 2000, Python 2.4.1. Source files are attached. Unzip preserving paths. To run, open a cmd window and set PythonPath to the location of the "system" folder. Run ServerRun.py. The program creates two class instances in two different modules, then calls a class function on one instance which takes as parameter the second instance. A call to isinstance to check if the parameter is of the correct class fails. If a parameter is passed to ServerRun.py then the class module is imported in a different way (specifying the path to the class) and the isinstance check succeeds. The output shows that before the call to the class function, an isinstance() call succeeds in both cases. There is obviously an easy fix in code, but I think that isinstance checking should not depend on how modules are imported. And, if I am using an incorrect module import sequence, that sequence should be disallowed. Sample output (also showing Windows 2000 version) is: Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. C:\system\server>set pythonpath=c:\system C:\system\server>serverrun ServerRun: oNew.__class__ == Stream.CElement == isinstance(oNew, Stream.CElement) == True AddField(): oNew.__class__ == CElement == isinstance(oNew, CElement) == False C:\system\server>serverrun 1 ServerRun: oNew.__class__ == Stream.CElement == isinstance(oNew, Stream.CElement) == True AddField(): oNew.__class__ == CElement == isinstance(oNew, CElement) == True C:\system\server> -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-02 11:19 Message: Logged In: YES user_id=1188172 This has bitten me too at one time. When you import a module from a package starting from different sys.path entries, you will end up with two different modules in sys.modules. This seems to be intended behaviour, but I don't know enough about it to close this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249615&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1243192 ] Incorrect documentation of re.UNICODE
Bugs item #1243192, was opened at 2005-07-22 18:20 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243192&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: nhaldimann (nhaldimann) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: Incorrect documentation of re.UNICODE Initial Comment: The effects of the re.UNICODE flag are incorrectly documented in the library reference. Currently it says (Section 4.2.3): U UNICODE Make \w, \W, \b, and \B dependent on the Unicode character properties database. New in version 2.0. But this flag in fact also affects \d, \D, \s, and \S at least since Python 2.1 (I have checked 2.1.3 on Linux, 2.2.3, 2.3.5 and 2.4 on OS X and the source of _sre.c makes this obvious). Proof: Python 2.4 (#1, Feb 13 2005, 18:29:12) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> not re.match(r"\d", u"\u0966") True >>> re.match(r"\d", u"\u0966", re.UNICODE) <_sre.SRE_Match object at 0x36ee20> >>> not re.match(r"\s", u"\u2001") True >>> re.match(r"\s", u"\u2001", re.UNICODE) <_sre.SRE_Match object at 0x36ee20> \u0966 is some Indian digit, \u2001 is an em space. I propose to change the docs to: U UNICODE Make \w, \W, \b, \B, \d, \D, \s, and \S dependent on the Unicode character properties database. New in version 2.0. Maybe the documentation of \d, \D, \s, and \S in section 2.4.1 of the library reference should also be adapted. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-02 12:30 Message: Logged In: YES user_id=1188172 Thanks! Committed as Doc/lib/libre.tex r1.114, r1.112.2.2. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1243192&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1250170 ] gethostbyname(gethostname()) fails on misconfigured system
Bugs item #1250170, was opened at 2005-08-02 12:17 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=1250170&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tadeusz Andrzej Kadlubowski (tkadlubo) Assigned to: Nobody/Anonymous (nobody) Summary: gethostbyname(gethostname()) fails on misconfigured system Initial Comment: Hello, I downloaded python CVS tree, compiled it and ran tests. Two tests failed: urllib2 and mimetools. Both in the same fashion, when doing socket.gethostbyname(socket.gethostname()) (It is used in mimetools.py library in line 130 and in test_urllib2.py test unit in line 352.) In the interpreter it fails in the following way: >>> import socket >>> socket.gethostbyname(socket.gethostname()) Traceback (most recent call last): File "", line 1, in ? socket.gaierror: (-2, 'Name or service not known') The reason is that my hostname is bogus, no single DNS knows about it, and I don't see any reason to set up a DNS server on my box. Of course editing /etc/hosts and adding my hostname as an alias for 127.0.0.1 solves the problem. Anyway I don't see any particular reason why the library shouldn't handle such situation i.e. when there's no connection between hostname and IP address. What do you think about it? I can make a SF patch item to solve this issue if you like. I am quite sure adding try/catch will make it in both cases. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250170&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1249615 ] isinstance() fails depending on how modules imported
Bugs item #1249615, was opened at 2005-08-01 14:54 Message generated for change (Comment added) made by hgibson50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249615&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hugh Gibson (hgibson50) Assigned to: Nobody/Anonymous (nobody) Summary: isinstance() fails depending on how modules imported Initial Comment: I have found an inconsistency with instance type checking dependent on how modules are imported. Using Windows 2000, Python 2.4.1. Source files are attached. Unzip preserving paths. To run, open a cmd window and set PythonPath to the location of the "system" folder. Run ServerRun.py. The program creates two class instances in two different modules, then calls a class function on one instance which takes as parameter the second instance. A call to isinstance to check if the parameter is of the correct class fails. If a parameter is passed to ServerRun.py then the class module is imported in a different way (specifying the path to the class) and the isinstance check succeeds. The output shows that before the call to the class function, an isinstance() call succeeds in both cases. There is obviously an easy fix in code, but I think that isinstance checking should not depend on how modules are imported. And, if I am using an incorrect module import sequence, that sequence should be disallowed. Sample output (also showing Windows 2000 version) is: Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. C:\system\server>set pythonpath=c:\system C:\system\server>serverrun ServerRun: oNew.__class__ == Stream.CElement == isinstance(oNew, Stream.CElement) == True AddField(): oNew.__class__ == CElement == isinstance(oNew, CElement) == False C:\system\server>serverrun 1 ServerRun: oNew.__class__ == Stream.CElement == isinstance(oNew, Stream.CElement) == True AddField(): oNew.__class__ == CElement == isinstance(oNew, CElement) == True C:\system\server> -- >Comment By: Hugh Gibson (hgibson50) Date: 2005-08-02 13:00 Message: Logged In: YES user_id=732318 The case I found here is particularly worrying because I'm doing the isinstance() check in the module that contains the class. The success of the check depends on how that module was imported into other modules. The two cases are: from server.Stream import Stream from Stream import Stream We found this problem in a large application under development. Unit testing of the class succeeded because of the way the class module was imported. But the application itself failed because of the way one module imported the class module. The failure was obvious in our application but clearly there may be subtle failure modes - for example, exception handling may use isinstance() internally to see if an exception is an instance of a given class. I've modified the code and added some more testing which shows clearly that it's not the class object itself which is the problem, but when you have a class method which accepts an instance of the class as a parameter. Any test of the class of that parameter will fail if the first instance is created in one module and the second instance is created in another module, and they import the class module differently. Note that it's not restricted to isinstance() - checking __class__ fails as well. Also, in both of the modules that import the class module, isinstance() checking succeeds. There is a false sense of security that isinstance() checking will be OK. Modifed code attached. Hugh -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-02 09:19 Message: Logged In: YES user_id=1188172 This has bitten me too at one time. When you import a module from a package starting from different sys.path entries, you will end up with two different modules in sys.modules. This seems to be intended behaviour, but I don't know enough about it to close this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249615&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1249615 ] isinstance() fails depending on how modules imported
Bugs item #1249615, was opened at 2005-08-01 16:54 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249615&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Hugh Gibson (hgibson50) Assigned to: Nobody/Anonymous (nobody) Summary: isinstance() fails depending on how modules imported Initial Comment: I have found an inconsistency with instance type checking dependent on how modules are imported. Using Windows 2000, Python 2.4.1. Source files are attached. Unzip preserving paths. To run, open a cmd window and set PythonPath to the location of the "system" folder. Run ServerRun.py. The program creates two class instances in two different modules, then calls a class function on one instance which takes as parameter the second instance. A call to isinstance to check if the parameter is of the correct class fails. If a parameter is passed to ServerRun.py then the class module is imported in a different way (specifying the path to the class) and the isinstance check succeeds. The output shows that before the call to the class function, an isinstance() call succeeds in both cases. There is obviously an easy fix in code, but I think that isinstance checking should not depend on how modules are imported. And, if I am using an incorrect module import sequence, that sequence should be disallowed. Sample output (also showing Windows 2000 version) is: Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp. C:\system\server>set pythonpath=c:\system C:\system\server>serverrun ServerRun: oNew.__class__ == Stream.CElement == isinstance(oNew, Stream.CElement) == True AddField(): oNew.__class__ == CElement == isinstance(oNew, CElement) == False C:\system\server>serverrun 1 ServerRun: oNew.__class__ == Stream.CElement == isinstance(oNew, Stream.CElement) == True AddField(): oNew.__class__ == CElement == isinstance(oNew, CElement) == True C:\system\server> -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-08-02 15:14 Message: Logged In: YES user_id=89016 The problem is not isinstance() per se, but the fact that you import one Python script as two different modules. A simple demo might look like this: class Foo: pass import bug print isinstance(Foo(), bug.Foo) Put this in bug.py and run "python bug.py" and you'll get: True False So I think this bug should be closed. -- Comment By: Hugh Gibson (hgibson50) Date: 2005-08-02 15:00 Message: Logged In: YES user_id=732318 The case I found here is particularly worrying because I'm doing the isinstance() check in the module that contains the class. The success of the check depends on how that module was imported into other modules. The two cases are: from server.Stream import Stream from Stream import Stream We found this problem in a large application under development. Unit testing of the class succeeded because of the way the class module was imported. But the application itself failed because of the way one module imported the class module. The failure was obvious in our application but clearly there may be subtle failure modes - for example, exception handling may use isinstance() internally to see if an exception is an instance of a given class. I've modified the code and added some more testing which shows clearly that it's not the class object itself which is the problem, but when you have a class method which accepts an instance of the class as a parameter. Any test of the class of that parameter will fail if the first instance is created in one module and the second instance is created in another module, and they import the class module differently. Note that it's not restricted to isinstance() - checking __class__ fails as well. Also, in both of the modules that import the class module, isinstance() checking succeeds. There is a false sense of security that isinstance() checking will be OK. Modifed code attached. Hugh -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-08-02 11:19 Message: Logged In: YES user_id=1188172 This has bitten me too at one time. When you import a module from a package starting from different sys.path entries, you will end up with two different modules in sys.modules. This seems to be intended behaviour, but I don't know enough about it to close this. -- You can respond by visiti
[ python-Bugs-1250306 ] incorrect description of range function
Bugs item #1250306, was opened at 2005-08-02 08:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250306&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Gleeson (jgleeson) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect description of range function Initial Comment: The description of the behavior of the range function http://www.python.org/doc/current/lib/built-in-funcs.html#l2h-56 for negative values of step appears to be incorrect: "if step is negative, the last element is the largest start + i * step greater than stop." This implies that the last element is 'start'. I think it should say 'smallest' instead of 'largest'. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250306&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1250389 ] The -m option to python does not search zip files
Bugs item #1250389, was opened at 2005-08-02 17: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=1250389&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: The -m option to python does not search zip files Initial Comment: The -m option, to run a module from sys.path as a main program, does not work when the module is in a zip file. Here is an example demonstrating: D:\Data>type zipmtest.py def a(): print "Hello, world" if __name__ == '__main__': a() D:\Data>python -m zipmtest Hello, world D:\Data>zip -9 zipm zipmtest.* adding: zipmtest.py (92 bytes security) (deflated 8%) D:\Data>set PYTHONPATH=zipm.zip D:\Data>del zipmtest.py Deleting D:\Data\zipmtest.py 1 file deleted D:\Data>python -m zipmtest python: module zipmtest not found D:\Data>python -c "import zipmtest" (note the last import - python can find the zipmtest module quite happily, but -m misses it). This is a fairly severe limitation on -m, particularly as use of "egg" distributions (which are basically zipfiles) becomes more common. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250389&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1250469 ] Tix: PanedWindow.panes nonfunctional
Bugs item #1250469, was opened at 2005-08-02 13:52 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=1250469&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Majromax (majromax) Assigned to: Martin v. Löwis (loewis) Summary: Tix: PanedWindow.panes nonfunctional Initial Comment: Tix.PanedWindow.panes() is nonfunctional for any but single-letter pane names; the culprit is the following line of code from Tix.PanedWindow.panes: names = self.tk.call(self._w, 'panes') Since the Tk "panes" command returns a string, it is not iterated over properly. The fix is: names = self.tk.split(self.tk.call(self._w, 'panes')) Attached is error log from Python 2.4, Windows 2k. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1250469&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
