On 12/19/05, zope-request@zope.org <zope-request@zope.org> wrote:

Send Zope mailing list submissions to
       zope@zope.org

To subscribe or unsubscribe via the World Wide Web, visit
       http://mail.zope.org/mailman/listinfo/zope
or, via email, send a message with subject or body 'help' to
       zope-request@zope.org

You can reach the person managing the list at
       zope-owner@zope.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Zope digest..."

Today's Topics:

  1. Re: Zope Persistence (was: XML-RPC within ZOPE) (Lennart Regebro)
  2. Re: Zope Persistence (was: XML-RPC within ZOPE) (Lennart Regebro)
  3. zyncer 0.7.0? (David H)
  4. Re: zyncer 0.7.0? (David H)
  5. RE: zopectl or runzope just won't start zope (Russell Winter)
  6. Re: Zope Persistence (was: XML-RPC within ZOPE) (Jan-Ole Esleben)
  7. Re: zope-2.9 r40780 make install doesn't finish,  files
     missing from bin (Sascha Ottolski)
  8. Re: Zope Persistence (was: XML-RPC within ZOPE) (Lennart Regebro)
  9. Re: Zope Persistence (was: XML-RPC within ZOPE) (Jan-Ole Esleben)

----------------------------------------------------------------------

Message: 1
Date: Sun, 18 Dec 2005 01:30:39 +0100
From: Lennart Regebro <regebro@gmail.com >
Subject: Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)
To: Jan-Ole Esleben <esleben@gmail.com>
Cc: zope user list < zope@zope.org>
Message-ID:
       <319e029f0512171630s3921efdaseb54be4c12281480@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On 12/17/05, Jan-Ole Esleben <esleben@gmail.com> wrote:
> To simplify, in ZOPE, for any given product, during a
> transaction the product is effectively locked.

This statement is incorrect.

> So if I have, say, a
> list field that contains some data and a dictionary field that
> contains some other data, and the "internal" call changes the dict
> while the original call changes the list, that breaks the transaction,
> while in usual situation in a database, nothing would break.

If you use all non-persistent aware dicts and lists, yes. Using only
dicts and lists is suboptimal in most OO-languages, and that goes for
Python too. It is correct that with Zope, the negative impact of that
type of pre'ogramming-style is increased. This is however simply
solved by not doing that type of suboptimization, and instead using
persistant-aware objects.

> No. It does happen, and it _did_ happen in my original problem. Zope
> doesn't even care if anything actually changes, it just considers an
> object changed that set self._p_changed=1.

No, se above.

> > You just said "different sets of data". That reasonably must mean
> > different objects, unless you envision having huge objects with only
> > marginally connected sets of data all stored as attributes. And then
> > you have other problems. :-)
>
> No. An object usually binds together different sets of data (as in the
> above example - it has several fields, and that is true for almost any
> given object).

Yes. You said "different sets of data". That reasonably means
different objects. If it doesn't, yuo need to take a long hard look at
your object hierarchy.

> What you are saying is "don't program the ZOPE way",

No, in fact, I'm saying "program the Zope way", and I am beginning to
suspect that the problem is that you are not.

> and it would eventually lead to the conclusion that your product
> classes should not have any persistent data, which is the conclusion I
> have come to.

Then you didn't read what I said.

> > > That's my whole point. I think it is a very
> > > significant point nonetheless, because this is just an extreme case of
> > > what happens when you couple data and programs, and persistent classes
> > > are just that: application data inside program code.

> > Eh, no they aren't.
>
> Please don't just claim stuff.

You do.

> ZOPE has persistent classes. Persistent
> classes store data that in ordinary programs would not survive as
> long.

Not unless you tell them to. If you don't want the data stored, then
do not set it as an attribute on a persistent object.

> In ordinary systems, you would have to find a way to store the
> data and retrieve it, thus having a model that isn't implicit and
> entangled with your code.

What is implicit with it?

> Of course, you could do the same in ZOPE,
> but I addressed that above, and you could mess up ordinary code, but I
> think we're agreed that it is not something you should aim for (and I
> think I have made it clear why I do not believe it's as easy to mess
> up generic Python code in this way)

Well, sorry, it's not clear for me.

