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.
-- ?!ng
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4