[Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?
Tim Peters
tim.one@home.com
Fri, 13 Apr 2001 03:12:05 -0400
[Tim]
> No, there's nothing wrong with the tokenizer code: it's coded
> in C, and the C text convention is that lines end with \n, period.
> Reliance on that convention is ubiquitous -- and properly so.
[Just van Rossum]
> I don't get it: why would a thin layer on top of stdio be bad?
> Seems much less work than reimplementing stdio.
What does that question have to do with the snippet you quoted? In context,
that snippet was saying that if you did write a small layer on top of stdio,
one that just made \n show up when and only when you think Python should
believe a line ends, then nothing in the tokenizer would need to change
(except to call that layer instead of fgets()), and even the tokenizer's
current \r\n mini-hack could be thrown away.
If that's all you want, that's all it takes. If you want more than just
that, you need more than just that (but I see Guido already explained that,
and I explained too why the Windows Python cannot recognize \r endings with
reasonable speed for *general* use short of building our own stdio -- but I
don't really much care how fast the compiler runs, if all you want is the
same limited level of hack afforded by the existing one-shot \r\n tokenizer
trick -- and the compiler isn't using the *general*-case fileobject.c
get_line() anyway).
you-pay-for-what-you-want-and-the-more-you-want-the-more-you'll-pay-ly
y'rs - tim