At 11:47 PM 12/13/99 +0200, Itamar Shtull-Trauring wrote:
Moved to zope-dev.
"Phillip J. Eby" wrote:
At the risk of excessively critiquing such a young and exciting product, may I suggest that some care be taken w/respect to namespace issues in PythonMethods? That is, rather than adding things like "special_formats" and using special names like "traverse_subpath", couldn't we use import with a special module path? (E.g. "from _Zope.special_formats import html_quote".) Then, specials would not be a part of the common namespace.
This would be the only thing you can import in any case (no imports in PM), so how about just renaming traverse_subpath to _traverse_subpath and special_formats to _special_formats? That way there's no chance of namespace conflicts without adding an import.
It's not namespace conflicts I'm worried about, so much as namespace "pollution". Putting things in the global namespace means it'll be hard to subdivide future extensions. That's (one reason) why Python has modules and import in the first place. Putting more reserved words in PythonMethods just makes it less like Python and more like Perl, which is what we all (I assume) want to get away from with PythonMethods. As for no imports in PM, that's pretty straightforward to fix. We just need ImportModule objects, which can be placed in the acquisition hierarchy, and to which the Zope security permissions apply. PythonMethods can then interpret "import" by searching their acquisition hierarchy for an ImportModule of the correct name, and following a security check, extract the needed info. ImportModule objects could specify path or package info, or even export just a specified list of names. Indeed, ImportModules need not be Python modules at all, but just a way of providing things that can be "import"ed.