[issue17526] inspect.findsource raises undocumented error for code objects with empty filename
New submission from Nils Bruin:
It would seem reasonable that an empty filename would be a legitimate way of
indicating that a code object does not have a corresponding source file.
However, if one does that then inspect.findsource raises an unexpected
IndexError rather than the documented IOError.
This seems due to the fix introduced on issue9284
Python 3.2.3 (default, Jun 8 2012, 05:40:07)
[GCC 4.6.3 20120306 (Red Hat 4.6.3-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import inspect
>>> C=compile("print(1)","","single")
>>> D=compile("print(1)","","single")
>>> inspect.findsource(C)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib64/python3.2/inspect.py", line 547, in findsource
raise IOError('could not get source code')
IOError: could not get source code
>>> inspect.findsource(D)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib64/python3.2/inspect.py", line 537, in findsource
if not sourcefile and file[0] + file[-1] != '<>':
IndexError: string index out of range
--
components: Library (Lib)
messages: 185025
nosy: Nils.Bruin
priority: normal
severity: normal
status: open
title: inspect.findsource raises undocumented error for code objects with empty
filename
type: behavior
versions: Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue17526>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17526] inspect.findsource raises undocumented error for code objects with empty filename
Nils Bruin added the comment: The most straightforward change I can think of is to change the line if not sourcefile and file[0] + file[-1] != '<>': to if not sourcefile and (not file or file[0] + file[-1] != '<>'): That solves the problem in the cases I have observed. -- ___ Python tracker <http://bugs.python.org/issue17526> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17816] Weak*Dictionary KeyErrors during callbacks
New submission from Nils Bruin: The following program is a little dependent on memory layout but will usually generate lots of Exception KeyError: (A(9996),) in ignored messages in Python 2.7. import weakref class A(object): def __init__(self,n): self.n=n def __repr__(self): return "A(%d)"%self.n def mess(n): D=weakref.WeakValueDictionary() L=[A(i) for i in range(n)] for i in range(n-1): j=(i+10)%n D[L[i]]=L[j] return D D=mess(1) D.clear() The reason is that on D.clear() all entries are removed from D before actually deleting those entries. Once the entries are deleted one-by-one, sometimes the removal of a key will result in deallocation of that key, which may be a not-yet-deleted ex-value of the dictionary as well. The callback triggers on the weakref, but the dict itself was already emptied, so nothing is found. I've checked and on Python 3.2.3 this problem does not seem to occur. I haven't checked the Python source to see how Python 3 behaves differently and whether that behaviour would be easy to backport to fix this bug in 2.7. -- components: Library (Lib) messages: 187570 nosy: Nils.Bruin priority: normal severity: normal status: open title: Weak*Dictionary KeyErrors during callbacks versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue17816> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17816] Weak*Dictionary KeyErrors during callbacks
Nils Bruin added the comment: Have you tried if the fix at issue7105 solves the problem? I don't see the patch there introduce a `clear` method override for WeakValueDictionary or WeakKeyDictionary. The one for WeakSet still calls self.data.clear(), which for dictionaries would still result in the problem in this ticket (but not for WeakSet, because clearing a WeakSet shouldn't decref anything other than the weak references stored in the underlying set). -- ___ Python tracker <http://bugs.python.org/issue17816> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17816] Weak*Dictionary KeyErrors during callbacks
Nils Bruin added the comment: I think the difference in behaviour between Py3 and Py2 is coming from: http://hg.python.org/cpython/file/a26df2d03989/Objects/dictobject.c#l1275 which first clears all values before removing any keys. For a WeakValueDictionary that means all the weakrefs are neutralized before the can be activated. I don't quite understand how Py3 manages to avoid problems for a WeakKeyDictionary, but apparently it does. -- ___ Python tracker <http://bugs.python.org/issue17816> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17816] Weak*Dictionary KeyErrors during callbacks
Nils Bruin added the comment: One solution is to patch both WeakValueDictionary and WeakKeyDictionary with their own clear methods where we first store the strong links (to keys, resp. values) in a list, then clear the underlying dictionaries (this will now trigger the deletion of the weakrefs, so all callbacks are neutralized), and then delete the list. It does use more storage that way, but it gets rid of the ignored key errors. This is a different problem from issue7105, which deals with the (much more complicated) scenario of avoiding dictionary reshaping due to GC when iterators are still (potentially) active. -- keywords: +patch Added file: http://bugs.python.org/file30101/17816_custom_clear.patch ___ Python tracker <http://bugs.python.org/issue17816> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