To summarize:

If you have two different processes changing the same set of data, you
will get confllict errors. You claim that you will not, but this is
false.

You claim that you can't control what a persistent class store. That is false.

You claim that the whole Zope product gets locked, that is false. It's
on a object-basis, not a product basis.

You claim that things get locked that shouldn't be locked in Zope. It
is not clear to me why you say that.

--
Lennart Regebro, Nuxeo     http://www.nuxeo.com/
CPS Content Management     http://www.cps-project.org/

------------------------------

Message: 2
Date: Sun, 18 Dec 2005 01:35:46 +0100
From: Lennart Regebro <regebro@gmail.com>
Subject: Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)
To: Jan-Ole Esleben <esleben@gmail.com >
Cc: Tino Wildenhain <tino@wildenhain.de>, zope user list
       <zope@zope.org>
Message-ID:
       < 319e029f0512171635n1bc72607ie198b44fbd8128e8@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On 12/17/05, Jan-Ole Esleben <esleben@gmail.com> wrote:
> You should be able to
> design stuff incrementally with a little experimentation along the way
> without constantly impending danger of it all crashing down on you.

I don't undertand why you say that this isn't possible in Zope.

> That's how Python works, and RoR etc. In ZOPE, we're back to the
> temptation to "just stuff a bunch of data into my object". And it's
> not even obvious that this is a problem, because everything is so
> tightly interdependent. It's exactly what Python usually avoids
> ("explicit is better than implicit").

I agree that there is too much implicitness in Zope 2. I don't agree
that persistance is a part of that. It isn't implicit at all. Maybe
it's not easy to understand, but it isn't particularily implicit, and
neither is it uncontrollable, as you seem to say.

--
Lennart Regebro, Nuxeo     http://www.nuxeo.com/
CPS Content Management     http://www.cps-project.org/

------------------------------

Message: 3
Date: Sat, 17 Dec 2005 18:13:18 -0800
From: David H < bluepaul@earthlink.net>
Subject: [Zope] zyncer 0.7.0?
To: zope user list <zope@zope.org>
Message-ID: < 43A4C5BE.60402@earthlink.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi List,

I downloaded  zsyncer-0.7.0  and am having problems.  Its not working
for me and it no longer displays prompts for destination password and
user name when clicking its <edit> tab.   Anyone else seeing this?

More importantly, as a fall-back is there a version (0.6.1?) others
recommend?

All best,
David

------------------------------

Message: 4
Date: Sat, 17 Dec 2005 19:58:01 -0800
From: David H <bluepaul@earthlink.net>
Subject: Re: [Zope] zyncer 0.7.0?
To: Alan Milligan < alan@balclutha.org>
Cc: zope user list <zope@zope.org>
Message-ID: <43A4DE49.6090301@earthlink.net>
Content-Type: text/plain; charset="iso-8859-1"

Alan Milligan wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>David H wrote:
>
>
>>Hi List,
>>
>>I downloaded  zsyncer-0.7.0  and am having problems.  Its not working
>>for me and it no longer displays prompts for destination password and
>>user name when clicking its <edit> tab.   Anyone else seeing this?
>>
>>
>>
>You need to use extended url auth syntax:
>http://username:password@your.domain.com/bla ...
>
>This is because we can have multiple targets all with different
>passwords ...
>
>Alan
>
>
>
Alan,

Thanks for your response.  Apparently my <zope-instance>bin/zopectl stop
/ restart sequence was not working on my remote (zettai) instance.
I had to do a shutdown from the control panel and *then* a bin/zopectl
start worked just fine - and zyncer came up as it should. The install of
zsyncer 0.7.0 on my *localr* system was fine - hence the disconnect in
what I was seeing ...

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/zope/attachments/20051217/1a59bae7/attachment-0001.htm

------------------------------

Message: 5
Date: Sun, 18 Dec 2005 22:54:05 +1100
From: "Russell Winter" <rwinter@r2solutions.com.au>
Subject: RE: [Zope] zopectl or runzope just won't start zope
To: "'Qass'" <qassair@gmail.com>, <zope@zope.org>
Message-ID: < 00ed01c603c9$bf38d340$1e0a0a0a@WinterRGM>
Content-Type: text/plain;       charset="us-ascii"

