[Python-Dev] Strings: '\012' -> '\n'
Moshe Zadka
moshez@zadka.site.co.il
Fri, 19 Jan 2001 02:19:45 +0200 (IST)
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