On 2/11/13 11:00 AM, Ed Leafe wrote: > On Feb 11, 2013, at 12:36 PM, Paul McNett <[email protected]> wrote: > >> The rationale is simply that we were loading way too many things upon >> someone issuing >> 'import dabo'. There's a class of users that use very specific things from >> the >> framework inside their web applications, such as only using the biz and data >> layer, >> but no dApp and no UI, or only using the report writer and nothing else. >> Rather than >> importing everything everyone would possibly need in 'import dabo', we >> should make >> things available via explicit import via subpackages. > > I think the question is more accurately phrased "what harm was there in > importing those things?"
The harm from the POV of the web application was that it it would take longer to 'import dabo'. Since web applications are stateless they must normally do this import with each hit. And since web applications aren't necessarily going to need the stuff we were importing up front, it made sense to hold the importing until explicitly asked for. > Do you see performance improvements? Lower memory requirements? I see a rough speedup of 5-12.5x of 'import dabo' (.20-.25 sec versus .02-.04 sec). Of course my desktop application code eventually explicitly imports the stuff that dabo used to import up front, though, so overall there isn't a gain for my desktop applications. > I thought that namespaces were managed by dicts, and that they were all > pointers to each other, so having, say, dabo.dApp defined doesn't take up any > significant memory over not adding it to the namespace. That's my understanding as well. But look at all the stuff that dApp.py imports. Let's not do that until and unless it's needed is all I'm say'n. Paul _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/[email protected]