Not that I am any real guru on this, however, I am still learning myself, my
2c worth....

The error output suggests that Zope is installed on a network share of some
sort ...

File
"/network/share/home/sra/Zope-2.8.4-final/lib/python/Zope2/Startup/__init__.
py",
line 24, in ?

Are the permissions or effective user correct for the appropriate
filesystems and files.?

If you installed the binaries as root, but are running Zope as another user,
you will need to assign either that effective user to the root group, or
potentially less hazardous, security wise, assign the correct effective user
group rights to the filesystem area, including the network share.

If you have not assigned an effective user, or ran mkzopeinstance as root,
then you may see these type of errors when trying to run Zope as another
user without the correct permissions. Or when running as root, when
effective user permissions are assigned elsewhere.

Russ

-----Original Message-----
From: zope-bounces@zope.org [mailto:zope-bounces@zope.org] On Behalf Of Qass
Sent: Thursday, December 15, 2005 5:13 AM
To: zope@zope.org
Subject: [Zope] zopectl or runzope just won't start zope

Hi:

I'm new to zope and yesterday installed zope 2.8.4 on a linux system running
python 2.3.5 Having followed installation instructions I got to the point of
'zopectl start' and got the following error message while trying both
'runzope' and 'zopectl'.

I've tried installing different versions of Zope and get the same error
(error absent with Zope 3). At one point, Zope did start (I moved it to a
different port) but when I tried installing Plone in the Products directory
of the zope instance, the 'Plone Site' did not show up in the drop down menu
on the right hand side of the ZMI. Which is why I decided to reinstall and
have been getting errors since. I haven't messed around with the Python
installation at all.

In this latest install I ran 'make instance' intead of 'make install'
just to see if I would get the same error as I did yesterday when I had an
instance of Zope running and I did.

Any help in trying to fix this would be highly appreciated. I've tried
changing PYTHONPATH in the zopectl file but that just leads to more and more
errors.

Traceback (most recent call last):
File "/blah//Zope- 2.8.4-final/lib/python/Zope2/Startup/run.py", line 56,
in ?
   run()
File "/blah/Zope-2.8.4-final/lib/python/Zope2/Startup/run.py", line 17, in
run
   import Zope2.Startup
File "/blah/Zope- 2.8.4-final/lib/python/Zope2/__init__.py", line 60, in ?
   from Zope2.Startup.run import configure
File
"/network/share/home/sra/Zope-2.8.4-final/lib/python/Zope2/Startup/__init__.
py",
line 24, in ?
   import ZConfig
File "/blah/Zope-2.8.4-final/lib/python/ZConfig/__init__.py", line 21, in
?
   from ZConfig.loader import loadConfig, loadConfigFile
File "/blah/Zope-2.8.4-final/lib/python/ZConfig/loader.py", line 23, in ?
   import ZConfig.datatypes
File "/blah/Zope-2.8.4-final/lib/python/ZConfig/datatypes.py", line 19, in
?
   import datetime
File "/blah/Zope-2.8.4-final/lib/python/DateTime/__init__.py", line 13, in
?
   from DateTime import DateTime
File "/blah/Zope-2.8.4-final/lib/python/DateTime/DateTime.py", line 21, in
?
   from datetime import datetime
File "/blah/Zope-2.8.4-final/lib/python/DateTime/DateTime.py", line 21, in
?
   from datetime import datetime
ImportError: cannot import name datetime

Thank you very much for your help.

Qass
_______________________________________________
Zope maillist  -   Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )

------------------------------

Message: 6
Date: Sun, 18 Dec 2005 13:45:48 +0100
From: Jan-Ole Esleben <esleben@gmail.com>
Subject: Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)
To: Lennart Regebro < regebro@gmail.com>
Cc: zope user list <zope@zope.org>
Message-ID: <3756d9750512180445u1c47cdccl@mail.gmail.com >
Content-Type: text/plain; charset=ISO-8859-1

> > To simplify, in ZOPE, for any given product, during a
> > transaction the product is effectively locked.
> This statement is incorrect.

