[Zope-CMF] SVN: Products.CMFDefault/trunk/Products/CMFDefault/__init__.py Move clashing imports into body of initialize().

[yuppie]

Hi Tres!


Tres Seaver wrote:
> yuppie wrote:
> 
>> Tres Seaver wrote:
>>> Log message for revision 94389:
>>>   Move clashing imports into body of initialize().
>>>
>>> Changed:
>>>   U   Products.CMFDefault/trunk/Products/CMFDefault/__init__.py
>> What are "clashing imports"? Can't they be fixed in an other way? I'd 
>> prefer to have less code in initialize(), not more.
> 
> Importing anything at module scope in the __init__ can shadow the
> "proper" import paths.  I would rather do *nothing* at import time, and
> then do any necessary imports inside the 'initialize', i.e., as late as
> possible.  An alternative would be to import 'initialize' itself from
> another module.

Well. The initialize() pattern is Zope 2 Products specific. I'm fine 
with moving everything that isn't useful outside initialize() into that 
function.

But some imports in __init__ have (also) a different purpose: They make 
sure security is initialized correctly. Moving those imports inside 
initialize() makes it less predictable when security is initialized.

>> Running CMF trunk tests with Zope 2.10, I now get random test-module 
>> import failures like this one:
>>
[...]
>>
>> Digging a bit deeper, I found a circular import in Zope that causes 
>> these failures:
> 
> My bad:  I hadn't tested with non-trunk Zopes.  We might get away with
> saying that CMF 2.2 requires at least Zope 2.11, but I think they would
> break there too.

Yes. I see the same issue with Zope 2.11.

I propose to fix this in Zope 2.10 and 2.11. And to make the latest 
Version of Zope 2.10 or 2.11 required for CMF 2.2.

>> AccessControl.Permission uses ApplicationDefaultPermissions defined in 
>> App.class_init and App.class_init imports AccessControl.Permission.
>>
>> AFAICS moving ApplicationDefaultPermissions to AccessControl.Permission 
>> would be the best way to fix this.
> 
> Yes, there is a bunch of stuff in App which doesn't belong there.
> Unmasking it (by ripping out the imports from Globals) was a first step
> to moving it into the right location.

Do you want to change that as part of your Zope refactoring or should I 
check in my fix?


Cheers,

	Yuppie