extract elements of n char from a list

[Tim Peters]

[Fernando Perez]
> ...
> However, I'd like to mention a _minor_ inaccuracy in the text you
> refer to by Tim.

That's me!

> He says that on Unix machines, time.clock() returns the user
> time from your process. Technically that's not 100% true, as it returns
> the sum of  (user+system) time consumed by your process.
>
> The clock.c sources confirm this (from glibc-2.2.5):

To be technical right back <wink>, I wrote about "Unix-like systems", which
is a far broader world than is covered by glibc alone.  The POSIX / Single
UNIX Specification says only this:

    DESCRIPTION
    The clock() function shall return the implementation's best
    approximation to the processor time used by the process since the
    beginning of an implementation-defined era related only to the
    process invocation.

    RETURN VALUE
    To determine the time in seconds, the value returned by clock() should
    be divided by the value of the macro CLOCKS_PER_SEC. ... If the
    processor time used is not available or its value cannot be
    represented, the function shall return the value (clock_t)-1.

There's no distinction drawn between "user time" and "system time", and
"processor time" is left undefined.  I do confess that I used the phrase
"user time" merely to distinguish the behavior of UNIX-like systems from the
Windows wall-clock time behavior of clock(), though, without your particular
meaning of user time in mind.  My apologies if it mislead, although, if it
did, I hope it also helped drive home the larger point that timing
algorithms across platforms (even just across different flavors of Unix!) is
a business fraught with peril.