"in" for dicts (was: Python 2.1 function attributes)

[Tim Peters]

[Tim]
> we also haven't pulled the platform-dependent tricks Perl does
> to optimize char-at-a-time reading the way vendors *should*
> optimize fgets() but almost never do (Tru64 Unix appears to be
> the sole probable exception to date).

[Thomas Wouters]
> FreeBSD, actually, had insane performance in that area as well.
> (getc() being just as fast as getc_unlocked(), in processes with
> only a single thread active.)

This one doesn't have anything to do with locking or not, it has to do with
whether the inner loop is optimized to use register shadows of _iobuf
members, and to use the platform's moral equivalent of the _cnt member to
avoid needing to check for EOF in the inner loop.  It's not "legal" to do
that in user-level code, because it requires breaking into the FILE*
abstraction.  Vendors can do it under the covers, although apparently almost
never do.  The unique thing about Tru64 Unix was the report that using the
fgets() method was substantially faster than using the getc_unlocked()
method; that's darned hard to account for unless Tru64 optimizes the inner
loop of fgets() (as Perl does).

IOW, just using getc_unlocked() still leaves a pile of *potential*
improvement on the floor, even on a single-thread run, but improvement you
can't get at without cheating (unless the vendor libc authors were savvy
enough to do it for you).

If Perl while(<>) is still substantially faster on FreeBSD than Python 2.1
using the fgets() method in single-thread runs, platform failure to optimize
fgets() in this way is a top contender for "why".