How to get insight in the relations between tracebacks of exceptions in an exception-chain

[Klaas van Schelven via Python-list]

Hi,

This question is best introduced example-first:

Consider the following trivial program:

```
class OriginalException(Exception):
pass


class AnotherException(Exception):
pass


def raise_another_exception():
raise AnotherException()


def show_something():
try:
raise OriginalException()
except OriginalException:
raise_another_exception()


show_something()
```

running this will dump the following on screen (minus annotations on the
Right-Hand-Side):

```
Traceback (most recent call last):
  File "./stackoverflow_single_complication.py", line 15, in
show_something t1
raise OriginalException()
__main__.OriginalException

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "./stackoverflow_single_complication.py", line 20, in 
t0
show_something()
  File "./stackoverflow_single_complication.py", line 17, in
show_something t2
raise_another_exception()
  File "./stackoverflow_single_complication.py", line 10, in
raise_another_exceptiont3
raise AnotherException()
__main__.AnotherException
```

What we see here is first the `OriginalException` with the stackframes
between the moment that it was raised and the moment it was handled.
Then we see `AnotherException`, with _all_ a complete traceback from its
point-of-raising to the start of the program.

In itself this is perfectly fine, but a consequence of this way of
presenting the information is that the stackframes are _not_ laid out on
the screen in the order in which they were called (and not in the reverse
order either), as per the annotations _t1_, _t0_, _t2_, _t3_. The path
leading up to _t1_ is of course the same as the path leading up to _t2_,
and the creators of Python have chosen to present it only once, in the
latter case, presumably because that Exception is usually the most
interesting one, and because it allows one to read the bottom exception
bottom-up without loss of information. However, it does leave people that
want to analyze the `OriginalException` somewhat mystified: what led up to
it?

A programmer that wants to understand what led up to _t1_ would need to
[mentally] copy all the frames above the point _t2_ to the first stacktrace
to get a complete view. However, in reality the point _t2_ is, AFAIK, not
automatically annotated for you as a special frame, which makes the task of
mentally copying the stacktrace much harder.

Since the point _t2_ is in general "the failing line in the `except`
block", by cross-referencing the source-code this excercise can usually be
completed, but this seems unnecessarily hard.

**Is it possible to automatically pinpoint _t2_ as the "handling frame"?**

(The example above is given without some outer exception-handling context;
I'm perfectly fine with answers that introduce it and then use `traceback`
or other tools to arrive at the correct answer).

This is the most trivial case that illustrates the problem; real cases have
many more stack frames and thus less clearly illustrate the problem but
more clearly illustrate the need for (potentially automated) clarification
of what's happening that this SO question is about.


regards,
Klaas


Previously asked here:
https://stackoverflow.com/questions/78270044/how-to-get-insight-in-the-relations-between-tracebacks-of-exceptions-in-an-excep
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on the importance of exceptions

[Meredith Montgomery]

Meredith Montgomery  writes:

> I'm trying to show people that exceptions are a very nice thing to have
> when it comes to detecting when something went awry somewhere.  I'd like
> a real-world case, though.  

Here's my contribution.  I want to handle all errors in main() and the
real job is done in does_a_job(), which, in turns, needs to delegate
tasks to those other procedures that fail sometimes.  

It's does_a_job() that /must/ distinguish the error codes because errors
come in as False from both opens_file() and reads_file().  So the checks
must be done both in does_a_job() and in main().  (We also notice that
does_a_job() has a return-type that's a union (sometimes an integer,
sometimes a string), which makes distinguishing error code and success a
bit harder.)

--8<---cut here---start->8---
from random import randint

def main():
  r, data = does_a_job()
  if r < 0:
if r == -1:
  print("Fatal. Could not open file.")
  return None
if r == -2:
  print("Fatal. Could not read file")
  return None
  print(f"Great! We got the data: ``{r}''.")

def does_a_job():
  okay = opens_file()
  if not okay:
return -1
  okay, data = reads_file()
  if not okay:
return -2
  closes_file()
  return data

def open_file(): # Opens okay with probability 80%
  return randint(1,10) <= 8

def read_file(): # Reads okay with probability 50%
  return randint(1,10) <= 5, "data I am"

def closes_file():  # Works with probability 1
  return True
--8<---cut here---end--->8---

If we could give the program a final destination at does_a_job(), the
job would be easier.  But all we want to do in does_a_job() is to
propagate the error conditions upwards to main() to really decide what
to do.  Exceptions lets us do that with a cleaner version.

--8<---cut here---start->8---
from random import randint

def main():
  try:
data = does_a_job()
  except FileNotFoundError:
print("Fatal. Could not open file.")
  except MemoryError:
print("Fatal. Could not read file")
  else:
print(f"Great! We got the data: ``{data}''.")

def does_a_job():
  open_file()
  data = reads_file()
  close_file()
  return data

def open_file(): # Opens okay with probability 80%
  if randint(1,10) <= 8:
return True
  raise FileNotFoundError("Sorry: the file system is /so/ busy right now.")

def reads_file(): # Reads okay with probability 50%
  if randint(1,10) <= 5:
return "data I am"
  raise MemoryError("Sorry: not enough memory for /all/ this data.")

def close_file():  # Works with probability 1
  return True
--8<---cut here---end--->8---
-- 
https://mail.python.org/mailman/listinfo/python-list

on the importance of exceptions

[Meredith Montgomery]

I'm trying to show people that exceptions are a very nice thing to have
when it comes to detecting when something went awry somewhere.  I'd like
a real-world case, though.  

Here's what I'm sort of coming up with --- given my limited experience
and imagination.  Below, you have f calling g caling h calling j which
returns True or False based on a random thing.  (This simulates a task
that sometimes succeeds and sometimes fails.)  If while at f() I want to
know what happened at j(), I'm going to have to propagate that
information upwards through the execution stack.  I can't do that right
now: I'd have to change f, g and h.

--8<---cut here---start->8---
from random import randint
  
def f():
  g()

def g():
  h()

def h():
  if j():
print("I got a 2.")
  else:
print("I got a 1.")

def j():
  return randint(1,2) == 2
--8<---cut here---end--->8---

If instead of that, j() would be raising an exception when it fails,
then all I only need to change f() to know what happens.

I could replace j's test with opening a file, say.  That would improve
it a little.  I'm sure you guys know excellent cases to show.  Would you
be so kind to share anything you might have in mind?
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue504723] Bad exceptions from pickle

[admin]

Change by admin :


--
github: None -> 35933

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue420502] seek/tell beyond eof without exceptions

[admin]

Change by admin :


--
github: None -> 3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue401362] fix GC debugging output w.r.t. exceptions

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue212558] dictionary lookup does not check exceptions

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue502236] Asynchronous exceptions between threads

[admin]

Change by admin :


--
github: None -> 35905

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue494871] test exceptions in various types/methods

[admin]

Change by admin :


--
github: None -> 35786

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue467571] profile.py mishandles exceptions

[admin]

Change by admin :


--
github: None -> 35273

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue449151] Multiple interpreters break exceptions

[admin]

Change by admin :


