Am 29.12.2008 um 19:20 schrieb Tres Seaver:
> As Jens noted, this change is for FSProperties and FSSQLMethods only.
Yep, and these aren't generally objects that need to be changed
frequently in the FS.
>> On another and only slightly related note: Tres, in September I seem
>> to remember you saying that the biggest stumbling block for moving to
>> Python 2.5 and beyond was support for RestrictedPython implements,
>> PythonScripts. If this is the case, do we need to add deprecating
>> PythonScripts/untrusted code to the roadmap?
> I don't have that appetite at the CMF level: I think much of the work
> has actually been done to ensure that RP works under Python 2.5+
> at the Zope level.
It's good to know that they will still work with Python 2.5. My own
introduction to Zope was heavily dependent upon combining
PythonScripts and PageTemplates and I'm currently seconded to a .NET
based CMS which has something remarkably similar: they are a very
useful way of encapsulating site-specific behaviour so it would be
nice to have them around in one form or other if the associated issues
(security, global validity, etc. can be resolved) otherwise some
bright spark's bound to reinvent them!
You are, of course, right that this wouldn't be a CMF only issue but I
think that it's something we should be thinking of once we have a
complete set of "experimental" browser views. <looks appropriately
>>>> from AccessControl import ClassSecurityInfo
>>>> from AccessControl.SecurityInfo import ClassSecurityInfo
>> I didn't realise this counts as a relative import but I'm all in
>> favour of spelling things out.
> That one isn't relative: it is just another "façade" import.
Façade imports are where classes and modules are populated through a
package's __init__.py or module?
Zope-CMF maillist - Zope-CMF@lists.zope.org
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests