[Zope] Zope needs this (and Dynamo has it)

[Alexander Staubo]

> From: 'Martijn Faassen' [mailto:faassen@vet.uu.nl]
> Sent: Sunday, March 12, 2000 12:11 AM
> To: Zope Mailing List (E-mail)
> Subject: Re: [Zope] Zope needs this (and Dynamo has it)
> 
> 
[snip]
> [snip explanation why open-source like collaboration is 
> harder for languages]
> 
> It's hard for language *design*, yes, but it's less hard when 
> you're doing
> language implementation (for instance a faster one), and it's 
> easier still
> when you're writing libraries and such. And it does happen 
> for language
> design as well -- the Python static type design is currently 
> being fleshed
> out (in bursts) by the types-SIG (though of course Guido does final
> approval about what goes into Python proper).

Indeed, but do I need to remind you that we're still at version 1.52?
:-)

And as for your argument that OSS boosts language implementation, true
in theory, but sitting down with a compiler and changing it, or building
a compiler from scratch, is a daunting and time-consuming task. I have,
certainly, thought about building a native-code compiler for Python. But
no time right now.

Your comments are well received. I hope I can put my own comments to
shame in the future by committing some of my resources to the Python
effort. As for the types-SIG, I've read through Guido's latest proposal,
and found it so-so; I have some comments about the syntax -- which IMHO
is heading in the right direction, but I feel it's still quite
unpolished, like the new "decl" keyword and the very odd, un-Pythonic
"->" operator. Other than that, it looks a lot like I had in mind
myself.

[Re: C++ extensions with Python]
> There are various tools out there for Python which do offer 
> this kind of
> functionality, though, I think? Check at the vaults of 
> parnassus sometime:
> http://www.vex.net/parnassus

Not sure which you mean. Found this one:
http://www.vex.net/parnassus/apyllo.py?i=52521115

> > Let me finish the last sentence first: I also have a 
> database-centric
> > Zope app that causing me headache. The ZODB is *way* too immature to
> > replace a database right now -- fine for the kind of stuff 
> that runs on
> > zope.org, not for us. We're actually looking at alternative 
> app servers
> > and solutions (such as hardwired C++ CGI code) right now. 
> It's a shame,
> > and I'm fighting it, but we might end up with something like Dynamo.
> 
> I'll repeat my question; why not use a relational database? Do you
> need an object database? How is the ZODB too immature?

Interestingly enough, I'm discussing this with Jon Udell on his Byte
newsgroups (go news.cmpnet.com). I'll quote something I wrote in this
discussion, slightly edited for clarity:

<quote>
I can't easily tell Zope that objects of type A refers to objects of 
type B (mutual relationships), and that objects of type B should not 
be deletable as long as an object of type A is referring to it 
(referential integrity). The only kind of relationship Zope knows 
about is containment, a parent-child relationship. There is simply no 
other way for an object to refer to another object.

Consider the case of news articles. Let's say articles should be able 
to hold multiple sections of text, as well as images. Assuming we use 
Z Classes and not Products, two solutions come to mind: Either (a) let 
an article be a descendant of Zope's folder or object manager 
classes, and thus contain any such sub-data as objects -- a design 
which currently is the most useful, but which has its shortcomings -- 
or (b) let sub-data exist as objects elsewhere in the ODB, and have 
string attributes on the article object that refer to their names, 
eg. an attribute "Illustrations" of type "lines" containing image IDs 
such as "mayor.jpg", "airplane.jpg" etc. This is obviously ugly -- 
for example, these image objects could be moved or removed and the 
article object would never know. As for dividing article texts into 
multiple sections (page 1, page 2 etc., with appropriate headings), 
this is obviously pretty simple with scheme (a), but in the case of 
(b), the text could exist in one large attribute, and some sort of 
page tagging system might be enforced -- or we could go all the way 
and do XML. So far, with these solutions, we'll survive. Cracks begin 
to show when we start thinking about organizing authors, 
publications, and document flow.

