[issue473753] Plug sys.exc_info() leaks

Change by admin : -- github: None -> 35382 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32679] concurrent.futures should store full sys.exc_info()

Irit Katriel added the comment: Following the changes in issue45711, exc_info[2] is exactly the same as exc_info[1].__traceback__, so there is no point in making this change now. -- resolution: -> not a bug stage: -> resolved status: open -> closed

[issue32679] concurrent.futures should store full sys.exc_info()

Irit Katriel added the comment: The SO link seems to refer to Python 2, but on this issue the version are Python 3. In Python 3 the traceback is accessible from the exception via its __traceback__ attribute. Does that not give you what you need? -- nosy: +iritkatriel

[issue35790] Correct the description of sys.exc_info() and add a code example

Change by Julien Palard : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue35790] Correct the description of sys.exc_info() and add a code example

Julien Palard added the comment: New changeset d515c610c61b9a8c40c037a3dc3bfc8d67563658 by Géry Ogam in branch 'master': bpo-35790: Correct the description of sys.exc_info() and add a code example (GH-11625) https://github.com/python/cpython/commit/d515c610c61b9a8c40c037a3dc3bfc8d67563658

[issue35790] Correct the description of sys.exc_info() and add a code example

Change by Géry : -- nosy: +cheryl.sabella -eric.araujo, ezio.melotti, willingc title: Correct a statement about sys.exc_info() values restoration -> Correct the description of sys.exc_info() and add a code example type: -> enhancement versions: +Python 3.6, Python 3.8, Pyth

[issue36270] DOC: Add link to sys.exc_info for "Reference Manual"

Change by Julien Palard : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue36270] DOC: Add link to sys.exc_info for "Reference Manual"

miss-islington added the comment: New changeset f79a022d762edc749d0fecdc50c567d2bb910c53 by Miss Islington (bot) in branch '3.8': bpo-36270: Doc: add link to traceback object reference (GH-13119) https://github.com/python/cpython/commit/f79a022d762edc749d0fecdc50c567d2bb910c53 --

[issue36270] DOC: Add link to sys.exc_info for "Reference Manual"

Change by miss-islington : -- pull_requests: +15627 pull_request: https://github.com/python/cpython/pull/16002 ___ Python tracker ___

[issue36270] DOC: Add link to sys.exc_info for "Reference Manual"

Julien Palard added the comment: New changeset 9936371af298d465095ae70bc9c2943b4b16eac4 by Julien Palard (Björn Meier) in branch 'master': bpo-36270: Doc: add link to traceback object reference (GH-13119) https://github.com/python/cpython/commit/9936371af298d465095ae70bc9c2943b4b16eac4

[issue32679] concurrent.futures should store full sys.exc_info()

Brian Quinlan added the comment: My understanding is that tracebacks have a pretty large memory profile so I'd rather not keep them alive. Correct me if I'm wrong about that. -- ___ Python tracker

[issue36270] DOC: Add link to sys.exc_info for "Reference Manual"

Change by Bjoern Meier : -- keywords: +patch pull_requests: +13032 stage: needs patch -> patch review ___ Python tracker ___ ___

[issue32679] concurrent.futures should store full sys.exc_info()

Change by Cheryl Sabella : -- nosy: +bquinlan, pitrou versions: -Python 3.4, Python 3.5, Python 3.6 ___ Python tracker ___ ___

[issue36270] DOC: Add link to sys.exc_info for "Reference Manual"

New submission from Cheryl Sabella : In the docs for `sys.exc_info()`, the description of traceback says: traceback gets a traceback object (see the ---> Reference Manual <---) which encapsulates the call stack at the point where the exception originally occurred. It might b

[issue35790] Correct a statement about sys.exc_info() values restoration

Change by Géry : -- keywords: +patch, patch, patch pull_requests: +11386, 11387, 11388 stage: -> patch review ___ Python tracker ___

[issue35790] Correct a statement about sys.exc_info() values restoration

Change by Géry : -- keywords: +patch, patch pull_requests: +11386, 11387 stage: -> patch review ___ Python tracker ___ ___

[issue35790] Correct a statement about sys.exc_info() values restoration

Change by Géry : -- keywords: +patch pull_requests: +11386 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list

[issue35790] Correct a statement about sys.exc_info() values restoration

