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

['Martijn Faassen']

Alexander Staubo wrote:
[snip me writing that open source does help with languages]
> 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.

But still people do change compilers! People have added garbage collecting
to the Python interpreter, list comprehensions, and there's the whole huge
stackless effort. I'm sure there are more examples in the past, for Python.
Without open source, this wouldn't have happened.

> I have,
> certainly, thought about building a native-code compiler for Python. But
> no time right now.

I've thought about it too, and no time either. Maybe we should get
together some time. :)

[snip tyepes-SIG
I agree that the syntax could use some polishing.

[extending Python easily with C++]
> Not sure which you mean. Found this one:
> http://www.vex.net/parnassus/apyllo.py?i=52521115

I didn't mean any in particular, I just knew they existed. :)
There's also a tool used to wrap the Qt interface in Python.

[snip description of efficiency problem with Zope]
> > 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:

[snip discussion]

That's indeed a shortcoming in Zope as it stands, but that's not an
efficiency problem, is it? A faster Python wouldn't solve it. :)

> [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! :-)

FOO, BAR, BAZ = range(3) 

:)

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

That's true, but please note that C's enum is used successfully and 
isn't checked either.

[snip experiments]

I agree it might be nice to have a more elegant way to deal with
enumerated types. Perhaps as a result of static type checking extensions?

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

Well, it makes sense to disallow mutable dictionary keys. You asked why
have two kinds of lists, I tried to give the answer. Lists and tuples have
been moving towards each other in recent Python versions, though; I believe
originally only tuples supported unpacking. If there was somekind of
mutability system in place that could replace tuples.

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

It's cute though, as immutable objects behave like pass by value objects
do (except those darn tuples again, if they contain something mutable like
a list or an instance). I think that's a neat idea. 

[snip discussion of grokkability]
> Well. Sure it is. Damn, I think you're right. ;-)

*grins*

Regards,

Martijn