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_