[issue13814] Generators as context managers.
New submission from Arkadiusz Wahlig : Generators should support the with statement with __exit__ calling self.close(). with genfunc() as g: for item in g: print(item) -- messages: 151530 nosy: yak priority: normal severity: normal status: open title: Generators as context managers. type: enhancement versions: Python 2.7, Python 3.4 ___ Python tracker <http://bugs.python.org/issue13814> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13328] pdb shows code from wrong module
Arkadiusz Wahlig added the comment: How to reproduce: Given a module foo.py imported using zipimport with a function bar, if we try to set a breakpoint in bar using: > break foo.bar pdb would take filename and lineno from the function object but would use current frame to get module globals. linecache would return a line from current module but also store it in cache under foo's filename. -- ___ Python tracker <http://bugs.python.org/issue13328> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13328] pdb shows code from wrong module
New submission from Arkadiusz Wahlig : If pdb is used to debug code using zipimport, it may end up displaying source code from wrong module. Python will execute the correct code but the source code lines displayed by pdb (including the "list" command) will come from an unrelated module. Reason: The pdb obtains lines of code using the linecache module. When used with zipimported modules, linecache requires the module's globals dict to be passed in along with the filename. The filename is then used as a cache key for future lookups. A bug in pdb causes it to pass filename and globals from different modules when calling linecache thus polluting the cache with bogus data. A patch for 2.7.2 is attached that fixes the problem. The patch also fixes another problem: When Bdb (Pdb parent class from bdb.py) calls linecache, it calls Bdb.canonic(filename) before passing the filename to it. It doesn't pass the module's globals though. This isn't a problem because the call is always made after Pdb has queried source lines for the same module (and it does pass the globals). However, because Pdb doesn't call Bdb.canonic() on the filename, the cache key is different and Bdb's call fails. To fix this, the patch adds calls to Bdb.canonic(filename) whenever Pdb passes a filename to linecache. -- files: pdb.diff keywords: patch messages: 146885 nosy: yak priority: normal severity: normal status: open title: pdb shows code from wrong module type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file23601/pdb.diff ___ Python tracker <http://bugs.python.org/issue13328> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13188] generator.throw() ignores __traceback__ of exception
Arkadiusz Wahlig added the comment: I don't think this should be applied to 2.7. In 2.x, the full exception info consists of the (type, value, traceback)-trio. Programmer is expected to pass this around to retain full exception info. Re-raising just the value (exception instance) using "raise value" starts a fresh traceback. Currently "raise" and gen.throw() behave the same in that regard and there's no reason to change that. Python 3 reduces the exception info to one object by adding __traceback__ to the exception instance so it's reasonable to expect that "raise" and gen.throw() will be able to extract the full info from just the instance. "raise" does that today, gen.throw() didn't, hence this bug report. -- nosy: +yak ___ Python tracker <http://bugs.python.org/issue13188> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13259] __bytes__ not documented
New submission from Arkadiusz Wahlig : It looks like Python 3 supports the __bytes__ magic method (called by bytes(obj)). However, it's not documented anywhere. Also, I could not find any reference to BDFL accepting it but it looks like it got in anyway. Here are some posts back from 2007 where he argues against it: http://mail.python.org/pipermail/python-3000/2007-August/009375.html -- assignee: docs@python components: Documentation messages: 146334 nosy: docs@python, yak priority: normal severity: normal status: open title: __bytes__ not documented versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue13259> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
