On 12/20/12 8:32 AM, Paul McNett wrote: > It wasn't that 'import *' is too objectionable but rather the sheer number of > names > that wound up in dabo's namespace. The reason for these changes is to allow a > web app > to import and use the reportwriter at runtime without spending cycles loading > unneeded things (dabo.db, dabo.biz, dabo.ui, dabo.dApp). During my process of > widdling down the imports I got annoyed by all the names in dir(dabo) and > thought > that reading our code would be easier with an explicit settings namespace.
I'm going to retreat on the settings changes with my tail between my legs because of potential breakage in user applications. I have it all working and tested in the dabo codebase and in my code, however there's no good way to flip over to using the settings namespace gently. Not without hacking sys.__modules__, as far as I can see. The issue is that user code could be setting or getting dabo settings attributes at runtime using for example 'dabo.dateFormat = "%x"' and they'd need to change that to 'dabo.settings.dateFormat = "%x"' immediately upon this commit which isn't cool, especially since the problem would be silent. I went through all my code and none of it gets or sets dabo settings at runtime, but I can't guarantee the change won't affect others, and it doesn't really fix anything, so I'll be committing my big commit sans the settings changes sometime in the next few days hopefully. Paul _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/dabo-dev Searchable Archives: http://leafe.com/archives/search/dabo-dev This message: http://leafe.com/archives/byMID/[email protected]
