[issue3497] a bug in the interpreter?
New submission from vadim suvorov <[EMAIL PROTECTED]>: The result of the attached script execution is extremely unstable. The change in the print statement in line 146 from 'print "1"' to 'print 1' (string literal to numerical) changes the result of execution to the correct (presumably) one. The results are also affected by commenting out calls to empty method in lines 143 or 227. The use of dis.dis() affects results of the execution as well. More than, the location of error (the triggered assert) shifts in the code, or it is possible that an Exception is raised. The script was tested in Python 2.5.2 in Windows XP SP2 and SP3, 2.6beta2 in Windows XP SP3 and in 2.5.2 Ubuntu 8.0.4 with consistent results. (I mean that behavior of the script is changed by calling of empty methods or irrelevant print statements. The assert shifts.) Sorry for the long script. I failed to further reduce its size because effect disappears. Expected output: ~ 1 1 1 1 1 1 1 1 1 1 1 1 Congratulations: grid solved! 1 2 3 4 5 6 7 8 910 1 B B B B B . B . . B 2 . B . . B B B B . B 3 . . . . . B B . B B 4 . . . B B B B B B . 5 B . B B B . . B B B ~ Received output (example): ~ 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 Traceback (most recent call last): File "E:\pet projects\nonograms\nonogramsolver10.py", line 244, in g.solve() File "E:\pet projects\nonograms\nonogramsolver10.py", line 230, in solve seq.simplescan() File "E:\pet projects\nonograms\nonogramsolver10.py", line 99, in simplescan assert self.clues, "a seq with no clues" AssertionError: a seq with no clues ~ -- components: Interpreter Core files: nonogramsolver10.py messages: 70658 nosy: bad severity: normal status: open title: a bug in the interpreter? type: behavior versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file11045/nonogramsolver10.py ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3497> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3497] a bug in the interpreter?
Changes by vadim suvorov <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file11046/nonogramsolver09.py ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3497> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3497] a bug in the interpreter?
vadim suvorov <[EMAIL PROTECTED]> added the comment: tested Python 2.4.4 on WinXP SP3. It required minor modifications of the code (removing conditional expressions), but the effect stayed. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3497> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3497] a bug in the interpreter?
Changes by vadim suvorov <[EMAIL PROTECTED]>: -- versions: +Python 2.4 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3497> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3497] a bug in the interpreter?
vadim suvorov <[EMAIL PROTECTED]> added the comment: Thank you very much, Tim. I am still very much confused, how change in print statement changes order in which items are removed from a set. I presumed it to be undefined but deterministic (similar to dict()): while I cannot tell which order it is going to be, I can be sure it does not depend on changes in other objects. For example, it does not depend on things like if something is printed, or some dummy method called. I have little doubts that the script contains (or might contain) bugs. I am now trying to use 3.0b2, which shows deterministic (in the sense above) behaviour. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3497> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3497] a bug in the interpreter?
vadim suvorov <[EMAIL PROTECTED]> added the comment: Tim, Martin, thank you very much. I think now it is not an issue, and the record can be closed. Thank you very much again, and please accept my apology. 2 Guilherme Polo: I ran it many times. The results in WinXP (with constant script) are very consistent. 2 Martin v. Löwis: Thank you very much for the excellent explanation. It was exactly what I needed. I did not realize that hash depends on memory location. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3497> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5634] cPickle error in case of recursion limit
New submission from vadim suvorov :
In case of heavily recursive data structure cPickle produces
intermittent random exceptions (AttributeError, etc.). The expected is
RuntimeError: ('maximum recursion depth exceeded in ...'). In addition,
the behavior differs for classic/new classes.
The reason: the cPickle needs several optional methods (__getstate__,
__getinitargs__) for each object. In their absence an AttributeError is
generated. It is normally suppressed, but suppression itself causes
recursion. The error in exception processing leads to fancy errors.
The proposed solution: temporary (for call of PyErr_ExceptionMatches())
increase recursion limit.
--
files: !!!
messages: 84915
nosy: bad
severity: normal
status: open
title: cPickle error in case of recursion limit
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file13527/!!!
___
Python tracker
<http://bugs.python.org/issue5634>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