You're right. It should be "during any transaction where there are
potential changes to the object". And I agree, it's actually a lot
more complicated than I'd thouht at first. What I describe can happen,
but it happens under rather magical circumstances. I have an example
where it actually happens; this is code from a product that is
instantiated twice, one of those instances called TPCDest, the other
TestPChanged; the method called directly is " TestPChanged.test()":

security.declareProtected("Use TestPChanged", "test_internal")
def test_internal(self, args=None, args2=None):
   "Called by test via XML-RPC"
   if args2:
       self.a.append(1)
   self._p_changed = 1
   if not args:
       import xmlrpclib
       s = xmlrpclib.ServerProxy("http://USER:PASSWORD@localhost:8080/ ",
           allow_none=True)
       s.TestPChanged.test_internal(1)
   return self.a

security.declareProtected("Use TestPChanged", "test")
def test(self, args2=None):
   "Called directly via ZOPE"
   if args2:
       self.a.append(1)
   self._p_changed = 1
   import xmlrpclib
   s = xmlrpclib.ServerProxy("http://USER:PASSWORD@localhost:8080/",
       allow_none=True)
   return s.TPCDest.test_internal()

Zope obviously looks at the code, because if you remove the "if args2"
(which is _never_ true), then a ConflictError happens.

Maybe I'm stupid, but could someone point out _where_ exactly I am?

> > No. It does happen, and it _did_ happen in my original problem. Zope
> > doesn't even care if anything actually changes, it just considers an
> > object changed that set self._p_changed=1.
> No, se above.

You're right that it doesn't always, but see my example.

> Yes. You said "different sets of data". That reasonably means
> different objects. If it doesn't, yuo need to take a long hard look at
> your object hierarchy.

Simply not true. What if I have a field titles (that is a hash of
titles to Book objects)
and a field comments (that is an array of comments on the library)? Is
that so obviously
not a sane example?

> > > > That's my whole point. I think it is a very
> > > > significant point nonetheless, because this is just an extreme case of
> > > > what happens when you couple data and programs, and persistent classes
> > > > are just that: application data inside program code.
> > > Eh, no they aren't.
> > Please don't just claim stuff.
> You do.

I don't. I at least try to give reasons wherever I make a statement
that could be challenged.

> > In ordinary systems, you would have to find a way to store the
> > data and retrieve it, thus having a model that isn't implicit and
> > entangled with your code.
> What is implicit with it?

See the example for some major implicitness. It's also implicit
because you have no control over what a transaction considers a
tainted object. (You have no real control over the transaction).

> If you have two different processes changing the same set of data, you
> will get confllict errors. You claim that you will not, but this is
> false.

I am explicitly talking about changing different sets of data within
the same object. You noted that above yourself.

> You claim that you can't control what a persistent class store. That is false.

I don't. I say that if I want to avoid such problems as I describe
altogether, I cannot store anything in a persistent class and thus
lose most of what makes ZOPE so interesting.

> You claim that the whole Zope product gets locked, that is false. It's
> on a object-basis, not a product basis.

I never said that, or at least I didn't mean it. If it sounded like
that, I apologize (maybe I used Product metonymically for instance
somewhere, which would not be a good idea, I agree).

> You claim that things get locked that shouldn't be locked in Zope. It
> is not clear to me why you say that.

See the example.

Ole

------------------------------

Message: 7
Date: Sun, 18 Dec 2005 15:32:40 +0100
From: Sascha Ottolski <sascha.ottolski@gallileus.de >
Subject: Re: [Zope] zope-2.9 r40780 make install doesn't finish,        files
       missing from bin
To: zope@zope.org
Cc: Jeff Kowalczyk < jtk@yahoo.com>
Message-ID: <200512181532.41103.sascha.ottolski@gallileus.de>
Content-Type: text/plain;  charset="iso-8859-15"

Am Mittwoch, 14. Dezember 2005 21:11 schrieb Jeff Kowalczyk:
> I'm having some trouble with the 'make install' stage of Zope-2.9 svn.

Hi Jeff,

just stumbled over the same problem. By chance, we figured out how to do it:
you need to "make sdist" beforehand, which creates a tarball for you, which
in turn you must use to perform the regular install. "make sdist" needs
"zpkg", which is found at http://svn.zope.org/zpkgtools/; don't know how to
install it, so we just changed the path in the makefile to point to the right
place, in our case

       ZPKG=/mnt/source/svn/svn.zope.org/zpkgtools/bin/zpkg