--
github: None -> 34924

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue445815] urllib doesn't handle proxy exceptions

[admin]

Change by admin :


--
github: None -> 34857

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue443559] creating exceptions is underdocumented

[admin]

Change by admin :


--
github: None -> 34807

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue422004] Missing "fixup" for "exceptions" module

[admin]

Change by admin :


--
github: None -> 34467

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue425261] re propagates opaque exceptions

[admin]

Change by admin :


--
github: None -> 34519

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue417913] odd behavior when reloading "exceptions"

[admin]

Change by admin :


--
github: None -> 34390

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue221706] exceptions module cannot be imported in two interpreters

[admin]

Change by admin :


--
github: None -> 33451

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue400851] traceback.py, with unicode exceptions

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue400869] exceptions in _PyImport_Inittab

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue221706] exceptions module cannot be imported in two interpreters

[admin]

Change by admin :


--
github: None -> 33451

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue401362] fix GC debugging output w.r.t. exceptions

[admin]

Change by admin :


--
github: None -> 33017

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue212558] dictionary lookup does not check exceptions

[admin]

Change by admin :


--
github: None -> 32974

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue400851] traceback.py, with unicode exceptions

[admin]

Change by admin :


--
github: None -> 32603

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue400869] exceptions in _PyImport_Inittab

[admin]

Change by admin :


--
github: None -> 32613

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47185] code.replace(co_code=new_code) no longer catch exceptions on Python 3.11

[STINNER Victor]

STINNER Victor  added the comment:

Ok sure, I created bpo-47236 "Document types.CodeType.replace() changes about 
co_exceptiontable".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47185] code.replace(co_code=new_code) no longer catch exceptions on Python 3.11

[Guido van Rossum]

Guido van Rossum  added the comment:

If you think the changes to .replace() should be documented just open a new 
bpo. You made this issue about your various proposals to change .replace().

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47185] code.replace(co_code=new_code) no longer catch exceptions on Python 3.11

[STINNER Victor]

STINNER Victor  added the comment:

>>> def f():
... foo()
... try:
... bar()
... except:
... pass
... 
>>> def g():
... try:
... foo()
... bar()
... except:
... pass
... 

>>> dis.dis(f)
  1   0 RESUME   0

  2   2 LOAD_GLOBAL  1 (NULL + foo)
 14 PRECALL  0
 18 CALL 0
 28 POP_TOP

  3  30 NOP

  4  32 LOAD_GLOBAL  3 (NULL + bar)
 44 PRECALL  0
 48 CALL 0
 58 POP_TOP
 60 LOAD_CONST   0 (None)
 62 RETURN_VALUE
>>   64 PUSH_EXC_INFO

  5  66 POP_TOP

  6  68 POP_EXCEPT
 70 LOAD_CONST   0 (None)
 72 RETURN_VALUE
>>   74 COPY 3
 76 POP_EXCEPT
 78 RERAISE  1
ExceptionTable:
  32 to 58 -> 64 [0]
  64 to 66 -> 74 [1] lasti

>>> dis.dis(g)
  1   0 RESUME   0

  2   2 NOP

  3   4 LOAD_GLOBAL  1 (NULL + foo)
 16 PRECALL  0
 20 CALL 0
 30 POP_TOP

  4  32 LOAD_GLOBAL  3 (NULL + bar)
 44 PRECALL  0
 48 CALL 0
 58 POP_TOP
 60 LOAD_CONST   0 (None)
 62 RETURN_VALUE
>>   64 PUSH_EXC_INFO

  5  66 POP_TOP

  6  68 POP_EXCEPT
 70 LOAD_CONST   0 (None)
 72 RETURN_VALUE
>>   74 COPY 3
 76 POP_EXCEPT
 78 RERAISE  1
ExceptionTable:
  4 to 58 -> 64 [0]
  64 to 66 -> 74 [1] lasti


Oh, I didn't follow recent bytecode changes. Ok, now I see that it is not 
longer possible to build the exception table just from the bytecode. The 
purpose of the exception table is to handle exceptions: the opcodes related to 
exception handles are simply gone in Python 3.11.

I was thinking about looking for things like PUSH_EXC_INFO or POP_EXCEPT, but 
as Guido shows, it doesn't work: the start of the "try" block cannot be 
detected in the bytecode anymore in Python 3.11.


> If code.replace() is not updated to recompute co_exceptiontable, at least, it 
> would be nice to document the bpo-40222 changes in What's New in Python 3.11 
> and in the CodeType documentation

You closed the issue. I understand that you don't want to document 
CodeType.replace() changes neither. Users of this API should follow Python 
development and notice that their code no longer works with Python 3.11.

--

___
Python tracker 
<https://bugs.python.org/issue47185>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47185] code.replace(co_code=new_code) no longer catch exceptions on Python 3.11

[Guido van Rossum]

Guido van Rossum  added the comment:

This idea just cannot work. Take these two functions:

def f():
foo()
try:
bar()
except:
pass

def g():
try:
foo()
bar()
except:
pass

Using dis to look at their disassembly, the only hint that in f(), the call to 
foo() is outside the try block and in g() it is inside it is the presence of 
some NOP opcodes. The actual demarcation of where the try blocks start and end 
is exclusively determined by the exception table.

It just doesn't make sense to try to validate that correct parameters are being 
passed in when you are modifying co_code and friends.

--
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47185] code.replace(co_code=new_code) no longer catch exceptions on Python 3.11

[Gregory P. Smith]

Change by Gregory P. Smith :


--
nosy: +gregory.p.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41233] Missing links to errnos on Built-in Exceptions page

[Jelle Zijlstra]

Jelle Zijlstra  added the comment:

Thanks for the patch!

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41233] Missing links to errnos on Built-in Exceptions page

[miss-islington]

miss-islington  added the comment:


New changeset e47e6ffed36eb1dd82da3bcadf8b45b894ef4ce2 by Miss Islington (bot) 
in branch '3.9':
bpo-41233: Add links to errnos referenced in exceptions docs (GH-21380)
https://github.com/python/cpython/commit/e47e6ffed36eb1dd82da3bcadf8b45b894ef4ce2


--

___
Python tracker 
<https://bugs.python.org/issue41233>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41233] Missing links to errnos on Built-in Exceptions page

[miss-islington]

miss-islington  added the comment:


New changeset 3fa800d7a7a405f51e0e8c9b7dac2f2a75c17bb4 by Miss Islington (bot) 
in branch '3.10':
bpo-41233: Add links to errnos referenced in exceptions docs (GH-21380)
https://github.com/python/cpython/commit/3fa800d7a7a405f51e0e8c9b7dac2f2a75c17bb4


--

___
Python tracker 
<https://bugs.python.org/issue41233>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41233] Missing links to errnos on Built-in Exceptions page

[miss-islington]

Change by miss-islington :


--
pull_requests: +30378
pull_request: https://github.com/python/cpython/pull/32317

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41233] Missing links to errnos on Built-in Exceptions page

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 8.0 -> 9.0
pull_requests: +30377
pull_request: https://github.com/python/cpython/pull/32316

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41233] Missing links to errnos on Built-in Exceptions page

