[Zope3-dev] Re: Zope 3 Packages vs Python Packages

[Jon Whitener]

At 1/17/03 11:23 AM +0100, Paul Everitt wrote:
>1) 95% of the people in Zopeland that encounter the thing currently being discussed will be average schmoes.  They will *not* know or care about the fine semantic details of Python packages.

Hey, that's me! (Although, I prefer "schlemiel".)  I don't know the differences between Python packages and Zope 3 packages, but according to Paul in an eariler post, it may matter to me eventually:

At 1/15/03 11:38 AM +0100, Paul Everitt wrote in
"[Zope3-dev] Re: IMPORTANT RFS: Through the Web Site Development":
>Jon Whitener wrote:
>>The use (let alone creation) of products / packages is minimal for
>>me: a MailHost here, an ExternalEditor there, and I'm happy.  The
>>obvious emphasis on package management for Zope 3 doesn't mean a
>>whole lot to me.  
[...]

>I think there's an aspect missing from this, though.  Here's why it *is* important to you, IMO.

>I'm eager to see a Zope 3 world where others do your work for you.  They create interesting things that you can install and make small changes to.  
[...]

>While you might not be someone that adapts and redistributes, you'll be a beneficiary of package management.  And this will require you to see a package you've downloaded and find out what it can do.

>--Paul

My point is that if the average schlemiel will likely work with packages, then it may indeed be important to maintain a consistent differentiation between Python packages and Zope 3 packages.  Bear in mind that many earnest Zope newbies are also (almost by definition) earnest Python newbies as well.  If Zope is their entrance into Python (as it is with me), it's sometimes hard to figure out where one ends and the other begins.

In my ignorance, I do not know whether the "fine semantic" differences between Python packages and Zope 3 packages are so rarefied that only the most advanced Zope developers would ever need to know them.  But even if that is the case, it seems smart to maintain a verbal separation, even if that only entails calling Zope packages "Zope packages" (consistently).

If there is any one thing that many Zope newbies share, it's a frustration with Zope documentation.  To risk adding to that is a bad choice, because if it can cause confusion, it will.

>2) Inventing a new, unfamiliar term to avoid mental-collusion for the 5% of insiders will help ensure we don't have to worry too much about the 95%'ers. :)  ("Bundle, how cute, where did they come up with *that* word?")

(I'm not sure how the irony is intended here, but I'll go ahead anyway...)

If there is a difference between Python packages and Zope 3 packages, it should be reflected in the language somehow.  People coming to Zope are already learning *so much* that is new (especially if they have no Python background), that any single term will not bother them if it helps their understanding at all (at first, or in the future when they're developers).

>3) Let's start thinking about how Zope 3 will portray itself to people that aren't on zope3-dev.

Ideally, it will portray itself as accessible, consistent, and clearly understandable.

>--Paul

If you don't like bundle, I'm willing to license zackage(sm) on reasonable terms.  I also own egakcap(sm) which just rolls off the tongue. :P


Jon Whitener
Detroit Michigan USA