On 29/06/17 19:00, eryk sun wrote:
> On Thu, Jun 29, 2017 at 6:50 AM, Steven D'Aprano wrote:
>> try:
>> something
>> except:
>> exc_type, exc, tb = sys.exc_info()
>> print(traceback.extract_tb(tb))
>> raise
>>
>> Why does it
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.
D
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
On Thu, Jun 29, 2017 at 6:50 AM, Steven D'Aprano 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 exception, when
> th
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
here:
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 Change
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 correc
On Tue, 05 Oct 2010 16:17:57 +0200
"Jonas H." wrote:
>
> Right now I have this minimal struct:
>
> static PyTypeObject StartResponse_Type = {
> PyObject_HEAD_INIT(&PyType_Type)
> 0, /* ob_size */
> "start_response", /* tp_name */
> sizeof(St
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 want
On Mon, 04 Oct 2010 23:30:58 +0200
"Jonas H." wrote:
>
> > [...] here's a minimal, but __complete__, module that defines a new type:
> >
> > [...]
> > static PyTypeObject noddy_NoddyType = {
> > [...]
> > 0, /*tp_dealloc*/
> > [...]
> > };
>
> So I thought "co
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 he
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
On Sun, 03 Oct 2010 16:33:48 +0200
"Jonas H." 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) ->
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 referenc
On Sun, 03 Oct 2010 14:44:32 +0200
"Jonas H." 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 `app`
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 `P
On Sat, 02 Oct 2010 23:35:01 +0200
"Jonas H." wrote:
>
> This WSGI application:
>
>def app(env, start_response):
>start_response('200 alright', [])
>try:
>a
>except:
> import sys
>
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_res
> 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
En Tue, 23 Mar 2010 19:43:40 -0300, Vinay Sajip
escribió:
On Mar 23, 8:49 pm, Pascal Chambon 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
On Mar 23, 8:49 pm, Pascal Chambon 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 come up before crea
d 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 where the
exception originally occurred."
The Lang
on is : is that possible to enforce, by a way or another,
> > the retrieval of the FULL traceback at exception raising point, instead
> > of that incomplete one ?
>
> Thanks for bringing this topic! I learned a lot trying to understand what
> happens.
>
> The excepti
nd 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 mo
Gabriel Genellina a écrit :
En Wed, 17 Mar 2010 09:42:06 -0300, Pascal Chambon
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
En Wed, 17 Mar 2010 09:42:06 -0300, Pascal Chambon
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 provide frames for
callee (do
On Mar 17, 10:42 am, Pakal 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
nes():
> log.trace(line)
>
>
>
> Le Wed, 17 Mar 2010 03:42:44 -0700 (PDT),
> Pakal a écrit :
>
> > Hello
> >
> > I've just realized recently that sys.exc_info() didn't return a full
> > traceback for exception concerned : it actually only c
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(*
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(
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
31 matches
Mail list logo
