This is where we capture outstanding issues that need to be resolved for this project.

• Should the repackaging of External Methods be put into the scope of this project?

  Resolved

  The Product will include "Python Method (Unrestricted)", a revamped External Method replacement. The Product will be named "PythonMethods" (note the "s"), so that it can be installed alongside "PythonMethod" and "ExternalMethod" and allow for incremental transition to the new objects.

• What should be provided in StandardPythonMethodModule? This is reserved for stuff that isn't important enough to be a builtin, but important enough to be available through a simple "from Zope import foo".

  Jim

  Given the ability to import any module with security assertions, why is this needed?

  Evan

  I worry that there may be methods/classes/objects which are so useful in PythonMethods that everyone will want to use them in their Products/ZClasses/examples/etc, but which will require everyone to add a separate Product in order to access them. I want to be able to have a standard place to put such things that is part of Zope.

• How can Python Methods be given access to the power of DT_In?

  Jim

  I don't understand this. What power is being refered to here?

  Evan

  The ability to filter out elements we aren't authorized to use. Easy sorting, batching, and statistics. That stuff.

• The usability of the current interface, (i.e. the separation of Id, parameters, and function body; the Bindings Tab; FTP access) is untested and has not been compared to any alternatives. There is extensive discussion at InterfaceIssueDiscussion.

• UsuabilityIssues should probably be discussed a little more.