New submission from Géry : In the documentation of the try statement (https://docs.python.org/3/reference/compound_stmts.html#the-try-statement), I think that the sentence: "sys.exc_info() values are restored to their previous values (before the call) when returning from a fun

[issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate

Change by Serhiy Storchaka : -- status: open -> closed ___ Python tracker ___

[issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate

Mark Shannon added the comment: Nothing left to do. This is now obsolete. -- resolution: -> out of date stage: patch review -> resolved status: pending -> open ___ Python tracker

[issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate

Serhiy Storchaka added the comment: Aren't they were moved in issue25612? Is there something that should be done in this issue? -- nosy: +serhiy.storchaka ___ Python tracker

[issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate

Change by Serhiy Storchaka : -- status: open -> pending ___ Python tracker ___

[issue32679] concurrent.futures should store full sys.exc_info()

Jonas H. added the comment: See also https://stackoverflow.com/questions/19309514/getting-original-line-number-for-exception-in-concurrent-futures for other people having the same problem -- ___ Python tracker

[issue32679] concurrent.futures should store full sys.exc_info()

New submission from Jonas H. <jo...@lophus.org>: Use case: Try to get a future's result using concurrent.futures.Future.result(), and log the full exception if there was any. Currently, only "excinst" (sys.exc_info()[1]) is provided with the Future.exception() method. P

Re: sys.exc_info

On 29/06/17 19:00, eryk sun wrote: > On Thu, Jun 29, 2017 at 6:50 AM, Steven D'Aprano <st...@pearwood.info> wrote: >> try: >> something >> except: >> exc_type, exc, tb = sys.exc_info() >> print(traceback.extract_tb(tb)) >> rais

Re: sys.exc_info

quot;credits" or "license" for more information. try: ... raise 'error', 'message' ... except: ... import sys ... print sys.exc_info() ... ('error', 'message', ) This was deprecated in 2.5, and (I think?) removed in 2.7. Deprecated in 2.5, gone in 2.6. From

Re: sys.exc_info

On 29/06/17 08:50, Steven D'Aprano wrote: > sys.exc_info() returns three items: > > (exception type, exception value, traceback) > > https://docs.python.org/2/library/sys.html#sys.exc_info > > https://docs.python.org/3/library/sys.html#sys.exc_info > > > &g

Re: sys.exc_info

On Thu, Jun 29, 2017 at 6:50 AM, Steven D'Aprano <st...@pearwood.info> wrote: > try: > something > except: > exc_type, exc, tb = sys.exc_info() > print(traceback.extract_tb(tb)) > raise > > Why does it return the exception type separately from the

sys.exc_info

sys.exc_info() returns three items: (exception type, exception value, traceback) https://docs.python.org/2/library/sys.html#sys.exc_info https://docs.python.org/3/library/sys.html#sys.exc_info and may be used something like this example: try: something except: exc_type, exc, tb

[issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate

Mark Shannon added the comment: This issue is rather old, so I will create a new GitHub PR for the code change. This issue can be closed. Note that https://bugs.python.org/issue25612 is a manifestation of the problem that this was intended to solve. -- nosy: +Mark Shannon

The use of sys.exc_info for catching exceptions

: import sys try: pr.update() except (ConfigurationException,): e = sys.exc_info()[1] returnString = "%s %s" % (e.line, e.errormsg) I understand that there has been a discussion about deprecating sys.exc_info() on [1] and in section "Possible Future Compatible Changes&

[issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate

Mark Shannon added the comment: Updated patch to support exception chaining and to merge cleanly. -- versions: +Python 3.6 -Python 3.4 Added file: http://bugs.python.org/file40015/exc_info3.patch ___ Python tracker rep...@bugs.python.org

[issue5970] sys.exc_info leaks into a generator

Georg Brandl added the comment: Out of date now that 2.7 is also in maintenance mode. -- nosy: +georg.brandl resolution: - out of date status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5970

[issue7340] Doc for sys.exc_info has warning that is no longer valid

Changes by Serhiy Storchaka storch...@gmail.com: -- keywords: +easy versions: +Python 3.3, Python 3.4 -Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7340 ___

[issue7340] Doc for sys.exc_info has warning that is no longer valid

Roundup Robot added the comment: New changeset 3fa3e7975724 by Benjamin Peterson in branch '3.3': remove warning about tb circular reference (closes #7340) http://hg.python.org/cpython/rev/3fa3e7975724 New changeset d866bbdd68e8 by Benjamin Peterson in branch 'default': merge 3.3 (#7340)

[issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate

Changes by Terry J. Reedy tjre...@udel.edu: -- versions: +Python 3.4 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13897 ___ ___

[issue14098] provide public C-API for reading/setting sys.exc_info()

Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 9fdec1354af4 by Martin v. Löwis in branch 'default': Issue #14098: New functions PyErr_GetExcInfo and PyErr_SetExcInfo. http://hg.python.org/cpython/rev/9fdec1354af4 -- nosy: +python-dev

[issue14098] provide public C-API for reading/setting sys.exc_info()

Martin v. Löwis mar...@v.loewis.de added the comment: Thanks for the patch! -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14098 ___

[issue14098] provide public C-API for reading/setting sys.exc_info()

Ronald Oussoren ronaldousso...@mac.com added the comment: The documentation does not explain how this new API is different from PyErr_Fetch/PyErr_Restore. In particular the documentation doesn't mention that PyErr_Fetch and PyErr_GetExcInfo access different bits of the error state (curexc_*

[issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate

Stefan Behnel sco...@users.sourceforge.net added the comment: As long as there is a way to access these fields directly from the struct (with the usual preprocessor conditional), I don't think Cython will actually start to use the PyErr_[GS]etExcInfo() functions in CPython - simply for

[issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate

Mark Shannon m...@hotpy.org added the comment: According to PEP 384 (Defining a Stable ABI) the thread state object is opaque, so we should be free to add or remove fields. Nevertheless, I have added a new patch that simply moves the f_exc... fields from the frame object to the generator. It

[issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate

Antoine Pitrou pit...@free.fr added the comment: According to PEP 384 (Defining a Stable ABI) the thread state object is opaque, so we should be free to add or remove fields. Mmh, be aware the stable ABI is only a restricted part of the official API. There are APIs which are not part of the

[issue14098] provide public C-API for reading/setting sys.exc_info()

Stefan Behnel sco...@users.sourceforge.net added the comment: Done. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14098 ___ ___

[issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate

Antoine Pitrou pit...@free.fr added the comment: This looks rather good on the principle. I think PyExcState needn't be public, it should be _PyExcState. I haven't checked the detailed mechanics of the patch, I hope someone else can. -- nosy: +pitrou

[issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate

Stefan Behnel sco...@users.sourceforge.net added the comment: FWIW, Cython keeps the exception state in the generator struct and that works nicely. Note that Amaury is right in that extensions use tstate-exc_value and friends. Cython does so quite extensively, for example. I don't see any use

[issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate

Antoine Pitrou pit...@free.fr added the comment: Note that Amaury is right in that extensions use tstate-exc_value and friends. Cython does so quite extensively, for example. I understand for Cython, but why would pedestrian extension code look up tstate-exc_value? --

[issue14098] provide public C-API for reading/setting sys.exc_info()

Antoine Pitrou pit...@free.fr added the comment: Stefan's latest patch looks fine to me. -- nosy: +pitrou stage: - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14098 ___

[issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate

the surperfluous fields from the frameobject? The logic for accessing sys.exc_info can be moved to into the new accessor fucntions. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13897

[issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate

Stefan Behnel sco...@users.sourceforge.net added the comment: I can't speak for much outside of Cython, and Cython generated modules would best be regenerated with a newer Cython version anyway in order to work with Py3.3. I'm not sure that's currently required, though. As long as there is a

[issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate

Antoine Pitrou pit...@free.fr added the comment: As long as there is a way to access these fields directly from the struct (with the usual preprocessor conditional), I don't think Cython will actually start to use the PyErr_[GS]etExcInfo() functions in CPython - simply for performance

[issue14098] provide public C-API for reading/setting sys.exc_info()

Martin v. Löwis mar...@v.loewis.de added the comment: Fine with me as well. Stefan, please submit a contributor form. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14098 ___

[issue14098] provide public C-API for reading/setting sys.exc_info()

Stefan Behnel sco...@users.sourceforge.net added the comment: This is now implemented in PyPy: https://bitbucket.org/pypy/pypy/changeset/623bcea85df3 Are there any objections to applying the equivalent patch to CPython? -- ___ Python tracker

[issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate

frame and threadstate whenever entering or leaving a generator, each generator (and the threadstate) has its own exception state. It order to find the topmost exception state, sys.exc_info searches the stack of generators until it finds one. In practice the generator stack will be very shallow

[issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate

Jim Jewett jimjjew...@gmail.com added the comment: I think the latest patch is indeed cleaner. -- nosy: +Jim.Jewett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13897 ___

[issue14098] provide public C-API for reading/setting sys.exc_info()

Changes by Stefan Behnel sco...@users.sourceforge.net: Added file: http://bugs.python.org/file24734/pyerr_getexcinfo.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14098 ___

[issue14098] provide public C-API for reading/setting sys.exc_info()

Stefan Behnel sco...@users.sourceforge.net added the comment: I wonder if these functions should have an error return value, i.e. return -1 on failure. They'd never fail in CPython, but other implementations may want to report failures, in case their internal implementation is more involved.

[issue14098] provide public C-API for reading/setting sys.exc_info()

Stefan Behnel sco...@users.sourceforge.net added the comment: Writing up a test case, I noticed that it makes sense to let PyErr_SetExcInfo() steal the references. This matches the main use case of saving and restoring the fields. For the getter, it's still best to return new references in

[issue14098] provide public C-API for reading/setting sys.exc_info()

Changes by Stefan Behnel sco...@users.sourceforge.net: -- keywords: +patch Added file: http://bugs.python.org/file24613/exc_info_capi.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14098

[issue14098] provide public C-API for reading/setting sys.exc_info()

New submission from Stefan Behnel sco...@users.sourceforge.net: Following up on recent mailing list threads on pypy-dev and python-dev, this is a request for adding a public C-API to read and write the sys.exc_info() fields, currently stored in tstate-exc_*. While not of major interest

[issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate

Mark Shannon m...@hotpy.org added the comment: This issue was too broad. The new patch is focussed on sys.exc_info. All hints of coroutines have been removed and f_yieldfrom is untouched. New patch reduces code by 65 lines and does not conflict with issue 13607. -- title: Move fields

[issue13897] Move fields relevant to sys.exc_info out of frame into generator/threadstate

Changes by Mark Shannon m...@hotpy.org: Removed file: http://bugs.python.org/file24350/coro.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13897 ___

Re: [C-API] Weird sys.exc_info reference segfault

On Tue, 05 Oct 2010 16:17:57 +0200 Jonas H. jo...@lophus.org wrote: Right now I have this minimal struct: static PyTypeObject StartResponse_Type = { PyObject_HEAD_INIT(PyType_Type) 0, /* ob_size */ start_response, /* tp_name */

Re: [C-API] Weird sys.exc_info reference segfault

On 10/06/2010 02:01 PM, Antoine Pitrou wrote: It shouldn't. Are you sure you're calling PyType_Ready in the module initialization routine? Yeah. The problem was that the type struct was declared 'static' in another module so the changes `PyType_Ready` made to the struct weren't applied

Re: [C-API] Weird sys.exc_info reference segfault

On 10/04/2010 11:41 PM, Antoine Pitrou wrote: Well, it should work, but you have to call PyType_Ready() to fill in the NULL fields with default values (for those where it's necessary). Does it solve it for you? Yes, thank you! Although I do not understand which fields I have to provide. I

Re: [C-API] Weird sys.exc_info reference segfault

On 10/03/2010 11:52 PM, Antoine Pitrou wrote: You probably have a problem in your tp_dealloc implementation. `tp_dealloc` is NULL... -- http://mail.python.org/mailman/listinfo/python-list

Re: [C-API] Weird sys.exc_info reference segfault

On 10/04/2010 10:46 AM, Jonas H. wrote: On 10/03/2010 11:52 PM, Antoine Pitrou wrote: You probably have a problem in your tp_dealloc implementation. `tp_dealloc` is NULL... Alright, `tp_dealloc` must not be NULL because it's called by `_Py_Dealloc`. The C-API tutorial is quite confusing

Re: [C-API] Weird sys.exc_info reference segfault

On Mon, 04 Oct 2010 23:30:58 +0200 Jonas H. jo...@lophus.org wrote: [...] here's a minimal, but __complete__, module that defines a new type: [...] static PyTypeObject noddy_NoddyType = { [...] 0, /*tp_dealloc*/ [...] }; So I thought

Re: [C-API] Weird sys.exc_info reference segfault

On 10/03/2010 01:16 AM, Antoine Pitrou wrote: You should check that you aren't doing anything wrong with env and start_response (like deallocate them forcefully). I commented out the `Py_DECREF(start_response)` after the `app` call and the crash was gone. `start_response` is created via

Re: [C-API] Weird sys.exc_info reference segfault

On Sun, 03 Oct 2010 14:44:32 +0200 Jonas H. jo...@lophus.org wrote: On 10/03/2010 01:16 AM, Antoine Pitrou wrote: You should check that you aren't doing anything wrong with env and start_response (like deallocate them forcefully). I commented out the `Py_DECREF(start_response)` after the

Re: [C-API] Weird sys.exc_info reference segfault

On 10/03/2010 03:47 PM, Antoine Pitrou wrote: You shouldn't call PyObject_FREE yourself, but instead rely on Py_DECREF to deallocate it if the reference count drops to zero. So, instead of commenting out Py_DECREF and keeping PyObject_FREE, I'd recommend doing the reverse. That way, if a

Re: [C-API] Weird sys.exc_info reference segfault

On Sun, 03 Oct 2010 16:33:48 +0200 Jonas H. jo...@lophus.org wrote: Humm. Now the behaviour is as follows: with assignment to local variable -- * start_response = PyObject_NEW(...) - start_response-ob_refcnt=1 * wsgiapp(environ, start_response) -

[C-API] Weird sys.exc_info reference segfault

Hello list, I have a really weird reference problem with `sys.exc_info`, and, if I'm right, function frames. The software in question is bjoern, a WSGI web server written in C, which you can find at http://github.com/jonashaag/bjoern. This WSGI application: def app(env, start_response

Re: [C-API] Weird sys.exc_info reference segfault

On Sat, 02 Oct 2010 23:35:01 +0200 Jonas H. jo...@lophus.org wrote: This WSGI application: def app(env, start_response): start_response('200 alright', []) try: a except: import sys sys.exc_info() return ['hello

[issue7340] Doc for sys.exc_info has warning that is no longer valid

Changes by Mark Lawrence breamore...@yahoo.co.uk: -- assignee: georg.brandl - d...@python nosy: +d...@python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7340 ___

[issue7340] Doc for sys.exc_info has warning that is no longer valid

Changes by Éric Araujo mer...@netwok.org: -- resolution: - accepted stage: - needs patch versions: -Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7340 ___

Re: Castrated traceback in sys.exc_info()

As you see, the traceback only starts from function c, which handles the exception. It doesn't show main(), a() and b(), which might however be (and are, in my case) critical to diagnose the severity of the problem (since many different paths would lead to calling c()). This results in

Re: Castrated traceback in sys.exc_info()

En Tue, 23 Mar 2010 19:43:40 -0300, Vinay Sajip vinay_sa...@yahoo.co.uk escribió: On Mar 23, 8:49 pm, Pascal Chambon chambon.pas...@wanadoo.fr wrote: Should I open an issue for this evolution of exceptiuon handling, or should we content ourselves of this hacking of frame stck ? Possibly

Re: Castrated traceback in sys.exc_info()

. The exception traceback (what sys.exc_info()[2] returns) is *not* a complete stack trace. The sys module documentation is wrong [1] when it says ...encapsulates the call stack at the point where the exception originally occurred. The Language Reference is more clear [2]: Traceback objects

Re: Castrated traceback in sys.exc_info()

  of that incomplete one ? Thanks for bringing this topic! I learned a lot trying to understand what   happens. The exception traceback (what sys.exc_info()[2] returns) is *not* a   complete stack trace. The sys module documentation is wrong [1] when it   says ...encapsulates the call stack at the point

Re: Castrated traceback in sys.exc_info()

to understand what happens. The exception traceback (what sys.exc_info()[2] returns) is *not* a complete stack trace. The sys module documentation is wrong [1] when it says ...encapsulates the call stack at the point where the exception originally occurred. The Language Reference is more clear [2

Re: Castrated traceback in sys.exc_info()

On Mar 23, 8:49 pm, Pascal Chambon chambon.pas...@wanadoo.fr wrote: Should I open an issue for this evolution of exceptiuon handling, or should we content ourselves of this hacking of frame stck ? Possibly worth raising an issue (not logging-related), but perhaps it's worth seeing if this has

Re: Castrated traceback in sys.exc_info()

Gabriel Genellina a écrit : En Wed, 17 Mar 2010 09:42:06 -0300, Pascal Chambon chambon.pas...@gmail.com escribió: traceback functions indeed allow the manipulation of exception tracebacks, but the root problem is that anyway, since that traceback is incomplete, your

Re: Castrated traceback in sys.exc_info()

En Wed, 17 Mar 2010 09:42:06 -0300, Pascal Chambon chambon.pas...@gmail.com escribió: traceback functions indeed allow the manipulation of exception tracebacks, but the root problem is that anyway, since that traceback is incomplete, your traceback.format_exc().splitlines() will only

Castrated traceback in sys.exc_info()

Hello I've just realized recently that sys.exc_info() didn't return a full traceback for exception concerned : it actually only contains the frame below the point of exception catching. That's very annoying to me, because I planned to log such tracebacks with logging.critical(*, exc_info

Re: Castrated traceback in sys.exc_info()

realized recently that sys.exc_info() didn't return a full traceback for exception concerned : it actually only contains the frame below the point of exception catching. That's very annoying to me, because I planned to log such tracebacks with logging.critical(*, exc_info=True

Re: Castrated traceback in sys.exc_info()

) Le Wed, 17 Mar 2010 03:42:44 -0700 (PDT), Pakal chambon.pas...@gmail.com a écrit : Hello I've just realized recently that sys.exc_info() didn't return a full traceback for exception concerned : it actually only contains the frame below the point of exception catching. That's very

Re: Castrated traceback in sys.exc_info()

On Mar 17, 10:42 am, Pakal chambon.pas...@gmail.com wrote: Hello I've just realized recently that sys.exc_info() didn't return a full traceback for exception concerned : it actually only contains the frame below the point of exception catching. That's very annoying to me, because I planned

[issue7340] Doc for sys.exc_info has warning that is no longer valid

New submission from Greg Hewgill g...@hewgill.com: Based on a short discussion on python-dev: http://mail.python.org/pipermail/python-dev/2009-November/094306.html the Warning box in the documentation for sys.exc_info needs to be updated in light of PEP 3134, and perhaps moved elsewhere since

[issue5274] sys.exc_info()[1] - different handling from str() and unicode() - py 2.6

Georg Brandl ge...@python.org added the comment: Duplicate of #6108. -- nosy: +georg.brandl resolution: - duplicate status: open - closed superseder: - unicode(exception) behaves differently on Py2.6 when len(exception.args) 1 ___ Python tracker

[issue5970] sys.exc_info leaks into a generator

Antoine Pitrou pit...@free.fr added the comment: Adding some tests to check that a bug is /not/ fixed looks weird to me. If we did that for every trunk change that we don't want to end up in the stable branch, there'd be lots of new tests of dubious utility. Besides, py3k isn't affected ;)

[issue5970] sys.exc_info leaks into a generator

Barry A. Warsaw ba...@python.org added the comment: I agree with Antoine. -- versions: -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5970 ___

[issue5970] sys.exc_info leaks into a generator

Jeffrey Yasskin jyass...@gmail.com added the comment: Re py3k: oops, thanks for checking. Re 2.6: Fine with me, second patch removed. -- assignee: barry - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5970

[issue5970] sys.exc_info leaks into a generator

Changes by Jeffrey Yasskin jyass...@gmail.com: Removed file: http://bugs.python.org/file13928/exc_info_26.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5970 ___

[issue5970] sys.exc_info leaks into a generator

New submission from Jeffrey Yasskin jyass...@gmail.com: There's an obscure bug in sys.exc_info after a yield statement. def test(): def raising_generator(): try: raise IndexError(inner exception) except IndexError: yield 3

[issue5970] sys.exc_info leaks into a generator

Jeffrey Yasskin jyass...@gmail.com added the comment: I think we should _not_ backport any fix for this bug to the 2.6 series, since any changes to user behavior would be pretty subtle. To prevent that backport, I'd like to apply exc_info_26.patch to the 2.6 branch, with Barry's approval.

[issue5274] sys.exc_info()[1] - different handling from str() and unicode() - py 2.6

Vlastimil Brom vlastimil.b...@gmail.com added the comment: I just want to confirm, that the reported issue is the same in python 2.6.2, is it really the intended behaviour in python 2.6 (as opposed to 2.5)? vbr -- components: +Unicode ___ Python

sys.exc_info() different between python 2.5.4 and 2.6.1?

Hi all, I just noticed a changed behaviour of sys.exc_info() between python 2.5.4 and 2.6.1 and wanted to ask, wheter it was intended, and how to deal with the new state. Some code triggers an error while opening a text file (windows 1250 - with non-ascii characters) wrongly as utf-8, this gets