[Pythonmac-SIG] Re: [Python-Dev] Import hook to do end-of-line conversion?

[Tim Peters]

[Guido]
>> ...
>> that's when Python's parser (eventually) grew the habit of
>> silently ignoring a \r just before a \n in a source file.

[Chris Barker]
> It can do that? I had no idea. Probably because I work on the Mac and
> Linux almost exclusively, and hardly ever encounter a Windows box.

>> It's a sign of how backward the Mac world is that the problem only
>> now pops up for the Mac. :-)

> Actually it's a sign of how *nix/Windows focused Python is. It's sad
> to see that someone thought to fix the problem for *nix/Windows, and
> didn't even consider the Mac (as Just pointed out the problem has
> been know for a long time).

This is a reversal of history.  The code to ignore
    \r
when seeing
    \r\n
originally (1995) applied to *all* platforms.  I don't know why, but Jack
submitted a patch to disable this behavior only when "#ifdef macintosh", in
revision 2.29 of Parser/tokenizer.c, about 4 years ago.  The #ifdef
introduced then still exists today; 3 lines introduced by that patch start
with XXX here for clarity (appropriately defined <wink>):

XXX #ifndef macintosh
			/* replace "\r\n" with "\n" */
XXX			/* For Mac we leave the \r, giving a syntax error */
			pt = tok->inp - 2;
			if (pt >= tok->buf && *pt == '\r') {
				*pt++ = '\n';
				*pt = '\0';
				tok->inp = pt;
			}
XXX #endif

I have no idea what Mac C libraries return for text-mode reads.  They must
convert \r to \n, right?  In which case I guess any \r remaining *should* be
"an error" (but where would it come from, if the C library converts all \r
thingies?).  Do they leave \n alone?  Etc:  submit a patch that makes the
code above "work", and I'm sure it would be accepted, but a non-Mac person
can't guess what's needed.

As to "considering the Mac", guilty as charged:  I don't know anything about
it.  What's to consider?  How often do you consider the impact of chnages on,
say, OpenVMS?  Same thing, provided you're as ignorant of it as I am of your
system.

> Frankly, it's also a symptom the the isolationist attitude of a
> lot of Mac users/developers. and Don't get me started on the spaces
> vs tabs thing!

The std for distributed Python code is 4-space indents, no hard tab
characters.  So there's nothing left there to get started on <wink>.

it's-not-that-we-don't-want-to-"fix"-macs-it's-that-we-don't-know-
    how-macs-work-or-what-"fix"-*means*-to-a-macizoid-ly y'rs  - tim