[Jelle Zijlstra]

Jelle Zijlstra  added the comment:


New changeset a74892cb2168d249d9a8c53fad605a5def9b41d4 by yyyan in branch 
'main':
bpo-41233: Add links to errnos referenced in exceptions docs (GH-21380)
https://github.com/python/cpython/commit/a74892cb2168d249d9a8c53fad605a5def9b41d4


--
nosy: +JelleZijlstra

___
Python tracker 
<https://bugs.python.org/issue41233>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47185] code.replace(co_code=new_code) no longer catch exceptions on Python 3.11

[Guido van Rossum]

Guido van Rossum  added the comment:

[Victor]
> Do you consider that .replace() must reject changing co_code if other tables 
> are not updated?

I simply don't believe it can always do that correctly, so I believe it should 
not do it.

> Debugging tables are not strictly required just to *execute* code, no?

No, but if they are wrong crashes might happen when they are consulted. At the 
very least they would confuse users.

> If you consider that the caller *must* update co_exceptiontable, replace() 
> must raise an exception in this case, to prevent creating a code object which 
> would behave in a strange way (broken exception handling).

No. There are a zillion use cases. If you are using .replace() you are taking 
responsibility for the result.

> If someone really wants testing an empty exception table just for fun, it 
> would still be possible to pass co_exceptiontable=b''.

> My concern is more about people upgrading to Python 3.11 and who "suddenly" 
> don't get their exceptions handled anymore. I would prefer catching such bug 
> at the replace() call, rather than having to execute the code (and only 
> notice the bug in production? oops).

Where would these people get the value that they're using to replace co_code? 
Surely if they are generating bytecode it will already be broken. Pretty much 
all instructions are different in 3.11.

--

___
Python tracker 
<https://bugs.python.org/issue47185>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47185] code.replace(co_code=new_code) no longer catch exceptions on Python 3.11

[Dominic Davis-Foster]

Change by Dominic Davis-Foster :


--
nosy: +dom1310df

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47185] code.replace(co_code=new_code) no longer catch exceptions on Python 3.11

[STINNER Victor]

STINNER Victor  added the comment:

Guido (msg416498)
> Surely the bigger issue is that the contents of new_code itself must be 
> totally different? Also there are other tables that need to be adjusted if 
> you really do change co_code, e.g. the debugging tables.

Do you consider that .replace() must reject changing co_code if other tables 
are not updated?

Debugging tables are not strictly required just to *execute* code, no?

If you consider that the caller *must* update co_exceptiontable, replace() must 
raise an exception in this case, to prevent creating a code object which would 
behave in a strange way (broken exception handling).

If someone really wants testing an empty exception table just for fun, it would 
still be possible to pass co_exceptiontable=b''.

My concern is more about people upgrading to Python 3.11 and who "suddenly" 
don't get their exceptions handled anymore. I would prefer catching such bug at 
the replace() call, rather than having to execute the code (and only notice the 
bug in production? oops).

--

___
Python tracker 
<https://bugs.python.org/issue47185>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47185] code.replace(co_code=new_code) no longer catch exceptions on Python 3.11

[STINNER Victor]

STINNER Victor  added the comment:

python-dev thread:
https://mail.python.org/archives/list/python-...@python.org/thread/KWSPCLXDHBAP2U4LBSMLQEOC7LREDMPB/

Mark wrote:

"You can pass the exception table the same way you pass all the other 
arguments. The exception table depends on the code, but that is nothing new. 
The bytecode library already recomputes the consts, names, etc."

Constants and names are easy to build, it's just an array and the bytecode 
refers to their index.

Building the exception table is more complicated. It's nice that the format is 
documented in 
https://github.com/python/cpython/blob/main/Objects/exception_handling_notes.txt
 but it would be more convenient to put it in the regular Python documentation 
(docs.python.org), no? I discovered that file by mistake with filename 
completion in my editor while looking for Objects/exceptions.c :-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47185] code.replace(co_code=new_code) no longer catch exceptions on Python 3.11

[STINNER Victor]

STINNER Victor  added the comment:

> How would you compute the exception table from the bytecode? There are no 
> clues in the bytecode about where the try and except blocks are.

Disassemble the bytecode to rebuild basic blocks and detect which ones are 
except blocks. I don't know how the exception table works :-) It's just a guess.

Or do you think that this job should be done by the caller?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47185] code.replace(co_code=new_code) no longer catch exceptions on Python 3.11

[Guido van Rossum]

Guido van Rossum  added the comment:

How would you compute the exception table from the bytecode? There are no clues 
in the bytecode about where the try and except blocks are.

--
nosy: +gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47185] code.replace(co_code=new_code) no longer catch exceptions on Python 3.11

[Eric Snow]

Change by Eric Snow :


--
nosy: +Mark.Shannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47185] code.replace(co_code=new_code) no longer catch exceptions on Python 3.11

[STINNER Victor]

New submission from STINNER Victor :

Since bpo-40222 "Zero cost exception handling", code object created by from 
bytecode with code.replace(co_code=new_code) no longer catch exceptions on 
Python 3.11, unless an exception table is set explicitly.

Example:
---
def f():
try:
print("raise")
raise ValueError
except ValueError:
print("except")
else:
print("else")
print("exit func")

def g(): pass

if 1:
code = f.__code__
g.__code__ = g.__code__.replace(
co_code=code.co_code,
co_consts=code.co_consts,
co_names=code.co_names,
co_flags=code.co_flags,
co_stacksize=code.co_stacksize)
else:
g.__code__ = f.__code__  # this code path works on Python 3.11

g()
---

Output with Python 3.10 (ok):
---
raise
except
exit func
---

Output with Python 3.11 (oops):
---
raise
Traceback (most recent call last):
  ...
ValueError
---

Would it make sense to automatically compute co_exceptiontable on 
code.replace(co_code=new_code)? If it's computed automatically, I don't know if 
it makes still sense to call code.replace(co_code=new_code, 
co_exceptiontable=new_table).

It seems like currently, the only implementation to build an exception table 
lives in Python/compile.c which compiles AST to bytecode. It cannot be reused 
for code.replace() which takes bytecode as input, not AST.

--

If code.replace() is not updated to recompute co_exceptiontable, at least, it 
would be nice to document the bpo-40222 changes in What's New in Python 3.11 
and in the CodeType documentation:

* https://docs.python.org/dev/library/types.html#types.CodeType
* https://docs.python.org/dev/whatsnew/3.11.html

--
components: Interpreter Core
messages: 416479
nosy: vstinner
priority: normal
severity: normal
status: open
title: code.replace(co_code=new_code) no longer catch exceptions on Python 3.11
versions: Python 3.11

___
Python tracker 
<https://bugs.python.org/issue47185>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47108] asyncio-stream does not document exceptions

[Christian Bodt]

New submission from Christian Bodt :

reader.read() might raise ConnectionResetError and possibly other exceptions, 
but this is not explained in the documentation.

See this stacktrace example:

Traceback (most recent call last):
  File "D:\Dropbox\repos\wxasync\src\examples\server.py", line 23, in 
