:-) those kind of optimizations like the exec one could eventually make sense on embedded.
eventually one day when web2py will have to run on embedded we will take care of that :-) 2010/9/16 mdipierro <[email protected]>: > I should also stress another major upside of exec. All the other > frameworks, Flask and Django for example, do not do exec but reload > modules when the file change. This allows to see changes in the code > reflected immediately in the app and mimics the exec. > > First of all this works only when they run with the built-in python > web server, not when in production with apache for example. In that > case they may get inconsistent behavior is a file changes and apache > serves some requests from an existing process and others from a new > process. Yet they will tell you that you should not edit your file in > production. Doh! > > The Python documentations when describing the "reload" keyword, says > that reloading modules is dangerous. In fact, if a module defines a > global object (and they do) and there are references to it, you may > end up up inconsistent references and memory leaks. The exec mechanism > protects us from this and web2py never had any memory leak or > inconsistent references. > > On Sep 16, 7:49 am, mdipierro <[email protected]> wrote: >> One downside of using exec is, theoretically, performance penalty >> since code has to be interpreted at every request. In practice we have >> not seen a measurable performance penalty because the time to >> interpret the code is less than the time to execute it. >> >> On Sep 16, 1:36 am, Anthony <[email protected]> wrote: >> >> > Nice. This is very helpful. How do we find this again (without digging >> > up this message) -- I don't think I see this posting in the AlterEgo >> > listing (http://web2py.com/AlterEgo)? >> >> > I think the stuff about exec probably belongs in the book. My >> > understanding is that exec also enables all of the web2py globals to >> > be available everywhere without requiring lots of imports and object >> > passing. If that's the case, maybe point that out too (is that the >> > "ease of use" reference?). >> >> > Also, a lot of web2py detractors complain about exec/eval being "bad," >> > but they never say why. Is the main concern the possible security risk >> > of executing user input (which wouldn't apply to web2py since it only >> > uses exec in the framework layer)? Are there any other reasons exec >> > would be bad (Armin expressed some concerns a while back >> > --http://groups.google.com/group/web2py/msg/1771226ba4a72cc0)? >> >> > Anthony >> >> > On Sep 16, 1:11 am, mdipierro <[email protected]> wrote: >> >> > >http://web2py.com/AlterEgo/default/show/271 >> >>
