[Zope-Perl] features.

[Chris McDonough]

>       For
> >     example, it'd be nice to be able to "return %hash;" at the
>
> It would have to be "return \%hash;" otherwise the hash is expanded
> into a list of key/value pairs.  When I think of it, a Script(Perl)
> thingy is called in scalar context, which means that this actually
> returns a fractional string like "1/8".  Just yet another strange
> feature of perl.  Mainly useful as a boolean test to tell that the
> %hash contains elements.

Is it possible to specify that you want a value from a Perl function
returned in array context from a Perl Script thingy?  I don't even know that
this is desirable, but I see that it's possible by setting the __wantarray__
attr on the perlref object, but passing in __wantarray__=1 as an argument to
a perl doesn't appear to work (although I have absolutely no idea or
expectation that it should).

Regardless, there's a misleading failure with a "__wantarray__=1" kw
argument in the arg list:

Error Type: PerlError
Error Value: Can't declare scalar assignment in "my" at (eval 13) line 3,
near ") ="

for the script:

my %a = ();
return %a;

For the same script without __wantarray__=1 in the arglist, a null value is
returned, but no err is raised.

>
> >     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?
>
> We should find out what is the "correct" fix to make "perl ref"
> objects do the sensible thing inside the Zope security machinery.

One "right thing" is to let folks set attrs on perl ref objects, so we can
do the Zopish thing with them and give them a
__allow_access_to_unprotected_subobjects__ attr.

We could alternately do this via a Python wrapper class for perl ref objects
in zoperl if we want to commit to keeping the C and Python stuff in sync.
This is an alternate "right thing".  This would also allow us to assert in
Python that the object implements a "DontCheckMeForSecurity" interface
(there is new interfaces stuff in Zope for 2.3), which is probably the
"real" right solution.  That the security policy currently depends on Python
typing for waiving security checks on an object is suboptimal in this case,
and declaring such an interface would allow us to partly move away from
depending on Python typing in an orderly fashion.

> getitem() like overloading is simply not provided for
> "Script(Perl,restricted)".  The only thing you can do with python
> objects here are getattr.

Bummer.  So basically if you want to do a getitem on a Python object in a
restricted Perl Script, you're currently out of luck because we can't expose
Python::getitem due to security constraints, right?

> The $self->Foo works because we provide a Python::Object::AUTOLOAD
> method that catch these calls and transforms them into a
> Python::getattr() call (with automatic Python::apply()) if the fetched
> attribute happens to be callable).

Just curious, why is the apply automatic?  Is autocall a Perl idiom?

> For restricted Script(Perl) we provide an alternative
> Python::Object::AUTOLOAD (the compartment_pyobject_AUTOLOAD function
> you find in zoperl/lib/perl/Zope.pm) that does the same but also
> invoke the Zope security machinery.
>
> The $self->{Foo} syntax works because we provide '%{}' (hash access)
> overloading in Python::Object.  For the safe compartments we don't try
> to set up something similar.  I think there might even be issues with
> getting it to work at all.  A workaround might be to simply export
> Python::getitem() to the compartment so that the example could be
> written like:
>
>    for (Python::getitem($self, "Control_Panel")->objectIds) {
>        ...
>    }
>
> and work in both places.

This breaks security.  :-(  Basically, any time getattr or getitem is called
on a Python object, we need to make sure that the returned object is either
a native Python datatype or, if it isn't, that the user making the call has
the appropriate roles to access the object.

> > 3.  Help screens for zoperl need to be added (I can do this).
>
> Nice.  I think it makes sense for DC to take over all GUI issues with
> the Perl* products.  Writing Zope products is probably something you
> do better than us.

I'll start CVS modules for zoperl and pyperl at DC based on beta4/6
respectively and send you any changes I make...

> > 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.
>
> I agree that this needs to happen, but I think it can wait until after
> 1.0.  If I have time or not depends on priorities outside my control
> here at ActiveState, so I can't really tell.

Alright, I'll let the execs figure this one out.

Thanks for all the other answers...

- C