handle_connection
data = await reader.read(100)
  File "C:\Python-3.9\lib\asyncio\streams.py", line 684, in read
await self._wait_for_data('read')
  File "C:\Python-3.9\lib\asyncio\streams.py", line 517, in _wait_for_data
await self._waiter
  File "C:\Python-3.9\lib\asyncio\proactor_events.py", line 280, in 
_loop_reading
data = fut.result()
  File "C:\Python-3.9\lib\asyncio\windows_events.py", line 812, in _poll
value = callback(transferred, key, ov)
  File "C:\Python-3.9\lib\asyncio\windows_events.py", line 461, in finish_recv
raise ConnectionResetError(*exc.args)
ConnectionResetError: [WinError 64] Le nom réseau spécifié n’est plus disponible

--
assignee: docs@python
components: Documentation
messages: 415933
nosy: christian.bodt, docs@python
priority: normal
severity: normal
status: open
title: asyncio-stream does not document exceptions
versions: Python 3.11

___
Python tracker 
<https://bugs.python.org/issue47108>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32669] cgitb file to print OSError exceptions

[Irit Katriel]

Irit Katriel  added the comment:

cgi/cgitb are deprecated as per PEP 594, so there won't be further enhancements 
to them.

--
nosy: +iritkatriel
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45828] [sqlite3] use unraisable exceptions in callbacks

[Erlend E. Aasland]

Change by Erlend E. Aasland :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26208] decimal C module's exceptions don't match the Python version

[Constantine Evans]

Constantine Evans  added the comment:

Some other non-matching exceptions are unfriendly, but do not come from 
libmpdec and could be made to match without, I think, causing problems.  For 
example:

>>> format(_decimal.Decimal(1), "invalid")
...
ValueError: invalid format string
>>> format(_pydecimal.Decimal(1), "invalid")
...
ValueError: Invalid format specifier: invalid

Would it make sense to make a patch to make these match?

--
nosy: +const

___
Python tracker 
<https://bugs.python.org/issue26208>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32696] Fix pickling exceptions with multiple arguments

[Ziga Seilnacht]

Change by Ziga Seilnacht :


--
nosy:  -zseil

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32696] Fix pickling exceptions with multiple arguments

[Zefir-13000]

Change by Zefir-13000 :


--
nosy: +Zefir-13000
nosy_count: 11.0 -> 12.0
pull_requests: +28801
pull_request: https://github.com/python/cpython/pull/30602

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37287] [doc] Add section on pickling to exceptions documentation

[Irit Katriel]

Irit Katriel  added the comment:

This is the same as issue32696.

I'm turning this into a documentation issue.

--
assignee:  -> docs@python
components: +Documentation -Library (Lib)
nosy: +docs@python, iritkatriel
title: picke cannot dump Exception subclasses with different super() args -> 
[doc] Add section on pickling to exceptions documentation
type:  -> enhancement
versions: +Python 3.10, Python 3.11 -Python 3.7, Python 3.8

___
Python tracker 
<https://bugs.python.org/issue37287>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32696] Fix pickling exceptions with multiple arguments

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32696] Fix pickling exceptions with multiple arguments

[Georg Brandl]

Change by Georg Brandl :


--
nosy:  -georg.brandl

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32696] Fix pickling exceptions with multiple arguments

[Irit Katriel]

Irit Katriel  added the comment:

This isn't really an issue with exceptions, it's just that __reduce__ goes out 
of sync with the object's constructor signature. Here's a simple example of the 
same:

class Base:
   def __init__(self, msg):
   self.msg = msg

   def __reduce__(self):
   return type(self), (self.msg,)

class Derived(Base):
   def __init__(self, a, b):
   super().__init__(f'{a}|{b}')

x = Derived('a', 'b')
assert x.msg == 'a|b'
y = pickle.dumps(x, -1)
z = pickle.loads(y)

---
Output:

Traceback (most recent call last):
  File "/Users/iritkatriel/src/cpython/zz.py", line 22, in 
z = pickle.loads(y)
^^^
TypeError: Derived.__init__() missing 1 required positional argument: 'b'

If I define __reduce__ on Derived to return an arg tuple of the right length 
for its __init__, it works:

class Derived(Base):
   def __init__(self, a, b):
   super().__init__(f'{a}|{b}')

   def __reduce__(self):
   return type(self), tuple(self.msg.split('|'))

But note that this is not something we could make the base class do, it has no 
way of finding out what the semantics of the derived class constructor args are.

--

___
Python tracker 
<https://bugs.python.org/issue32696>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27015] pickling and repr of exceptions with kwargs

[Irit Katriel]

Change by Irit Katriel :


--
title: subprocess.CalledProcessError's repr changes based on kwargs, and 
doesn't unpickle -> pickling and repr of exceptions with kwargs
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 3.4, Python 3.5, Python 
3.6, Python 3.7, Python 3.8

___
Python tracker 
<https://bugs.python.org/issue27015>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26208] decimal C module's exceptions don't match the Python version

[Cédric Krier]

Change by Cédric Krier :


--
nosy: +ced

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42413] Replace custom exceptions for timeouts with TimeoutError

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Done.
Thanks, Kumar!

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42413] Replace custom exceptions for timeouts with TimeoutError

[Andrew Svetlov]

Andrew Svetlov  added the comment:


New changeset da4b214304df38cf1831071804a2b83938f95923 by Kumar Aditya in 
branch 'main':
bpo-42413: Replace `concurrent.futures.TimeoutError` and `asyncio.TimeoutError` 
with builtin `TimeoutError` (GH-30197)
https://github.com/python/cpython/commit/da4b214304df38cf1831071804a2b83938f95923


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42413] Replace custom exceptions for timeouts with TimeoutError

[Kumar Aditya]

Change by Kumar Aditya :


--
nosy: +kumaraditya303
nosy_count: 13.0 -> 14.0
pull_requests: +28418
pull_request: https://github.com/python/cpython/pull/30197

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1182143] making builtin exceptions more informative

[Daniel Diniz]

Change by Daniel Diniz :


--
nosy: +iritkatriel

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28559] Unclear error message when raising wrong type of exceptions

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> rejected
stage: patch review -> resolved
status: pending -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45828] [sqlite3] use unraisable exceptions in callbacks

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset c4a69a4ad035513ada1c0d41a46723606b538e13 by Erlend Egeberg 
Aasland in branch 'main':
bpo-45828: Use unraisable exceptions within sqlite3 callbacks (FH-29591)
https://github.com/python/cpython/commit/c4a69a4ad035513ada1c0d41a46723606b538e13


--
nosy: +pablogsal

___
Python tracker 
<https://bugs.python.org/issue45828>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Irit Katriel]

Irit Katriel  added the comment:

Try the search function on the tracker (that's what I would need to do to find 
what to link).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Martin]

Martin  added the comment:

Thanks for your definitive answer, this is what I was waiting for.

I understand and I totally agree that subclassing is the way to go to make 
traceback more flexible.

Would you mind linking the other issues concerning the general improvement of 
traceback?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Irit Katriel]

Irit Katriel  added the comment:

