Je suis partial (être un expert Python mais assez rouillé en Java) mais je pense que le Python exécution de GAE est actuellement le plus avancé et le mieux développé que le Java runtime-le premier a eu une année supplémentaire pour se développer et mûrir, après tout.
Comment les choses vont continuer à aller de l'avant est bien sûr difficile de prédire -- la demande est probablement plus forte sur le Java côté (surtout depuis qu'il n'est pas seulement à propos de Java, mais d'autres langues perché au sommet de la JVM, donc c'est LA façon de gérer par exemple, PHP ou Ruby code sur App Engine); le Python App Engine équipe n'a cependant l'avantage d'avoir à bord de Guido van Rossum, l'inventeur de Python et un incroyablement forte ingénieur.
En termes de flexibilité, le moteur Java, comme déjà mentionné, ne vous offrons la possibilité de l'exécution du bytecode JVM faites par les différentes langues, et pas seulement Java -- si vous êtes dans un langage multi-boutique qui est assez grand et positif. Vice versa, si vous détestez en Javascript mais doit exécuter du code dans le navigateur de l'utilisateur, de Java GWT (générer le Javascript pour vous à partir de votre Java-le niveau de codage) est beaucoup plus riche et plus avancés que Python-côté de remplacement (dans la pratique, si vous choisissez de Python, vous serez l'écriture de certains JS-vous pour cette fin, alors que si vous choisissez Java GWT est utilisable alternative si vous détestez l'écriture JS).
En termes de bibliothèques, il est à peu près un lavage -- la JVM est assez restreint (pas de fils, pas de classe personnalisée chargeurs, pas de JNI, pas de relationnel) de nuire à la simple réutilisation de l'existant bibliothèques Java autant, ou plus, que les bibliothèques Python sont de même entravée par les restrictions semblables sur l'exécution Python.
En termes de performances, je pense que c'est un lavage, si vous devez un benchmark sur des tâches de votre propre, ne comptez pas sur les performances de très optimisé JIT basé sur la JVM implémentations de l'actualisation de leur grand temps de démarrage et de l'empreinte mémoire, parce que l'app engine environnement est très différent (les coûts de démarrage sera versée souvent, comme des instances de votre application sont démarrés, arrêtés déplacé à différents hôtes, etc, tous les trasparently à vous -- de tels événements sont généralement beaucoup moins cher avec Python environnements d'exécution qu'avec les machines virtuelles).
Le XPath/XSLT situation (à euphémismes...) n'est pas exactement parfait de chaque côté, soupir, mais je pense que c'est peut être un peu moins mauvais dans la JVM (où, apparemment, d'importants sous-ensembles de Saxon peut être fait pour courir, avec un peu de soin). Je pense qu'il vaut la peine de l'ouverture de questions sur l' Appengine Questions de page avec XPath et XSLT dans leurs titres, maintenant il y a seulement des questions demandant des bibliothèques spécifiques, et c'est myope: je ne sais pas vraiment COMMENT une bonne XPath/XSLT est mis en œuvre, pour Python et/ou Java, tant que j'arrive à l'utiliser. (Bibliothèques spécifiques peuvent faciliter la migration de code existant, mais c'est moins important que d'être en mesure d'effectuer des tâches telles que la "appliquer rapidement de transformation XSLT" en QUELQUE sorte!-). Je sais que je serais étoiles à une telle question, si bien formulé (en particulier dans une langue de manière indépendante).
Dernier mais non le moindre: n'oubliez pas que vous pouvez avoir différentes versions de votre application (à l'aide de la même banque de données) certaines sont mises en œuvre avec le runtime de Python, certains avec Java runtime, et vous pouvez accéder à des versions qui diffèrent du "défaut/active" explicite Url. Vous pouvez donc avoir à la fois le Python et le code Java (dans les différentes versions de votre application) d'utiliser et de modifier de la même banque de données, de vous accorder encore plus de souplesse (si seulement on aura le "gentil" URL de la forme foobar.appspot.com -ce qui est probablement important seulement pour l'accès par les utilisateurs interactifs sur les navigateurs, j'imagine;-).
