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

['Martijn Faassen']

Alexander Staubo wrote:
> Pardon me for sending off another email in mid-stride. Damn cat :-)

No problem.

> 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?

> [snip]
> > > Python has plenty of problems, but they're tiny by 
> > comparison and imho
> > > they're mostly artifacts of Python's currently somewhat 
> > anemic syntax
> > > (eg., only two kinds of loops, no "switch", no protected members, no
> > > constants, no syntax for declaring mutability).
> > 
> > I suggest you go discuss these things on comp.lang.python. :)
> 
> 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]

> > I think the two loops are fine, though it would be nice to have the
> > current constructs to know about iterators. I believe Guido is
> > taking that into consideration. Also there's the list-comprehension
> > proposal which may help here. 
> 
> The list comprehension syntax is cute, but not, I think, so clever.
> Perhaps it'll prove to be a nice feature, even a successful one, but
> personally I doubt, even with the knowledge in the back of my head of
> how this stuff works, that I would instinctively grasp for a
> list-comprehension expression as naturally as I grab for, say, a "while"
> loop. My head is just not wired that way, and I think the syntax looks
> positively alien for Python -- it's not "pythonic".

I'm having some trouble with it too, but perhaps that's just not being
familiar with the concept yet. But at least it looks less horrid than
some map()s and such.

> > 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. :)

> > I'm not sure what you mean with syntax for declaring 
> > mutability, though
> > it sounds interesting.
> 
> I don't particularly take to the idea of a having
> mutability/immulatibility property burned into the type itself.
> 
> 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.

> 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.

> 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.

But that might result in a lot of incomprehensible code. I'm not sure if 
I'm in favor of having 'out' parameters anyway. constness as defined in
C++ is also tricky, as it infects code; everything that touches it
needs to be const-correct. Python tends to be less strict in this area.

[optimized statically typed modules calling classic python modules, why
is this tricky?]

Yes, it is doable but tricky in combination with static typing. See
the types-SIG for more info; I believe Guido has some messages on that.

Regards,

Martijn