While I do think this module should be more customisable than it is, I think it 
should be done via support for subclassing rather than injecting functions that 
get forwarded on as you do here.

There are other issues on bpo related to customising this module, with more 
convincing use cases than suppressing errors. I think it’s more likely that a 
patch will be accepted which solves the general problem of this module being 
inflexible (while being backwards compatible).

The patch you propose here solves a small part of the problem while making the 
api clunkier and it commits us to supporting this new parameter when we try to 
solve the general problem.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Martin]

Martin  added the comment:

Irit, would you be able to take a look at the patch?

---

I found another application scenario for the patch: In Numpy and Pandas, the 
assert_* functions in testing have a __tracebackhide__ local that advises 
pytest to hide the frame. With the patch in place, we could at least not 
display any locals if __tracebackhide__ is present.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32731] getpass.getuser() raises an unspecified exceptions (ImportError, OSError, etc)

[Jacob Walls]

Change by Jacob Walls :


--
nosy: +jacobtylerwalls
nosy_count: 4.0 -> 5.0
pull_requests: +27977
pull_request: https://github.com/python/cpython/pull/29739

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42872] Inconsistent exceptions thrown by pathlib.Path.mkdir on different OSes

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Improper NotADirectoryError when opening a file in a fake 
directory

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41742] Request for docs.python.org/3/library/configparser.html#exceptions improvement

[Irit Katriel]

Irit Katriel  added the comment:

I agree with Terry, it's pretty clear that this is a list of the exceptions 
that are defined in the module. Indeed many builtin exceptions can be raised 
from any piece of code (for example, you can run out of memory in any module).

--
nosy: +iritkatriel
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue41742>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32731] getpass.getuser() raises an unspecified exceptions (ImportError, OSError, etc)

[Irit Katriel]

Change by Irit Katriel :


--
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 2.7, Python 3.7, Python 
3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32696] Fix pickling exceptions with multiple arguments

[4-launchpad-kalvdans-no-ip-org]

Change by 4-launchpad-kalvdans-no-ip-org :


--
nosy: +4-launchpad-kalvdans-no-ip-org

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45828] [sqlite3] use unraisable exceptions in callbacks

[Erlend E. Aasland]

Change by Erlend E. Aasland :


--
keywords: +patch
pull_requests: +27834
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/29591

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45828] [sqlite3] use unraisable exceptions in callbacks

[Erlend E. Aasland]

Change by Erlend E. Aasland :


--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45828] [sqlite3] use unraisable exceptions in callbacks

[Erlend E. Aasland]

New submission from Erlend E. Aasland :

In order to print tracebacks from exceptions in SQLite callbacks, the sqlite3 
extension module provides sqlite3.enable_callback_tracebacks(flag). Setting the 
flag to True instructs the sqlite3 extension module to PyErr_Print() if an 
exception occurs during a callback. Else, PyErr_Clear() is called.

>From the sqlite3.enable_callback_tracebacks() docs:

By default you will not get any tracebacks in user-defined functions,
aggregates, converters, authorizer callbacks etc. If you want to debug
them, you can call this function with flag set to True. Afterwards, you
will get tracebacks from callbacks on sys.stderr. Use False to disable the
feature again.


Few other exceptions use a similar approach:

$ grep -r PyErr_Print Modules 
Modules/_tkinter.c:PyErr_Print();
Modules/_testcapimodule.c:PyErr_Print();
Modules/main.c:PyErr_Print();
Modules/main.c:PyErr_Print();
Modules/main.c:PyErr_Print();
Modules/_io/bytesio.c:PyErr_Print();
Modules/_sqlite/connection.c:PyErr_Print();
Modules/_sqlite/cursor.c:PyErr_Print();
Modules/_xxtestfuzz/fuzzer.c:PyErr_Print();
Modules/_xxtestfuzz/fuzzer.c:PyErr_Print();
Modules/_xxtestfuzz/fuzzer.c:PyErr_Print();
Modules/_xxtestfuzz/fuzzer.c:PyErr_Print();
Modules/_xxtestfuzz/fuzzer.c:PyErr_Print();
Modules/_xxtestfuzz/fuzzer.c:PyErr_Print();
Modules/_xxtestfuzz/fuzzer.c:PyErr_Print();
Modules/_ctypes/callbacks.c:PyErr_Print();


We get a higher hit for unraisable exceptions:

$ grep -r PyErr_WriteUnraisable Modules | wc -l
  45


AFAICS, using unraisable exceptions is a better approach.


Current behaviour:

