ART is an install-time compiler from Dalvik bytecode to native code. It improves CPU, RAM, and battery usage, but still requires whatever code is run through it to be converted to Dalvik bytecode.

If we don't currently have a way to run Python on a Dalvik JIT, then we don't currently have a away to run Python on ART.

Why did they go to an install-time optimizer instead of inventing something better than Dalvik?

Well, continuing to run legacy apps efficiently is almost certainly a requirement. Presumably it's also a requirement for them that the Java semantics easily and efficiently map to their program representation.

An AoT compiler instantly makes everyone's favorite Android apps start faster, and many of them run faster, without having to wait for (sometimes defunct) publishers to re-compile the apps.

A static single assignment representation that matches the Java semantics, such as Michael Franz's SafeTSA, would be better than Dalvik bytecode if they're going to do install-time generation of native code.

In any case, I hope they continue to promote architecture-independent distribution formats for apps and libraries. I've said for a while that I think compiling directly to native code is going to eventually be treated like we now treat hand-written assembly... a last resort for small pieces of code that need speed and have been found to not be efficiently served by more abstract tools.

My guess is that it's still Java-like under the hood -- at the very least, calling out to API endpoints will be...

Probably doesn't change much at all. (Though I'd love to be wrong).