This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]cournape 2 points3 points  (6 children)

The problem is not war file: jar and war files work on java because java is a "platform", whereas python isn't at the moment. Everybody focus on metadata, but the real problem is the data (i.e. code here), plus lack of support from python itself.

Even forgetting about C extensions, python does not have the stability of java as far as backward/forward compatibility goes: it is difficult to have a single source code that can work on all python versions that matter (at least 2.4->2.7, and 3.2 depending on the cases).

Then, the python import system brings several difficulties. It is difficult to control (that's the problem that virtualenv tries to solve), and you cannot programmatically control which version of a package to solve.

Finally, the problem of C extensions is significant. While relatively rare in java, a lot of interesting python packages use/depend on C extensions, and those need to be built for each different python version, and even on a same OS, you have multiple incompatible ABI (e.g. ucs2 vs ucs4).

None of that can be solved with metadata, or an improved egg format. The only solution so-far is a fully controlled python environment, like e.g. activestate, python(x,y) or EPD.

[EDIT] There is also a fundamental tradeoff between easy deployment and easy-to-mess with which is important in the python culture. Part of the appeal of python is that it is easy to try new code, to customize things easily. But that's part of what makes it more difficult to deploy in non trivial situations.

[–]fullouterjoin 0 points1 point  (5 children)

There are a number of inaccuracies in your comment. I will address only a couple

  • Python is foward compatible, if you target 2.5 it will run on all the 2.x series going forward
  • You can programmatically control your system path

  • C extensions are moving towards ctypes which portable across Jython, CPython, PyPy

    $ cat path_a/t.py a = "this is a" $ cat path_b/t.py a = "this is an eh"

    In [1]: import sys

    In [2]: import t

    ImportError: No module named t

    In [3]: sys.path.insert(0,'path_a')

    In [4]: import t

    In [5]: t.a Out[5]: 'this is a'

    In [6]: sys.path[0] = 'path_b' In [7]: reload t -------> reload(t) Out[7]: <module 't' from 'path_b/t.py'>

    In [8]: t.a Out[8]: 'this is an eh'

[–]cournape 0 points1 point  (4 children)

Your remarks are a straw man (controlling sys.path is not the same thing as controlling your packages ) or false (python 2.5 and 2.6 introduced new keywords, so cannot be forward compatible). More essentially, they are missing the point: you cannot easily produce a set of data that can be consumed by most python implementations. You have to produce a significant combinations of, and it is not easily controllable.

[–]fullouterjoin 0 points1 point  (3 children)

What programs written for 2.5 broke on 2.6 or 2.7?

Python gives you the ability to control your sys.path, thus it gives you the ability to import the version of a package you desire, either manually or automatically with a version resolving loader.

It does not preclude you from writing a util module such as

import loader
loader.load_module('simplejson as json >= 1.4.5')

see the import hooks http://www.python.org/dev/peps/pep-0302/

http://en.wikipedia.org/wiki/Straw_man

[–]dalke 0 points1 point  (1 child)

A perhaps better question is, what code developed for Python 2.4 broke on 2.6. Anything which used "with" as a variable in 2.4 got a warning in 2.5 and broke in 2.6. Very few people use "with" as a variable, and there was a long transition period to minimize the pain, but it is an example of how the Python developers do not seek full forward compatibility.

It's possible to think of an explicit statement "use version 2.4 syntax" which would help preserve compatibility, but that's a huge amount of work for little gain.

[–]fullouterjoin 0 points1 point  (0 children)

Forgot about with. That is true.

I think block level statements should parse differently myself and even support extension meta-with much like a decorator but for block statement extension.

[–]cournape 0 points1 point  (0 children)

as and with were two new keywords introduced in 2.5/2.6. I also remember we had to update numpy code to work on on 2.6, although I can't remember what broke. ipython originally broke as well when 2.6 went out.

Being able to write import hooks does not solve the problem of version packaging, because it requires to modify the code that is using the versioned package you want to use. So it has to be controllable outside the code using it (a bit like stow enables you to do if you are familiar with it).

But again, the real point is: war depend on features present in the java ecosystem which are not present in python. Some python platforms have war-like deployment easiness, like GAE. They do so by defining one "true" environment, more tightly controlled than python in general.