Python 3.10.0 (v3.10.0:b494f5935c, Oct  4 2021, 14:59:20) [Clang 12.0.5 
(clang-1205.0.22.11)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> cx = sqlite3.connect(":memory:")
>>> cx.set_trace_callback(lambda stmt: 5/0)
>>> cx.execute("select 1")

>>> sqlite3.enable_callback_tracebacks(True)
>>> cx.execute("select 1")
    Traceback (most recent call last):
  File "", line 1, in 
ZeroDivisionError: division by zero



With unraisable exceptions:

Python 3.11.0a2+ (heads/sqlite-unraisable-exceptions-dirty:de29590d6a, Nov 
17 2021, 10:29:19) [Clang 13.0.0 (clang-1300.0.29.3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> cx = sqlite3.connect(":memory:")
>>> cx.set_trace_callback(lambda stmt: 5/0)
>>> cx.execute("select 1")

>>> sqlite3.enable_callback_tracebacks(True)
>>> cx.execute("select 1")
Exception ignored in:  at 0x10b4e3ee0>
Traceback (most recent call last):
  File "", line 1, in 
ZeroDivisionError: division by zero



The user experience is mostly unchanged; we get one extra line, telling us that 
the exception was ignored. Also, users can now use sys.unraisablehook:

>>> sys.unraisablehook = lambda unraisable: print(unraisable)
>>> cx.execute("select 1")
UnraisableHookArgs(exc_type=, 
exc_value=ZeroDivisionError('division by zero'), exc_traceback=, err_msg=None, object= at 0x10b4e3ee0>)
    


The only question I have, is if we should deprecate 
sqlite3.enable_callback_tracebacks() after switching to unraisable exceptions.

--
components: Extension Modules
messages: 406459
nosy: erlendaasland
priority: normal
severity: normal
status: open
title: [sqlite3] use unraisable exceptions in callbacks
versions: Python 3.11

___
Python tracker 
<https://bugs.python.org/issue45828>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45815] Document exceptions raised by fnmtach

[Dimitri Papadopoulos Orfanos]

New submission from Dimitri Papadopoulos Orfanos :

The fnmatch documentation should explicitly mention the type of exceptions 
raised by fnmatch.fnmatch():
https://docs.python.org/3/library/fnmatch.html

In my case it raised sre_constants.error, and it took some time to understand 
that the proper way to catch this type of exceptions is to catch the re.error 
superclass, by reading https://bugs.python.org/issue795379.

Actually that would be the case for any module using the re module under the 
hood, possibly passing an ill-formed regex to a re function.

--
assignee: docs@python
components: Documentation, Library (Lib), Regular Expressions
files: sre_constants.error_stderr.txt
messages: 406396
nosy: DimitriPapadopoulosOrfanos, docs@python, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Document exceptions raised by fnmtach
versions: Python 3.11
Added file: https://bugs.python.org/file50442/sre_constants.error_stderr.txt

___
Python tracker 
<https://bugs.python.org/issue45815>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Martin]

Martin  added the comment:

Thanks Joe!

> 1. The changes are sufficient to let the user make things work the way it is 
> requested that they work and anyone who does not start using the new 
> format_locals parameter will get the old behavior.

That was my goal :)

> 2. A side comment: I just noticed that the docstring for 
> FrameSummary.__init__ does not document the filename, lineno, and name 
> parameters.  Perhaps this could be fixed at the same time?

I agree and already updated the pull request.

> 3. The new parameter format_locals is slightly confusingly named, because it 
> does not format a single string from all the locals but instead gives a 
> dictionary of strings with one string for each local.

I think format_locals is OK here (local*s*: plural), but I'm open to better 
suggestions.

> 4. I personally think it would be better to include something like the 
> example value for format_locals as an extra attribute of the traceback module 
> so everybody doesn't have to write the same function.  That said, the 
> documented example is sufficient.

I sort of agree, but I also don't know what such a general-purpose function 
would entail. Suggestions?

> 5. It is not clear to me why this stringify-ing of the locals can't be done 
> in StackSummary._extract_from_extended_frame_gen.  It passes the dictionary 
> of locals and also the function to transform it to FrameSummary.  It would 
> make more sense to transform it first.  I suppose there might be some user 
> somewhere who is directly calling FrameSummary so the interface needs to stay.

I agree! In principle, FrameSummary has been little more than a container 
without (much) logic of its own.
Memory efficiency requires that that FrameSummary does not hold references to 
the original locals, thats why repr() was used.
I think as well that it would have been better to keep FrameSummary as a mere 
container and do the conversion of the locals elsewhere.
But at this point, this shouldn't be changed anymore.

> 6. I fantasize that the new format_locals parameter would have access to the 
> frame object.  In order for this to happen, the frame object would have to be 
> passed to FrameSummary instead of the 3 values (locals, name, filename) that 
> are extracted from it.  I think the current interface of FrameSummary was 
> designed to interoperate with very old versions of Python.  Oh well.

Do you have a use case for that? I have no clue what you would do with the 
frame object at this point.

> 7. If anyone wanted to ever refactor FrameSummary (e.g., to enable my fantasy 
> in point #6 just above), it becomes harder after this.  This change has the 
> effect of exposing details of the interface of FrameSummary to users of 
> StackSummary.extract and TracebackException.  The four parameters that the 
> new parameter format_locals takes are most of the parameters of FrameSummary.

Previously, I totally misread your request to "not just the local variable 
values, but also the name of the local variable and maybe also the stack frame 
it is in". This is why I included filename, lineno and name as parameters to 
format_locals which now seems totally useless to me and I'll remove them (if 
nobody objects).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Joe Wells]

Joe Wells  added the comment:

Some quick comments on Martin's pull request.

1. The changes are sufficient to let the user make things work the way it is 
requested that they work and anyone who does not start using the new 
format_locals parameter will get the old behavior.

2. A side comment: I just noticed that the docstring for FrameSummary.__init__ 
does not document the filename, lineno, and name parameters.  Perhaps this 
could be fixed at the same time?

3. The new parameter format_locals is slightly confusingly named, because it 
does not format a single string from all the locals but instead gives a 
dictionary of strings with one string for each local.

4. I personally think it would be better to include something like the example 
value for format_locals as an extra attribute of the traceback module so 
everybody doesn't have to write the same function.  That said, the documented 
example is sufficient.

5. It is not clear to me why this stringify-ing of the locals can't be done in 
StackSummary._extract_from_extended_frame_gen.  It passes the dictionary of 
locals and also the function to transform it to FrameSummary.  It would make 
more sense to transform it first.  I suppose there might be some user somewhere 
who is directly calling FrameSummary so the interface needs to stay.

6. I fantasize that the new format_locals parameter would have access to the 
frame object.  In order for this to happen, the frame object would have to be 
passed to FrameSummary instead of the 3 values (locals, name, filename) that 
are extracted from it.  I think the current interface of FrameSummary was 
designed to interoperate with very old versions of Python.  Oh well.

7. If anyone wanted to ever refactor FrameSummary (e.g., to enable my fantasy 
in point #6 just above), it becomes harder after this.  This change has the 
effect of exposing details of the interface of FrameSummary to users of 
StackSummary.extract and TracebackException.  The four parameters that the new 
parameter format_locals takes are most of the parameters of FrameSummary.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Ken Jin]

Change by Ken Jin :


--
nosy:  -kj

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Martin]

Martin  added the comment:

I improved the example in traceback.rst to illustrate how format_locals works.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Martin]

Martin  added the comment:

