[Python-Dev] Strings: '\012' -> '\n'

[Guido van Rossum]

> On Tue, 16 Jan 2001, Guido van Rossum wrote:
> > You mean the tp_print and tp_str function slots in type objects,
> > right?  tp_print *should* always render exactly the same as tp_str.
> > tp_print is used by the print statement, not by value display at the
> > interactive prompt.
> 
> Uh, i hate to disagree with you about your own interpreter, but:
> 
>     com_expr_stmt in Python/compile.c
>         inserts a PRINT_EXPR opcode if c_interactive is true;
>     eval_code2 in Python/ceval.c
>         handles PRINT_EXPR by calling displayhook;
>     sys_displayhook in Python/sysmodule.c
>         prints the object by calling PyFile_WriteObject on sys.stdout;
>     PyFile_WriteObject in Objects/fileobject.c
>         calls PyObject_Print if the file is really a PyFileObject;
>     PyObject_Print in Objects/object.c
>         calls op->ob_type->tp_print if it's not NULL.
> 
> The print statement produces a PRINT_ITEM opcode, which invokes
> PyFile_WriteObject with a Py_PRINT_RAW flag.  That Py_PRINT_RAW
> flag is propagated down to PyObject_Print and into string_print,
> where it causes the string to fwrite itself directly without quoting.
> 
> > So, string_print most definitely should *not* be changed -- only
> > string_repr!
> 
> I had to change them both before i actually saw the change in the
> interactive interpreter.  Actually, your statement above (that the
> two should always render the same) seems to imply that if i change
> one, i must also change the other.

Oops.  I'm so grateful that we have a collective memory! :-)

You're right: tp_print() can be invoked in two modes: with or without
Py_PRINT_RAW flag.  In raw mode, it should behave exactly like str();
in cooked mode exactly like repr().

--Guido van Rossum (home page: http://www.python.org/~guido/)