[Zope-dev] Re: PythonLibraries Product

[Evan Simpson]

Seb Bacon wrote:
> So AFAICT it's a convenience which allows you (a) to keep related 
> functions together; and (b) to store local variables in a convenient 
> place.  It definitely sounds useful but also a lot of work for something 
> it's possible to manage without quite easily at the moment..?
> 
> Could you provide a brief summary of why this is better than a folder of 
> python scripts?  Perhaps a use case which illustrates the problems of 
> the current way of doing things?

It isn't *better* than a Folder of Scripts, it's *different* :-) I have 
two weak use-cases, a longstanding "I'm going to write that some day" 
itch, and some aesthetic arguments.

One of the more frequently stated complaints about ZPTs is that to 
properly remove non-presentation logic and ugly little Python 
expressions from a template, you either need a pile of little Scripts, 
or a single "controller" Script that precalculates everything and passes 
it to the template.  I've settled, fairly happily, on the second solution.

Both of these solutions suffer from the "two or more objects to 
accomplish one task" management problem.  I usually combine the objects 
in a dedicated Folder, which is still a bit awkward, and doesn't solve 
everything.  One drawback is that the individual components are all 
published, despite the fact that I only intend one of them to be 
web-addressable.  It would be very handy to attach the Scripts directly 
to the template, but the straightforward way of doing that means making 
the template a container, and opens a whole can of worms.  Instead, what 
if templates had a Library tab, and it worked with External Editor?  It 
would actually be easier to *just* write this, and not have independent 
Library objects, but generalizing this capability feels right to me.

 From an aesthetic viewpoint, a Library looks and works more like 
regular Python than a Script.  Even though a Library is not a "*.py" 
file, it uses a subset of that syntax, so dedicated editor modes will 
like it better.  Multi-line triple-quoted strings will not get extra 
spaces added to them.  The "##" header hack won't be necessary, so line 
numbers in External Editor will match error message line numbers.

On the other hand, Libraries don't support 'traverse_subpath', require 
an extra path step to address, and don't allow permission and proxy 
settings at individual function granularity.

Cheers,

Evan @ 4-am