[ python-Bugs-1611944 ] sndhdr.what() does not recognize wav file
Bugs item #1611944, was opened at 2006-12-09 02:37 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611944&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Floris van Manen (klankschap) Assigned to: Nobody/Anonymous (nobody) Summary: sndhdr.what() does not recognize wav file Initial Comment: using 2.5 on osx 10.4 the sndhdr.what() function fails to recognize some wav headers. however these wav files are recognized correctly by other 'standard' applications like quicktime and itunes. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-12-09 08:55 Message: Logged In: YES user_id=849994 Originator: NO We'd need some more information about these specific wave files in order to improve sndhdr.what(). Can you try to find out why they aren't recognized correctly, or what their header (sndhdr reads the first 512 bytes) looks like? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611944&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1223238 ] race in os.makedirs()
Bugs item #1223238, was opened at 2005-06-18 16:37 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1223238&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Mattias Engdeg�rd (yorick) Assigned to: Nobody/Anonymous (nobody) Summary: race in os.makedirs() Initial Comment: os.makedirs() can fail if one of its components is created while it is running (perhaps by another process). This is because it checks for each directory if it exists before creating it. This is bad programming style. A correct implementation would just call mkdir() on each directory (starting with the rightmost, probably) and ignoring any EEXIST error. This would not only fix the bug, it would also be faster (fewer syscalls). The patch is simple, but there is a wart in the design: os.makedirs() throws an error if the (rightmost) directory already exists, although by calling this function the user has clearly indicated that she wants the directories to be created if they don't exist and have no complaints otherwise. This leads to code like: try: os.makedirs(path) except OSError: pass which is doubly bad because it hides the race condition! So, before I submit a patch, should we: a) just fix this bug but keep the old design b) fix this bug, and don't throw an error if the dir exists or maybe do a) for the next 2.4.x bugfix release and b) in 2.5? -- >Comment By: Georg Brandl (gbrandl) Date: 2006-12-09 09:25 Message: Logged In: YES user_id=849994 Originator: NO Fixed by patch #1608267. -- Comment By: Nir Soffer (nirs) Date: 2005-12-05 01:32 Message: Logged In: YES user_id=832344 I agree that raising an error for existing directories is usually not what you want, but changing this will break any code that count on that documented behavior. -- Comment By: Mattias Engdeg�rd (yorick) Date: 2005-07-18 12:08 Message: Logged In: YES user_id=432579 Whether the dir creation is done right-to-left or left-to-right is less important. If the expected usage pattern is that most of the directories already exist, then right-to-left may be faster, otherwise left-to-right is. One advantage with the former is its slightly simpler code (no need to check for ENOENT). >current 2.4 code does not return an error if the directory exists, >the patch must not change that behavior. You mean the contrary? From what I can see of the 2.4 code, it throws an error if the directory exists. This is almost never what you want, so I strongly doubt fixing that misfeature in 2.5 would break anything. I'm happy with the suggested patch for 2.5 in #1239890. -- Comment By: Nir Soffer (nirs) Date: 2005-07-17 21:10 Message: Logged In: YES user_id=832344 current 2.4 code does not return an error if the directory exists, the patch must not change that behavior. It will not be a good idea to change that behavior in 2.5 or any version, it can break lot of code. -- Comment By: Georg Brandl (birkenfeld) Date: 2005-07-17 19:56 Message: Logged In: YES user_id=1188172 See patch #1239890. -- Comment By: Mattias Engdeg�rd (yorick) Date: 2005-06-25 21:11 Message: Logged In: YES user_id=432579 I'm fine with fixing the design for 2.5 and ignoring the bug for 2.4, since programs susceptible to the bug must use some kind of work-around in 2.4.x (x < 2) anyway. What I am using right now is: def makedirs(name, mode=0777): try: os.mkdir(name, mode) return except OSError, err: if err.errno == errno.EEXIST: return if err.errno != errno.ENOENT: raise makedirs(os.path.dirname(name), mode) makedirs(name, mode) This is compact and elegant, but relies on mkdir producing the correct errno values, which should be true for all platforms I'm aware of. It could also theoretically loop infinitely in bizarre cases but I don't see how that ever could happen. -- Comment By: Neil Schemenauer (nascheme) Date: 2005-06-18 17:43 Message: Logged In: YES user_id=35752 I vote to fix the design for 2.5. Backporting the minimal fix to 2.4 would be optional, IMO. -- You can respond by visiting: https://sourceforge.net/t
[ python-Bugs-1611944 ] sndhdr.what() does not recognize wav file
Bugs item #1611944, was opened at 2006-12-09 03:37 Message generated for change (Comment added) made by klankschap You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611944&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Open Resolution: None Priority: 5 Private: No Submitted By: Floris van Manen (klankschap) Assigned to: Nobody/Anonymous (nobody) Summary: sndhdr.what() does not recognize wav file Initial Comment: using 2.5 on osx 10.4 the sndhdr.what() function fails to recognize some wav headers. however these wav files are recognized correctly by other 'standard' applications like quicktime and itunes. -- >Comment By: Floris van Manen (klankschap) Date: 2006-12-09 10:56 Message: Logged In: YES user_id=1064918 Originator: YES Attached you find (in a rar file) a 260kb wav file, 2 tracks, 24 bit, 44.1kHz You can play it, ask either OSX or XP to show the properties. Yet sndhdr.what() returns None File Added: Audio01.rar -- Comment By: Georg Brandl (gbrandl) Date: 2006-12-09 09:55 Message: Logged In: YES user_id=849994 Originator: NO We'd need some more information about these specific wave files in order to improve sndhdr.what(). Can you try to find out why they aren't recognized correctly, or what their header (sndhdr reads the first 512 bytes) looks like? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611944&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1611944 ] sndhdr.what() does not recognize wav file
Bugs item #1611944, was opened at 2006-12-09 03:37 Message generated for change (Comment added) made by klankschap You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611944&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Floris van Manen (klankschap) Assigned to: Nobody/Anonymous (nobody) Summary: sndhdr.what() does not recognize wav file Initial Comment: using 2.5 on osx 10.4 the sndhdr.what() function fails to recognize some wav headers. however these wav files are recognized correctly by other 'standard' applications like quicktime and itunes. -- >Comment By: Floris van Manen (klankschap) Date: 2006-12-09 11:02 Message: Logged In: YES user_id=1064918 Originator: YES Apparently the sndhdr.what() function does not skip the embedded comment chunk at the start. -- Comment By: Floris van Manen (klankschap) Date: 2006-12-09 10:56 Message: Logged In: YES user_id=1064918 Originator: YES Attached you find (in a rar file) a 260kb wav file, 2 tracks, 24 bit, 44.1kHz You can play it, ask either OSX or XP to show the properties. Yet sndhdr.what() returns None File Added: Audio01.rar -- Comment By: Georg Brandl (gbrandl) Date: 2006-12-09 09:55 Message: Logged In: YES user_id=849994 Originator: NO We'd need some more information about these specific wave files in order to improve sndhdr.what(). Can you try to find out why they aren't recognized correctly, or what their header (sndhdr reads the first 512 bytes) looks like? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611944&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1611944 ] sndhdr.what() does not recognize wav file
Bugs item #1611944, was opened at 2006-12-09 02:37 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611944&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Floris van Manen (klankschap) Assigned to: Nobody/Anonymous (nobody) Summary: sndhdr.what() does not recognize wav file Initial Comment: using 2.5 on osx 10.4 the sndhdr.what() function fails to recognize some wav headers. however these wav files are recognized correctly by other 'standard' applications like quicktime and itunes. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-12-09 10:26 Message: Logged In: YES user_id=849994 Originator: NO I see. The problem is, as the "bext" chunk can be arbitrarily long, the test function would need more than 512 bytes to read the "fmt " chunk, or it could return that it cannot read the format details. Would you like to work on a patch? -- Comment By: Floris van Manen (klankschap) Date: 2006-12-09 10:02 Message: Logged In: YES user_id=1064918 Originator: YES Apparently the sndhdr.what() function does not skip the embedded comment chunk at the start. -- Comment By: Floris van Manen (klankschap) Date: 2006-12-09 09:56 Message: Logged In: YES user_id=1064918 Originator: YES Attached you find (in a rar file) a 260kb wav file, 2 tracks, 24 bit, 44.1kHz You can play it, ask either OSX or XP to show the properties. Yet sndhdr.what() returns None File Added: Audio01.rar -- Comment By: Georg Brandl (gbrandl) Date: 2006-12-09 08:55 Message: Logged In: YES user_id=849994 Originator: NO We'd need some more information about these specific wave files in order to improve sndhdr.what(). Can you try to find out why they aren't recognized correctly, or what their header (sndhdr reads the first 512 bytes) looks like? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611944&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1612113 ] Dictionary ordering docs are too unclear of dangers
Bugs item #1612113, was opened at 2006-12-09 06:57 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=1612113&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 Private: No Submitted By: Calvin Spealman (ironfroggy) Assigned to: Nobody/Anonymous (nobody) Summary: Dictionary ordering docs are too unclear of dangers Initial Comment: The footnote #3 on this page of the documentation details some thoughts on the order of dictionaries and the results of the different key and value retreival methods. I think it promises more than it should. The current content tells the reader they can expect consistant results from a dictionary as far as order goes, and we know this to be simply untrue and even in the circumstances where its likely (but still not impossible), such as `zip(d.values(), d.keys())` there is not even any compelling reason to use such odd methods, making the very fact that the idea is documented suspect. I recommend the footnote be removed entirely, or replaced with "Keys and values are listed in an arbitrary order which is non-random, varies across Python implementations, and depends on the dictionary's history of insertions and deletions. Do not expect anything of the order of the items(), keys(), values(), iteritems(), iterkeys(), and itervalues() methods' results." Page in question: http://docs.python.org/lib/typesmapping.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612113&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1611944 ] sndhdr.what() does not recognize wav file
Bugs item #1611944, was opened at 2006-12-09 03:37 Message generated for change (Comment added) made by klankschap You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611944&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Floris van Manen (klankschap) Assigned to: Nobody/Anonymous (nobody) Summary: sndhdr.what() does not recognize wav file Initial Comment: using 2.5 on osx 10.4 the sndhdr.what() function fails to recognize some wav headers. however these wav files are recognized correctly by other 'standard' applications like quicktime and itunes. -- >Comment By: Floris van Manen (klankschap) Date: 2006-12-09 13:01 Message: Logged In: YES user_id=1064918 Originator: YES this could be a start. however the initial 512 bytes might be too short. i don't see (yet) how to increase that in a snazzy way. i just changed it into a read(1024) def test_wav_test( h ): if h[:4] != 'RIFF' or h[8:12] != 'WAVE': return None if h[12:16] == 'fmt ': style = get_short_le(h[20:22]) nchannels = get_short_le(h[22:24]) rate = get_long_le(h[24:28]) sample_bits = get_short_le(h[34:36]) return 'wav', rate, nchannels, -1, sample_bits elif h[12:16] == 'bext': offset = 12 while True: try: if h[offset:offset+4] == 'fmt ': nchannels = get_short_le( h[offset+10:offset+12] ) rate = get_long_le( h[offset+12:offset+16] ) sample_bits = get_short_le( h[offset+22:offset+24] ) return 'wav', rate, nchannels, -1, sample_bits offset += ( get_long_le( h[offset+4:offset+8] ) + 8 ) except IndexError: print 'header buffer too short' return None -- Comment By: Georg Brandl (gbrandl) Date: 2006-12-09 11:26 Message: Logged In: YES user_id=849994 Originator: NO I see. The problem is, as the "bext" chunk can be arbitrarily long, the test function would need more than 512 bytes to read the "fmt " chunk, or it could return that it cannot read the format details. Would you like to work on a patch? -- Comment By: Floris van Manen (klankschap) Date: 2006-12-09 11:02 Message: Logged In: YES user_id=1064918 Originator: YES Apparently the sndhdr.what() function does not skip the embedded comment chunk at the start. -- Comment By: Floris van Manen (klankschap) Date: 2006-12-09 10:56 Message: Logged In: YES user_id=1064918 Originator: YES Attached you find (in a rar file) a 260kb wav file, 2 tracks, 24 bit, 44.1kHz You can play it, ask either OSX or XP to show the properties. Yet sndhdr.what() returns None File Added: Audio01.rar -- Comment By: Georg Brandl (gbrandl) Date: 2006-12-09 09:55 Message: Logged In: YES user_id=849994 Originator: NO We'd need some more information about these specific wave files in order to improve sndhdr.what(). Can you try to find out why they aren't recognized correctly, or what their header (sndhdr reads the first 512 bytes) looks like? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611944&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1612113 ] Dictionary ordering docs are too unclear of dangers
Bugs item #1612113, was opened at 2006-12-09 12:57 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612113&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: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Calvin Spealman (ironfroggy) Assigned to: Nobody/Anonymous (nobody) Summary: Dictionary ordering docs are too unclear of dangers Initial Comment: The footnote #3 on this page of the documentation details some thoughts on the order of dictionaries and the results of the different key and value retreival methods. I think it promises more than it should. The current content tells the reader they can expect consistant results from a dictionary as far as order goes, and we know this to be simply untrue and even in the circumstances where its likely (but still not impossible), such as `zip(d.values(), d.keys())` there is not even any compelling reason to use such odd methods, making the very fact that the idea is documented suspect. I recommend the footnote be removed entirely, or replaced with "Keys and values are listed in an arbitrary order which is non-random, varies across Python implementations, and depends on the dictionary's history of insertions and deletions. Do not expect anything of the order of the items(), keys(), values(), iteritems(), iterkeys(), and itervalues() methods' results." Page in question: http://docs.python.org/lib/typesmapping.html -- >Comment By: Martin v. Löwis (loewis) Date: 2006-12-09 15:31 Message: Logged In: YES user_id=21627 Originator: NO You seem to be saying (without actually saying it) that the footnote is untrue. Can you give an example that demonstrates it is untrue? I believe the footnote is correct, precise, and complete as it stands, and fail to see a bug here. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612113&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1611753 ] can't pickle NAN's in binary mode
Bugs item #1611753, was opened at 2006-12-08 18:45
Message generated for change (Comment added) made by mwh
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611753&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Wayne Christopher (wayne606)
>Assigned to: Michael Hudson (mwh)
Summary: can't pickle NAN's in binary mode
Initial Comment:
I think the problem is that pack(">d", float("nan")) does not work. Same for
Inf. This works fine with pickle in ascii mode. I tried this on SuSE 10.0,
x86_64.
Python 2.4.2 (#2, Sep 10 2006, 23:53:27)
[GCC 4.1.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
>>> foo = [1, 2, float("nan")]
>>> foo
[1, 2, nan]
>>> fp = file("/tmp/xxx", "wb")
>>> pickle.dump(foo, fp, -1)
Traceback (most recent call last):
File "", line 1, in ?
File "/home/software/64/lib/python2.4/pickle.py", line 1382, in dump
Pickler(file, protocol, bin).dump(obj)
File "/home/software/64/lib/python2.4/pickle.py", line 231, in dump
self.save(obj)
File "/home/software/64/lib/python2.4/pickle.py", line 293, in save
f(self, obj) # Call unbound method with explicit self
File "/home/software/64/lib/python2.4/pickle.py", line 614, in save_list
self._batch_appends(iter(obj))
File "/home/software/64/lib/python2.4/pickle.py", line 647, in _batch_appends
save(x)
File "/home/software/64/lib/python2.4/pickle.py", line 293, in save
f(self, obj) # Call unbound method with explicit self
File "/home/software/64/lib/python2.4/pickle.py", line 489, in save_float
self.write(BINFLOAT + pack('>d', obj))
SystemError: frexp() result out of range
--
>Comment By: Michael Hudson (mwh)
Date: 2006-12-09 14:37
Message:
Logged In: YES
user_id=6656
Originator: NO
This is fixed in 2.5 (and if you think it worked fine in ASCII mode, I
don't think you tried moving your pickles between Linux and Windows
systems...).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1611753&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1612113 ] Dictionary ordering docs are too unclear of dangers
Bugs item #1612113, was opened at 2006-12-09 06:57 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612113&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: Pending Resolution: Works For Me Priority: 5 Private: No Submitted By: Calvin Spealman (ironfroggy) Assigned to: Nobody/Anonymous (nobody) Summary: Dictionary ordering docs are too unclear of dangers Initial Comment: The footnote #3 on this page of the documentation details some thoughts on the order of dictionaries and the results of the different key and value retreival methods. I think it promises more than it should. The current content tells the reader they can expect consistant results from a dictionary as far as order goes, and we know this to be simply untrue and even in the circumstances where its likely (but still not impossible), such as `zip(d.values(), d.keys())` there is not even any compelling reason to use such odd methods, making the very fact that the idea is documented suspect. I recommend the footnote be removed entirely, or replaced with "Keys and values are listed in an arbitrary order which is non-random, varies across Python implementations, and depends on the dictionary's history of insertions and deletions. Do not expect anything of the order of the items(), keys(), values(), iteritems(), iterkeys(), and itervalues() methods' results." Page in question: http://docs.python.org/lib/typesmapping.html -- >Comment By: Tim Peters (tim_one) Date: 2006-12-09 09:51 Message: Logged In: YES user_id=31435 Originator: NO The statement that the various ways of extracting info from a dict are consistent /provided that/ they're "called with no intervening modifications to the dictionary" (did you miss that crucial qualification?) is part of the language definition: it definitely and deliberately constrains the set of possible implementations. The docs didn't originally say this, but people noted it was true in then-current CPython, and asked whether they could rely on it. At that point, Guido decided to elevate this property of the CPython implementation to a language requirement, and the footnote was added. Of course you're not /required/ to rely on it ;-). -- Comment By: Martin v. Löwis (loewis) Date: 2006-12-09 09:31 Message: Logged In: YES user_id=21627 Originator: NO You seem to be saying (without actually saying it) that the footnote is untrue. Can you give an example that demonstrates it is untrue? I believe the footnote is correct, precise, and complete as it stands, and fail to see a bug here. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612113&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1610485 ] GUI for Python 2.3, 2.4, and 2.5 is very sluggish
Bugs item #1610485, was opened at 2006-12-06 18:44 Message generated for change (Comment added) made by g4rlik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1610485&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.5 Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: g4rlik (g4rlik) Assigned to: Kurt B. Kaiser (kbk) Summary: GUI for Python 2.3, 2.4, and 2.5 is very sluggish Initial Comment: The GUI for Python versions 2.3, 2.4, and 2.5 are very sluggish. When I type in them, or simply move them around my desktop, they are very slow. Someone helping me from [EMAIL PROTECTED] was able to guess that the reason the GUI is slow for me is because of the subprocesses running, and he was right. To cope with this problem, I created an idle.txt file, and added this to the first line of it: c:\python25\python c:\python25\Lib\idlelib\idle.py -n After that I saved the extension to .bat and now when I run that file, the Python GUI opens without any subprocesses running and I have no problem. However, I'd still really like to know how I could fix this problem even more. The GUIs for Python version 2.2 and below run fine for me. I am using Windows XP Home Edition Service Pack 2. -- >Comment By: g4rlik (g4rlik) Date: 2006-12-09 10:19 Message: Logged In: YES user_id=1662589 Originator: YES Here are some important bits from the first e-mails. "Dear Will, > Hello there. I'll keep this short and sweet for you, seeing as > you're a volunteer (thank you by the way!). Hello! We're glad to help. > The Python GUI for versions 2.3, 2.4, and 2.5 are very slow on my > computer. Whenever I type in the GUI or simply move the GUI around > my desktop, its response time is slower than normal. However, the > GUIs of Python versions 2.2 and below are not slow at all for me. I'm not at all sure, but the timing suggests that the problem may be in IDLE's using a subprocess. If that's the explanation, you should see something different if you start IDLE without a subprocess. You ought to be able to do that by opening a command-shell window and typing something like: c:\python25\python c:\python25\Lib\idlelib\idle.py -n Of course, your directory names may be different. If that does improve IDLE's performance, that still leaves the question of why a subprocess performs much worse on your computer than on most people's. Let us know what you get. Someone else here may have a different idea or a better idea about that one. Regards, Matt" "I'm a trifle curious why a loopback network connection and a subprocess should load your machine so much, but I doubt that it would be easy to figure that out by email." -- Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-08 23:42 Message: Logged In: YES user_id=149084 Originator: NO Yes, please do. -- Comment By: g4rlik (g4rlik) Date: 2006-12-08 21:54 Message: Logged In: YES user_id=1662589 Originator: YES I'm not exactly sure how I'd give you a link to the discussion on [EMAIL PROTECTED] I was talking via e-mail and I'm not sure how to link that. Would you want me to copy and paste it? -- Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-08 17:21 Message: Logged In: YES user_id=149084 Originator: NO OK, I'll close this for now. Feel free to reopen it if you come up with something definitive and/or can find others having the same problem. Can you give me a link to the discussion on [EMAIL PROTECTED] -- Comment By: g4rlik (g4rlik) Date: 2006-12-08 16:51 Message: Logged In: YES user_id=1662589 Originator: YES I'd just like to say thanks for looking into the problem. As for now, I can either deal with it or use Python 2.2, it's no problem. -- Comment By: Kurt B. Kaiser (kbk) Date: 2006-12-08 00:13 Message: Logged In: YES user_id=149084 Originator: NO Your system is powerful enough, by an order of magnitude :-) My W2K system is about 400 Mhz. It shows no slowdown with 2.3 - 2.5. If your system is slow only with the subprocess, there must be something about using the socket interface that is problematic. I don't know much about XP Home, but I vaguely recollect hearing about some difficulties with it. You might try upgrading to Win XP Pro, or install Linux. -- Comment By: g4rlik (g4rlik) Date: 2006-12-07 19:14 Message: Logged In: YES user_id=166258
[ python-Feature Requests-1612190 ] Py_DEBUG
Feature Requests item #1612190, was opened at 2006-12-09 16:48 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=1612190&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 Private: No Submitted By: nitro (nitrogenycs) Assigned to: Nobody/Anonymous (nobody) Summary: Py_DEBUG Initial Comment: Hello, I am writing an extension module (Win32, VC8). Of course I need to #include . Now, when _DEBUG is defined in my application Py_DEBUG gets defined as well (in pyconfig.h). I don't want this to happen as I have to link to the python debug library that way. However, I don't want to debug python, I only want to debug my own application. So the automatic definition of Py_DEBUG doesn't seem right. A solution that would be backwards compatible could look like: #ifdef _DEBUG && !defined(Py_NO_DEBUG) # define Py_DEBUG #endif Could something like this be included in python? Note that #undef _DEBUG #include #define _DEBUG does not work as VC8 complains in this case, because some header files had the _DEBUG preprocessor symbol and some didn't. That trick used to work in VC 6 and 7.x. I've seen a lot of people fighting this problem. Another problem that also arises from pyconfig.h is this code: # ifdef _DEBUG # pragma comment(lib,"python24_d.lib") # else I don't think it's clean that python tells my program what to link to. I am the one who should (and wants to) do this via a linker switch. I know that some people probably would regard the code above as a feature, but it's the opposite imo. A backwards compatible change could look like: #ifdef MS_COREDLL # ifndef Py_BUILD_CORE /* not building the core - must be an ext */ # if defined(_MSC_VER) && !defined(Py_NO_AUTOMATIC_MSVC_LINK) /* So MSVC users need not specify the .lib file in their Makefile (other compilers are generally taken care of by distutils.) */ # ifdef _DEBUG # pragma comment(lib,"python24_d.lib") # else # pragma comment(lib,"python24.lib") # endif /* _DEBUG */ # endif /* _MSC_VER */ # endif /* Py_BUILD_CORE */ #endif /* MS_COREDLL */ Thanks, -Matthias -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1612190&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1528593 ] Printing: No print dialog or page setup
Feature Requests item #1528593, was opened at 2006-07-25 22:49 Message generated for change (Comment added) made by taleinat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1528593&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.6 Status: Open Resolution: None Priority: 3 Private: No Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: Printing: No print dialog or page setup Initial Comment: The printing solution for IDLE on OSX is lacking a page setup dialog, or even a print dialog. This means output will also be sent to the default printer. If there is no default printer (which means the user hasn't defined a printer at all) the user will get a confusing message (lpr failed). BTW. the message is clear for technical users, but not for mac users that aren't unix saffy. It would be nice if IDLE could interface with the Carbon/Cocoa print system using a real print dialog. That way users can select another than the default printer, change page settings and can even print to PDF. I've filed this as a low-priority issue for 2.6 because there's no way this will get into 2.5 and it likey non-trivial as well. BTW. this might be a feature-request rather than a bug. -- Comment By: Tal Einat (taleinat) Date: 2006-12-09 18:55 Message: Logged In: YES user_id=1330769 Originator: NO This is a problem on all platforms. We have recently been discussing possible solutions for Windows platforms, but until now haven't found a solution that doesn't require the 'win32' package. The Unix/Linux platforms could probably be addressed without special modules/packages... -- Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-26 23:45 Message: Logged In: YES user_id=149084 It's not just an OSX problem. Printing in IDLE is very rudimentary at this point. Making this an RFE. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1528593&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-404444 ] [IDLE] auto indent/parentheses
Feature Requests item #40, was opened at 2001-02-27 01:46 Message generated for change (Comment added) made by taleinat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=40&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: None Status: Open Resolution: Later Priority: 5 Private: No Submitted By: Charles Doutriaux (cdoutri) Assigned to: Nobody/Anonymous (nobody) Summary: [IDLE] auto indent/parentheses Initial Comment: It'd be really nice to have an automatic indent of a line when using the "TAB" key anywhere on the line, this feature exist in the python emacs mode and is REALLY nice and a total time-saver. Also, having the possibility to see which parentheses/brackets you're closing while typing (as in a lot of editors) would be really nice -- Comment By: Tal Einat (taleinat) Date: 2006-12-09 18:58 Message: Logged In: YES user_id=1330769 Originator: NO The Parentheses/Bracket feature is already addressed by the ParenMatch extension. I agree that an "auto-indent-line" function would be very time-saving. -- Comment By: Tim Peters (tim_one) Date: 2001-12-10 19:47 Message: Logged In: YES user_id=31435 Chagned Category to IDLE. -- Comment By: Tim Peters (tim_one) Date: 2001-03-18 21:32 Message: Logged In: YES user_id=31435 Hmm. SF threw us another curve ball here: the new "Data Type" value "Feature Requests" has only "None" as a possible value for "Assigned To". The intro text in PEP 42 doesn't know about this either ... -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2001-03-18 18:32 Message: Logged In: YES user_id=12800 Thomas explained it nicely in a followup to the PEP 42 checkin. Included here for completeness. "The TAB comment is pretty easy to explain: the user wants IDLE to re-indent the *current* line whenever he presses TAB, regardless of where his cursor is at that moment." Indeed, this is how python-mode (and most language editing modes) in Emacs works. You typically have to type ^Q TAB to get a real tab character inserted. Assigning to Guido since he's the most enthusiastic IDLE hacker, but moving it to Feature Requests and re-opening. -- Comment By: Tim Peters (tim_one) Date: 2001-03-17 21:55 Message: Logged In: YES user_id=31435 Added to PEP 42 and marked Later/Closed. Assigned to Barry in the hopes that he can clarify the TAB business (I don't understand what this is asking for -- doesn't a TAB key act like a TAB keyin Emacs? maybe I always rebound it in my Emacs days). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=40&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1571112 ] simple moves freeze IDLE
Bugs item #1571112, was opened at 2006-10-05 06:46 Message generated for change (Comment added) made by taleinat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571112&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.5 Status: Open Resolution: None Priority: 7 Private: No Submitted By: Douglas W. Goodall (douglas_goodall) Assigned to: Kurt B. Kaiser (kbk) Summary: simple moves freeze IDLE Initial Comment: Using version 2.5 for Windows... import os then type "print os." and wait for the hint window. then scroll to the bottom (spawnv). That's it. At this point IDLE is frozen. I have done it a few times in a row. It seems very reproduceable to me. Be well. Doug -- Comment By: Tal Einat (taleinat) Date: 2006-12-09 19:33 Message: Logged In: YES user_id=1330769 Originator: NO This cause for this bug is an endless loop in AutoCompleteWindow.py, line 121: 114 selstart = self.completions[cursel] [snip...] 121 while cursel > 0 and selstart[:i] <= self.completions[cursel-1]: 122 i += 1 123 newstart = selstart[:i] The case where this loop becomes endless only arises when the same completion item appears twice in the completions list, thus self.completions[cursel-1] and self.completions[cursel] are identical. This happens with the os module because spawnv and spawnve appear twice in os.__all__. Solution: 1) Fix the potentially endless loop (add a bound for i) 2) Remove identical completion items from the completions list (its a bug anyways) -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-08 19:47 Message: Logged In: YES user_id=580910 As an additional data point: this seems to work just fine on Mac OS X. -- Comment By: Raymond Hettinger (rhettinger) Date: 2006-10-08 05:16 Message: Logged In: YES user_id=80475 I can reproduce this in Py2.5 final. This may be a TkInter bug and not unique to IDLE or to Windows. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-10-07 18:58 Message: Logged In: YES user_id=341410 I can reproduce this on 2.5 beta 2, and it dies exactly when 'spawnv' is highlighted. I have no suggested fixes, only reproducing to verify that this is not user-specific bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571112&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1612262 ] Class Browser doesn't show internal classes
Feature Requests item #1612262, was opened at 2006-12-09 19:38 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=1612262&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tal Einat (taleinat) Assigned to: Nobody/Anonymous (nobody) Summary: Class Browser doesn't show internal classes Initial Comment: If I define a class within a class, like this: class A: class B: pass def foo(self): pass The class browser shows that A contains foo, but it doesn't show B at all. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1612262&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1566611 ] Idle 1.2 - Calltips Hotkey does not work
Bugs item #1566611, was opened at 2006-09-27 23:24 Message generated for change (Comment added) made by taleinat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566611&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: fladd (fladd710) Assigned to: Kurt B. Kaiser (kbk) Summary: Idle 1.2 - Calltips Hotkey does not work Initial Comment: Hitting CTRL+Backslash does not show the calltip (which is not shown by default) on Windows Xp with Python 1.5 Final. -- Comment By: Tal Einat (taleinat) Date: 2006-12-09 19:45 Message: Logged In: YES user_id=1330769 Originator: NO You mean 2.5 final is suppose... Works for me, Python 2.5 final, WinXP Pro. Does this never work or only sometimes? Have you checked you key definitions? Does it work in the Shell window? Please be more specific... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566611&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1562193 ] IDLE Hung up after open script by command line...
Bugs item #1562193, was opened at 2006-09-20 16:10
Message generated for change (Comment added) made by taleinat
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562193&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Marek Nowicki (faramir2)
Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE Hung up after open script by command line...
Initial Comment:
Hello,
I wrote that code in python and saved as prx.py:
--- CUT ---
from BaseHTTPServer import HTTPServer,
BaseHTTPRequestHandler
from time import strftime, gmtime
import urllib2
import thread
from sys import stdout
class RequestHandler(BaseHTTPRequestHandler):
def serve(self):
print "%s %s %s\r\n%s" % (self.command,
self.path,
self.request_version, self.headers)
header={}
header["content-length"]=0
for i in str(self.headers).split("\r\n"):
j=i.split(":", 1)
if len(j)==2:
header[j[0].strip().lower()] =
j[1].strip()
content=self.rfile.read(int(header["content-
length"]))
print content
url="http://faramir2.prv.pl";
u=urllib2.urlopen(url)
for i,j in u.info().items():
print "%s: %s" % (i,j)
self.server_version = "Apache"
self.sys_version = ""
self.send_response(200)
self.send_header("Content-type", "text/html;
charset=ISO-8859-2")
self.send_header("Connectin", "close")
self.end_headers()
def do_POST(self): self.serve()
def do_HEAD(self): self.serve()
def do_GET(self): self.serve()
address = ("", 80)
server = HTTPServer(address, RequestHandler)
thread.start_new_thread(server.serve_forever, () )
--- CUT ---
When I right click on that file and select "Edit with
IDLE" it opens. Then
when I push F5 the script is running. *Python Shell*
is restarting. But
when I try to connect by browser to http://
localhost:80/ IDLE Hung-up. I
don't see that hung ups when I open IDLE from shortcut
and then in IDLE
open file prx.py and run it works normally - good.
IDLE does't hung up.
I don't know why it works like that, but I think that
it's bug..
Python version: 2.5c2
Tk version: 8.4
IDLE version: 1.2c2
OS Version: Microsoft Windows XP Professional with SP2
---
Again:
* Freeze:
>
"C:\Python25\pythonw.exe" "C:\Python25\Lib\idlelib\idle.pyw"
-n -e "prx.py"
// then F5 on IDLE
// when run open Browser and try to open page: http://
localhost:80
// IDLE freezes
* Works ok:
>
"C:\Python25\pythonw.exe" "C:\Python25\Lib\idlelib\idle.pyw"
-e
// open prx.py in IDLE
// press F5 on IDLE
// run Browwser and try to open page: http://
localhost:80
// all works ok
---
regards,
Marek
--
Comment By: Tal Einat (taleinat)
Date: 2006-12-09 19:54
Message:
Logged In: YES
user_id=1330769
Originator: NO
Well, the issue obviously only happens when IDLE is running without a
subprocess.
The code you pasted is unindtented so I'm not going to try it out...
My guess would be that your server is blocking in a way that it blocks all
threads. This is why, when it is run in the same process as IDLE's GUI,
IDLE hangs. However, when you run IDLE with a subprocess, it's the
subprocess which is blocked, so IDLE works normally. (this is what the
subprocess is there for :)
In any case, IDLE is behaving just fine here. This isn't a bug in IDLE.
This could be a bug with the thread module, or a bug in BaseHTTPServer, or
several other places. But it is most likely caused by some misunderstanding
on your part of blocking operations, threads, and the interaction between
them.
You should have tried posting this on c.l.py before posting a bug on SF,
and I suggest you do so now.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1562193&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
