I'm debugging a python script and, occasionally, print in python stops working, plus errors in python don't print either.  Simplly no output box shows up.

When this occurs the only thing that seems to get it working again is to close Poser and reopen it. Also, when it occurs, *none* of my scripts will print anything nor show python errors.

Is there some way to turn back on that output box, short of restarting Poser?

This is Poser 13 under Windows 11.

You're aware that 'print' is one of the key changes between Python 2 (Poser 11 and predecessors) and Python 3 (Poser 12 and up)? It sounds like perhaps you're trying to run a Python 2 script in a Python 3 environment. Print statements, strings, and iterated lists are handled differently.  Print is fairly easily fixed though.

Nah, it was something more subtle than that.

I was using print statements for debugging a script. It had four print statements. I would open Poser, load my scene, run the script -- and three prints would work. I would rerun the script and the print box would not even open, not for that script nor for any of my other scripts. I would relaunch Poser and the script would print again. Three statements printed. The fourth did not, and, as before, the script would no longer even open the print box. I would have to relaunch Poser again.

Inexplicably enough, changing the line, "str = input.Value()", gleamed from working code, to use "x" as the variable name instead of "str" -- and the problem went away. Makes no sense at all, but, trust me, I have over 50 years experience as a programmer. Changing that line of code (which is *still* in another working piece of code) did the magic. No clue. Maybe there was a non-printing character in the statement or somesuch, but whatever was going on, it screwed scripts royally, requiring closing and reopening Poser to clear it.

Thank you for your suggestions however. This forum really works well for getting answers, suggestions, clues, etc., and I love it.

Curious. Is there a limit on str (string?) print statements, perhaps?

I've been having this problem off and on today whilst dabbling with a set of scripts for adjusting groups of lights by f-stops. And -- it may turn out to be that I was crashing Python by trying to invoke a method on a null object. I haven't done testing to nail that down, but it makes more sense than thinking that "str" was actually and truly a magically taboo variable name.

Return a string version of object. If object is not provided, returns the empty string. Otherwise, the behavior of str() depends on whether encoding or errors is given, as follows.

If neither encoding nor errors is given, str(object) returns type(object).__str__(object), which is the “informal” or nicely printable string representation of object. For string objects, this is the string itself. If object does not have a __str__() method, then str() falls back to returning repr(object).

If at least one of encoding or errors is given, object should be a bytes-like object (e.g. bytes or bytearray). In this case, if object is a bytes (or bytearray) object, then str(bytes, encoding, errors) is equivalent to bytes.decode(encoding, errors). Otherwise, the bytes object underlying the buffer object is obtained before calling bytes.decode(). See Binary Sequence Types — bytes, bytearray, memoryview and Buffer Protocol for information on buffer objects.

Passing a bytes object to str() without the encoding or errors arguments falls under the first case of returning the informal string representation (see also the -b command-line option to Python). For example:

str(b'Zoot!')
"b'Zoot!'"

For more information on the str class and its methods, see Text Sequence Type — str and the String Methods section below. To output formatted strings, see the f-strings and Format String Syntax sections. In addition, see the Text Processing Services section.

Thanks for the information, but, actually, str is not a protected keyword and can definitely be used as a variable name. I've downloaded code from this forum which uses it as a variable name, as does much of my derived code. The issue was a typo a line or so earlier, such that I was referencing a null object in the line which was assigning a value to str.