[Zope-Perl] features.

[Chris McDonough]

Gisle et. al,

You may be wondering why I'm posting all these messages to the Zope-Perl
list lately. It's because I've been tasked by DC with determining how close
to production-ready Zope-Perl is.  From what I can see so far, it's very
close.  Somebody asked me how to pronounce "Gisle" the other day, I told
them I pronouce it "God."  :^)

Some potential issues....

1.  Requiring folks to manually marshal nonscalar Perl data into
    Python native datatypes in return expressions to get any
    real use out of them is sort of.. painful.  Although it's
    arguably more explicable in docs because there's not a
    lot of magic going on.  Does anybody have any opinions on
    whether this marshalling should be more transparent?  For
    example, it'd be nice to be able to "return %hash;" at the
    end of a restricted Perl method and have it marshalled
    into a Python dictionary for you for use in DTML.  I understand
    that doing this with mutable data is dangerous due to expectations
    that the data struct is mutable between languages, but
    the current behavior is to return a string rep of the hash,
    which is generally unhelpful.  Gisle made restricted Perl methods
    much more useful when he sent the patch to Zope.pm which exposed
    the Python::* marshalling routines, I wonder if this is enough?

2.  Why does this work in an unrestricted Perl Method but not in a
    restricted Perl method?

    args: self

    my @names;
    for ($self->{Control_Panel}->objectIds()) {
        push (@names, $_);
    }
    return Python::list(@names);

    (In an unrestricted Perl method, you need to pop $self off the arg
    stack when it comes in, but otherwise they're identical.)

    In a restricted Perl method, this fails with:

    Error Type: PerlError
    Error Value: Not a HASH reference at testreturn line 2.

    I'm sure this is probably a stupid question, but I don't care. :-)
    Pointers to docs on Perl indirection and OO notation accepted,
    particularly any that can help me understand this phenomena.

3.  Help screens for zoperl need to be added (I can do this).

4.  Docs for DBI_DA need to be written if we want to include it
    in zoperl (I can also do this).  What are the gotchas with
    DBI_DA right now?

5.  Restricted PMs probably want to use bindings like Python Scripts,
    so you get get to context, container, etc, as opposed to passing
    them on the args list.  If DC still has credit with Activestate,
    and Gisle has time, we can maybe hook him up with Evan Simpson
    so he can understand how to do this.

6.  We may want to consider a binary distribution for Windows users.
    That said, I'm very impressed that I could use nmake to compile
    pyperl on Windows!  I'm not sure of the relative importance of
    this.  I imagine we will not distribute Zope-Perl with the default
    Zope, as its functionality depends on potentially patched versions
    of Python and particular Perl versions.

7.  Relatedly, do we know of a stock
    Python/Perl combination that does not require patching of Python?
    I'm using Zope-Perl happily with AS Perl 623 and stock Python 1.5.2
    on Windows.  Are there particular configurations which require
    patching?  If we adopt Python 2.X, will we still potentially
    require that folks build their own patched Python?  It's not
    really clear from the docs under what configurations you need
    to patch.

8.  Understanding threading gotchas from a high level is desirable.
    Maybe a few FAQ entries should be concocted with example failure
    scenarios.

I may come up with more issues, but these are what I can think of so far.