Zope doesn't provide a framework to solve this things. Equally worse 
is that the ZODB hierarchy is so easily polluted with things that 
don't belong there. You end up putting a lot of objects in the root 
folder because they're needed globally -- and anyone who has used 
Zope will tell you that a folder becomes unwieldy and disorganized 
when it grows past 20+ objects. (Case in point: Personally, several of 
my Zope sites have a root-level Utils folder containing oft-used 
External Methods, because they tend to pollute the whole namespace.)
Zope needs a multiple-root, "multihomed" hierarchy. Z Classes must
be able to exist anywhere, not just in the one Products hierarchy.
</quote> 

[Re: Python syntax issues]
> > I don't necessarily say they're _my_ problems, but some people think
> > they are, and that counts. I don't miss "switch" myself, 
> although I do
> > miss a kind of enumerated type.
> 
> Like this?
> 
> FOO, BAR, BAZ = range(3)
> 
> [snip neat example of the use of eval() in Python]

No, although that's a clever trick. Hey, do it again! :-)

What you cite above may mirror the effect of an enumerated type, but it
doesn't contain any meta-information about the type itself: That is,
FOO, BAR, BAZ are integers. They will fit into any integer expression
and can be passed to any function taking integer arguments. The function
won't balk if you pass a value from another "enumeration". Another
problem with the above is that there is no way to ask Python to
enumerate the values or names in the sequence, because its values are
part of the top-level namespace -- I don't like that kind of namespace
pollution.

Instead, perhaps, this:

  class Enum:
    def __init__(self, Value):
      self.Value = Value
    def __int__(self):
      return self.Value

  class DeadParrot(Enum):
    FOO, BAR, BAZ = range(3)

  def PetShop(P):
    if int(P) == DeadParrot.FOO:
      print 'It''s resting.'

  D = DeadParrot(DeadParrot.FOO)
  PetShop(D)

...But hardly elegant.

> > > I don't think you'll see protected members any time soon.
> > 
> > I think Zope's source code is one huge, glowing argument in 
> favour of
> > having protected members.
> 
> Why so? I myself think Zope's source is an argument for 
> explicit interfaces. :)

The same side of two different coins, I think. :-)

> > Tuples are immutable, dicts and lists are mutable. Why? 
> Because Guido
> > says so. Jon Udell, I think it was, has argued that tuples 
> are currently
> > a redundant element in the language. Why have two kinds of lists? It
> > just confuses people.
> 
> Well, tuples can be used as dictionary keys, lists cannot.

And that makes sense to you? I don't know the historical significance of
tuples in Python -- I know the mathematical meaning, but Python tuples
aren't quite it -- but it smells a lot like an interface that has been
fit to the size of the implementation. A lot like, coincidentally, a
procrustean bed. (Coincidentally because the term has popped up a lot
lately; see the Byte thread.)
 
> > A syntax for declaring the mutability of types would be helpful in
> > clearing out this mess. For example, you should be able to declare a
> > dict to be immutable when passed to a certain function call -- ie.,
> > forcing a copy.
> 
> Forcing a *copy*, implicitly? But Python works with reference 
> semantics
> only? It's be nice to have a way to declare stuff immutable, I think,
> but I'm not sure how often one would need to use it. There's something
> to say for knowing something's a tuple, instead of having a list and
> having to know whether it's immutable or not. Though perhaps that's
> not a big problem in practice.

I think the idea that mutability as a behaviour is distributed among
primitives is, frankly, a questionable design choice. ;-)

> > Python has no "out" parameter, only "in" parameters that
> > are mutable depending on the type of the object passed. The 
> syntax I'm
> > alluding to would effectively give you both "out" and "const"
> > parameters.

(No, it would not -- it would effectively give you both "out" and
*pass-by-value* parameters.)

> But that might result in a lot of incomprehensible code. I'm 
> not sure if 
> I'm in favor of having 'out' parameters anyway.

The alternative is returning dictionaries or tuples, is it not? Maybe
I'm not thinking in a Pythonic vein. Maybe

	A, B, C = GetABC()

is more immediately grokkable than

	GetABC(A, B, C)   # assuming these are "out" parameters

Well. Sure it is. Damn, I think you're right. ;-)

-- 
Alexander Staubo         http://alex.mop.no/
"`Ford, you're turning into a penguin. Stop it.'"
--Douglas Adams, _The Hitchhiker's Guide to the Galaxy_