Thanks Massimo, the AlterEgo posting makes the case for exec and the
capitalized helper class names clearly and persuasively! I agree with
Anthony that it belongs in the book.
I was never much bothered by either of those issues, but there is one
bit of 'magic' that did (and to some extent still does) confuse me.
I'm wondering if it might be worthwhile to give an detailed
explanation what goes on in form.accepts().
When I first saw the idiom
if form.accepts():
...
return dict(form=form)
my assumption was that the call to form.accepts() was somehow
rendering and transmitting the page and waiting for a user response.
But then, I wondered how that could be since the form isn't passed to
the view until the return() is executed. Then I tried tracing a
controller and saw that it was being called multiple times. I got
lost down in the gluon code and more or less gave up trying to find
out exactly how the rabbit gets into the hat. Now I just use it and
trust that it works, but it still bothers me not to know what's going
on under the hood.
On Sep 16, 8:58 am, mdipierro <[email protected]> wrote:
> 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
