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

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

yuppie wrote:
> 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.

Sounds fine.

>>> 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?

I think we could put your fix in on the Zope 2.10 and 2.11 branches, as
well as on my no_globals_imports branch.  I'm not ready to commit to the
other cleanups right now.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJWS8t+gerLs4ltQ4RAqivAKDKnh4CHnUT6ztd1uFTMUpBedOgwQCfT1Ou
1tA0QihSVKrUHBvkxR/dPew=
=sDtT
-----END PGP SIGNATURE-----