On 25 avr, 20:44, mart <msenecal...@gmail.com> wrote: > how cool! so if all looks good, will we need to make a switch or will > both be supported for a while? > > Thanks, > Mart :)
The new import function changes how things are loaded when a module is imported from models, controllers or modules (the "modules" directory). If you do "import x" it will try transparently to do "import applications.your_app.modules.x". If it does not work, it will fall back on the traditional Python way of importing things. This new import enables to have different modules or packages that are dependent on one or another in the "modules" folder. Before that, the developer was force to modify the modules to use local_import instead or import or from this import that. A second good thing is that if app A uses x in 'modules' and app B uses a different version of x in 'modules', the two versions will work without collision. The down side is that import x for app A does import x under the module name "applications.A.modules.x" and for the app B it is of course "applications.B.modules.x" so if the developer is expecting to have a module named "x" in sys.modules, he will have a bad surprise. But it is very small inconvenient I believe. It is small design tread off. local_import still work like before and it enables modules to be easily reloaded. But we can now use a standard import. This is now available in trunk. Cool?
