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.