Hope that helps,

Sascha

--
Gallileus - the power of knowledge

Gallileus GmbH                   http://www.gallileus.info/

Pintschstra�e 16                  fon +49-(0)30-41 93 43 43
10249 Berlin                      fax +49-(0)30-41 93 43 45
Germany

------------------------------

Message: 8
Date: Sun, 18 Dec 2005 17:00:22 +0100
From: Lennart Regebro < regebro@gmail.com>
Subject: Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)
To: Jan-Ole Esleben <esleben@gmail.com>
Cc: zope user list < zope@zope.org>
Message-ID:
       <319e029f0512180800gb6d7fa8hac21ad01c8d3c2a0@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On 12/18/05, Jan-Ole Esleben <esleben@gmail.com> wrote:
> > > To simplify, in ZOPE, for any given product, during a
> > > transaction the product is effectively locked.
> > This statement is incorrect.
>
> You're right. It should be "during any transaction where there are
> potential changes to the object".

No, this statement is still correct. Replace "product" with "object"
and you are right.

> And I agree, it's actually a lot more complicated than I'd thouht at first.

Or simpler. ;-)

> but it happens under rather magical circumstances. I have an example
> where it actually happens; this is code from a product that is
> instantiated twice, one of those instances called TPCDest, the other
> TestPChanged; the method called directly is "TestPChanged.test()":
>
>   security.declareProtected("Use TestPChanged", "test_internal")
>   def test_internal(self, args=None, args2=None):
>     "Called by test via XML-RPC"
>     if args2:
>         self.a.append(1)
>     self._p_changed = 1
>     if not args:
>         import xmlrpclib
>         s = xmlrpclib.ServerProxy("http://USER:PASSWORD@localhost:8080/",
>             allow_none=True)
>         s.TestPChanged.test_internal(1)
>     return self.a
>
>   security.declareProtected("Use TestPChanged", "test")
>   def test(self, args2=None):
>     "Called directly via ZOPE"
>     if args2:
>         self.a.append(1)
>     self._p_changed = 1
>     import xmlrpclib
>     s = xmlrpclib.ServerProxy("http://USER:PASSWORD@localhost:8080/ ",
>         allow_none=True)
>     return s.TPCDest.test_internal()
>
> Zope obviously looks at the code, because if you remove the "if args2"
> (which is _never_ true), then a ConflictError happens.
>
> Maybe I'm stupid, but could someone point out _where_ exactly I am?

I don't understand the question. I would like to point out that you
set self._p_changed even when you don't change anything. :-)

It seems to me that you say that if you process calls test and another
calls test_internal, you get a conflict error. This is correct, and as
noted before, that code would create a conflict in any type of
environment. If you have two processes trying to modify the same
dataset, which is what your example seems to do, then you get a
conflict.

What you claim, is that if you have two processes in Zope change two
different datasets, you get a conflict. That statement is still false.

> > Yes. You said "different sets of data". That reasonably means
> > different objects. If it doesn't, yuo need to take a long hard look at
> > your object hierarchy.
>
> Simply not true. What if I have a field titles (that is a hash of
> titles to Book objects)
> and a field comments (that is an array of comments on the library)? Is
> that so obviously
> not a sane example?

Yes, sorry, having non-persistent aware dictionaries or arrays, and
then complaining that you have problems with persitency...

> > > In ordinary systems, you would have to find a way to store the
> > > data and retrieve it, thus having a model that isn't implicit and
> > > entangled with your code.
> >
> > What is implicit with it?
>
> See the example for some major implicitness.

What is implicit with it?

> It's also implicit
> because you have no control over what a transaction considers a
> tainted object. (You have no real control over the transaction).

Thats still not true.

> I am explicitly talking about changing different sets of data within
> the same object. You noted that above yourself.

Then these different sets should be different objects, and the object
should be an object container: Problem solved.

> > You claim that you can't control what a persistent class store. That is false.
>
> I don't. I say that if I want to avoid such problems as I describe
> altogether, I cannot store anything in a persistent class and thus
> lose most of what makes ZOPE so interesting.

