On Thu, 18 Jan 2001 01:29:13 -0800 (PST), Ka-Ping Yee <ping@lfw.org> wrote: > 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 > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > > -- Moshe Zadka <sig@zadka.site.co.il> This is a signature anti-virus. Please stop the spread of signature viruses! Fingerprint: 4BD1 7705 EEC0 260A 7F21 4817 C7FC A636 46D0 1BD6
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