[ python-Bugs-1370322 ] Bytecode problems with test_colorsys
Bugs item #1370322, was opened at 2005-11-30 19:49 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&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: None Priority: 7 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: Bytecode problems with test_colorsys Initial Comment: Starting point: "make clean; make" in the 2.5 source tree. "make test" hangs at test_colorsys. Careful investigation shows that when the bytecode is freshly generated by "make all" (precisely in test___all__) the .pyc file is different from what a direct call to "regrtest.py test_colorsys" produces. Curiously, a call to "regrtest.py test___all__" instead of "make test" produces the correct bytecode. System is Linux 2.6, x86, gcc 3.4.4. I have attached both versions of colorsys.pyc. -- >Comment By: Armin Rigo (arigo) Date: 2005-12-01 10:32 Message: Logged In: YES user_id=4771 It's again a problem with floats. For example, the constant 0.3 in rgb_to_yiq shows up as 0.0 in bad.pyc. The constant 1.72986 shows up as 1.0. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370322&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1350060 ] built-in method .__cmp__
Bugs item #1350060, was opened at 2005-11-07 08:55 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350060&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: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: built-in method .__cmp__ Initial Comment: Bound methods of built-in objects have a strange __cmp__/__hash__ combination: they compare equal only if their __self__ are identical, but they hash based on the hash of __self__ instead of its _Py_HashPointer(). Built-in methods should consistently be based on the identity *or* the equality of __self__. For reference, regular instance methods are based on the equality. So I propose to fix built-in method objects in the same way. -- >Comment By: Armin Rigo (arigo) Date: 2005-12-01 10:40 Message: Logged In: YES user_id=4771 Sorry, my mistake: regular instance methods behave like built-in methods. They are both based on the identity of their 'self' but use its hash to compute their own hash. This bug report is thus only about why should the hash of methods and built-in methods depend on the hash of their 'self'. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1350060&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1246405 ] Segmentation fault when importing expat from xml.parser
Bugs item #1246405, was opened at 2005-07-28 01:07 Message generated for change (Comment added) made by bernhard You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246405&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jean-Pierre (jean-pierre24) Assigned to: Nobody/Anonymous (nobody) Summary: Segmentation fault when importing expat from xml.parser Initial Comment: Hello, I have a strange segmentation fault when importing expat from xml.parsers in the following program (I removed all that is un-necessary to reproduce the bug, which is why the code may look odd). I've also posted this bug on wxPython bug lists because I'm not sure if it's related to Python or wxPython, but anyway the backtrace told me that the segmentation fault occurs when importing expat. import wx import wx.html class MainFrame(wx.Frame): def __init__(self, prnt): wx.Frame.__init__(self, parent=prnt) wx.html.HtmlWindow(wx.Window(self, -1), -1) print "debug 1" from xml.parsers import expat print "debug 2" class BoaApp(wx.App): def OnInit(self): wx.InitAllImageHandlers() MainFrame(None) return True app = BoaApp() The segmentation fault occurs between 'debug 1' and 'debug 2'. If I try to remove anything else, it doesn't happen. I have confirmed the bug on SunOS 5.8, on linux Red Hat Enterprise Server 3 and linux Advanced Server 3. I'm working with Python 2.4.1 and wxPython 2.6.1.0 Here is in attached file, the backtrace from gdb. Feel free to ask me any additional information... -- Comment By: Bernhard Herzog (bernhard) Date: 2005-12-01 14:51 Message: Logged In: YES user_id=2369 Could this be the same problem as bug 1075984 ? URL: https://sourceforge.net/tracker/index.php?func=detail&aid=1075984&group_id=5470&atid=105470 -- Comment By: Jean-Pierre (jean-pierre24) Date: 2005-10-06 22:23 Message: Logged In: YES user_id=1247525 Yes I can try with different version of wx, but it will take time. Anyway for today here is in attachment the valgrind output on linux x86. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-05 05:34 Message: Logged In: YES user_id=33168 I don't have the problem with Python 2.3.4 and wx 2.5.5.1. Are you able to try different versions of wxPython? I notice that wx 2.6.2 is available. Are you able to run under valgrind or purify? If you run under valgrind, be sure to specify --suppressions=Misc/valgrind-python.supp The file is in the Python distribution. You can download it through SourceForge ViewCVS. -- Comment By: Jean-Pierre (jean-pierre24) Date: 2005-10-05 00:05 Message: Logged In: YES user_id=1247525 Link is : http://sourceforge.net/tracker/index.php?func=detail&aid=1246397&group_id=9863&atid=109863 Unfortunately, absolutely nothing has happened since I reported the bug. -- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-04 07:10 Message: Logged In: YES user_id=33168 Can you provide a link to the wx bug report? Has anything happend with it? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246405&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-1370948 ] Start and end parameters for list.count()
Feature Requests item #1370948, was opened at 2005-12-01 16:12 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=1370948&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: None Status: Open Resolution: None Priority: 5 Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: Start and end parameters for list.count() Initial Comment: For lists and strings, the index() method has start and end parameters. For strings, the count() method has start and end parameters as well. But for lists, the count() method has no such parameters. I think it may be a good idea to allow start and end parameters for count() on lists as well, if only for consistency reasons. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1370948&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1371247 ] locale.windows_locale
Bugs item #1371247, was opened at 2005-12-01 21:50 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=1371247&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: locale.windows_locale Initial Comment: from locale.py: # # this maps windows language identifiers (as used on Windows 95 and # earlier) to locale strings. # # NOTE: this mapping is incomplete. If your language is missing, please # submit a bug report to Python bug manager, which you can find via: # http://www.python.org/dev/ # Make sure you include the missing language identifier and the suggested # locale code. # The complete mapping table can be found here: http://www.dx21.com/SCRIPTING/VBSCRIPT/LCID.ASP -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1371247&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1371247 ] locale.windows_locale
Bugs item #1371247, was opened at 2005-12-01 21:50 Message generated for change (Comment added) made by ghazel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1371247&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: locale.windows_locale Initial Comment: from locale.py: # # this maps windows language identifiers (as used on Windows 95 and # earlier) to locale strings. # # NOTE: this mapping is incomplete. If your language is missing, please # submit a bug report to Python bug manager, which you can find via: # http://www.python.org/dev/ # Make sure you include the missing language identifier and the suggested # locale code. # The complete mapping table can be found here: http://www.dx21.com/SCRIPTING/VBSCRIPT/LCID.ASP -- >Comment By: Greg Hazel (ghazel) Date: 2005-12-01 22:30 Message: Logged In: YES user_id=731668 I believe there's a small typo in that page. Spanish 1034 says hex 0x0C0A when hex(1034) is 0x040A The rest seems correct (hex and int values match). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1371247&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1370197 ] memory leak - ast_error_finish
Bugs item #1370197, was opened at 2005-11-30 08:41
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370197&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: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: memory leak - ast_error_finish
Initial Comment:
http://svn.python.org/view/python/trunk/Python/ast.c?
rev=41486&view=markup
function ast_error_finish
It first gets the errstr, for a possible early out.
If there is an error string, it is increfed, but it is
not decrefed on the other early outs. (lineno==-1 and
failure to build a tmp.
"""
Py_INCREF(errstr);
lineno = PyInt_AsLong(PyTuple_GetItem(value, 1));
if (lineno == -1)
return;
Py_DECREF(value);
loc = PyErr_ProgramText(filename, lineno);
if (!loc) {
Py_INCREF(Py_None);
loc = Py_None;
}
tmp = Py_BuildValue("(ziOO)", filename, lineno,
Py_None, loc);
Py_DECREF(loc);
if (!tmp)
return;
value = Py_BuildValue("(OO)", errstr, tmp);
Py_DECREF(errstr);
"""
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-01 21:22
Message:
Logged In: YES
user_id=33168
ISTM that we don't need the INCREF or DECREF for errstr. Do
you agree?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1370197&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1355842 ] Incorrect Decimal-float behavior for += and *=
Bugs item #1355842, was opened at 2005-11-13 11:17
Message generated for change (Comment added) made by connelly
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&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: Connelly (connelly)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect Decimal-float behavior for += and *=
Initial Comment:
The += and *= operators have strange behavior when the
LHS is a Decimal and the RHS is a float (as of
2005-11-13 CVS decimal.py).
Example:
>>> d = Decimal('1.02')
>>> d += 2.1
>>> d
NotImplemented
A blatant violation of "Errors should never pass silently."
Also, a bad error description is produced for the *=
operator:
>>> d = Decimal('1.02')
>>> d *= 2.9
Traceback (most recent call last):
File "", line 1, in ?
TypeError: can't multiply sequence by non-int
--
>Comment By: Connelly (connelly)
Date: 2005-12-02 06:17
Message:
Logged In: YES
user_id=1039782
The += and *= operations also give the same strange behavior
when the LHS is a Decimal and the RHS is str or unicode:
>>> d = Decimal("1.0")
>>> d += "5"
>>> d
NotImplemented
>>> d = Decimal("1.0")
>>> d *= "1.0"
Traceback (most recent call last):
File "", line 1, in ?
TypeError: can't multiply sequence by non-int
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-11-14 04:43
Message:
Logged In: YES
user_id=33168
Hmmm. __add__ returns NotImplemented which works with
classic classes, but not new-style classes. I wonder if
NotImplementedError is supposed to be raised for new-style
classes.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355842&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
