Lately, I've gotten to liking using fake namespaces when it comes to certain Zope things, particularly Permissions and Meta Types. I got the idea from Zope 3, whose core permissions include elements like "zope.Public", and am applying it to a current consulting project. All the permissions and meta types registered have a customer specific prefix (lower case). Two benefits of this -- (1) I ensure that at deployment time, there are no conflicting/confusing product names in the add list - if two customers have different Artifact objects, they're identified as such; (2) It groups application/customer specific objects and permissions together in the management screens. This is very nice, especially as security and permissions are often a key feature in getting contracts.
Another habit I've gotten into (and am expanding upon) is stronger use of constants, particularly for Permission names, but also for status values and other things of interest where I don't want to run into a typo. We started using permission constants in the CMF quite a while back now, and Zope itself picked up on this too. We now have the AccessControl.Permissions module, allowing a Product developer to use security.declareProtected(Permissions.view, 'example_method'). Not only does this look a bit better, but it helps protect against issues with typos in the permission name, allowing them to be caught at import time instead of weeks later (ie - catching the difference between "Access Content Information" and "Access Contents Information"). This is useful in one's own projects as well. I like to keep mine local to the module containing the content object I'm working on. Now that I'm trying this simple namespaces experiment, it makes it even better. And this leads to clearer product initialization code, like the following:
import customer
def initialize(context):
context.registerClass(
customer.Customer,
permission=customer.AddCustomer,
constructors=(customer.manage_addCustomerForm,
customer.manage_addCustomer,),
)