[Python-Dev] xreadlines : readlines :: xrange : range

[Tim Peters]

[Tim]
> It's a shame that almost all vendors missed that fgets was defined
> as a primitive by the C committee precisely so that vendors *could*
> pull this speed trick under the covers.  It's also a shame that Perl
> did it for them <wink>.

[Andrew Kuchling]
> So, should Python be changed to use fgets(), available on all ANSI C
> platforms, rather than the glibc-specific getline()?  That would be
> more complicated than the brain-dead easy course of using getline(),
> which is obviously why I didn't do it; PyFile_GetLine() had annoyingly
> complicated logic.

The thrust of my original comment above is that fgets is almost never faster
than what Python is doing now, because vendors overwhelmingly do *not*
exploit the opportunity the std gave them.  So, no, switching to fgets()
wouldn't help.

> When this was discussed in comp.lang.python, someone also mentioned
> getc_unlocked(), which saves the overhead of locking the stream every
> time, but that didn't seem a fruitful avenue for exploration.

Well, get_unlocked isn't std (not even in C99).  Mentioning it did inspire
me to discover, however, that while the MS fgets() is the typical "getc in a
loop" thing, at least it locks/unlocks the stream once each at function
entry/exit, and uses a special MS flavor of getc ("_getc_lk") inside the
loop.  However, that this helps is an illusion, because the body of their
_getc_lk macro is identical to the body of their getc macro.  Smells like a
bug, or an unfinished project.