time.clock() or time.time()

[Magnus Lycka]

Shane Hathaway wrote:
> However, isn't this thoroughly un-Pythonic?  No wonder people have to 
> ask.

Only if they've never read K&R, and I thought that was compulsory! ;^)

There are a few python libraries, such as time and math, that are
basically just thin wrappers around standard C libraries. In some
cases, they are complemented with more modern libraries, such as
datetime.

You might argue on how pythonic (or useful, or beginner friendly)
they are, but they cost very little to maintain across platforms.
It's important to keep the maintenance costs down for any project,
certainly for a project such as Python, and as far as I know, there
is no cross platform standard API to access CPU time, so a
time.cputime() function would require a lot of work to maintain,
and I don't know if anyone really had a strong need for it.

There is a benefit to maintain (standard or not) API's that
programmers have experience from when programming in other languages.
Of course, I think it's a good thing to properly adapt API's to Python
ways of working. I.e. if a C++ library returning an iterator is wrapped,
I want to be able to do...

for item in container:
    print item

...rather than...

it = container.start()
while it != container.end():
     item = it.deref()
     print item

Still, it's often a Good Thing if a Python API is as similar as
possible to e.g. a C++ API that it wraps.

One of the great aspects of Python is that it's a good team player.
It doesn't try to create a world of its own, like Smalltalk and
ABC does, but blends in well in a mixed language environment.

We work extensively with a mix of C++ and Python (as well as some
other languages) here at Carmen, and it would be painful if I had
to remember two different API's for each library that I access from
both C++ and Python.