Just to avoid misunderstandings: My pull request is not at all about silencing 
exceptions. It is about customizing the output of the traceback module. (Just 
like the introduction of capture_locals previously: #22936)

(-X capture_locals, on the other hand, is a hypothetical idea that might help 
with debugging, but we don't have to discuss this now.)

My main argument for the proposed change is that traceback is useless in 
certain situations, because capture_locals is not "robust" (it *might* raise 
exceptions; I could handle these in the calling code but that would again hide 
the stack trace that I was about to investigate) and might dump sensitive data 
like passwords into logfiles (msg237320, msg237323).

Nothing is taken away or hidden, but flexibility is added.

(The only other option to resolve these issues would be to re-implement much of 
the current functionality of traceback in a third-party module, which would 
lead to maintainability problems and fragmentation.)

--
nosy: +rbcollins

___
Python tracker 
<https://bugs.python.org/issue43656>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Andrei Kulakov]

Andrei Kulakov  added the comment:

Martin:

I have a couple of concerns:

 - Generally (AFAIK) Python is very conservative about silencing arbitrary 
exceptions. There are a few functions with args like `ignore_errors`, but those 
are for errors in the logic of respective functions. I don't recall examples 
where any error would be silenced via an argument, but if there are such cases, 
it would be interesting to look into how the design decision was made.

In this case of course arbitrary exceptions coming any objects' __repr__ may be 
silenced.

There is a clear and very explicit way to catch exceptions via try/except and 
as a dev, I would really want to be able to look at a module, look at all 
try/except clauses and be confident that exceptions are not silenced elsewhere.

 - You are targeting this fix to production use, but realistically, if merged, 
it will be used both in testing and production. Which means, by not seeing 
these exceptions in testing, you will have a higher chance of deploying them to 
production where they can surface in other circumstances.

IOW, as a dev I might prefer to see these errors early and often, rather than 
have a mechanism that ends up silencing errors more broadly than intended.

I'm not saying this fix should be rejected, but that there's a tricky balance 
here -- and I don't feel confident enough about this solution to approve the PR 
if I reviewed it.

--

___
Python tracker 
<https://bugs.python.org/issue43656>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Martin]

Martin  added the comment:

I see two scenarious discussed here:

Scenario 1 (Offline / Batch-Mode):
A system runs user-supplied jobs that may fail. In the case of an error, the 
system shouldn't crash but rather store a maximally helpful message and carry 
on with the next job. Most likely, the relevant information is the situation 
that lead to the error in the first place, not that repr() has also gone wrong 
as a result.

This could be a a system to automatically test the homework code of your 
students. Or, like in my case, a framework that runs experiments. You would 
very likely want a system that does not crash if a __repr__ is wrongly 
implemented but prints a readable traceback and carries on with the next job.

Here, format_locals could be used to fall back to a different representation of 
an object if repr() fails.

This is the use case that my pull request tries to address primarily.

Scenario 2 (Online / Write, Test, Repeat):
A user frequently rewrites and executes their code until the desired outcome 
appears.
Errors inevitably happen. In this case, a maximally helpful stack trace is 
needed. Again, the relevant information is the situation that lead to the error 
in the first place, not that repr() has also gone wrong as a result.

Yes, it would be hard for unexperienced users to come up with 
StackSummary.extract(format_locals=...) by themselves.
But, the correct way would be to use a debugger anyway, not some hand-written 
code to print exceptions on the fly.

However, if your students receive a template file where they fill in missing 
function bodies etc, there might already be a substantial amount of code which 
they don't understand at first, nor do they need to care. Therefore, a piece of 
code that formats exceptions nicely would hurt here.

I think the most useful change for Scenario 2 (if, for some reason, a proper 
debugger is not an option) could be to add a command line option (e.g. -X 
capture_locals) so that a complete stack trace is printed if an exception 
bubbles up to interpreter level. (Here, it wouldn't hurt to handle exceptions 
in repr() because the interpreter already stopped exection anyway.)
This option would be very easy to teach to inexperienced users.

My pull request would provide preparation for this more extensive change.

--

___
Python tracker 
<https://bugs.python.org/issue43656>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39228] traceback.FrameSummary does not handle exceptions from `repr()`

[Martin]

Martin  added the comment:

I submitted a pull request for the related issue43656:

https://github.com/python/cpython/pull/29299

It introduces a format_locals parameter that enables the customized formatting 
of a FrameSummary.

This way, a user of traceback could provide a function that handles exceptions 
within __repr__ if necessary.

--

___
Python tracker 
<https://bugs.python.org/issue39228>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Andrei Kulakov]

Andrei Kulakov  added the comment:

Martin: I'm not sure what is the best way to fix this issue, so I hope someone 
else will look into this.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Martin]

Martin  added the comment:

Could the participants of this issue please have a look at my pull request:

https://github.com/python/cpython/pull/29299

What do you like, what don't you like? Does it work for your use case?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45694] Limit the number of chained exceptions included in formatted traceback

[Guido van Rossum]

Change by Guido van Rossum :


--
nosy: +gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45694] Limit the number of chained exceptions included in formatted traceback

[Irit Katriel]

New submission from Irit Katriel :

There is currently a limit on the number of frames in each traceback, but not 
on the number of chained exceptions displayed. This is why traceback.py avoids 
recursion (making the code more complex). A limit should probably be added.

--
components: Interpreter Core, Library (Lib)
messages: 405533
nosy: iritkatriel
priority: normal
severity: normal
status: open
title: Limit the number of chained exceptions included in formatted traceback
type: enhancement
versions: Python 3.11

___
Python tracker 
<https://bugs.python.org/issue45694>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Martin]

Change by Martin :


--
pull_requests: +27563
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/29299

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Martin]

Martin  added the comment:

Once again a very good summary, thanks Joe!

> it would be quite useful if this function parameter was given not just the 
> local variable values, but also the name of the local variable and maybe also 
> the stack frame it is in

So this would be something like `format_locals(filename, lineno, name, locals) 
-> dict[str,str]` that could be used inside FrameSummary.__init__. I like that!

I wouldn't bother with detecting un-repr-able objects in Python itself, but if 
the above `format_locals` was implemented, you could easily prepare such a 
formatter for your students that hides `self` et al. and/or catch exceptions 
during `repr` to your liking.

What is needed to get an OK for such a change?

--

___
Python tracker 
<https://bugs.python.org/issue43656>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Joe Wells]

Joe Wells  added the comment:

1. As background, it is worth remembering that a major motivation for why 
FrameSummary.__init__ stringifies the local variable values in its parameter 
locals is to prevent the resulting data structure from keeping those values 
live.  This enables them to be garbage collected.

2. It has been suggested that TracebackException.__init__ or 
StackSummary.extract could be given a function parameter.  This could either be 
a new parameter or could involve using the existing capture_locals parameter 
with a non-bool.  The purpose of this suggestion is to allow customizing the 
use of repr to stringify local variable values.  If this suggestion is 
followed, it would be quite useful if this function parameter was given not 
just the local variable values, but also the name of the local variable and 
maybe also the stack frame it is in.  This would enable filtering out undesired 
variables.  For example, I would usually prefer to filter most of the variables 
from the __main__ module frame, because they are just noise that makes it hard 
to see the important details.  Some ability to filter would also help with the 
security issue that is discussed in issue 23597 that Irit pointed to.

3. I doubt that new students will be setting up calls to TracebackException or 
modifying sys.excepthook on their own.  Although a simple interface is clearly 
good, it might be more important to have an interface that maximizes the 
usefulness of the feature.

4. I no longer have the tracebacks my students were getting.  You can look at 
the traceback from the example in msg 404319 for a traceback.  While I was 
debugging this, I got much more complicated tracebacks because two of the 
classes in traceback.py also throw exceptions during their __init__ method that 
leave the not-yet-initialized object in a repr-will-raise-an-exception state.  
Despite having decades of programming experience, it actually took me a long 
time before I realized that the exceptions I was debugging were junk exceptions 
due to attempts to call repr on not-yet-initialized objects.  I think figuring 
this out would be extremely challenging for my second-year undergraduate 
students.

5. If one of the calls to repr in FrameSummary.__init__ raises an exception, 
this prevents all the other local variable values from being inspected.  If it 
is desired to report local variable values that cause repr to raise an 
exception, then it would be good to collect all such exceptions, which requires 
handling each exception and then continuing to traverse the traceback stack.  
Because of point 1 above, it might often be best to turn each such exception 
into a string.  To avoid infinite loops in the debugging/logging tools, it 
would often be best not to attempt to traverse the traceback stack of each of 
these extra exceptions.  If this argument is a good argument, this seems to 
mean that my most recent proposed fix is a good balance.

6. It is not clear if there is a reliable way to detect whether repr raises an 
exception due to an object's initialization having been interrupted, but all of 
the failures that I observed of this sort were for the variable name “self”.  
In one case, the repr failure was for a normal local variable of an __new__ 
method which was not a parameter of this method; the variable was named “self” 
by convention, but this convention would be difficult to automatically verify.  
In the two other cases, the repr failure was for a parameter named “self” which 
was the first parameter of an __init__ method.  So it would help to give 
special treatment to the first parameter of __init__ methods, but this would 
not solve the problem for __new__ methods.

