[ python-Bugs-1544762 ] x!=y and [x]==[y] (!)
Bugs item #1544762, was opened at 2006-08-22 12:51 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&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.5 Status: Open >Resolution: Invalid Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: x!=y and [x]==[y] (!) Initial Comment: Easy to obtain the weird behavior in the summary (in 2.5rc1 and earlier): >>> inf=1e >>> x = y = inf/inf >>> x!=y and [x]==[y] True I propose to fix it by ensuring that lists (and tuples etc) compare their items with exactly the same logic as the == and != operators use. Alex ([EMAIL PROTECTED]) -- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-28 08:10 Message: Logged In: YES user_id=80475 IMO, this should not be changed. Through-out Python (not just for lists and tuples), internal routines assume that identity implies equality. All your example shows is that the oddball NaN is in-fact odd. IMO, the result weird, but correct. The x!=y result is correct because that is a property of NaNs and the [x]==[y] result is correct because the two lists have identical content. You would get the expected result when the content is not identical: >>> inf=1e >>> x = inf/inf >>> y = inf/inf >>> x != y True >>> [x] == [y] I do not want the rest of Python mucked-up just because NaNs are designed to not follow the most basic definitions of equality (i.e. a relation is an equality relative if and only if it is reflexsive, symmetric, and transitive). Closing as not-a-bug. -- Comment By: Santiago Gala (sgala) Date: 2006-08-24 15:13 Message: Logged In: YES user_id=178886 sorry, forget my last comment, as floats are immutable. -- Comment By: Santiago Gala (sgala) Date: 2006-08-24 06:32 Message: Logged In: YES user_id=178886 comparing tuples by == on elements, instead of "is", would break tuple inmutability and make them unsuitable for keys, BTW. Doing the same with lists would make them behave different to tuples. Liskov and Guttag (Addison Wesley, 2001) book has and interesting discussion on equality in collections, and how java's model has problems (as basically any model with mutable objects that hash on content instead of identity). Python has been doing it right for a lot of time. -- Comment By: Santiago Gala (sgala) Date: 2006-08-24 06:26 Message: Logged In: YES user_id=178886 This is a consequence of the way list equality is implemented. Counterexample: >>> inf=1e >>> x=inf/inf >>> y=inf/inf >>> x!=y and [x] == [y] False i.e. [x] == [y] iff x is y strings are interned in python (so 'a' is chr(97) returns True), and ints (so 1+1 is 1+1 returns True) but not floats (so inf/inf is inf/inf returns False). Interning floats (or at least "special" numbers, such as nan or inf) could make sense, but I guess this is a RFE, and not a bug, and a different one. -- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-23 03:46 Message: Logged In: YES user_id=1581732 FYI: while not directly related, NaN comparisons keep making trouble. Per bug 1514428, python makes the mistake that inf > Nan should return false, just like Nan < inf. -- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-22 17:49 Message: Logged In: YES user_id=1581732 This appears to be a special oddity of NaN, which is a member of the set of "Things That Do Not Equal Themselves". 1. Are there any more members of this set? 2. Does this mean that any complex data type containing an integer is no a member of this set? 3. Is it odd that, say, a user's StatisticsArray will not equal itself if some statistic in the array is Nan? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545837 ] array.array borks on deepcopy
Bugs item #1545837, was opened at 2006-08-24 04:49
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&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: Later
Priority: 7
Submitted By: Václav Haisman (wilx)
>Assigned to: Anthony Baxter (anthonybaxter)
Summary: array.array borks on deepcopy
Initial Comment:
Hi,
I think there is a bug arraymodule.c this line:
{"__deepcopy__",(PyCFunction)array_copy,METH_NOARGS,
copy_doc},
should probably have METH_O instead of METH_NOARGS
there, since according to docs and the prototype of the
array_copy() function there is one parameter.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2006-08-28 08:32
Message:
Logged In: YES
user_id=80475
Should this be fixed in the release candidate?
--
Comment By: Thomas Wouters (twouters)
Date: 2006-08-24 13:50
Message:
Logged In: YES
user_id=34209
Thanks! Fixed in the trunk (which is 2.6-to-be) revision
51565, and it will also be fixed for Python 2.4.4 and 2.5.1.
It's unfortunately just a bit too late for 2.5.0.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1544762 ] x!=y and [x]==[y] (!)
Bugs item #1544762, was opened at 2006-08-22 12:51 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&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.5 >Status: Closed Resolution: Invalid Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: x!=y and [x]==[y] (!) Initial Comment: Easy to obtain the weird behavior in the summary (in 2.5rc1 and earlier): >>> inf=1e >>> x = y = inf/inf >>> x!=y and [x]==[y] True I propose to fix it by ensuring that lists (and tuples etc) compare their items with exactly the same logic as the == and != operators use. Alex ([EMAIL PROTECTED]) -- Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-28 08:10 Message: Logged In: YES user_id=80475 IMO, this should not be changed. Through-out Python (not just for lists and tuples), internal routines assume that identity implies equality. All your example shows is that the oddball NaN is in-fact odd. IMO, the result weird, but correct. The x!=y result is correct because that is a property of NaNs and the [x]==[y] result is correct because the two lists have identical content. You would get the expected result when the content is not identical: >>> inf=1e >>> x = inf/inf >>> y = inf/inf >>> x != y True >>> [x] == [y] I do not want the rest of Python mucked-up just because NaNs are designed to not follow the most basic definitions of equality (i.e. a relation is an equality relative if and only if it is reflexsive, symmetric, and transitive). Closing as not-a-bug. -- Comment By: Santiago Gala (sgala) Date: 2006-08-24 15:13 Message: Logged In: YES user_id=178886 sorry, forget my last comment, as floats are immutable. -- Comment By: Santiago Gala (sgala) Date: 2006-08-24 06:32 Message: Logged In: YES user_id=178886 comparing tuples by == on elements, instead of "is", would break tuple inmutability and make them unsuitable for keys, BTW. Doing the same with lists would make them behave different to tuples. Liskov and Guttag (Addison Wesley, 2001) book has and interesting discussion on equality in collections, and how java's model has problems (as basically any model with mutable objects that hash on content instead of identity). Python has been doing it right for a lot of time. -- Comment By: Santiago Gala (sgala) Date: 2006-08-24 06:26 Message: Logged In: YES user_id=178886 This is a consequence of the way list equality is implemented. Counterexample: >>> inf=1e >>> x=inf/inf >>> y=inf/inf >>> x!=y and [x] == [y] False i.e. [x] == [y] iff x is y strings are interned in python (so 'a' is chr(97) returns True), and ints (so 1+1 is 1+1 returns True) but not floats (so inf/inf is inf/inf returns False). Interning floats (or at least "special" numbers, such as nan or inf) could make sense, but I guess this is a RFE, and not a bug, and a different one. -- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-23 03:46 Message: Logged In: YES user_id=1581732 FYI: while not directly related, NaN comparisons keep making trouble. Per bug 1514428, python makes the mistake that inf > Nan should return false, just like Nan < inf. -- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-22 17:49 Message: Logged In: YES user_id=1581732 This appears to be a special oddity of NaN, which is a member of the set of "Things That Do Not Equal Themselves". 1. Are there any more members of this set? 2. Does this mean that any complex data type containing an integer is no a member of this set? 3. Is it odd that, say, a user's StatisticsArray will not equal itself if some statistic in the array is Nan? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1528802 ] Turkish Character
Bugs item #1528802, was opened at 2006-07-26 10:05
Message generated for change (Comment added) made by ahmetbiskinler
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Unicode
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 6
Submitted By: Ahmet Bişkinler (ahmetbiskinler)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Turkish Character
Initial Comment:
>>> print "Mayıs".upper()
>>> MAYıS
>>> import locale
>>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254')
>>> print "Mayıs".upper()
>>> MAYıS
>>> print "ğüşiöçı".upper()
>>> ğüşIöçı
MAYıS should be MAYIS
ğüşIöçı should be ĞÜŞİÖÇI
but
>>> "Mayıs".upper()
>>> "MAYIS"
is right
--
>Comment By: Ahmet Bişkinler (ahmetbiskinler)
Date: 2006-08-28 16:57
Message:
Logged In: YES
user_id=1481281
As you saw in the picture the IDLE does its work. Its is the
one who is working right.
The python interpreter(C:\Python25\Python.exe) has the
problem with it. Does the interpreter generate bug reports
if there is no crashing or else... And I don't know how to
file an IDLE bug report from the
interpreter(C:\Python25\Python.exe).
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-08-21 13:01
Message:
Logged In: YES
user_id=38388
Could we please get some things straight first:
1. if you're working with IDLE and it doesn't do what you
expect it to, please file an IDLE bug report, not a Python
one; the same it true for any other Python IDE you are using
2. string's .lower() and .upper() method rely 100% on the
platform's C lib implementation of these functions; there's
nothing Python can do about bugs in these implementations
3. if you want reproducable behavior across platforms,
please always use Unicode, *not* 8-bit strings, for text data.
I see that #1 has already been done, so the IDLE specific
discussion should continue there.
#2 is the cause of the problem, then all we can do is point
you to #3.
If #3 fails for some reason, then we should investigate
this. However, be aware that the Unicode database has a
fixed set of case mappings and we currently don't support
extended case mapping which is locale and context sensitive.
Again, patches are welcome.
Please provide your examples using the repr() of the string
or Unicode objects in question. This makes it a lot easier
to test your examples on other platforms.
Thanks.
--
Comment By: Ahmet Bişkinler (ahmetbiskinler)
Date: 2006-08-21 10:55
Message:
Logged In: YES
user_id=1481281
There are still some problems with it. As in the image.
http://img205.imageshack.us/img205/3998/turkishcharpythonyu5.jpg
The upper() works fine(except ı and i uppercase) with IDLE
since upper() doesn't even work.
Another problem is with the ı(dotless) and i(dotted) 's upper.
ı(dotless) should be I (dotless)
i(dotted) should be İ (dotted)
ı = I
i = İ
For more information:
http://www.i18nguy.com/unicode/turkish-i18n.html
--
Comment By: Santiago Gala (sgala)
Date: 2006-08-18 17:37
Message:
Logged In: YES
user_id=178886
Done: Bug #1542677
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-17 22:08
Message:
Logged In: YES
user_id=849994
Please submit that as a separate IDLE bug.
--
Comment By: Santiago Gala (sgala)
Date: 2006-08-17 21:58
Message:
Logged In: YES
user_id=178886
Idle from 2.5rc1 (svn today) produces a different result
than console (with my default, utf-8, encoding):
IDLE 1.2c1
>>> print "á"
á
>>> print len("á")
2
>>> print "á".upper()
á
>>> str("á")
'\xc3\xa1'
>>> print u"á"
á
>>> print len(u"á")
2
>>> print u"á".upper()
á
>>> str(u"á")
Traceback (most recent call last):
File "", line 1, in
str(u"á")
UnicodeEncodeError: 'ascii' codec can't encode characters in
position 0-1: ordinal not in range(128)
Again, IDLE 1.1.3 (python 2.4.3) produces a different result:
IDLE 1.1.3
>>> print "á"
á
>>> print len("á")
2
>>> print "á".upper()
á
>>> str("á")
'\xc3\xa1'
>>> print u"á"
á
>>> print len(u"á")
2
>>> print u"á".upper()
á
>>> str(u"á")
'\xc3\x83\xc2\xa1'
>>>
I'd say idle is broken, as it is not able to respect utf-8
for print (or even len) of unicode strings.
OTOH, with some tricks I can manage to get an accented a in
a unicode in idle:
>>> import unicodedata
>>> print unicodedata.lookup("LATIN SMALL LETTER A WITH ACUTE")
á
>>> print len(unicodedata.lookup("LATIN SMALL LETTER A WITH
ACUTE"))
1
--
[ python-Bugs-1542949 ] idle in python 2.5c1 freezes on macos 10.3.9
Bugs item #1542949, was opened at 2006-08-18 21:51 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&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: 6 Submitted By: David Strozzi (dstrozzi) >Assigned to: Ronald Oussoren (ronaldoussoren) Summary: idle in python 2.5c1 freezes on macos 10.3.9 Initial Comment: Hi, I installed python 2.5b3 on a powerbook ppc laptop running macos 10.3.9 a few days ago. python and idle worked. Now I installed 2.5c1. python works fine from a terminal. When I start idle, it loads, puts up its menu bar, opens a shell window, displays usual startup info, and gives me a prompt. But, I can't type or get a cursor. Whenever I move the mouse over the idle window or menu bar, I get a spinning color wheel and can't do anything. I deleted the whole /library/python tree, reinstalled 2.5c1, and exactly the same thing happened. Oh, and I rebooted :) Not sure what is happening, or how to diagnose. -- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-28 09:59 Message: Logged In: YES user_id=149084 Maybe priority should be higher? Hopefully Ronald has time to look at this; I don't have access to a Mac. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1547931 ] Typo in Language Reference Section 3.2 Class Instances
Bugs item #1547931, was opened at 2006-08-28 10:05 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=1547931&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: whesse_at_clarkson (whesse1) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in Language Reference Section 3.2 Class Instances Initial Comment: In the Python Language Reference, Section 3.2, subsection "Class Instances", HTML version, the sentence ending "... user-defined method object whose im_class attribute is C whose im_self attribute is the instance. " should add the word "and" to read "... user-defined method object whose im_class attribute is C and whose im_self attribute is the instance. " -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1547931&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1542949 ] idle in python 2.5c1 freezes on macos 10.3.9
Bugs item #1542949, was opened at 2006-08-19 03:51 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&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: 6 Submitted By: David Strozzi (dstrozzi) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: idle in python 2.5c1 freezes on macos 10.3.9 Initial Comment: Hi, I installed python 2.5b3 on a powerbook ppc laptop running macos 10.3.9 a few days ago. python and idle worked. Now I installed 2.5c1. python works fine from a terminal. When I start idle, it loads, puts up its menu bar, opens a shell window, displays usual startup info, and gives me a prompt. But, I can't type or get a cursor. Whenever I move the mouse over the idle window or menu bar, I get a spinning color wheel and can't do anything. I deleted the whole /library/python tree, reinstalled 2.5c1, and exactly the same thing happened. Oh, and I rebooted :) Not sure what is happening, or how to diagnose. -- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 17:22 Message: Logged In: YES user_id=580910 I can reproduce this on 10.3.9: IDLE starts and opens the interactive window, but then completely blocks (spinning cursor). If I start IDLE from the commandline (/Applications/MacPython\ 2.5/ IDLE.app/Contents/MacOS/IDLE) I get a message about 'console' not being a valid command name. That requires further looking into, but is a red herring for this particular problem, removing the Tk-console hiding code in macosxSupport.py results in the same behaviour, without any further output on the console as well. Upgrading aquatk to the latest version (8.4.10.0) on tcltkaqua.sf.net didn't help, IDLE still hangs (Duh, that's because there's a /System/Library/ Frameworks/Tk.framework, which means a user install won't be used for IDLE). The problem is also unrelated to my IDLE.app work, the same problem occurs when starting $prefix/lib/python2.5/idlelib/idle.py. According to gdb the IDLE process is handing in a semaphore call inside the Tcl mainloop. Time to get into serious debugging mode I guess :-( BTW. IDLE does work correctly on a 10.4.7 system. -- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-28 15:59 Message: Logged In: YES user_id=149084 Maybe priority should be higher? Hopefully Ronald has time to look at this; I don't have access to a Mac. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1542949 ] idle in python 2.5c1 freezes on macos 10.3.9
Bugs item #1542949, was opened at 2006-08-18 21:51 Message generated for change (Comment added) made by dstrozzi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&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: 6 Submitted By: David Strozzi (dstrozzi) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: idle in python 2.5c1 freezes on macos 10.3.9 Initial Comment: Hi, I installed python 2.5b3 on a powerbook ppc laptop running macos 10.3.9 a few days ago. python and idle worked. Now I installed 2.5c1. python works fine from a terminal. When I start idle, it loads, puts up its menu bar, opens a shell window, displays usual startup info, and gives me a prompt. But, I can't type or get a cursor. Whenever I move the mouse over the idle window or menu bar, I get a spinning color wheel and can't do anything. I deleted the whole /library/python tree, reinstalled 2.5c1, and exactly the same thing happened. Oh, and I rebooted :) Not sure what is happening, or how to diagnose. -- >Comment By: David Strozzi (dstrozzi) Date: 2006-08-28 11:48 Message: Logged In: YES user_id=1056922 Well, if there's anything I can do as a 10.3.9 user to test this, let me know. Too busy to delve into the python source code though... -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 11:22 Message: Logged In: YES user_id=580910 I can reproduce this on 10.3.9: IDLE starts and opens the interactive window, but then completely blocks (spinning cursor). If I start IDLE from the commandline (/Applications/MacPython\ 2.5/ IDLE.app/Contents/MacOS/IDLE) I get a message about 'console' not being a valid command name. That requires further looking into, but is a red herring for this particular problem, removing the Tk-console hiding code in macosxSupport.py results in the same behaviour, without any further output on the console as well. Upgrading aquatk to the latest version (8.4.10.0) on tcltkaqua.sf.net didn't help, IDLE still hangs (Duh, that's because there's a /System/Library/ Frameworks/Tk.framework, which means a user install won't be used for IDLE). The problem is also unrelated to my IDLE.app work, the same problem occurs when starting $prefix/lib/python2.5/idlelib/idle.py. According to gdb the IDLE process is handing in a semaphore call inside the Tcl mainloop. Time to get into serious debugging mode I guess :-( BTW. IDLE does work correctly on a 10.4.7 system. -- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-28 09:59 Message: Logged In: YES user_id=149084 Maybe priority should be higher? Hopefully Ronald has time to look at this; I don't have access to a Mac. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1479785 ] Quitter object masked
Bugs item #1479785, was opened at 2006-05-01 17:01 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479785&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: Fixed Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Kurt B. Kaiser (kbk) Summary: Quitter object masked Initial Comment: 2.5 introduces a Quitter object (defined in site.py) to make the quit/exit message more friendly. Lines 480-482 of PyShell.py override this, so that users of Idle never see the improved feature. Unfortunately, simply removing those lines isn't quite enough to solve the problem, as IDLE catches SystemExit exceptions. Getting around that, I didn't have time to track down yet. -- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 18:43 Message: Logged In: YES user_id=580910 When I type quit() in the Python Shell window I get a dialog that says: > The program is still running! > Do you want to kill it? (Python 2.5c1) -- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-16 07:03 Message: Logged In: YES user_id=149084 Rev 51306: Patch #1540892 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479785&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1542949 ] idle in python 2.5c1 freezes on macos 10.3.9
Bugs item #1542949, was opened at 2006-08-19 03:51 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&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: 6 Submitted By: David Strozzi (dstrozzi) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: idle in python 2.5c1 freezes on macos 10.3.9 Initial Comment: Hi, I installed python 2.5b3 on a powerbook ppc laptop running macos 10.3.9 a few days ago. python and idle worked. Now I installed 2.5c1. python works fine from a terminal. When I start idle, it loads, puts up its menu bar, opens a shell window, displays usual startup info, and gives me a prompt. But, I can't type or get a cursor. Whenever I move the mouse over the idle window or menu bar, I get a spinning color wheel and can't do anything. I deleted the whole /library/python tree, reinstalled 2.5c1, and exactly the same thing happened. Oh, and I rebooted :) Not sure what is happening, or how to diagnose. -- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 18:59 Message: Logged In: YES user_id=580910 I've created a new installer from the head of the release25-maint branch and that works correctly. I'm keeping this issue open because I want to investigate why 2.5c1 doesn't work while the current head of the 2.5 branch does work. -- Comment By: David Strozzi (dstrozzi) Date: 2006-08-28 17:48 Message: Logged In: YES user_id=1056922 Well, if there's anything I can do as a 10.3.9 user to test this, let me know. Too busy to delve into the python source code though... -- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 17:22 Message: Logged In: YES user_id=580910 I can reproduce this on 10.3.9: IDLE starts and opens the interactive window, but then completely blocks (spinning cursor). If I start IDLE from the commandline (/Applications/MacPython\ 2.5/ IDLE.app/Contents/MacOS/IDLE) I get a message about 'console' not being a valid command name. That requires further looking into, but is a red herring for this particular problem, removing the Tk-console hiding code in macosxSupport.py results in the same behaviour, without any further output on the console as well. Upgrading aquatk to the latest version (8.4.10.0) on tcltkaqua.sf.net didn't help, IDLE still hangs (Duh, that's because there's a /System/Library/ Frameworks/Tk.framework, which means a user install won't be used for IDLE). The problem is also unrelated to my IDLE.app work, the same problem occurs when starting $prefix/lib/python2.5/idlelib/idle.py. According to gdb the IDLE process is handing in a semaphore call inside the Tcl mainloop. Time to get into serious debugging mode I guess :-( BTW. IDLE does work correctly on a 10.4.7 system. -- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-28 15:59 Message: Logged In: YES user_id=149084 Maybe priority should be higher? Hopefully Ronald has time to look at this; I don't have access to a Mac. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1548092 ] curses module segfaults on invalid tparm arguments
Bugs item #1548092, was opened at 2006-08-28 19:47
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548092&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: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marien Zwart (marienz)
Assigned to: Nobody/Anonymous (nobody)
Summary: curses module segfaults on invalid tparm arguments
Initial Comment:
At least on my platform the ncurses "tparm" function
returns NULL on certain invalid arguments.
PyCurses_tparm does not check the return value, it just
passes it to PyString_FromString. This means:
python -c "import curses;curses.setupterm();print
curses.tparm('', curses.COLOR_GREEN)"
gives me:
zsh: segmentation fault python -c
(tested with python 2.4.3)
I am not sure what the best fix is. An exception would
make sense to me, but the (related) tigetstr function
returns None to python if the wrapped c function
returns NULL, and I have not used the curses module
enough to know what is more common.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548092&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1548178 ] Add 'find' method to sequence types
Bugs item #1548178, was opened at 2006-08-28 22:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548178&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: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: kovan (kovan) Assigned to: Nobody/Anonymous (nobody) Summary: Add 'find' method to sequence types Initial Comment: In the benefit of Python's readability and simplicity, a 'find' method could be added to sequence types, that would return the first item in the list that matches some criteria. For example, it's a common practice to use lists of (key,value) pairs instead of dictionaries when the sequence must be ordered. To find an element maching a key in such cases, I frequently find myself writing (IMHO) too much code for such a straightforward operation. AFAIK currently there are two easy ways to do this (shouln't be one, and only one?): for item in items: if item.attribute == key: foundItem = item break else: foundItem = None OR foundItems = [item for item in items if item.key == value] if foundItems: foundItem = foundItem[0] IMO, in none of the cases the code is as clear and, specially, as short, as it should be. With the find method, the same code would be: item = items.find(lambda x: x.key == value) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548178&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1548178 ] Add 'find' method to sequence types
Bugs item #1548178, was opened at 2006-08-28 22:47 Message generated for change (Settings changed) made by kovan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548178&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: Feature Request Status: Open Resolution: None >Priority: 4 Submitted By: kovan (kovan) Assigned to: Nobody/Anonymous (nobody) Summary: Add 'find' method to sequence types Initial Comment: In the benefit of Python's readability and simplicity, a 'find' method could be added to sequence types, that would return the first item in the list that matches some criteria. For example, it's a common practice to use lists of (key,value) pairs instead of dictionaries when the sequence must be ordered. To find an element maching a key in such cases, I frequently find myself writing (IMHO) too much code for such a straightforward operation. AFAIK currently there are two easy ways to do this (shouln't be one, and only one?): for item in items: if item.attribute == key: foundItem = item break else: foundItem = None OR foundItems = [item for item in items if item.key == value] if foundItems: foundItem = foundItem[0] IMO, in none of the cases the code is as clear and, specially, as short, as it should be. With the find method, the same code would be: item = items.find(lambda x: x.key == value) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548178&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1548252 ] Recursion limit exceeded in the match function
Bugs item #1548252, was opened at 2006-08-29 02:05
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=1548252&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: wojtekwu (wojtekwu)
Assigned to: Nobody/Anonymous (nobody)
Summary: Recursion limit exceeded in the match function
Initial Comment:
Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import re
>>> exp = re.compile("((a*)(b*))*")
>>> result = exp.match("a")
Traceback (most recent call last):
File "", line 1, in ?
RuntimeError: maximum recursion limit exceeded
>>>
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548252&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1548252 ] Recursion limit exceeded in the match function
Bugs item #1548252, was opened at 2006-08-28 21:05
Message generated for change (Comment added) made by andresriancho
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548252&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: wojtekwu (wojtekwu)
Assigned to: Nobody/Anonymous (nobody)
Summary: Recursion limit exceeded in the match function
Initial Comment:
Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import re
>>> exp = re.compile("((a*)(b*))*")
>>> result = exp.match("a")
Traceback (most recent call last):
File "", line 1, in ?
RuntimeError: maximum recursion limit exceeded
>>>
--
Comment By: Andres Riancho (andresriancho)
Date: 2006-08-28 22:31
Message:
Logged In: YES
user_id=1284064
I tried this on:
Python 2.4.3 (#2, Apr 27 2006, 14:43:58)
seems to be fixed.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548252&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1548288 ] sgmllib.sgmlparser is not thread safe
Bugs item #1548288, was opened at 2006-08-28 23:32
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=1548288&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: Andres Riancho (andresriancho)
Assigned to: Nobody/Anonymous (nobody)
Summary: sgmllib.sgmlparser is not thread safe
Initial Comment:
Python version:
===
[EMAIL PROTECTED]:~$ python
Python 2.4.3 (#2, Apr 27 2006, 14:43:58)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Problem description:
sgmlparser is not thread safe, i discovered this
problem when trying to fetch and parse many html files
at the same time.
An example of this bug can be found attached.
The sgmlparser input html is this string:
''*100 , this was written this way to
simplify the code, please note that if you replace this
string with a "large" html document, it will also fail.
solution:
=
make the lib thread safe, or add some lines to the
documentation saying that it aint thread safe.
Traceback:
==
python sgml-not-threadSafe.py
Started all threads
Successfully parsed html
Exception in thread Thread-3:
Traceback (most recent call last):
File "/usr/lib/python2.4/threading.py", line 442, in
__bootstrap
self.run()
File "/usr/lib/python2.4/threading.py", line 422, in run
self.__target(*self.__args, **self.__kwargs)
File "sgml-not-threadSafe.py", line 10, in parseHtml
self._parser.feed( html )
File "/usr/lib/python2.4/sgmllib.py", line 95, in feed
self.goahead(0)
File "/usr/lib/python2.4/sgmllib.py", line 129, in
goahead
k = self.parse_starttag(i)
File "/usr/lib/python2.4/sgmllib.py", line 262, in
parse_starttag
self.error('unexpected call to parse_starttag')
File "/usr/lib/python2.4/sgmllib.py", line 102, in error
raise SGMLParseError(message)
SGMLParseError: unexpected call to parse_starttag
Successfully parsed html
Successfully parsed html
Additional note
===
To recreate this bug, you should run the sample code
more than one time. Thread handling aint always the
same, the issue is there but sometimes it fails to
appear on the first (second, third...) run.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548288&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1548332 ] whichdb too dumb
Bugs item #1548332, was opened at 2006-08-28 22:51
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=1548332&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: Extension Modules
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Curtis Doty (dotysan)
Assigned to: Nobody/Anonymous (nobody)
Summary: whichdb too dumb
Initial Comment:
On my system with db4, I noticed that whichdb doesn't
know anything about more recent database types created
by the bsddb module.
Python 2.4.3 (#1, Jun 13 2006, 11:46:08)
[GCC 4.1.1 20060525 (Red Hat 4.1.1-1)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>>
>>> from whichdb import *
>>> import bsddb
>>>
>>> dbfile= "hash"
>>> bsddb.hashopen( dbfile)
{}
>>> whichdb( dbfile)
'dbhash'
>>> # yay
...
>>> dbfile= "btree"
>>> bsddb.btopen( dbfile)
{}
>>> whichdb( dbfile)
''
>>> # bah
...
>>> dbfile= "recno"
>>> bsddb.rnopen( dbfile)
{}
>>> whichdb( dbfile)
''
>>> # humbug!
It looks like both these database types share:
#define DB_BTREEMAGIC 0x053162
So this might be a start:
--- Python-2.5c1/Lib/whichdb.py.orig 2005-02-05
22:57:08.0 -0800
+++ Python-2.5c1/Lib/whichdb.py 2006-08-28
13:46:57.0 -0700
@@ -109,6 +109,10 @@
if magic in (0x00061561, 0x61150600):
return "dbhash"
+# Check for binary tree
+if magic == 0x00053162:
+return "btree"
+
# Unknown
return ""
But alas, I'm not clear on the best way to
differentiate between btree and recno.
The above example is on 2.4 but persists in 2.5.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548332&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
