Here's my take: When my bid was accepted to redesign the site I'm working on, I settled on Zope instead of PHP (it compiled without error.) I knew nothing about Python or Zope. Now I'm happily using Zope and I just got Learning Python. I'm not very far into it, but just learning some of the basics I'm starting to realize how close to the surface Python is. I would love to see Python Methods take over more of the "engine" behavior from DTML. I assume, however, that ngDTML would still include things like <dtml-in>, otherwise I'll pull my hair out. I also think there's some things that can/should be pushed elsewhere- REQUEST.set is a good example- I get a content-type for images, why not let me do that with other objects? Maybe the drop-down list of properties could be like the object-selection, so you could add new property types (content-type, tinytable...) Simultaneously, the last thing I want to see is for HTML to get imbedded in python. I used a Perl module where I built forms programmatically, and I don't want to go back to that. I've spent most of my time on this project getting out from under some developer who thought implementing HTML in javascript was a good idea. I'm also frustrated with things like TreeTag.py that imbed HTML into them, not allowing me to change their output to fit my fancy. I don't really have a problem with PythonMethods being scattered throuought my hierarchy: indeed, if they live with aquisition the same as everybody else, this could be quite useful. (as an aside, I'd like to be able to use factories like this, so that certain objects are only creatable at certain places in the hierarchy) Perhaps if DTML has a consistent method of dealing with things passed to/from npythonMethods, and a way of invoking them (dtml-call?), they would be more used. I know I stay as far away from the _ stuff as I can. If I have to use one of those _[blarg._['foo']] things, i copy it from someone else and hope that it works. It sure reminds me of something somebody called another language- "executable line noise". anyway, python seems to me to be a transparent enough language that there's no compelling need to obfuscate it for things it does well enough already. Plus, the "closer" python is in the upgrade path from content manager -> developer -> zope source contributor, the sooner you'll have more of the latter. wannabe zope hacker, -- Ethan "mindlace" Fremen you cannot abdicate responsibility for your ideology.