[Zope-dev] Re: [Zope] ANN: Python Methods 0.1.7 up and over to DC

Phillip J. Eby pje@telecommunity.com
Mon, 13 Dec 1999 17:14:15 -0500


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.