7. In some cases, it might be a bit complicated to ensure the object is always 
in a safe state for repr-ing during initialization.  This is because there may 
be many attributes that need to be modified and this is not generally done 
atomically.  One attribute could be designated to indicate that initialization 
is done, so that repr will be extra careful if that attribute does not have an 
expected value.  Given that this is only (so far) an issue for debuggers and 
traceback inspection tools, it is not clear how to motivate everyone who writes 
a __new__, __init__, or __repr__ method to do this safely.  Documentation can 
of course help.

--

___
Python tracker 
<https://bugs.python.org/issue43656>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Andrei Kulakov]

Andrei Kulakov  added the comment:

Martin: It's true that exceptions raised in other methods called from __init__ 
would still have this issue, but I feel like ~90% of it would be solved by the 
proposed fix.

It does introduce an inconsistency but it does so because it reflects the 
inconsistency of `self` being NOT initialized in __init__ and `self` being 
initialized in all other methods used after __init__. It makes intuitive sense 
that you don't get a repr of an object before it exists in a full state.

The doc fix is useful in itself, but I'm not sure it's enough given the issue 
reported by Joe with new students getting this error. When they get this error, 
they will not understand why it happens, what's the connection between the 
error and the argument that needs to be provided to fix it, and whether it's 
the correct fix or not.

If they *do* understand it, fixing the __repr__ is probably the best solution, 
and then no fix on our side is required.

My concern with adding a safe repr argument is that code using that argument 
can be copy pasted unknowingly and then it's not explicit/obvious that it will 
silence the errors raised due to broken __repr__'s. (including __repr__'s that 
are broken even outside of __init__ method).

If such an parameter is added, it's much better to make it a new parameter, to 
avoid backwards incompatible change, which means it can be backported.

--

___
Python tracker 
<https://bugs.python.org/issue43656>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Irit Katriel]

Irit Katriel  added the comment:

Martin, how about something like:

"This is typically used for debugging, so it is important that the 
representation is information-rich and unambiguous. Furthermore, this function 
should not raise exceptions because that can make it inappropriate for use in 
some debugging contexts. "

--

___
Python tracker 
<https://bugs.python.org/issue43656>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Martin]

Martin  added the comment:

Irit, I'm unsure about the wording. Something like ":meth:`__repr__` should 
always succeed, even if errors prevent a full description of the object."? "... 
even if the object is only partly initialized."?

Andrei, I think you can not simply omit the first argument. For virtually all 
methods, `self` is an important value for debugging. It could be omitted for 
__init__, but that would break consistency. Also, __init__ could call other 
methods that help initialize the object and therefore also deal with partly 
initialized objects.

I really think one important part of the solution to this problem is making 
people aware, that under some rare conditions, repr might receive a partly 
initialized object.

I'm also still convinced that the other part of the solution is a way to 
customize the behavior of StackSummary.extract and friends.
Context: I have written a tool (https://github.com/moi90/experitur) to run 
batches of (machine learning) experiments (so it is not interactive). In case 
of an error, the traceback is dumped into a file, together with the respective 
local variables (using 
`traceback.TracebackException.from_exception(...).format()`). I want this to 
succeed *in any case*, even if I was too ignorant to implement correct 
`__repr__`s in my experiment code (which is mostly on-time-use, so why should I 
care).

In the end, this whole problem only affects users of `capture_locals=True`, so 
we could just change the semantics of this parameter a bit:
False: do nothing, True: use repr (as before), : use this 
callable to convert the value to a string.
This way, we could avoid adding an additional parameter to many of the methods 
in traceback AND give users an easy way to customize exception formatting for 
easy debugging.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Irit Katriel]

Irit Katriel  added the comment:

Martin, would you like to submit a patch with this addition to the doc?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Andrei Kulakov]

Andrei Kulakov  added the comment:

I've been thinking that perhaps it makes sense to special case printing of 
`self` argument in `__init__` methods. The same exact issue happens with PDB 
`args` command in `__init__` methods.

My idea is that in the __init__, you generally don't want to print `self`  arg 
and trying to do so can cause this type of unexpected errors.

The reason is that __repr__ is not designed to be used for objects with 
unfinished initialization, because even if it doesn't break, it will give you 
incomplete or even misleading representation.

In case when __init__ has some complex logic that can raise an exception, it's 
likely that other local variables will help you identify the object. If there 
is no complex logic or other arguments, and __init__ still failed, you can say 
that there wasn't yet an actual object that can be uniquely represented.

Therefore I think it makes sense to simply omit representing `self` arg (or 
first arg of the method) in both `StackSummary.extract()` and PDB `args` 
command. It may break some existing code but I think it would be a small amount 
of code affected. Because of this it can only go into 3.11 version. I feel like 
on the balance it would be a good change to make, but I'm curious to hear other 
opinions.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Martin]

Martin  added the comment:

> Can we determine if they came from an initialized object or from object in 
> the middle of initialization?

That would be very nice because inside __init__ is the only place where we have 
to deal with partly initialized objects. But I think Python does not provide a 
way to detect this state.

Although I would very much like having FrameSummary robust to any kind error, I 
acknowledge that this might not be possible.

It might be frustrating for beginners, but I think the only way to "fix" this, 
is by having people implement their `repr`s correctly.

The documentation currently says[1]:

> This is typically used for debugging, so it is important that the 
> representation is information-rich and unambiguous.

It should be added that __repr__ might be used to display partly initialized 
objects during debugging and therefore should deal with these gracefully.

[1] https://docs.python.org/3/reference/datamodel.html#object.__repr__

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40899] Document exceptions raised by importlib.import

[Filipe Laíns]

Change by Filipe Laíns :


--
nosy: +FFY00

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Irit Katriel]

Irit Katriel  added the comment:

See also 23597.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42413] Replace custom exceptions for timeouts with TimeoutError

[Christian Heimes]

Christian Heimes  added the comment:

Andrew, could you please rebase your PR and get it submitted?

--
assignee: christian.heimes -> asvetlov
versions: +Python 3.11 -Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45549] Seek in file object didn't treat all paths of exceptions

[Eric V. Smith]

Eric V. Smith  added the comment:

That's behavior we can't change without breaking code.

And it's documented as working this way, at least on Linux: 
https://linux.die.net/man/2/lseek

--
nosy: +eric.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue43656] TracebackException or StackSummary.extract with capture_locals=True fail to catch exceptions raised by repr() on value of frame local variable in FrameSummary.__init__.

[Andrei Kulakov]

Andrei Kulakov  added the comment:

Martin: I was also thinking of adding a parameter to `extract()`. The issue I 
see is that it's still confusing and complicated for new students to understand 
the issue and find the parameter and understand why it's needed.

Joe: one important thing to note is that if an exception is caught and handled, 
it doesn't at all mean that unrelated exceptions from __repr__ can be silenced. 
Can we determine if they came from an initialized object or from object in the 
middle of initialization?

By the way, can you post a complete traceback that your students were getting? 
I would like to see how hard it is to tell from the traceback that a particular 
classes' __repr__ is at fault. If it's a long traceback please attach as a 
file..

--

___
Python tracker 
<https://bugs.python.org/issue43656>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com