This is still not correct.

> > You claim that things get locked that shouldn't be locked in Zope. It
> > is not clear to me why you say that.
>
> See the example.

I don't see how the example examplifies this.

It is obvious to me that you have misunderstood something. I don't
know what yet, though.

--
Lennart Regebro, Nuxeo     http://www.nuxeo.com/
CPS Content Management     http://www.cps-project.org/

------------------------------

Message: 9
Date: Sun, 18 Dec 2005 17:25:15 +0100
From: Jan-Ole Esleben <esleben@gmail.com>
Subject: Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)
To: Lennart Regebro < regebro@gmail.com>
Cc: zope user list <zope@zope.org>
Message-ID: <3756d9750512180825u35fd6eb9o@mail.gmail.com >
Content-Type: text/plain; charset=ISO-8859-1

> > but it happens under rather magical circumstances.

That's my problem. Can you, from the ZOPE documentation, predict that
the example below will cause a ConflictError? It doesn't if you alter
it only slightly! Please try!

> >   security.declareProtected("Use TestPChanged", "test_internal")
> >   def test_internal(self, args=None, args2=None):
> >     "Called by test via XML-RPC"
> >     if args2:
> >         self.a.append(1)
> >     self._p_changed = 1
> >     if not args:
> >         import xmlrpclib
> >         s = xmlrpclib.ServerProxy(" http://USER:PASSWORD@localhost:8080/",
> >             allow_none=True)
> >         s.TestPChanged.test_internal(1)
> >     return self.a
> >
> >   security.declareProtected("Use TestPChanged", "test")
> >   def test(self, args2=None):
> >     "Called directly via ZOPE"
> >     if args2:
> >         self.a.append(1)
> >     self._p_changed = 1
> >     import xmlrpclib
> >     s = xmlrpclib.ServerProxy("http://USER:PASSWORD@localhost:8080/ ",
> >         allow_none=True)
> >     return s.TPCDest.test_internal()

> I don't understand the question. I would like to point out that you
> set self._p_changed even when you don't change anything. :-)

I know. This is just example code. Just imagine that both methods
change completely unrelated sets of data in addition to not changing
self.a.

> It seems to me that you say that if you process calls test and another
> calls test_internal, you get a conflict error.

It doesn't really in most cases. And of course I can see now where it
does in this instance, but this is based on Zope looking at the code,
determining that self.a is changed before the _p_changed, and marking
the object tainted because of that.

> This is correct, and as
> noted before, that code would create a conflict in any type of
> environment. If you have two processes trying to modify the same
> dataset, which is what your example seems to do, then you get a
> conflict.
> What you claim, is that if you have two processes in Zope change two
> different datasets, you get a conflict. That statement is still false.

Actually, I don't think we're getting anywhere with this same
dataset/different dataset distinction. It wouldn't happen in a
database using application because there would be no transaction for
"self.a ". You see, nothing happens to it, so why would there be one?
This only happens when you mix your data with your code and have
implicit transactions handled by the server.

> Yes, sorry, having non-persistent aware dictionaries or arrays, and
> then complaining that you have problems with persitency...

But that's part of my point: I need to go out of my way to circumvent
Python, and I need to be really careful, because using dicts and lists
might still work. Nothing is enforced, and where it breaks is hard to
predict.

> > See the example for some major implicitness.
> What is implicit with it?

I explained this above. Transaction handling in Zope (someone else
pointed that out in this thread), Zope looking at the code to
determine that self.a has changed (which isn't really documented
anywhere obvious).

> > > You claim that things get locked that shouldn't be locked in Zope. It
> > > is not clear to me why you say that.
> > See the example.
> I don't see how the example examplifies this.

I have tried to make it a little clearer in this message.

> It is obvious to me that you have misunderstood something. I don't
> know what yet, though.

I think we might be misunderstanding each other because we both place
different value on implicitness and explicit design of data inside
code. I am mostly talking about what is, pragmatically, good
programming and a supportive environment.

Ole

------------------------------

_______________________________________________
Zope maillist  -  Zope@zope.org

End of Zope Digest, Vol 19, Issue 24
************************************