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

[Alexander Staubo]

> From: 'Martijn Faassen' [mailto:faassen@vet.uu.nl]
> Sent: Thursday, March 09, 2000 1:15 PM
> To: Zope Mailing List (E-mail)
> Subject: Re: [Zope] Zope needs this (and Dynamo has it)
> 

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

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.

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

> I don't miss switch. Functions are first class objects, and 
> dictionaries
> can be used instead of switch when necessary. Also, good 
> object oriented
> design tends to kill switch statements anyway.

I remember sitting down with Python for the first time create a simple
CGI type thing, and found that I could just do

  def DoSomething(): ...
  def DoSomethingElse(): ...

  DoSomething(eval('Do' + Args['cmd']))

and then call up the CGI using a query string such as
/cgi-bin/foo.py?cmd=Something. Wonderful, and better than any kind of
RTTI.

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

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

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. 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.
 
> [snip code generator extension idea]
> 
> Something like that would definitely be neat. The hard part would be
> in the translation process, of course. The other part is in the
> interfacing with regular Python; do you allow your translated function
> to refer to other Python objects? If you do, you're opening a can of
> worms. If you don't, then it starts to look like the 'Swallow' subset
> of Python I proposed once; a strict subset of Python with 
> added full type
> annotations, which is translatable into C or native machine code.

I haven't thought it through. I just think it was potential. Why
shouldn't the translated function refer to other objects? The function
would essentially just constitute native calls to the Py* APIs -- in
effect, a translated function would summarize the runtime calls made by
the interpreter during normal execution. Therefore, non-translated
Python code could just as easily refer to translated code (within a
"translated module", which would be a special object), because the
translator module would construct the necessary proxy object to forward
external calls to the inner code. Or something. ;-)

> > It would be an interim solution for certain CPU-intensive 
> modules, in
> > anticipation of such built-in functionality in CPython 
> itself. Possibly.
> 
> If you're starting such a project I want to hear more about it!

I'll let you know. ;-)

-- 
Alexander Staubo         http://alex.mop.no/
The difference between theory and practice is that, in theory,
there is no difference between theory and practice.