Hash: SHA1

Marius Gedminas wrote:
> On Mon, May 21, 2007 at 12:21:42PM -0400, Tres Seaver wrote:
>> Reinoud van Leeuwen wrote:
>>> On Mon, May 21, 2007 at 10:39:22AM -0400, Fred Drake wrote:
>>> As a developer it might be a good idea to have different installed pythons 
>>> in different environments to be sure that some modules (or python itself) 
>>> meet different requirements. 
>>> But as system maintainer I like to keep things simple. I do not want 
>>> similar trees of python installations all over the place if it can 
>>> be avoided. 
>> Just as with Java-based applications:  if the server's job includes
>> running Zope, then installing a separate Python interpreter is a pretty
>> low cost, with the following benefits:
>>  - You don't risk breaking your production Zope application in a
>>    distro-mandated upgrade to Python (e.g., Fedora 7 puts Python 2.5
>>    into /usr/bin/python).
> That's probably the best reason.  I ran away from Debian's Zope 2.x
> packages because they made upgrades painful.
>>  - You may not want to pay the cost of a Python optimized for desktop
>>    applications (UCS-4, anyone?)
> Do you have any numbers?  How much memory of a typical Zope 3 app is
> taken by Unicode strings?  (I'm not trying to invalidate your argument,
> I'm genuinely curious.)

No hard numbers, except a vague recollection of shock at the difference
in two appservers running the same application, where one was running
using a UCS-4 interpreter.  Given that pretty much *all* ZPT rendering
these days involves Unicode manipulation, lots of the "transient" memory
used while rendering a page (as opposed to the ZODB cache) is
potentially affected.

>>  - You may need to patch Python to work around a bug which is only
>>    problemnatic for long-running Python instances (e.g., the
>>    longstanding cgi.FieldStorage DoS problem).
> I don't think that's a good example.  I'd rather patch Zope in this
> particular case.

De gustibus, I guess.  Patching Python to work around issues which
affect your own application, but where the patch may languish in the SF
tracker for more than a year seems reasonable to me.   #112549 comes to
mind, for instance:  although reported against Python 2.3 while 2.3 was
still in maintenance, the fix never did make it into a 2.3 release, and
missed three third-dot revisions on the 2.4 side.

>>  - You can create a repeatable environment for testing each deployed
>>    application, even where those applications are running on boxes
>>    with different OS / distro-supplied Pythons.
> There's still a point where you stop, right?  You don't have a
> self-compiled libc and a self-compiled C compiler to make sure your
> self-compiled Pythons are really identical?

I don't go that far (yet ;), but I often do end up building other
non-Zope components:

  - libxml2/lxml, for instance, because the OS-provided one has
    typically been too old, and because getting the Python wrappers
    built any other way is a nightmare

  - postgres, because I want to use Python as a stored procedure

  - Squid3 for ESI.

  - (hypothetically) Apache + mod_python, because it hard-wires the
    location of the Python iterpreter / DLLs.

The end result is that we can develop on laptops (Linux or Mac) and
deploy to production boxes (various Linux flavors, FreeBSD) with a fair
amount of confidence that the pieces all work as expected;  the
platform-specific bits all get manaaged as part of the buildout libraries.

- --
Tres Seaver          +1 540-429-0999          [EMAIL PROTECTED]
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to