4 ms·

If you str is broken, the traceback would fail which would be awful. Once I wrote a str method on a class which got into an infinite loop :) When I sho

by Walkman 12y ago

If you __str__ is broken, the traceback would fail which would be awful. Once I wrote a __str__ method on a class which got into an infinite loop :) When I showed the traceback to an advanced developer, he told me immediately what was happening. How could we figure out the problem if my __str__ was broken and traceback would fail? Also recently I struggled with py.test which automatically does that (calling str() on every local variable in the test case) but it is broken, so py.test showed me strange Unicode Decode exceptions (it turned out, nothing wrong was in my code but py.test) and I had no idea what was going on. Took me hours to figure it out py.test has a issues with __future__ unicode_literals... tl;dr: not a good idea

raldi 12y ago
Doesn't seem like a showstopper to me; just fall back to current behavior if str() fails or takes too long, and truncate if it's too verbose.
- Walkman 12y ago
  How you define "too long" and "too verbose"?
  - raldi 12y ago
    Keep a running tally of time spent stringifying. If it passes 1000 msec over the entire life of the program, disable the feature. As for length, maybe 100 chars? I think that's around what repr() often uses.
    - Walkman 12y ago
      > Simple is better than complex. I think Python exceptions are verbose enough, not necessary to make it more verbose, more complicated.
    - pmahoney 12y ago
      Can str() call into a C extension that then loops forever?
      - moe 12y ago
        Can we contrive esoteric situations where this feature would fail spectacularly? Yes. Do they matter in reality? No. Make it an optional feature to be toggled with an interpreter flag. People like me can turn it on, you can keep it turned off.
        army 12y ago
        That doesn't seem that esoteric to me: in general the problem is that repr() can result in execution of arbitrary code, and that there's no way to cleanly and reliably terminate arbitrary code. This includes Python code: it's possible to terminate it at an arbitrary point, but that leaves things in an indeterminate state. I think it's pretty important that you shouldn't add features with unpredictable behaviour into the core of the language, particularly into error handling code.
        moe 12y ago
        It's esoteric because in reality it's the kind of bug that never happens. And if it happens it's trivial to identify the cause; "Oh, it hangs in the middle of a strack-trace, what could it possibly be...". Why would your code contain repr()-functions that trigger "unpredictable behavior" to begin with anyway?

If you __str__ is broken, the traceback would fail which would be awful. Once I wrote a __str__ method on a class which got into an infinite loop :) When I sho

by Walkman 12y ago

raldi 12y ago

Doesn't seem like a showstopper to me; just fall back to current behavior if str() fails or takes too long, and truncate if it's too verbose.

Walkman 12y ago
How you define "too long" and "too verbose"?
- raldi 12y ago
  Keep a running tally of time spent stringifying. If it passes 1000 msec over the entire life of the program, disable the feature. As for length, maybe 100 chars? I think that's around what repr() often uses.
  - Walkman 12y ago
    > Simple is better than complex. I think Python exceptions are verbose enough, not necessary to make it more verbose, more complicated.
  - pmahoney 12y ago
    Can str() call into a C extension that then loops forever?
    - moe 12y ago
      Can we contrive esoteric situations where this feature would fail spectacularly? Yes. Do they matter in reality? No. Make it an optional feature to be toggled with an interpreter flag. People like me can turn it on, you can keep it turned off.
      - army 12y ago
        That doesn't seem that esoteric to me: in general the problem is that repr() can result in execution of arbitrary code, and that there's no way to cleanly and reliably terminate arbitrary code. This includes Python code: it's possible to terminate it at an arbitrary point, but that leaves things in an indeterminate state. I think it's pretty important that you shouldn't add features with unpredictable behaviour into the core of the language, particularly into error handling code.
        moe 12y ago
        It's esoteric because in reality it's the kind of bug that never happens. And if it happens it's trivial to identify the cause; "Oh, it hangs in the middle of a strack-trace, what could it possibly be...". Why would your code contain repr()-functions that trigger "unpredictable behavior" to begin with anyway?