[issue38770] Pickle handle self references in classes
New submission from Saim Raza :
If the __qualname__ of a class is set to have a circular reference to itself,
pickle behaves differently based on protocol. Following script demonstrates the
issue:
==
from __future__ import print_function
import pickle, sys
class Foo:
__name__ = __qualname__ = "Foo.ref"
pass
Foo.ref = Foo
print(sys.version_info)
for proto in range(0, pickle.HIGHEST_PROTOCOL + 1):
print("{}:".format(proto), end=" ")
try:
pkl = pickle.dumps(Foo, proto)
print("Dump OK,", end=" ")
assert(pickle.loads(pkl) is Foo)
print("Load OK,")
except Exception as err:
print(repr(err))
==
OUTPUT:
Python2.7:
sys.version_info(major=2, minor=7, micro=16, releaselevel='final', serial=0)
0: Dump OK, Load OK,
1: Dump OK, Load OK,
2: Dump OK, Load OK,
Python3.7:
sys.version_info(major=3, minor=7, micro=3, releaselevel='final', serial=0)
0: RecursionError('maximum recursion depth exceeded while pickling an object')
1: RecursionError('maximum recursion depth exceeded while pickling an object')
2: RecursionError('maximum recursion depth exceeded while pickling an object')
3: RecursionError('maximum recursion depth exceeded while pickling an object')
4: Dump OK, Load OK,
==
This was introduced as a side effect of issue#23611 (?). I can think of the
following approaches to fix the issue and make the behavior consistent:
1. Check if the class has a self-reference and raise an error for all protocols.
2. Use memoization to handle self-references. I am not sure what should be
dumped in this case. In the example above `Foo` will exist in the namespace but
not `Foo.ref`.
3. Dump such classes similar to Python 2 pickle and Python 3 pickle protocol >=
4.
I had a stab at pickle.py and had a bit of success in doing point 3 above.
Posting this issue for discussions. I would be happy to submit a PR for this
issue.
Thanks,
Saim Raza
--
components: Library (Lib)
messages: 356388
nosy: Saim Raza, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Pickle handle self references in classes
type: behavior
versions: Python 2.7, Python 3.7
___
Python tracker
<https://bugs.python.org/issue38770>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36537] except statement block incorrectly assumes end of scope(?).
Saim Raza added the comment: > Knowing that pdb stops just before the interpreter executes the line after > pdb.set_trace(), what prevents you from writing the pdb.set_trace() statement > before the last line of the except clause ? Of course, that can be done. The issue here is to get the correct and expected behavior from pdb/ipdb. On a similar note, users might want to put just the set_trace() call and no other code in the block while writing the code or during debugging the exception caught. -- ___ Python tracker <https://bugs.python.org/issue36537> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36537] except statement block incorrectly assumes end of scope(?).
Saim Raza added the comment: Thanks, SilentGhost! However, should we try to fix set_trace as well to avoid hassles to other users? -- ___ Python tracker <https://bugs.python.org/issue36537> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36537] except statement block incorrectly assumes end of scope(?).
Saim Raza added the comment: This is pretty unintuitive from a user's stand point. Now, I need to *inconveniently* put some dummy code after the ser_trace call every time I want to access the exception inside the except block. Also, this is a change in behavior from Python 2.7. Is this documented somewhere? -- ___ Python tracker <https://bugs.python.org/issue36537> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36537] except statement block incorrectly assumes end of scope(?).
Saim Raza added the comment: https://docs.python.org/3/reference/compound_stmts.html#the-try-statement says = except E as N: foo = is converted to the following statement: = except E as N: try: foo finally: del N = In the examples in this thread, foo is 'import pdb; pdb.set_trace()'. So, I was expecting 'del N' to be executed only after executing foo. This implies that err should have been available in the scope. Further, isn't the code execution supposed to be stopped at the set_trace() line and not on the next line. Should it at least respect the scope (indentation) and not execute the '--Return--' line event until the user actually executes the next line (x=1 in your example)? -- ___ Python tracker <https://bugs.python.org/issue36537> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36537] except statement block incorrectly assumes end of scope(?).
New submission from Saim Raza :
If pdb.set_trace() is the last statement in the first code snippet, variable
'err' is (wrongly?) excluded from locals(). Adding any code after the
pdb.set_trace() statement makes 'err' available in locals.
In [2]: try:
...: raise ValueError("I am ValueError")
...: except ValueError as err:
...: print("err" in locals())
...: import pdb; pdb.set_trace()
...:
True
--Return--
> (5)()->None
-> import pdb; pdb.set_trace()
(Pdb) print("err" in locals())
False <-- BUG??
(Pdb) c
In [3]: try:
...: raise ValueError("I am ValueError")
...: except ValueError as err:
...: print("err" in locals())
...: import pdb; pdb.set_trace()
...: import os # Dummy code - makes variable 'err' available inside the
debugger.
...:
True
> (6)()->None
-> import os # Dummy code - makes variable err available inside debugger
(Pdb) print("err" in locals())
True
In [4]: sys.version_info
Out[4]: sys.version_info(major=3, minor=7, micro=3, releaselevel='final',
serial=0)
FTR, the variable 'err' is available in both cases in case of Python 2.7. Also,
this happens with ipdb as well.
Please note that I am aware that I need to assign the variable 'err' to some
variable inside the except block to access it outside the except block.
However, the pdb statement is still inside the except block in both cases.
--
components: Library (Lib)
messages: 339510
nosy: Saim Raza
priority: normal
severity: normal
status: open
title: except statement block incorrectly assumes end of scope(?).
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue36537>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36272] Recursive logging crashes Interpreter in Python 3
Saim Raza added the comment: Stack exhaustion doesn't seem to be due to be the root cause. A simple recursive function doesn't crash the interpreter in Python 3.6. >>> def rec(): rec() >>> rec() Traceback (most recent call last): File "", line 1, in File "", line 1, in rec File "", line 1, in rec File "", line 1, in rec [Previous line repeated 995 more times] RecursionError: maximum recursion depth exceeded -- ___ Python tracker <https://bugs.python.org/issue36272> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36272] Recursive logging crashes Interpreter in Python 3
New submission from Saim Raza :
Following code logs an error and calls itself leading to stack overflow and
eventually core dump in Python 3.6.
>>> import logging
>>> def rec():
... logging.error("foo")
... rec()
>>> rec()
[1]101641 abort (core dumped) python3
FTR, this doesn't crash Python 2.7.
Attaching the error (condensed) in Python 3.6:
ERROR:root:foo
...
--- Logging error ---
Traceback (most recent call last):
...
RecursionError: maximum recursion depth exceeded in comparison
...
Fatal Python error: Cannot recover from stack overflow.
...
[1]101641 abort (core dumped) python3
Python 2.7:
RuntimeError: maximum recursion depth exceeded
But no core dump in Python 2.7.
FTR, the error above with Python 3.6 will come into play if the log level is
set to logging.ERROR. Similarly for other log levels.
--
components: Library (Lib)
messages: 337747
nosy: Saim Raza
priority: normal
severity: normal
status: open
title: Recursive logging crashes Interpreter in Python 3
type: crash
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue36272>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
